ユニバーサル文字セット文字

UnicodeコンソーシアムとISO/IEC JTC 1/SC 2 / WG 2 は、ユニバーサル コード化文字セットの文字リストを共同で作成しています。ユニバーサル コード化文字セットは、一般的にユニバーサル文字セット(略称 UCS、正式名称: ISO / IEC 10646) と呼ばれ、自然言語、数学、音楽、その他の分野で使用される個別の記号である文字を、機械が読み取り可能な一意のデータ値にマッピングする国際標準です。このマッピングを作成することにより、UCS はコンピュータソフトウェア ベンダーが相互運用し、 UCS でエンコードされたテキスト文字列をベンダー間で転送 (交換) できるようにします。これはユニバーサルマップであるため、複数の言語を同時に表すために使用できます。これにより、複数のレガシー文字エンコーディングを使用することによる混乱が回避されます。レガシー文字エンコーディングを使用すると、使用する文字エンコーディングに応じて同じコードのシーケンスが複数の解釈を持つ可能性があり、間違ったエンコーディングを選択すると文字化けが発生する可能性があります。

UCS の潜在的な容量は 100 万文字以上です。各 UCS 文字は抽象的にコード ポイントで表されます。コード ポイントは 0 から 1,114,111 までの整数 (1,114,112 = 2 ²⁰ + 2 ¹⁶ または17 × 2 ¹⁶ = 0x 110000 コード ポイント) で、テキスト処理ソフトウェアの内部ロジック内で各文字を表すために使用されます。2024 年 9 月にリリースされたUnicode 16.0 の時点で、これらのコード ポイントのうち 299,056 (27%) が割り当てられ、155,063 (14%) に文字が割り当てられ、137,468 (12%) が私的使用のために予約され、2,048 がサロゲートのメカニズムを有効にするために使用され、66 が非文字として指定され、残りの 815,056 (73%) は割り当てられていません。エンコードされた文字の数は次のように構成されています。

• 149,641 個のグラフィカル文字 (一部はグリフが表示されないが、グラフィカル文字としてカウントされます)
• 制御および書式設定用の 237 個の特殊文字。

ISO は、文字名からコード ポイントへの文字の基本的なマッピングを維持しています。多くの場合、文字とコード ポイントという用語は同じ意味で使用されます。ただし、区別されている場合、コード ポイントは文字の整数、つまり文字のアドレスを指します。一方、ISO/IEC 10646 の文字にはコード ポイントとその名前の組み合わせが含まれますが、Unicode では、ブロック、カテゴリ、スクリプト、方向性など、他の多くの便利なプロパティが文字セットに追加されています。

UCS に加えて、補足的なUnicode 標準(ISO との共同プロジェクトではなく、Unicode コンソーシアムの出版物) では、次のような実装の詳細が提供されています。

1. UCSと他の文字セット間のマッピング
2. 異なる言語の文字と文字列の異なる照合順序
3. 双方向テキストをレイアウトするためのアルゴリズム（「BiDiアルゴリズム」）。同じ行のテキストが左から右（「LTR」）と右から左（「RTL」）の間で切り替わる場合があります。
4. 大文字小文字変換アルゴリズム

コンピュータ ソフトウェアのエンド ユーザーは、物理キーボードや仮想文字パレットなどのさまざまな入力方法を使用して、これらの文字をプログラムに入力します。

UCSは、平面、ブロック、文字カテゴリ、文字プロパティなど、さまざまな方法で分類できます。^[1]

HTMLまたはXMLの数値文字参照は、 Universal Character Set / Unicodeコードポイントで文字を参照し、次の形式を使用します 。

&#んんんん;

または

&#xうーん;

ここで、nnnnは10 進形式のコード ポイント、hhhhは16 進形式のコード ポイントです。XMLドキュメントでは、x は小文字でなければなりません。nnnnまたはhhhh は任意の桁数で、先頭にゼロを含めることができます。hhhh は大文字と小文字を混在させることができますが、通常は大文字を使用します。

対照的に、文字エンティティ参照は、目的の文字を置換テキストとして持つエンティティの名前で文字を参照します。エンティティは、事前に定義されているか (マークアップ言語に組み込まれている)、文書型定義(DTD)で明示的に宣言されている必要があります。形式は、他のエンティティ参照と同じです。

&名前;

ここで、name はエンティティの大文字と小文字を区別する名前です。セミコロンは必須です。

Unicode と ISO はコード ポイントのセットを 17 のプレーンに分割し、各プレーンには 65536 個の異なる文字 (合計 1,114,112 個) を含めることができます。2024 年 (Unicode 16.0) 時点で、ISO と Unicode コンソーシアムは 17 プレーンのうち 7 つのプレーンにのみ文字とブロックを割り当てています。その他のプレーンは空のままで、将来の使用のために予約されています。

現在、ほとんどの文字は最初のプレーンである基本多言語プレーンに割り当てられています。基本多言語プレーンは 2オクテットだけでアドレス指定できるため、これはレガシー ソフトウェアの移行を容易にするためです。最初のプレーン以外の文字は、通常、非常に特殊な用途やまれな用途に使用されます。

各プレーンは、最後の 4 つの数字の前の 1 つまたは 2 つの16 進数字(0 ～ 9、A ～ F) の値に対応します。したがって、U+24321 はプレーン 2、U+4321 はプレーン 0 (暗黙的に U+04321 と読み取られます)、U+10A200 はプレーン 16 (16 進数の 10 = 10 進数の 16) になります。1 つのプレーン内では、コード ポイントの範囲は 16 進数の 0000 ～ FFFF で、最大 65536 個のコード ポイントが生成されます。プレーンは、コード ポイントをその範囲のサブセットに制限します。

Unicode は UCS にブロック プロパティを追加し、各プレーンをさらに個別のブロックに分割します。各ブロックは、「数学演算子」や「ヘブライ文字」などの用途別に文字をグループ化したものです。以前に割り当てられていないコード ポイントに文字を割り当てる場合、コンソーシアムは通常、類似の文字のブロック全体を割り当てます。たとえば、同じスクリプトに属するすべての文字や、同様の目的を持つすべての記号が 1 つのブロックに割り当てられます。コンソーシアムがブロックに追加の割り当てが必要であると予測した場合、ブロックは割り当てられていないコード ポイントまたは予約済みのコード ポイントを維持することもあります。

