0

私は、ユーザーがテキスト記事で共同作業できるようにするアプリに取り組んでいます (通常、テキストの特定のスパンを強調表示/メモすることによって)。

ドキュメントを何らかの形式で提供する API を用意します (現在は .doc 形式ですが、Markdown などで配信したいと考えています)。記事の内容は変わらないと思います。

私は現在、これらのハイライトのエンコード形式にこだわっています。問題は、これらの記事にはいくつかの書式 (つまり、著者が別の外部記事から引用するブロック引用、および典型的な改行と段落間隔) があるため、クライアントはその書式をサーバーとは異なる方法で解釈することです。 .

たとえば、Markdown は引用符>内のコンテンツを表すために文字を使用しますが、HTML は文字を<blockquote>使用します。つまり、この場合、私の Javascript コードは、ユーザーが にあるテキストをハイライトしたときに<blockquote>、正しい文字オフセットを取得するために面倒な計算を行う必要があります。

最終的には、次のようにサーバー上で常に文字オフセットを操作したいと考えています。

// e.g.
// from the 55th character to the 58th character
// offset = [55, 3]

他のいくつかの方法を簡単に検討しました。

  • 記事を HTML でクライアントに送信しますが、HTML マークアップに CSS クラスなどを追加する必要があるため、同じ問題が発生します。
  • 記事のコンテンツを文字列の配列として送信し (記事の改行ごとに分割)、各項目にタイプを指定します (例: 'normal' または 'blockquote') - これはこの問題に取り組む単純な方法のようですが

私が見逃しているクライアントからのこれらのハイライトをエンコードする他のクリーンな方法はありますか?

EDIT：より明確にするために、これはクライアント側のアプリになります（最新のブラウザが必要です）。

4

1 に答える 1

1

これは難しい問題です。簡単な答えはありません。理想的には、さまざまな書式設定マークアップ言語で作業できるようにする、作業しやすい不変条件を考え出す必要があります。オフセットをドキュメント テキストに格納することをお勧めします (マークアップは無視します)。もちろん、エディタからテキスト オフセットを取得するのは簡単ではないかもしれません。ブラウザーで作業している場合、コンテンツは HTML になると思います。ブラウザーの選択オブジェクトからオフセットを取得することになりますが、これは理想的に必要なテキスト オフセットを提供しません。ただし、派手な XPath を使用して計算することはできます。そうした場合でも、ドキュメントを別の形式に変換すると、改行が変換または削除される可能性があるため、問題が発生する可能性があります。

答えは、いいえ、特効薬などありません。あなたは正しい道を進んでいます。

于 2013-03-05T04:32:20.097 に答える