Loading article…
Unicode ConsortiumとISO/IEC JTC 1/SC 2 / WG 2 は、Universal Coded Character Set の文字リストについて共同で作業しています。Universal Coded Character Set は、一般的にUniversal Character Set (略称: UCS、正式名称: ISO / IEC 10646) と呼ばれ、自然言語、数学、音楽、その他の分野で使用される文字、離散的な記号を、機械が読み取れる固有のデータ値にマッピングする国際標準です。このマッピングを作成することで、UCS はコンピュータ ソフトウェア ベンダーが相互運用し、UCS エンコードされたテキストストリングを相互に送信 (交換) できるようにします。これはユニバーサル マップであるため、複数の言語を同時に表現するために使用できます。これにより、複数の従来の文字エンコーディングを使用することによる混乱を回避できます。従来の文字エンコーディングを使用すると、同じコード シーケンスが使用する文字エンコーディングによって複数の解釈を持つ可能性があり、間違ったエンコーディングを選択すると文字化けが発生する場合があります。
UCS は 100 万文字を超える潜在容量を持っています。各 UCS 文字は、コード ポイント(0 から 1,114,111 までの整数、1,114,112 = 2 20 + 2 16または17 × 2 16 = 0x 110000コード ポイント) によって抽象的に表現され、テキスト処理ソフトウェアの内部ロジックで各文字を表すために使用されます。2025 年 9 月にリリースされたUnicode 17.0 の時点で、これらのコード ポイントのうち 303,808 (27%) が割り当てられ、159,866 (14%) に文字が割り当てられ、137,468 (12%) がプライベート使用のために予約され、2,048 がサロゲートのメカニズムを有効にするために使用され、66 が非文字として指定されており、残りの 810,304 (73%) は未割り当てとなっています。エンコードされた文字数は次のとおりです。
ISO は、文字名からコードポイントへの文字の基本的なマッピングを維持しています。多くの場合、文字とコードポイントという用語は互換的に使用されます。ただし、区別する場合、コードポイントは文字の整数、つまりアドレスと考えることができます。一方、ISO/IEC 10646 の文字には、コードポイントとその名前の組み合わせが含まれます。Unicode は、ブロック、カテゴリ、スクリプト、方向性など、文字セットに他の多くの便利なプロパティを追加します。
UCSに加えて、補足的なUnicode標準（ISOとの共同プロジェクトではなく、Unicodeコンソーシアムの出版物）では、次のような実装の詳細が提供されています。
コンピュータソフトウェアのエンドユーザーは、物理キーボードや仮想文字パレットなど、さまざまな入力方法を使用してこれらの文字をプログラムに入力します。
HTMLまたはXMLの数値文字参照は、Universal Character Set / Unicodeコードポイントによって文字を参照し、次の形式を使用します。
&#nnnn;または
&#xはぁぁぁ;ここで、nnnnは10 進数形式のコードポイント、hhhhは16 進数形式のコードポイントです。XML文書では、x は小文字でなければなりません。nnnnまたはhhhh は任意の桁数で、先頭にゼロを含めることができます。hhhh は大文字と小文字を混在させることができますが、通常は大文字を使用します。
一方、文字実体参照は、目的の文字を置換テキストとして持つ実体の名前で文字を参照します。この実体は、事前に定義されている（マークアップ言語に組み込まれている）か、文書型定義（DTD）で明示的に宣言されている必要があります。形式は、他の実体参照と同じです。
&名前;ここで、nameはエンティティの名称（大文字と小文字を区別します）です。セミコロンは必須です。
UnicodeとISOは、コードポイントのセットを17のプレーンに分割しており、各プレーンには65,536種類の文字、合計1,114,112文字を格納できます。2025年（Unicode 17.0）現在、ISOとUnicodeコンソーシアムは、17のプレーンのうち7つのプレーンにのみ文字とブロックを割り当てています。残りのプレーンは空のままで、将来の使用のために予約されています。
現在、ほとんどの文字は第1プレーン（基本多言語プレーン）に割り当てられています。これは、基本多言語プレーンがわずか2オクテットでアドレス指定できるため、既存ソフトウェアとの移行を容易にするためです。第1プレーン以外の文字は、通常、非常に特殊な用途またはまれな用途に使用されます。
各プレーンは、最後の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つのブロックには、ラテン文字以外でも一般的に使用される文字が多数含まれています。一般的に、特定のブロック内のすべての文字が同じ文字である必要はなく、1つの文字が複数の異なるブロックに存在することもあります。
Unicodeは、すべてのUCS文字に一般カテゴリとサブカテゴリを割り当てます。一般カテゴリは、文字、記号、数字、句読点、シンボル、制御文字（つまり、書式設定文字または非グラフィック文字）です。
種類には以下が含まれます。
Unicodeは10万文字以上をコード化しています。そのほとんどは、線形テキストとして処理するための文字素を表しています。しかし、文字素を表していないものや、文字素として特別な処理が必要なものもあります。 [ 4 ] [ 5 ] ASCII制御文字や従来の往復機能のために含まれている他の文字とは異なり、これらの特殊目的の文字はプレーンテキストに重要な意味を与えます。
ゼロ幅結合子やゼロ幅非結合子など、テキストのレイアウトを変更する特殊文字もあれば、テキストのレイアウトには全く影響せず、テキスト文字列の照合、マッチング、その他の処理方法に影響を与える特殊文字もあります。数学記号などの特殊用途文字は、一般的にテキストのレンダリングには影響しませんが、高度なテキストレイアウトソフトウェアでは、それらの文字の周囲の間隔を微妙に調整する場合があります。
Unicode では、Unicode テキストをレンダリングする際のフォントとテキストレイアウトソフトウェア (または「エンジン」) の役割分担は規定されていません。OpenTypeやApple Advanced Typographyなどのより複雑なフォント形式では、グリフのコンテキスト置換と配置が提供されるため、単純なテキストレイアウトエンジンは、グリフの選択と配置に関するすべての決定をフォントに完全に依存する可能性があります。同じ状況で、より複雑なエンジンは、フォントからの情報と独自のルールを組み合わせて、最適なレンダリングを実現する可能性があります。Unicode 仕様のすべての推奨事項を実装するには、テキストエンジンはあらゆるレベルの複雑さのフォントに対応できるように準備しておく必要があります。これは、コンテキスト置換と配置ルールが一部のフォント形式には存在せず、残りのフォント形式ではオプションであるためです。分数のスラッシュはその一例です。複雑なフォントでは、分数のスラッシュ文字が存在する場合に分数を作成するための配置ルールを提供する場合と提供しない場合がありますが、単純な形式のフォントでは提供できません。
テキストファイルまたはストリームの先頭に「U+FEFF ZERO WIDTH NO-BREAK SPACE」と表示される場合、エンコード形式とそのバイト順序を示します。
ストリームの最初のバイトが 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) は、ij のような二次元インデックスのように、句読点やスペースを省略できる文字間の区切り文字として機能します。非表示の掛け算 (U+2062) と関数適用 (U+2061) は、演算を示すグリフがなくても項の乗算や関数の適用が暗黙的に示される数学テキストで役立ちます。Unicode 5.1 では、整数の後に分数が続く場合、それらの和を表すが積は表さないことを示す数学用非表示プラス文字 (U+2064) も導入されています。
U +2044 ⁄分数スラッシュ文字は、Unicode 標準で特別な動作をします: [ 6 ]
分数スラッシュを使用して構築された分数の標準形式は、次のように定義されます。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では、方向タイプのみが異なる重複した記号をレパートリーに作成することもできましたが、代わりにそれらを統一し、中立的な方向タイプを割り当てることを選択しました。これらの記号は、レンダリング時に隣接する文字から方向を取得します。また、これらの記号の中には、右から左へのテキストで使用される場合にグリフが鏡像でレンダリングされることを示す双方向ミラーリング特性を持つものもあります。
中立文字のレンダリング時の方向性タイプは、マークが方向変化の境界に配置される場合に曖昧なままになることがあります。この問題を解決するために、Unicodeには、強い方向性を持ち、関連付けられたグリフがなく、双方向テキストを処理しないシステムでは無視できる文字が含まれています。
双方向中立文字を左から右へのマークで囲むと、その文字は左から右への文字として動作し、右から左へのマークで囲むと、右から左への文字として動作するように強制されます。これらの文字の動作については、Unicodeの双方向アルゴリズムに詳しく記載されています。
Unicodeは、複数の言語、複数の表記体系、さらには左から右、右から左のどちらの方向にも流れるテキストを、最小限の著者介入で処理できるように設計されていますが、双方向テキストの混在が複雑になり、著者によるより高度な制御が必要となる特別な状況も存在します。このような状況に対応するため、Unicodeには、右から左のテキスト内に左から右のテキストを、またその逆方向にも複雑に埋め込むことを制御する5つの文字が含まれています。
「文字」という用語は明確に定義されておらず、ほとんどの場合、私たちが指しているのは「文字素」です。文字素は、そのグリフによって視覚的に表現されます。使用される書体（しばしば誤ってフォントと呼ばれる）は、同じ文字の視覚的なバリエーションを表すことがあります。2つの異なる文字素が全く同じグリフを持つ場合や、平均的な読者が区別できないほど視覚的に似ている場合もあります。
文字はほぼ常に1つのコードポイントで表されます。たとえば、ラテン語の大文字「a」はコードポイントU+0041で表されます。
グラフィームU+00C4 Ä LATIN CAPITAL LETTER A WITH DIAERESISは、1 つの文字が複数のコード ポイントで表現できる例です。これは U+00C4 として表現することも、 U+0041 A LATIN CAPITAL LETTER 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 と、General Category プロパティ値が Separator であるすべての文字を空白文字として指定しています。Unicode 17.0の時点で、空白文字は合計 25 文字あります。
U+200Dゼロ幅ジョイナーとU+200Cゼロ幅非ジョイナーは、グリフの結合と連結を制御します。ジョイナーは、本来結合または連結されない文字を結合または連結させることはありません。しかし、非ジョイナーと組み合わせると、これらの文字を使用して、周囲の 2 つの結合または連結文字の結合および連結特性を制御できます。U +034F ͏結合グラフェムジョイナーは、主に基となるテキスト処理、文字列の照合、ケースフォールディングなどで、2 つの基本文字を 1 つの共通基本文字または二重字として区別するために使用されます。
最も一般的な単語区切り記号はU+0020 SPACEです。しかし、単語間の区切りを示し、改行アルゴリズムに関与する他の単語連結記号や単語区切り記号も存在します。U +00A0 NO-BREAK SPACEもグリフなしでベースラインを進めますが、改行を有効にするのではなく、むしろ抑制します。U +200B ZERO WIDTH SPACE は改行を許可しますが、スペースは提供しません。つまり、2 つの単語を分離するのではなく、結合するようなものです。最後に、U+2060 WORD JOINER は改行を抑制し、ベースラインを進めて生成される空白も一切含みません。
これらは、キャリッジリターン（U+000A）、ラインフィード（U+000D）、次行（U+0085）などの従来のエンコードされたASCII制御文字とは独立した、Unicodeのネイティブな段落区切り文字と行区切り文字を提供します。Unicodeは、おそらくUnicodeプレーンテキスト処理モデルの一部ではない他のASCII書式設定制御文字を提供していません。これらの従来の書式設定制御文字には、U+0009 <control-0009>が含まれます。(タブ)、U+000B <コントロール-000B>(垂直タブ)、およびフォームフィード (U+000C) は、ページ区切りとも考えられています。
キーボードのスペースバーで入力されるスペース文字（U+0020）は、多くの言語で単語区切り文字として意味的に機能します。互換性上の理由から、UCSにはスペース文字と互換性のあるさまざまなサイズのスペースも含まれています。これらの幅の異なるスペースはタイポグラフィにおいて重要ですが、Unicode処理モデルでは、このような視覚効果はリッチテキスト、マークアップ、その他のプロトコルで処理されることになっています。これらは主に、他の文字セットエンコーディングからのロスレス往復変換を処理するためにUnicodeレパートリーに含まれています。これらのスペースには以下が含まれます。
元のASCIIスペースを除き、その他のスペースはすべて互換文字です。この文脈では、これらのスペースはテキストに意味的な内容を付加するのではなく、スタイル制御を提供するものです。Unicodeでは、このような非意味的なスタイル制御はリッチテキストと呼ばれることが多く、Unicodeの目標の趣旨から外れています。異なる文脈で異なるスペースを使用するのではなく、このようなスタイルはインテリジェントなテキストレイアウトソフトウェアで処理されるべきです。
その他、文字体系固有の単語区切り記号として以下の3つがあります。
改行を抑制する（改行禁止文字）か、ソフトハイフン（U+00AD）（「シャイハイフン」とも呼ばれる）のように改行を示唆する文字など、改行を制御するために設計された文字がいくつかあります。これらの文字はスタイルのために設計されたものですが、複雑な改行を可能にするため、おそらく不可欠なものと言えるでしょう。
改行を禁止する文字は、ワードジョイナーU+2060で囲まれた文字シーケンスと同等のものとして扱われます。ただし、ワードジョイナーは、改行を禁止するために、改行を許可する文字の前後に追加することができます。
改行禁止文字と改行許可文字の両方が、他の句読点や空白文字と連携して、テキスト画像システムがUnicode改行アルゴリズム内で改行を判定できるようにします。[ 8 ]
何らかの目的や用途が与えられたコードポイントはすべて、指定コードポイントとみなされます。それらのコードポイントは、抽象文字に割り当てられることもあれば、その他の目的のために指定されることもあります。
実際に使用されているコードポイントの大部分は、抽象文字に割り当てられています。これには、Unicode規格で特定の用途に正式に指定されていないものの、意味のある情報交換を行うためには、送信者と受信者が事前にその解釈方法について合意しておく必要がある私的使用文字も含まれます。
UCSには137,468個のプライベート使用文字が含まれており、これらは3つの異なるブロックに分散されたプライベート使用用のコードポイントで、それぞれがプライベート使用領域（PUA）と呼ばれます。Unicode標準は、PUA内のコードポイントを正当なUnicode文字コードとして認識しますが、それらに（抽象的な）文字を割り当てません。その代わりに、個人、組織、ソフトウェアベンダー、オペレーティングシステムベンダー、フォントベンダー、エンドユーザーのコミュニティは、それらを自由に使用できます。クローズドシステム内では、PUA内の文字は曖昧さなく動作できるため、そのようなシステムはUnicodeで定義されていない文字やグリフを表現できます。[ 9 ]パブリックシステムでは、レジストリがなく、複数の組織が同じコードポイントを異なる目的で採用することを防ぐ方法がないため、その使用はより問題になります。このような競合の1つは、AppleがAppleロゴにU+F8FFを使用しているのに対し、ConScript Unicode Registryがクリンゴン文字のクリンゴンミイラ化グリフとしてU+F8FFを使用していることです。[ 10 ]
基本多言語プレーン（プレーン0）には、同名のPUAプライベート使用領域に6,400のプライベートユーザー文字が含まれており、その範囲はU+E000からU+F8FFです。プライベート使用プレーンであるプレーン15とプレーン16は、それぞれ独自のPUAを持ち、65,534のプライベート使用文字が含まれています（各プレーンの最後の2つのコードポイントは非文字です）。これらは、U+F0000からU+FFFFDの範囲の補足プライベート使用領域Aと、U+100000からU+10FFFDの範囲の補足プライベート使用領域Bです。
PUA（プライベート使用領域）は、特定のアジア系エンコーディングシステムから受け継がれた概念です。これらのシステムには、日本語で「外字」（通常フォントには含まれない珍しい文字）と呼ばれるものをアプリケーション固有の方法でエンコードするためのプライベート使用領域がありました。
UCS は、16 ビットを超えるワード表現に頼ることなく、初期の基本多言語プレーン外の文字をアドレス指定するためにサロゲートを使用します。 [ 11 ] 1024 個の「高」サロゲート (D800–DBFF) と 1024 個の「低」サロゲート (DC00–DFFF) があります。一対のサロゲートを組み合わせることで、他のすべてのプレーンの残りの文字をアドレス指定できます (1024 × 1024 = 他の 16 プレーンの 1,048,576 コード ポイント)。UTF -16では、高サロゲートの後に低サロゲートが続く形で常にペアで出現する必要があり、1 つのコード ポイントを表すために 32 ビットを使用します。
サロゲートペアはコードポイントを表します
ここで、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 には、アラビア語プレゼンテーション形式 A : U+FDD0..U+FDEF に位置する、別の 32 個の非文字コード ポイントの連続した範囲があります。ソフトウェア実装は、これらのコード ポイントを内部使用のために自由に使用できます。非文字の特に便利な例の 1 つは、コード ポイント 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 では、発音記号付きの文字を個別の文字として扱い、レンダリング時に単一のグリフとして扱います。たとえば、発音記号付きの「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の固有のアラビア文字に分解されます。ただし、これらの追加のアラビア文字が含まれているのは、テキスト処理ソフトウェアが、他の文字セットからUCSにテキストを変換したり、非Unicodeソフトウェアにとって重要な情報を失うことなくUCSからテキストを変換したりできるようにするためです。
しかし、特にUCSとUnicodeにおいては、単語内のどこに文字が現れても、常に同じ文字にエンコードまたはマッピングするのが望ましい方法です。そして、各文字の具体的な形状は、フォントとテキストレイアウトソフトウェアによって決定されます。このようにすることで、文字が単語内のどこに現れても、文字の内部メモリは同一のままになります。これにより、検索、ソート、その他のテキスト処理操作が大幅に簡素化されます。
Unicode のすべての文字は、膨大かつ増え続けるプロパティのセットによって定義されます。これらのプロパティのほとんどは、ユニバーサル文字セットの一部ではありません。これらのプロパティは、テキストの照合やソート、単語、文、文字の識別、テキストのレンダリングや画像化など、テキスト処理を容易にします。以下に、コアプロパティの一部を示します。Unicode 文字データベースには、他にも多くのプロパティが記載されています。[ 15 ]
Unicodeは、さまざまなプロパティによってUnicode文字レパートリー全体を対話的に照会できるオンラインデータベース[ 21 ]を提供しています。