UCS の最初の 256 個のコード ポイントは、西洋世界で最も一般的な 8 ビット文字エンコーディングであるISO 8859-1のコード ポイントに対応しています。その結果、最初の 128 文字もASCIIと同一です。Unicode ではこれらをラテン スクリプト ブロックと呼んでいますが、これら 2 つのブロックにはラテン スクリプト以外で一般的に役立つ文字が多数含まれています。一般に、特定のブロック内のすべての文字が同じスクリプトである必要はなく、特定のスクリプトが複数の異なるブロックに出現することもあります。

Unicode は、すべての UCS 文字に一般カテゴリとサブカテゴリを割り当てます。一般カテゴリは、文字、マーク、数字、句読点、記号、または制御文字 (つまり、書式設定文字または非グラフィカル文字) です。

種類は次のとおりです:

• 現代、歴史的、古代の文字。2024年（Unicode 16.0）現在、UCSは世界中で使用されている、または使用されていた168の文字を識別しています。さらに多くの文字が、将来UCSに追加されるためにさまざまな承認段階にあります。^[2]
• 国際音声記号。UCS は、国際音声記号の文字にいくつかのブロック (300 文字以上) を割り当てています。
• 結合発音区別符号。UCS およびテキスト処理関連のアルゴリズムの設計において Unicode が考えた重要な進歩は、結合発音区別符号の導入でした。任意の文字と組み合わせることができるアクセントを提供することで、Unicode および UCS は必要な文字数を大幅に削減します。UCS には合成文字も含まれていますが、これらは主に UCS 内で非 Unicode テキスト処理システムをサポートしやすくするために含まれています。
• 句読点。UCS は、発音区別符号の統一に加え、スクリプト間で句読点を統一しようとしました。多くのスクリプトにも句読点が含まれていますが、その句読点が他のスクリプトで同様の意味を持たない場合もあります。
• シンボル。UCS には、数学、技術、幾何学、その他の多くのシンボルが含まれています。これにより、シンボリック グリフを提供するためにフォントを切り替えるのではなく、独自のコード ポイントまたは文字を持つ個別のシンボルが提供されます。
  • 通貨。
  • 文字のような記号。これらの記号は、 ℅などの多くの一般的なラテン文字の組み合わせのように見えます。Unicode では、文字のような記号の多くを互換文字として指定しています。これは通常、文字の合成シーケンスをグリフに置き換えることでプレーンテキストで使用できるためです。たとえば、文字の合成シーケンスc/oをグリフ℅に置き換えます。
  • 数値形式。数値形式は、主に、合成分数とローマ数字で構成されています。文字シーケンスを構成する他の領域と同様に、Unicode アプローチでは、文字を組み合わせて分数を構成する柔軟性を重視しています。この場合、分数を作成するには、数字と分数スラッシュ文字 (U+2044) を組み合わせます。このアプローチが提供する柔軟性の例として、UCS には 19 個の合成分数文字が含まれています。ただし、考えられる分数は無限にあります。合成文字を使用すると、無限の分数が 11 個の文字 (0 ～ 9 と分数スラッシュ) で処理されます。すべての合成分数のコード ポイントを含む文字セットはありません。理想的には、テキスト システムは、分数が合成分数の 1 つ ( ⅓など) であるか、合成文字シーケンス ( 1⁄3など) であるかに関係なく、分数に対して同じグリフを表示する必要があります。ただし、Web ブラウザーは通常、Unicode とテキスト処理に関してはそれほど洗練されていません。こうすることで、事前に合成された分数と結合シーケンス分数が互いに互換性のある状態で表示されるようになります。
  • 矢印。
  • 数学的な。
  • 幾何学的形状。
  • レガシーコンピューティング。
  • コントロール ピクチャさまざまなコントロール文字をグラフィカルに表現します。
  • ボックスの描画。
  • ブロック要素。
  • 点字パターン。
  • 光学文字認識。
  • 技術的な。
  • ディンバット。
  • その他の記号。
  • 絵文字。
  • 記号と絵文字。
  • 錬金術のシンボル。
  • ゲームピース（チェス、チェッカー、囲碁、サイコロ、ドミノ、麻雀、トランプなど）。
  • チェスのシンボル
  • 太玄景。
  • 易経の六十四卦のシンボル。
• CJK。中国、日本、韓国 (CJK)、台湾、ベトナム、タイの言語をサポートするための表意文字やその他の文字に専念しています。
  • 部首と画数。
  • 表意文字。UCS の大部分は、東アジアの言語で使用される表意文字に充てられています。これらの表意文字のグリフ表現は、それらを使用する言語によって異なっていますが、UCS はこれらの漢字を、 Unicode が Unihan (Unified Han) と呼ぶものに統一しています。Unihan では、テキスト レイアウト ソフトウェアは、使用可能なフォントとこれらの Unicode 文字と連携して、適切な言語に適切なグリフを生成する必要があります。これらの文字を統一しているにもかかわらず、UCS には依然として 97,000 を超える Unihan 表意文字が含まれています。
