1

テキストをマーク付きのブロックに分割するプロセッサに取り組んでいます。

LOREM IPSUM SED AMED

次のように解析されます。

{word:1}LOREM{/word:1}{space:2}
{word:3}IPSUM{/word:3}{space:4}
{word:5}SED{/word:5}{space:6}
{word:7}AMED{/word:7}

しかし、「{word}」などは使用したくありません。プロセッサがダウンするためです。これは文字列であるためです...次のようにマークする必要があります。

\E002\0001 LOREM \E003\0001 \E004\0002
\E002\0003 IPSUM \E003\0004 \E004\0005
\E002\0006 SED   \E003\0006 \E004\0007
\E002\0008 AMED  \E003\0008
  • 最初の \E002 は要素の種類番号を意味し、最後のビットは要素の終了を表します。したがって、要素番号は +2 で増加します。
  • 2 番目の \0001 は、スタックの要素インデックスを意味します。
  • この例では、\E002 を無関係に使用しています。

しかし、\0001 は Unicode 範囲でも使用されており、これにより、最初からやり直すことになります...

では、どのユニコード範囲を使用できますか? \ff0000? またはどうすればこれを解決できますか？

ありがとう！

4

1 に答える 1

1

Unicode コンソーシアムはこれについて考えました。表示可能な文字を表すのではなく、代わりにメタコードを表すことを意図した一連の Unicode コード ポイントがあります。

非文字は、永久に予約されているコード ポイントであり、文字が割り当てられることはありません。
...
タグ文字は、マークアップ言語などの他のメカニズムがない場合に、テキスト ストリームの内部タグ付けの一般的なスキームをサポートすることを目的としていました。言語のタグ付けにタグ文字を使用することは非推奨です。
( http://www.unicode.org/versions/Unicode9.0.0/ch23.pdf )

通常の制御文字を「プライベート」タグとして使用できるようにする必要があります。これは、これらが適切な文字列で発生しないためです。これは からU+0000までの範囲で、タブ ( )、一般的な「戻り値」 (および)、および安全のためにそれ自体U+001Fを除きます(一部のライブラリは、文字列の途中にある Null 文字を好まない)。U+0009U+000AU+000DU+0000

非文字 非文字
は、内部使用のために Unicode 標準で永続的に予約されているコード ポイントです。Unicode テキスト データのオープン インターチェンジでの使用は推奨されません。

U+FEFF(現在公式には Not-A-Character として定義されています)、 またはU+FFFEを使用できますU+FFFF。さらにいくつかの「公式に非文字」が定義されており、それらが通常のテキスト文字列では発生しないことはほぼ確実です。

事前定義された定義を持ついくつかのランダムなシーケンスは、プレーン テキスト文字列で発生する可能性が非常に低いため、次のとおりです。

Specials: U+FFF0–U+FFF8
U+FFF0..U+FFF8 の範囲の 9 つの割り当てられていない Unicode コード ポイントは、特殊文字の定義用に予約されています。

注釈文字: U+FFF9–U+FFFB 行間
注釈は、一連の注釈付き文字に関連する注釈付きテキストで構成されます。すべての通常の編集およびテキスト処理アルゴリズムでは、注釈付き文字はテキスト ストリームの一部として扱われます。注釈テキストもコンテンツの一部ですが、すべてまたは一部のテキスト処理では、メイン テキスト ストリームの一部を形成しません。

タグ文字: U+E0000–U+E007F
このブロックは、Unicode の通常のテキスト コンテンツ文字と厳密に分離できる文字を使用して、ASCII ベースの文字列タグのスペル アウトを可能にする 95 個の特殊用途のタグ文字のセットをエンコードします。
（上記の章からのすべての引用）

慣習に従って、U+2028(行区切り) やU+2029段落区切りを使用することもできます。

技術的には、U+E000–<code>U+F8FF (「私用領域」) の使用は問題ありません。これらのコード ポイントは、特定のfontと組み合わせて明確な文字を定義できるからです。ただし、フォントが含まれているソースからプレーン テキストを取得すると、これらのコードが表示される可能性があります。

これを文字列にエンコードする方法については、プライベート タグ マーカーの直後の数値コードが有効な Unicode 文字であるかどうかは問題ではありません。独自のタグ マーカーの 1 つが表示された場合、直後の値は常に独自のプライベート シーケンス番号です。

ご覧のとおり、多くの可能性があります。最も重要な基準は、これらの文字列に対して他の関数を使用するかどうかだと思います。技術的に無効な Unicode である文字列を作成した場合 (たとえば、文字以外の値が含まれているため)、一部の外部関数はそれらの処理に失敗したり、不適切な値を黙って削除したりすることがあります。そのような場合、「有効な」コード ポイントのみを使用するシステムに厳密に固執する必要があります。

于 2016-09-04T23:12:05.857 に答える