Unicode制御文字

多くのUnicode文字はテキストの解釈や表示を制御するために使用されますが、これらの文字自体には視覚的または空間的な表現はありません。たとえば、ヌル文字( U+0000  NULL ) は、C プログラミング アプリケーション環境で文字列の終了を示すために使用されます。このように、これらのプログラムでは、文字列の開始メモリ アドレスが 1 つだけ必要になります(開始アドレスと長さは不要)。これは、プログラムがヌル文字を読み取った時点で文字列が終了するためです。

最も狭義には、制御コードとは一般カテゴリ に属する文字であり、 C0 および C1 制御コードCcで構成されます。この概念はISO/IEC 2022で定義され、Unicode に継承されています。最も一般的なセットはISO/IEC 6429で定義されています。制御コードは、文字名が割り当てられないなど、通常の Unicode 文字とは区別して扱われます (ただし、規範的な正式な別名は割り当てられています)。^{[1]広義には、}双方向テキストで使用される文字など、その他の非印刷書式文字もソフトウェアによって制御文字と呼ばれます。 ^[2]これらは主に一般カテゴリ(書式) に割り当てられ、Unicode 自体によって導入および定義された書式エフェクタに使用されます。 Cf

制御コード範囲 0x00～0x1F ("C0") および 0x7F は、1967 年版のUS-ASCIIに由来します。標準ISO/IEC 2022 (ECMA-35) は、ASCII の拡張方式を定義しており、これには 0x80～0x9F の 8 ビット制御コードの二次的な "C1" 範囲が含まれます。これは、バイト 0x40～0x5F のESCの 7 ビット シーケンスに相当します。これらの範囲のコードは、総称してC0 および C1 制御コードと呼ばれます。ISO/IEC 2022 では、これらの制御コードの異なる解釈を指定する複数の制御コード セットの存在が許可されていますが、最も一般的な解釈はISO/IEC 6429 (ECMA-48)で指定されています。

ISO /IEC 8859シリーズのエンコーディングは、8 ビット文字エンコーディング用に設計された ISO/IEC 2022 のサブセットである ISO/IEC 4873 (ECMA-43) レベル 1 に準拠しており、そのため 0x80～0x9F の範囲は ISO/IEC 6429 などの C1 制御コード セットによる非印刷コードとして使用するために予約されています。 ^[3] Unicode は、ASCII およびISO/IEC 8859-1から最初のブロックと2 番目のブロック (U+0000 から U+00FF まで) を継承しているため、C0 および C1 制御コード範囲 (U+0000～U+001F、U+007F～U+009F) が一般カテゴリ「Cc」として組み込まれています。これらの制御コードには規範的な名前は割り当てられていませんが、規範的な別名は割り当てられています。^[1]

カテゴリ「Cc」の制御コードは、フォーマットエフェクタに限らず、さまざまな目的に使用できます。たとえば、デフォルトのASCII C0セットには、6つのフォーマットエフェクタ（BS、HT、LF、VT、FF、CR）、10の転送制御、4つのデバイス制御、4つの情報セパレータ、および8つのその他の制御コードが含まれています。^[4]これらの文字のほとんどは、Unicodeテキスト処理で明確な役割を果たさず、端末エミュレータで使用されるような高レベルのプロトコルでのみ使用されます。特定の文字は、フォーマットやセンチネルの目的 でよく使用されます。

• U+0000  NULL (ヌル終端文字列で使用)
• U+0009 水平タブ (HT) (タブキーで挿入)
• U+000A  LINE FEED (LF) （改行として使用）
• U+000C  FORM FEED (FF) (プレーンテキストファイル内の改ページを示す)
• U+000D キャリッジリターン (CR) (一部の改行規則で使用)
• U+0085 次の行 (NEL) ( EBCDICから変換されたテキストの改行として使用されることがある)

Unicode は、U+0009—U+000D、U+001C—U+001F、およびU+0085 ( BSを除く ASCII フォーマットエフェクタ、および ASCII 情報セパレータと C1 NEL ) の意味のみを規定しています。残りの "Cc" 制御コードは Unicode に対して透過的であり、その意味は上位レベルのプロトコルに委ねられていますが、ISO/IEC 6429 で定義されている解釈がデフォルトとして提案されています。^{[5]さらに、トランスコードされた}Teletextなどの特定の特殊な上位レベルのプロトコルでは、 C0 制御コード範囲全体の異なる解釈が含まれる場合があります。 ^[6]

レガシーテキストで使用されるいくつかの改行文字を簡素化する試みとして^{[引用が必要]}、Unicode は行または段落を区切るための独自の改行文字を導入しています。U +2028 LINE SEPARATOR (略称 LS または LSEP) とU+2029 PARAGRAPH SEPARATOR (略称 PS または PSEP) です。

CR や LF と同様に、LS と PS はテキスト書式設定のエフェクタです。CR や LF とは異なり、これらはECMA-35 / ECMA-48の目的 (カテゴリ) では「制御コード」として扱われず、Unicode 自体によって完全に定義されたセマンティクスを持ちます。これらは、特定の空白文字に使用される主要カテゴリ(区切り文字)の下で、それぞれ独自のUnicode カテゴリCcと に割り当てられます。 ZlZpZ