• 楽譜。
• デュプロヤン速記。
• サットン サインライティング。
• 互換文字。UCS のいくつかのブロックは、ほぼ完全に互換文字専用です。互換文字は、Unicode のように文字とグリフを区別しない従来のテキスト処理システムをサポートするために含まれている文字です。たとえば、多くのアラビア文字は、文字が単語の末尾に現れる場合と、文字が単語の先頭に現れる場合で異なるグリフで表されます。Unicode のアプローチでは、内部のマシン テキスト処理と保存を容易にするために、これらの文字を同じ文字にマッピングすることを推奨しています。このアプローチを補完するために、テキスト ソフトウェアは、文字のコンテキストに基づいて、文字を表示するための異なるグリフ バリアントを選択する必要があります。このような互換性の理由から、4,000 を超える文字が含まれています。
• 制御文字。
• サロゲート。UCS には、サロゲート コード ポイント ペア用に、基本多言語面 (BMP) に 2048 個のコード ポイントが含まれています。これらのサロゲートを組み合わせることで、2 つのサロゲート コード ポイントを使用して、他の 16 面の任意のコード ポイントに対処できます。これにより、UTF-16 などの 16 ビット エンコーディング内で 20.1 ビット UCS をエンコードするためのシンプルな組み込み方法が提供されます。このようにして、UTF-16 は、BMP 内の任意の文字を 1 つの 16 ビット ワードで表すことができます。BMP 外の文字は、サロゲート ペアを使用して 2 つの 16 ビット ワード (合計 4 オクテットまたはバイト) を使用してエンコードされます。
• 私的使用。コンソーシアムは、さまざまなコミュニティ、オペレーティング システム、フォント ベンダー内で文字を割り当てることができる、いくつかの私的使用のブロックとプレーンを提供します。
• 非文字。コンソーシアムは、特定のコードポイントに文字が割り当てられないことを保証し、これらを非文字コードポイントと呼んでいます。これには、U+FDD0..U+FDEFの範囲と、各プレーンの最後の2つのコードポイント（16進数のFFFEとFFFFで終わる）が含まれます。^[3]

Unicode は 10 万を超える文字をコード化します。そのほとんどは、線形テキストとして処理するためのグラフィムを表します。ただし、グラフィムを表さない文字や、グラフィムとして特別な処理を必要とする文字もあります。^{[4] [5]} ASCII 制御文字や従来のラウンドトリップ機能のために含まれている他の文字とは異なり、これらの他の特殊目的の文字は、プレーンテキストに重要な意味を与えます。

ゼロ幅結合文字やゼロ幅非結合文字など、一部の特殊文字はテキストのレイアウトを変更できますが、その他の特殊文字はテキストのレイアウトにはまったく影響しませんが、テキスト文字列の照合、一致、またはその他の処理方法に影響します。数学的不可視文字などのその他の特殊目的の文字は、通常、テキストのレンダリングには影響しませんが、高度なテキスト レイアウト ソフトウェアでは、それらの文字の周囲の間隔を微妙に調整する場合があります。

Unicode では、Unicode テキストをレンダリングする際のフォントとテキスト レイアウト ソフトウェア (または「エンジン」) の分担は指定されていません。OpenTypeやApple Advanced Typographyなどのより複雑なフォント形式では、文脈に応じたグリフの置換や配置が提供されるため、単純なテキスト レイアウト エンジンでは、グリフの選択と配置の決定をすべてフォントに頼る場合があります。同じ状況で、より複雑なエンジンでは、フォントの情報と独自のルールを組み合わせて、最適なレンダリングを実現する場合があります。Unicode 仕様のすべての推奨事項を実装するには、テキスト エンジンが、あらゆるレベルの高度なフォントに対応できるように準備されている必要があります。これは、文脈に応じた置換や配置のルールが一部のフォント形式では存在せず、その他の形式ではオプションであるためです。分数スラッシュがその一例です。複雑なフォントでは、分数スラッシュ文字がある場合に分数を作成するための配置ルールが提供される場合と提供されない場合がありますが、単純な形式のフォントでは提供されません。

バイト オーダー マーク(BOM) U+FEFF は、テキスト ファイルまたはストリームの先頭に表示される場合、エンコード形式とそのバイト オーダーを示します。

ストリームの最初のバイトが 0xFE で 2 番目のバイトが 0xFF の場合、それらのバイトは UTF-8 では無効であるため、ストリームのテキストは UTF-8 でエンコードされていない可能性があります。また、0xFE、0xFF を 16 ビットのリトル エンディアン ワードとして読み取ると U+FFFE になり、意味がないため、リトル エンディアンバイト オーダーでUTF-16である可能性も低いです。このシーケンスは、 UTF-32エンコードのどの配置でも意味をなさないため、要約すると、テキスト ストリームがビッグ エンディアンバイト オーダーで UTF-16 としてエンコードされていることを示すかなり信頼性の高い指標として機能します。逆に、最初の 2 バイトが 0xFF、0xFE の場合、16 ビットのリトル エンディアン値として読み取ると、バイトは予期される 0xFEFF バイト オーダー マークを生成するため、テキスト ストリームは UTF-16LE としてエンコードされていると想定できます。ただし、次の 2 バイトが両方とも 0x00 の場合、この仮定は疑わしくなります。つまり、テキストがヌル文字 (U+0000) で始まるか、正しいエンコードが実際には UTF-32LE であり、完全な 4 バイト シーケンス FF FE 00 00 が 1 つの文字 (BOM) であるかのいずれかです。

U+FEFF に対応する UTF-8 シーケンスは 0xEF、0xBB、0xBF です。このシーケンスは他の Unicode エンコード形式では意味を持たないため、そのストリームが UTF-8 としてエンコードされていることを示すために使用される場合があります。

Unicode 仕様では、テキスト ストリームでバイト オーダー マークを使用する必要はありません。さらに、エンコード形式を示す他の方法がすでに使用されている場合は、バイト オーダー マークを使用しないように規定されています。

目に見えない区切り文字 (U+2063) は、主に数学用で、i⁣j のような 2 次元インデックスのように句読点やスペースを省略できる文字間の区切り文字を提供します。目に見えない倍数 (U+2062) と関数適用 (U+2061) は、演算を示すグリフなしで項の乗算や関数の適用が暗示される数学テキストで役立ちます。Unicode 5.1 では、数学用の目に見えないプラス文字 (U+2064) も導入されており、これは整数の後に分数が続く場合、積ではなく和を表す必要があることを示している可能性があります。

分数スラッシュ文字（U+2044）は、Unicode標準では特別な動作をします：^[6]（セクション6.2、その他の句読点）

