3

私は、クライアント側のエディターがサーバー側で知られている非常に大きなテキストを編集しているWebアプリケーションを持っています。

クライアントは、このテキストにあらゆる種類の変更を加えることができます。

サーバーが理解できる方法で結果の違いを送信するための最もネットワーク効率の良い方法は何ですか？また、これはクライアント側（Javascript）で発生するため、「高速」（または少なくとも目立って遅くない）にすることもできます。

いくつかのシナリオ：

  • ユーザーが1文字を変更する
  • ユーザーがランダムな位置でいくつかの文を変更する
  • ユーザーはすべてを消去し、空白のテキストになります。

ネットワーク効率が良くないため、diffのような構文を使用することはできません。行をチェックし、例1と3でひどい違いが生じます（特に最後の例では、結果が古いものよりも大きくなります）。

誰かがこの問題の経験がありますか？ユーザーは非常に大量のデータセット（約3〜5 MBのテキスト）を操作し、「新しい」コンテンツ全体をアップロードすることは大したことではありません。

明確にするために、私は転送の「プロトコル」を探しています。文字列の比較は問題ではありません。

4

5 に答える 5

3

私はこのトピックにあまり詳しくありませんが、非常に役立つ可能性のあるオープン ソース (Apache License 2.0) プロジェクトを紹介できます。

これは、Google のエンジニアが JavaScript を含む複数の言語で記述した Diff、Match、および Patch ライブラリであり、複数のオンライン共同編集サービスで使用されています。

リソースのリストは次のとおりです。

于 2009-10-16T05:59:19.613 に答える
1

サーバー上のコピーが変更されないことがわかっていると仮定すると、単純なアプローチは、編集 (削除と追加) のリストを送信することです。削除は開始インデックスと終了インデックスとして表され、追加は次のように表されます。開始インデックスと挿入するテキストとして。

使用する単純な差分アルゴリズム以上のものがある場合 (「文字列比較は問題ではない」という意味が正確にはわかりません)、移動またはコピーされたテキストのチャンクを検出し、それらを開始として送信することもできます。移動またはコピーされたテキスト部分の終了インデックス、および挿入先。

インデックスが元のドキュメントを参照しているか、これまでに編集されたドキュメントを参照しているかを追跡する必要があることに注意してください。この問題を回避する簡単な方法は、常にドキュメントの最後から最初に向かって編集を行うことです。以前の編集は、後の編集で指定されたオフセットに影響しません。

このようなアプローチの例については、出力のed形式を参照してください。これは基本的に、行指向のテキスト エディターdiff -eに入力できる入力です。絶対最小の差分を送信したい場合は、行ベースのインデックス作成ではなく文字ベースのインデックス作成を行うことができますが、同じ基本的なアプローチが機能します。ed

于 2009-10-16T04:45:35.540 に答える
0

500 ミリ秒ごとに変更を送信するだけでよいため、最後の 500 ミリ秒で行われた変更はすべて送信されますが、データは変更があった場合にのみ送信されます。

これで、変更された単語の位置を送信して単語全体を送信することができますが、位置はテキストの先頭からになります。

数文の価値はありませんが、いくつかの単語が含まれている可能性がありますが、変更順に送信すると、結果は一貫するはずです。

于 2009-10-16T04:58:17.707 に答える
0

ドキュメント内またはドキュメント外からのテキストの大きなセクションのドラッグ アンド ドロップ、カット アンド ペーストなど、 500 ミリ秒のような短い時間内であっても、編集を行う方法は非常に多いため、わかりません。すべてのシナリオを本当にうまくカバーする何かがあれば。これは確かにあなたの質問に対する額面通りの回答ではありませんが、インターフェイスを変更してテキスト サイズを制限し、既存のテキストを細かく分割することと比較して、このようなものを開発および維持する手間を慎重に検討します。

あなたの状況ではそれは不可能かもしれませんが、可能であれば、この方法で問題を回避し、編集後に完全なドキュメントを送信する方が、最終的にははるかに問題が少ないと思います.

于 2009-10-20T18:23:22.197 に答える