Unicode には、以前は言語タグとして使用されていたが現在は非推奨となっている 128 文字が含まれています。これらの文字は基本的に 128 個の ASCII 文字を反映していますが、BCP 47に従って後続のテキストが特定の言語に属するものとして識別するために使用されていました。たとえば、後続のテキストが米国で書かれた英語の変形であることを示すには、U +E0001 LANGUAGE TAG、U+E0065 TAG LATIN SMALL LETTER E 、 U +E006E TAG LATIN SMALL LETTER N 、 U+E002D TAG HYPHEN-MINUS、U+E0075 TAG LATIN SMALL LETTER UおよびU+E0073 TAG LATIN SMALL LETTER S というシーケンスが使用されていました。

これらの言語タグ文字は、それ自体は表示されません。ただし、テキスト処理や他の文字の表示に情報を提供します。たとえば、言語タグが韓国語を示している場合、Unihan 表意文字の表示では、タグが日本語を示している場合とは異なるグリフが使用される可能性があります。別の例として、10 進数字 0 から 9 の表示は、表示される言語に応じて異なる影響を受ける可能性があります。

タグ文字U+E0001 LANGUAGE TAGおよびU+E007F CANCEL TAGはUnicode 5.1 (2008) で非推奨となり、言語情報には使用すべきではありません。^[7]文字U+E0020 - U+E0073も非推奨となりましたが、Unicode 8.0 (2015) のリリースで復活しました。この変更は、「将来、タグ文字を言語タグを表す以外の目的で使用できるようにするため」に行われました。^[8] Unicode では、「プレーンテキスト ストリームでタグ文字を使用して言語タグを表すことは、テキストに関する言語情報を伝達するための非推奨のメカニズムのままです。」と述べています。 ^[8]

3 つの書式設定文字が行間注釈のサポートを提供します( U+FFF9 INTERLINEAR ANNOTATION ANCHOR、U+FFFA INTERLINEAR ANNOTATION SEPARATOR、U+FFFB INTERLINEAR ANNOTATION TERMINATOR )。これは、通常他のテキストの行間に表示される注釈を提供するために使用できます。Unicode では、このような注釈はリッチ テキストであるとみなされ、このような注釈には他のプロトコルを使用することが推奨されています。W3C Ruby マークアップ勧告は、より高度な行間注釈をサポートする代替プロトコルの例です。

Unicode は、特殊文字を使わずに標準的な双方向テキストをサポートします。つまり、Unicode 準拠のソフトウェアは、ヘブライ文字などの右から左に書く文字を、その文字のプロパティから単純に右から左に書く文字として表示する必要があります。同様に、Unicode は、左から右に書くテキストと右から左に書くテキストの混在を、特殊文字を使わずに処理します。たとえば、アラビア語 (“بسم الله”) (英語では「Bismillah」と訳されます) を英語のすぐ横に引用すると、アラビア語の文字は右から左に、ラテン文字は左から右に流れます。

しかし、左から右に書く文章が右から左に書く段落の冒頭で引用されている場合（またはその逆）は、方向性が正しく検出されない可能性があります。 ^[2]また、反対方向に流れる文章が階層的に埋め込まれている場合（英語の文章がアラビア語の文章を引用し、そのアラビア語の文章が英語の文章を引用している場合など）、双方向テキストのサポートはさらに複雑になります。他の状況でも複雑になることがあります。たとえば、著者が左から右に書く文字を上書きして右から左に流れるようにしたい場合などです。このような状況は非常にまれですが、Unicode では、埋め込まれた双方向テキストのレベルを最大 125 レベルまで制御するのに役立つ 12 個の文字を提供しています。^[9]

• U+061C ؜ アラビア文字マーク
• U+200E 左から右へのマーク
• U+200F 右から左へのマーク
• U+202A 左から右への埋め込み
• U+202B 右から左への埋め込み
• U+202C POP方向フォーマット
• U+202D 左から右へのオーバーライド
• U+202E 右から左へのオーバーライド
• U+2066 左から右への分離
• U+2067 右 から左への分離
• U+2068 最初の 強力な分離株
• U+2069 ポップ 方向分離

多くの文字は、コンテキストに応じて代替グリフにマップされます。たとえば、アラビア語とラテン語の筆記体文字は、文字が単語の最初の文字、最後の文字、中間の文字、または独立した文字であるかどうかに応じて、グリフを接続するために異なるグリフを置き換えます。これらのタイプのグリフの置き換えは、他の作成者の入力を必要とせずに、文字のコンテキストによって簡単に処理されます。作成者は、結合子や非結合子などの特殊用途の文字を使用して、通常は表示されないグリフの代替形式を強制することもできます。合字も同様の例で、リッチ テキスト属性として合字をオンまたはオフにするだけでグリフを置き換えることができます。

ただし、他のグリフの置換については、作成者の意図をテキストとともにエンコードする必要があり、文脈から判断できない場合があります。これは、歴史的に、または姓の表意文字として同じ文字に異なるグリフが使用されている、外字と呼ばれる文字/グリフの場合です。これは、グリフと文字を区別する際のグレーゾーンの 1 つです。姓が、その派生元の表意文字とわずかに異なる場合、それは単純なグリフの異体字ですか、それとも文字の異体字ですか。Unicode 3.2 および 4.0 では、文字セットに 256 の異体セレクターが含まれるようになったため、これらの結合マーク文字は、前の文字に対して 256 の可能な文字/グリフの異体字から選択できます。

Unicode は、制御ピクチャブロックでC0 制御コード(およびスペースと汎用改行)を表すためのグラフィック文字を提供します。これらは視覚的な表現であり、実際の制御コードそのものではありません。C1制御コードに相当する文字はありません。

• スペシャル（Unicode ブロック）
• ISO 2047