分数スラッシュを使用して構築された分数の標準形式は、1 つ以上の小数桁の任意のシーケンス (一般カテゴリ = Nd)、分数スラッシュ、1 つ以上の小数桁の任意のシーケンスと定義されます。このような分数は、¾などの単位で表示する必要があります。表示ソフトウェアが分数を単位にマッピングできない場合は、フォールバックとして単純な線形シーケンスとして表示することもできます (たとえば、3/4)。分数を前の数字から分離する場合は、適切な幅 (通常、細い、ゼロ幅など) を選択してスペースを使用できます。たとえば、1 +ゼロ幅スペース+ 3 +分数スラッシュ+ 4 は、 1¾と表示されます。

この Unicode 勧告に従うことで、テキスト処理システムはプレーン テキストのみから洗練されたシンボルを生成します。ここで、分数スラッシュ文字の存在は、レイアウト エンジンに、スラッシュの前後の連続するすべての数字から分数を合成するように指示します。実際には、フォントとレイアウト エンジン間の複雑な相互作用のため、結果はさまざまです。単純なテキスト レイアウト エンジンは、分数をまったく合成せず、代わりに Unicode フォールバック スキームで説明されているように、グリフを線形シーケンスとして描画する傾向があります。

より洗練されたレイアウト エンジンには、2 つの実際的な選択肢があります。Unicode の推奨事項に従うか、フォント自体の指示に従って分数を合成するかです。フォントの指示を無視することで、レイアウト エンジンは Unicode の推奨動作を保証できます。フォントの指示に従うことで、レイアウト エンジンは数字の配置と形状がその特定のフォントとその特定のサイズに合わせて調整されるため、より優れたタイポグラフィを実現できます。

フォントの指示に従うことの問題は、より単純なフォント形式では分数の合成動作を指定する方法がないことです。一方、より複雑な形式では、フォントに分数の合成動作を指定する必要がないため、多くのフォントでは指定されていません。複雑な形式のフォントのほとんどは、レイアウト エンジンに、1⁄2などのプレーン テキスト シーケンスを事前合成された½グリフに置き換えるように指示できます。しかし、それらの多くは分数を合成する指示を発行しないため、221⁄225などのプレーン テキスト文字列は22½25としてレンダリングされる可能性があります( ½は合成された分数ではなく、置き換えられた事前合成分数です)。このような問題に直面して、推奨される Unicode 動作に依存したい場合は、分数を合成することが知られているフォント、またはフォントに関係なく Unicode の推奨動作を生成することが知られているテキスト レイアウト ソフトウェアを選択する必要があります。

書字方向とは、Unicode 文字列内の文字の進行方向に関連して、ページ上にグリフが配置される方向です。英語および他のラテン文字の言語では、書字方向は左から右です。アラビア語やヘブライ語など、いくつかの主要な書字では、書字方向は右から左です。Unicode 仕様では、各文字に方向タイプを割り当てて、ページ上で文字のシーケンスをどのような順序で並べるかをテキスト プロセッサに通知します。

語彙文字 (つまり、文字) は通常、単一の書記体系に固有ですが、一部の記号と句読点は多くの書記体系で使用されます。Unicode は、方向タイプのみが異なる重複した記号をレパートリー内に作成することもできましたが、代わりにそれらを統合し、中立的な方向タイプを割り当てることを選択しました。これらの文字は、レンダリング時に隣接する文字から方向を取得します。これらの文字の一部には、右から左へのテキストで使用する場合にグリフを鏡像でレンダリングする必要があることを示す bidi-mirroredプロパティもあります。

中立文字のレンダリング時の方向タイプは、マークが方向変更の境界に配置されている場合、あいまいなままになることがあります。これに対処するために、Unicode には、強い方向性を持ち、グリフが関連付けられておらず、双方向テキストを処理しないシステムでは無視できる文字が含まれています。

• アラビア文字記号 (U+061C)
• 左から右へのマーク (U+200E)
• 右から左へのマーク (U+200F)

双方向中立文字を左から右のマークで囲むと、その文字は左から右の文字として動作するように強制され、右から左のマークで囲むと、右から左の文字として動作するように強制されます。これらの文字の動作については、Unicode の双方向アルゴリズムで詳しく説明されています。

Unicode は、複数の言語、複数の書記体系、さらには左から右または右から左に流れるテキストを、作成者の介入を最小限に抑えて処理できるように設計されていますが、双方向テキストの混合が複雑になり、作成者の制御がより必要になる特殊な状況もあります。このような状況では、Unicode には、右から左のテキスト内に左から右のテキストを複雑に埋め込むことや、その逆を制御するための 5 つの文字が含まれています。

• 左から右への埋め込み (U+202A)
• 右から左への埋め込み (U+202B)
• ポップ方向書式 (U+202C)
• 左から右へのオーバーライド (U+202D)
• 右から左へのオーバーライド (U+202E)
• 左から右への分離 (U+2066)
• 右から左への分離文字 (U+2067)
• 最初の強い分離株 (U+2068)
• ポップ方向分離 (U+2069)

• 行間注釈アンカー (U+FFF9)
• 行間注釈セパレータ (U+FFFA)
• 行間注釈終端子 (U+FFFB)

• プレフィックス付きフォーマットコントロール
  • アラビア数字記号 (U+0600)
  • アラビア語の記号サナ（U+0601）
  • アラビア語の脚注マーカー (U+0602)
  • アラビア語の手話サファ（U+0603）
  • アラビア語の手話サムバット（U+0604）
  • アラビア数字マーク (U+0605)
  • アラビア語のアーヤの終わり (U+06DD)
  • シリア語略語マーク(U+070F)
  • アラビアポンドマーク（U+0890）
  • アラビア語ピアストレマーク（U+0891）
  • カイティ数字記号 (U+110BD)
  • Kaith ナンバーサイン 上 (U+110CD)
• エジプトの象形文字
  • エジプト象形文字の垂直結合子 (U+13430)
  • エジプト象形文字水平結合子 (U+13431)
  • エジプトの象形文字を先頭に挿入 (U+13432)
  • エジプトの象形文字を下部に挿入 (U+13433)
  • エジプトの象形文字を上端に挿入 (U+13434)
  • エジプトの象形文字を下端に挿入 (U+13435)
  • エジプト象形文字オーバーレイ ミドル (U+13436)
  • エジプト象形文字の始まり部分 (U+13437)
  • エジプト象形文字の末尾部分 (U+13438)
  • エジプトの象形文字を中央に挿入 (U+13439)
  • エジプトの象形文字を上部に挿入 (U+1343A)
  • エジプトの象形文字が下部に挿入されています (U+1343B)
  • エジプト象形文字 囲み始め (U+1343C)
  • エジプト象形文字の終りの囲み (U+1343D)
  • エジプトの象形文字「壁で囲まれた囲いの始まり」 (U+1343E)
  • エジプトの象形文字の端の壁囲い (U+1343F)
• ブラーフミー
  • ブラーフミー数結合子 (U+1107F)
• ブラーフミー文字由来の死字形成（ヴィラマ文字および類似の発音区別符号）
  • デヴァナーガリー サイン ヴィラマ (U+094D)
  • ベンガル語の手話 ヴィラマ (U+09CD)
  • グルムキー文字ヴィラマ (U+0A4D)
  • グジャラート語のヴィラマ文字 (U+0ACD)
  • オリヤー文字ヴィラマ (U+0B4D)
  • タミル語のヴィラマ文字 (U+0BCD)
  • テルグ語手話ヴィラマ (U+0C4D)
  • カンナダ語手話ヴィラマ（U+0CCD）
  • マラヤーラム語記号垂直バー ヴィラマ (U+0D3B)
  • マラヤーラム語記号円形ヴィラマ (U+0D3C)
  • マラヤーラム語サイン ヴィラマ (U+0D4D)
  • シンハラ語サイン アルラクナ (U+0DCA)
  • タイ文字ピントゥ（U+0E3A）
  • タイ文字ヤマカン（U+0E4E）
  • ラオス手話 パーリ・ヴィラマ (U+0EBA)
  • ミャンマー手話 ヴィラマ (U+1039)
  • タガログ語手話 ヴィラマ (U+1714)
  • タガログ語記号パムドポッド (U+1715)
  • ハヌヌー サイン パムッドポッド (U+1734)
  • クメール文字 ヴィリアム (U+17D1)
  • クメール手話コエング（U+17D2）
  • タイ・タム・サイン・サコット（U+1A60）
  • タイ・タム・サイン・ラ・ハーム (U+1A7A)
  • バリ語のアデグ・アデグ（U+1B44）
  • スンダ語サイン パマアエ (U+1BAA)
  • スンダ サイン ヴィラマ (U+1BAB)
  • バタク・パンゴラット（U+1BF2）
  • バタク・パノンゴナン語 (U+1BF3)
  • シロティ ナグリ サイン ハサンタ (U+A806)
  • シロティ ナグリ サイン代替ハサンタ (U+A82C)
  • サウラーシュトラ サイン ヴィラマ (U+A8C4)
  • レジャン・ヴィラマ（U+A953）
  • ジャワ語パンコン（U+A9C0）
  • ミーテイ・マエク・ヴィラマ（U+AAF6）
  • カロシュティ・ヴィラマ（U+10A3F）
  • ブラーフミー・ヴィラーマ（U+11046）
  • ブラーフミー サイン オールド タミル ヴィラマ (U+11070)
  • カイティ文字ヴィラマ（U+110B9）
  • チャクマ・ヴィラマ（U+11133）
  • シャラダサインヴィラマ（U+111C0）
  • ホジキ文字ヴィラマ (U+11235)
  • クダワディ サイン ヴィラマ (U+112EA)
  • グランササインヴィラマ（U+1134D）
  • トゥル-ティガラリ サイン ヴィラマ (U+113CE)
  • トゥル - ティガラリ サイン ループ ヴィラマ (U+113CF)
  • トゥル語-ティガラリ語結合子 (U+113D0)
  • ネワサインヴィラマ（U+11442）
  • ティルフタ文字ヴィラマ（U+114C2）
  • シッダムサインヴィラマ（U+115BF）
  • モディサイン ヴィラマ (U+1163F)
  • タクリ文字ヴィラマ（U+116B6）
  • アホムサインキラー（U+1172B）
  • ドグラ文字ヴィラマ（U+11839）
  • ダイブ アクル サイン ハランタ (U+1193D)
  • アクル・ヴィラマのダイブ (U+1193E)
  • ナンディナガリ サイン ヴィラマ (U+119E0)
  • ザナバザル スクエアサイン ヴィラマ (U+11A34)
  • ザナバザール方陣サブジョイナー (U+11A47)
  • ソヨンボ語結合子 (U+11A99)
  • バイスキ サイン ヴィラマ (U+11C3F)
  • マサラム・ゴンディ・サイン・ハランタ (U+11D44)
  • マサラム・ゴンディ・ヴィラマ (U+11D45)
  • グンジャラ・ゴンディ・ヴィラマ (U+11D97)
  • カウイサインキラー（U+11F41）
  • カウィ結合子（U+11F42）
  • グルン ケマ サイン トルホーマ (U+1612F)
  • キラット・ライサイン・ヴィラマ(U+16D6B)
  • キラット・ライ・サイン・サート (U+16D6C)
• その他の機能を備えた歴史的なヴィラマ
  • チベット語のマーク・ハランタ（U+0F84）
  • ミャンマー手話アサット（U+103A）
  • リンブー文字サ-イ（U+193B）
  • ミーテイ・マイエク・アプン・イエク (U+ABED)
  • チャクマ・マーヤー（U+11134）
• モンゴル語の​​バリエーションセレクター
  • モンゴル語自由変形セレクター 1 (U+180B)
  • モンゴル語自由変形セレクター 2 (U+180C)
  • モンゴル語自由変形セレクター 3 (U+180D)
  • モンゴル語の​​母音区切り文字 (U+180E)
• 汎用バリエーションセレクター
  • バリエーションセレクター-1～-16 (U+FE00～U+FE0F)
  • バリエーションセレクター-17から-256 (U+E0100–U+E01EF)
• タグ文字 (U+E0001 および U+E0020～U+E007F)
• ティフィナ
  • ティフィナ子音ジョイナー (U+2D7F)
• オガム文字
  • オガムスペースマーク (U+1680)
• 表意文字
  • 表意文字の異体字表示 (U+303E)
  • 表意文字の説明 (U+2FF0–U+2FFB)
• 音楽フォーマット制御
  • 音楽記号 開始ビーム (U+1D173)
  • 音楽記号エンドビーム (U+1D174)
  • 音楽記号 始まりのタイ (U+1D175)
  • 音楽記号 エンドタイ (U+1D176)
  • 音楽記号 スラー開始 (U+1D177)
  • 音楽記号の終了スラー (U+1D178)
  • 音楽記号 フレーズ開始 (U+1D179)
  • 音楽記号終了フレーズ (U+1D17A)
• 短縮書式コントロール
  • 速記形式の文字の重なり (U+1BCA0)
  • 短縮形継続重複 (U+1BCA1)
  • 短縮形ダウンステップ（U+1BCA2）
  • 速記形式 上段 (U+1BCA3)
• 非推奨の代替書式
  • 対称スワッピングを禁止する (U+206A)
  • 対称スワッピングを有効にする (U+206B)
  • アラビア語のフォーム形成を禁止する (U+206C)
  • アラビア語フォームシェーピングを有効にする (U+206D)
  • 国別数字の形 (U+206E)
  • 名詞数字の形 (U+206F)

• オブジェクト置換文字 (U+FFFC)
• 置換文字 (U+FFFD)

「文字」という用語は明確に定義されておらず、ほとんどの場合、私たちが言及しているのはグラフィムです。 グラフィムは、グリフによって視覚的に表現されます。使用される書体(多くの場合、誤ってフォントと呼ばれます) は、同じ文字の視覚的なバリエーションを表すことができます。 2 つの異なるグラフィムがまったく同じグリフを持つことや、視覚的に非常に似ているため、平均的な読者がそれらを区別できない可能性があります。

書記素はほとんどの場合 1 つのコード ポイントで表されます。たとえば、ラテン大文字の A はコード ポイント U+0041 のみで表されます。

グラフィムLATIN CAPITAL A WITH DIAERESIS Äは、文字が複数のコード ポイントで表現できる例です。これは、U+00C4 または U+0041U+0308 になります。U+0041 はよく知られている A で、U+0308 はCOMBINING DIAERESIS ̈、つまり結合分音記号です。

結合マークが非結合マークのコードポイントに隣接している場合、テキストレンダリングアプリケーションは、一連の規則に従って、結合マークを他のコードポイントによって表されるグリフに重ね合わせて書記素を形成する必要があります。^[7]

したがって、BÄM という単語は 3 つの書記素になります。文字が実際にどのように構成されているかに応じて、3 つ以上のコード ポイントで構成される場合があります。

Unicodeは相互運用性のサポートのために空白文字とみなされる文字のリストを提供しています。ソフトウェア実装や他の標準では、この用語が若干異なる文字セットを表すために使用される場合があります。たとえば、JavaではU+00A0 NO-BREAK SPACEやU+0085 <control-0085>は空白文字とはみなされません。   Unicode では空白文字として扱われますが、Unicode では空白文字として扱われます。空白文字は、通常、プログラミング環境用に指定された文字です。多くの場合、そのようなプログラミング環境では構文上の意味を持たず、マシン インタープリタによって無視されます。Unicode では、従来の制御文字 U+0009 から U+000D および U+0085 を空白文字として指定し、さらに、一般カテゴリ プロパティ値が Separator であるすべての文字も空白文字として指定しています。Unicode 16.0 の時点では、合計 25 個の空白文字があります。

ゼロ幅ジョイナー(U+200D) とゼロ幅非ジョイナー(U+200C) は、グリフの結合と連結を制御します。ジョイナーは、本来は結合または連結されない文字を結合または連結させることはありません。ただし、非ジョイナーと組み合わせると、これらの文字を使用して、周囲の 2 つの結合または連結文字の結合および連結プロパティを制御できます。結合グラフィム ジョイナー (U+034F) は、2 つの基本文字を 1 つの共通の基本文字またはダイグラフとして区別するために使用され、主に基礎となるテキスト処理、文字列の照合、大文字と小文字の折りたたみなどに使用されます。

最も一般的な単語区切りはスペース (U+0020) です。ただし、単語間の区切りを示し、改行アルゴリズムに関与する単語結合子や区切り子は他にもあります。ノーブレーク スペース (U+00A0) もグリフなしでベースライン アドバンスを生成しますが、改行を可能にするのではなく、禁止します。ゼロ幅スペース (U+200B) は改行を可能にしますが、スペースは提供しません。つまり、2 つの単語を分離するのではなく、結合することになります。最後に、単語結合子 (U+2060) は改行を禁止し、ベースライン アドバンスによって生成される空白も一切含みません。

• 行区切り文字 (U+2028)
• 段落区切り文字 (U+2029)

これらは、キャリッジリターン (U+000A)、ラインフィード (U+000D)、次行 (U+0085) などの従来のエンコードされた ASCII 制御文字とは独立した、ネイティブの段落区切り文字と行区切り文字を Unicode に提供します。Unicode は、おそらく Unicode プレーンテキスト処理モデルの一部ではないその他の ASCII 書式制御文字を提供しません。これらの従来の書式制御文字には、タブ (U+0009)、行タブまたは垂直タブ (U+000B)、およびページ区切りとも考えられるフォームフィード (U+000C) が含まれます。

スペース文字 (U+0020) は、通常キーボードのスペース バーで入力され、多くの言語で意味的に単語の区切りとして機能します。レガシーな理由から、UCS には、スペース文字の互換性に相当するさまざまなサイズのスペースも含まれています。幅の異なるこれらのスペースはタイポグラフィでは重要ですが、Unicode 処理モデルでは、このような視覚効果はリッチ テキスト、マークアップ、その他のプロトコルで処理する必要があります。これらは主に、他の文字セット エンコーディングからのロスレス ラウンドトリップ トランスコーディングを処理するために Unicode レパートリーに含まれています。これらのスペースには次のものがあります。

1. エンクワッド (U+2000)
2. Em クワッド (U+2001)
3. エンスペース（U+2002）
4. Em スペース (U+2003)
5. 3 分の 1 スペース (U+2004)
6. 4 分の 1 スペース (U+2005)
7. 6 分の 1 スペース (U+2006)
8. 図形空間 (U+2007)
9. 句読点スペース (U+2008)
10. 薄い空間 (U+2009)
11. ヘアスペース（U+200A）
12. 中程度の数学空間 (U+205F)

元の ASCII スペースを除き、その他のスペースはすべて互換文字です。このコンテキストでは、これらのスペースはテキストに意味的な内容を実質的に追加せず、代わりにスタイル制御を提供することを意味します。Unicode では、この意味的ではないスタイル制御はリッチ テキストと呼ばれることが多く、Unicode の目標の範囲外です。異なるコンテキストで異なるスペースを使用するのではなく、このスタイルはインテリジェントなテキスト レイアウト ソフトウェアで処理する必要があります。

他の 3 つの表記体系固有の単語区切り文字は次のとおりです。

• モンゴル語の​​母音区切り文字 (U+180E)
• 表意文字スペース (U+3000): 表意文字の区切りとして動作し、通常は表意文字と同じ幅の空白としてレンダリングされます。
• オガムスペースマーク (U+1680): この文字はグリフ付きで表示される場合もあれば、空白のみで表示される場合もあります。

いくつかの文字は、改行を禁止したり (改行禁止文字)、ソフト ハイフン (U+00AD) (「シャイ ハイフン」と呼ばれることもあります) などの改行を提案したりすることで、改行を制御するように設計されています。このような文字は、スタイル設定のために設計されていますが、複雑な種類の改行を可能にするために不可欠であると考えられます。

ブレーク阻害

1. 非改行ハイフン (U+2011)
2. ノーブレークスペース (U+00A0)
3. チベットマークデリミタ Tsheg Bstar (U+0F0C)
4. 狭い改行禁止スペース (U+202F)

改行禁止文字は、Word Joiner U+2060 で囲まれた文字シーケンスと同等です。ただし、改行を許可する文字の前または後に Word Joiner を追加して、改行を禁止することができます。

ブレークを有効にする

1. ソフトハイフン (U+00AD)
2. チベットマーク音節間ツェグ (U+0F0B)
3. ゼロ幅スペース (U+200B)

改行禁止文字と改行可能文字は、他の句読点や空白文字と連携して、テキストイメージングシステムがUnicodeの改行アルゴリズム内で改行を判断できるようにします。^[8]

何らかの目的または用途が与えられたすべてのコード ポイントは、指定コード ポイントとみなされます。指定コード ポイントは、抽象文字に割り当てられたり、他の目的に指定されることがあります。

実際に使用されているコード ポイントの大部分は、抽象文字に割り当てられています。これには、Unicode 標準によって特定の目的のために正式に指定されていないものの、意味のある情報交換を行うため に送信者と受信者が事前にその解釈方法について合意しておく必要がある私用文字が含まれます。

UCS には 137,468 個の私的使用文字が含まれています。これらは私的使用のためのコード ポイントで、それぞれが私的使用領域(PUA) と呼ばれる 3 つの異なるブロックにまたがっています。Unicode 標準では、PUA 内のコード ポイントを正当な Unicode 文字コードとして認識しますが、それらに (抽象的な) 文字を割り当てることはありません。代わりに、個人、組織、ソフトウェア ベンダー、オペレーティング システム ベンダー、フォント ベンダー、およびエンド ユーザーのコミュニティが、必要に応じて自由に使用できます。クローズド システム内では、PUA 内の文字は明確に動作し、そのようなシステムは Unicode で定義されていない文字やグリフを表すことができます。^[9]パブリック システムでは、レジストリがなく、複数の組織が異なる目的で同じコード ポイントを採用するのを防ぐ方法がないため、それらの使用はより問題になります。このような競合の 1 つの例は、AppleがApple ロゴにU+F8FFを使用しているのに対し、ConScript Unicode レジストリはクリンゴン文字のクリンゴン ミイラ化グリフとして U+F8FF を使用しています。^[10]

基本多言語面 (第 0 面) には、同名の PUA私的使用領域に 6,400 個の私的使用文字が含まれており、範囲は U+E000 から U+F8FF です。私的使用面である第 15 面と第 16 面には、それぞれ 65,534 個の私的使用文字の PUA があります (各面の最後の 2 つのコード ポイントは非文字です)。これらは、 U+F0000 から U+FFFFD までの範囲の補助私的使用領域 Aと、U+100000 から U+10FFFD までの範囲の 補助私的使用領域 Bです。

PUA は、特定のアジアのエンコード システムから継承された概念です。これらのシステムには、日本語で外字(通常はフォントに含まれない珍しい文字) と呼ばれる文字をアプリケーション固有の方法でエンコードするための専用使用領域がありました。

UCS は、16 ビット以上のワード表現に頼らずに、初期の基本多言語面の外側の文字をアドレス指定するためにサロゲートを使用します。 ^[11] 1024 個の「高」サロゲート (D800～DBFF) と 1024 個の「低」サロゲート (DC00～DFFF) があります。サロゲートのペアを組み合わせることで、他のすべての面の残りの文字をアドレス指定できます (他の 16 面の 1024 × 1024 = 1048576 コード ポイント)。UTF -16では、常にペアで表示され、高サロゲートの後に低サロゲートが続くため、1 つのコード ポイントを表すのに 32 ビットが使用されます。

サロゲートペアはコードポイントを表す

10000 ₁₆ + ( H - D800 ₁₆ ) × 400 ₁₆ + ( L - DC00 ₁₆ )

ここでHとLはそれぞれ高サロゲートと低サロゲートの数値である。^[12]

DB80～DBFF の範囲の高サロゲート値は常に私的使用平面の値を生成するため、高サロゲート範囲は、さらに (通常の) 高サロゲート (D800～DB7F) と「高私的使用サロゲート」(DB80～DBFF) に分けられます。

孤立したサロゲートコードポイントには一般的な解釈がないため、この範囲の文字コード表や名前リストは提供されていません。Pythonプログラミング言語では、個々のサロゲートコードを使用して、Unicode文字列にデコードできないバイトを埋め込みます。^[13]

ハイフンなしの「非文字」という用語は、<not a character>内部使用のために恒久的に予約されている 66 個のコード ポイント ( というラベルが付けられている) を指し、したがって文字に割り当てられないことが保証されています。^[14] 17 のプレーンにはそれぞれ、非文字として末尾の 2 つのコード ポイントが確保されています。つまり、非文字は、BMP では U+FFFE と U+FFFF、プレーン 1 では U+1FFFE と U+1FFFF などとなり、プレーン 16 では U+10FFFE と U+10FFFF となり、合計 34 個のコード ポイントになります。さらに、BMP には、U+FDD0..U+FDEF という連続した範囲の別の 32 個の非文字コード ポイントがあります。ソフトウェア実装では、これらのコード ポイントを内部使用のために自由に使用できます。非文字の特に便利な例として、コード ポイント U+FFFE があります。このコード ポイントには、バイト オーダー マーク(U+FEFF)の逆 UTF-16/UCS-2 バイト シーケンスがあります。テキスト ストリームにこの非文字が含まれている場合、テキストが誤ったエンディアンで解釈されたことを示しています。

Unicode 標準のバージョン 3.1.0 から 6.3.0 では、非文字は「決して交換されるべきではない」と主張していました。標準の訂正 #9 では後に、これが「不適切な過剰拒否」につながっていると述べられ、「[非文字] は交換において違法ではなく、不正な Unicode テキストの原因にもならない」と明確にされ、元の主張は削除されました。

指定されていないその他のコード ポイントはすべて予約済みと呼ばれます。これらのコード ポイントは、Unicode 標準の将来のバージョンで特定の用途に割り当てられる可能性があります。

他の多くの文字セットでは、文字のあらゆる可能なグリフ表現に文字が割り当てられますが、Unicode では文字をグリフとは別に扱うようにしています。この区別は必ずしも明確ではありませんが、いくつかの例で区別がわかりやすくなります。多くの場合、テキストの読みやすさを向上させるために、2 つの文字が印刷上結合されます。たとえば、3 つの文字シーケンス「ffi」は、1 つのグリフとして扱われることがあります。他の文字セットでは、個々の文字「f」と「i」に加えて、このグリフにコード ポイントが割り当てられることがよくあります。

さらに、Unicode では、分音記号付き文字を個別の文字として扱い、レンダリングすると 1 つのグリフになります。たとえば、分音記号付きの「o」は「ö」です。従来、他の文字セットでは、各言語で使用される分音記号付き文字ごとに一意の文字コード ポイントが割り当てられていました。Unicode では、結合分音記号文字を任意の文字と組み合わせられるようにすることで、より柔軟なアプローチを実現しようとしています。これにより、文字セットに必要なアクティブ コード ポイントの数を大幅に削減できる可能性があります。たとえば、ラテン文字を使用し、分音記号を大文字と小文字の「a」、「o」、「u」と組み合わせる言語を考えてみましょう。Unicode のアプローチでは、ラテン文字「a」、「A」、「o」、「O」、「u」、「U」で使用するために、分音記号分音記号文字のみを文字セットに追加する必要があります。合計 7 文字です。レガシー文字セットでは、分音記号のない文字に使用する 6 つのコード ポイントに加えて、分音記号のある 6 つの 合成済み文字を追加する必要があります。つまり、合計 12 の文字コード ポイントになります。

UCS には、Unicode が互換文字として指定する数千の文字が含まれています。これらは、他の文字セットでは区別されるが、Unicode の文字アプローチでは区別されない文字に個別のコード ポイントを提供するために UCS に含まれた文字です。

この区別の主な理由は、Unicode が文字とグリフを区別していることです。たとえば、英語を筆記体で書く場合、文字「i」は、単語の先頭、単語の末尾、単語の途中、または単独で現れるかどうかによって、さまざまな形をとることがあります。アラビア文字で書かれたアラビア語などの言語は、常に筆記体です。各文字にはさまざまな形があります。UCS には 730 個のアラビア語フォーム文字が含まれており、これらは 88 個の固有のアラビア文字に分解されます。ただし、これらの追加のアラビア文字が含まれているのは、テキスト処理ソフトウェアが、非 Unicode ソフトウェアにとって重要な情報を失うことなく、テキストを他の文字セットから UCS に、またその逆に変換できるようにするためです。

ただし、特に UCS と Unicode の場合、その文字が単語内のどこに出現しても、常に同じ文字にエンコードまたはマップするアプローチが推奨されます。次に、各文字の個別の形式がフォントとテキスト レイアウト ソフトウェアの方法によって決定されます。この方法では、文字が単語内のどこに出現しても、文字の内部メモリは同じままです。これにより、検索、並べ替え、その他のテキスト処理操作が大幅に簡素化されます。

Unicode の文字はすべて、膨大なプロパティ セットによって定義され、その数は増え続けています。これらのプロパティのほとんどは、Universal Character Set の一部ではありません。これらのプロパティは、テキストの照合や並べ替え、単語、文、書記素の識別、テキストのレンダリングやイメージ化など、テキスト処理を容易にします。以下は、主要なプロパティの一部です。Unicode Character Database には、他にも多くのプロパティが文書化されています。^[15]

Unicodeは、さまざまなプロパティでUnicode文字レパートリー全体を対話的に検索するための オンラインデータベース^{[21]を提供しています。}

• ConScript Unicode レジストリ
• Unicode互換文字

• ユニコードコンソーシアム
• decodeunicode.org Unicode 5.0 の 98884 文字すべてを GIF 形式で収録した Unicode Wiki。全文検索も可能
• プロパティ別の Unicode 文字