ユニコード

ユニコード

Unicodeコンソーシアムのロゴ
エイリアス	ユニバーサルコード化文字セット(UCS) 国際標準化機構(ISO) 10646
言語	168 スクリプト(リスト)
標準	ユニコード標準
エンコード形式	UTF-8 UTF-16 GB18030 UTF-32 ボク サウスカロライナ州立大学 UTF-EBCDIC （珍しい） UTF-7 UT-1 形式 （廃止）
先行	ISO/IEC 8859など
公式サイト 技術ウェブサイト
ヴ t e

ユニコード（Unicode Standard）^{[注 1]は、}ユニコードコンソーシアムが管理するテキストエンコード標準であり、デジタル化可能な世界中のあらゆる書記体系のテキストの使用をサポートするように設計されています。標準のバージョン16.0 ^[A]では、154,998の 文字と168のスクリプト^[3]が、日常、文学、学術、技術のさまざまな文脈で使用されています。

数字、句読点、その他の記号を含む多くの一般的な文字は、標準内で統一されており、特定の書記体系に固有のものとして扱われていません。Unicodeは3790の絵文字をエンコードしており、その継続的な開発は標準の一部としてコンソーシアムによって行われています。^[4]さらに、Unicodeの広範な採用は、日本国外での絵文字の初期の普及に大きく貢献しました。Unicodeは最終的に110万を超える文字をエンコードできます。

Unicode は、さまざまなロケールやさまざまなコンピュータ アーキテクチャで使用される、互換性のない無数の文字セットの以前の環境をほぼ置き換えました。Unicode は、ほとんどのWeb ページを含むインターネット上のテキストの大部分をエンコードするために使用されており、関連する Unicode サポートは、現代のソフトウェア開発において一般的な考慮事項となっています。

Unicode文字レパートリーはISO/IEC 10646と同期しており、各文字はコード単位で同一です。しかし、Unicode 標準は文字が割り当てられているレパートリー以上のものです。開発者や設計者を支援するために、この標準ではチャートや参照データも提供され、さまざまな文字に関係する概念を説明して実装のガイダンスを提供する付録もあります。これらの付録で取り上げられているトピックには、文字の正規化、文字の構成と分解、照合、方向性などがあります。^[5]

Unicode テキストは、標準の抽象化された文字コードをバイトシーケンスに変換する方法を定義する、いくつかのエンコーディングのいずれかを使用してバイナリデータとして処理および保存されます。Unicode標準自体は、 UTF-8、UTF-16、UTF-32の 3 つのエンコーディングを定義していますが、他にもいくつか存在します。これらのうち、 UTF-8 は、 ASCIIとの下位互換性があるため、圧倒的に最も広く使用されています。

Unicode は元々、それまでに設計されたすべてのテキスト エンコーディングに存在する制限を克服する目的で設計されました。つまり、各エンコーディングはそれぞれのコンテキストで使用するために依存されていましたが、他のエンコーディングとの互換性は特に期待されていませんでした。実際、選択された 2 つのエンコーディングは、一緒に使用するとまったく機能しないことが多く、一方にエンコードされたテキストがもう一方には文字化けとして解釈されました。ほとんどのエンコーディングは、少数のスクリプト (多くの場合、主に特定のスクリプトとラテン文字)間の相互運用性を容易にするために設計されたものであり、多数のスクリプト間の相互運用性は考慮されておらず、サポートされているすべてのスクリプトが一貫した方法で扱われることも想定されていませんでした。

Unicode の根底にある考え方は、文字の単なる異体字とみなされるグラフィカルな区別ではなく、基礎となる文字(グラフィカル素とグラフィカル素のような単位) をエンコードすることを目指しています。グラフィカルな区別は、書体、マークアップの使用、またはその他の手段によって最も適切に処理されます。特に複雑なケース、たとえば漢字の綴り方の異体字の扱いでは、どの違いが独自のエンコードを正当化し、どの違いが他の文字のグラフィカルな異体字にすぎないかについて、かなりの意見の相違があります。

最も抽象的なレベルでは、Unicode は各文字にコード ポイントと呼ばれる一意の番号を割り当てます。サイズ、形状、スタイルなど、視覚的な表現に関する多くの問題は、 Web ブラウザーやワード プロセッサなど、実際にテキストをレンダリングするソフトウェアの裁量に委ねられています。ただし、迅速な採用を促すという目的もあり、この元のモデルの単純さは時間の経過とともにいくぶん複雑になり、標準の開発の過程でさまざまな実用的な譲歩がなされてきました。

最初の 256 個のコード ポイントは、すでに西ヨーロッパのスクリプトで記述されているテキストの変換を簡素化する目的で、ISO/IEC 8859-1標準を反映しています。さまざまなレガシー エンコーディングによる区別を保持し、それによってそれらのエンコーディングと Unicode の間で情報の損失なしに変換できるようにするため、外観と意図された機能の両方で他の文字とほぼ同じ多くの文字に、個別のコード ポイントが割り当てられました。たとえば、半角および全角フォームブロックには、ラテン アルファベットの意味の完全な複製が含まれています。これは、レガシーCJK エンコーディングに「全角」(CJK 文字の幅に一致) と「半角」(通常のラテン スクリプトに一致) の両方の文字が含まれていたためです。

ユニコード・ブルドッグ賞は、ユニコードの開発に影響を与えたとみなされる人々に贈られ、受賞者には小林達夫、トーマス・ミロ、ルーズベ・ポルナダー、ケン・ルンデ、マイケル・エバーソンなどが含まれる。^[6]

ユニコードの起源は、1980年代にゼロックス社の文字コード標準(XCCS)に関係する個人のグループにまで遡ります。 ^[7] 1987年、ゼロックス社の従業員であるジョー・ベッカーは、アップル社の従業員であるリー・コリンズとマーク・デイビスとともに、ユニバーサル文字セット作成の実用性について調査を始めました。^{[8]ピーター・フェンウィックと}デイブ・オプスタッドからの追加の情報を得て、^[7]ベッカーは1988年8月に「暫定的にユニコードと呼ばれる国際的/多言語テキスト文字エンコーディングシステム」の草案を発表しました。彼は「「ユニコード」という名前は、ユニークで統一されたユニバーサルエンコーディングを示唆することを意図している」と説明しています。^[7]

この文書「Unicode 88」では、ベッカーは16ビット文字を使用したスキームを概説した。^[7]

Unicode は、実用的で信頼性の高い世界共通のテキスト エンコーディングのニーズに応えることを目的としています。Unicode は、世界中のすべての言語の文字を網羅するために 16 ビットに拡張された「ワイドボディASCII」と大まかに説明できます。適切に設計された設計では、文字あたり 16 ビットでこの目的には十分すぎるほどです。

この設計上の決定は、「現代」で使用される文字と文字のみがエンコードを必要とするという仮定に基づいて行われました。^[7]

Unicode は、過去の遺物を保存することよりも、将来の有用性を確保することを優先しています。Unicode は、まず現代のテキスト (たとえば、1988 年に世界中で印刷されたすべての新聞と雑誌の統合) に掲載されている文字を対象としていますが、その数は間違いなく 2 ¹⁴ = 16,384 よりはるかに少ないです。これらの現代使用の文字以外の文字はすべて、廃止または希少と定義できます。これらは、一般的に役立つ Unicode の公開リストを混雑させるよりも、私的使用の登録に適しています。

1989 年初頭、Unicode ワーキング グループは拡大し、Metaphor の Ken Whistler と Mike Kernaghan、Research Libraries Groupの Karen Smith-Yoshimura と Joan Aliprand 、Sun Microsystemsの Glenn Wright が参加しました。1990 年には、 Microsoftの Michel Suignard と Asmus Freytag 、NeXTの Rick McGowan もグループに加わりました。1990 年末までに、既存の標準の再マッピング作業のほとんどが完了し、Unicode の最終レビュー ドラフトが完成しました。

ユニコードコンソーシアムは1991年1月3日にカリフォルニアで設立され、^{[9]その年の10月に}ユニコード標準の第1巻が出版されました。漢字を追加した第2巻は1992年6月に出版されました。

1996年、Unicode 2.0でサロゲート文字メカニズムが実装され、Unicodeは16ビットに制限されなくなりました。これにより、Unicodeのコードスペースが100万コードポイント以上に増加し、エジプトの象形文字などの多くの歴史的文字や、標準に含まれることが想定されていなかった数千のまれにしか使用されない文字や廃止された文字をエンコードできるようになりました。これらの文字の中には、まれにしか使用されないさまざまなCJK文字があり、その多くは主に固有名詞に使用されているため、元のUnicodeアーキテクチャが想定していたよりもユニバーサルエンコードにはるかに必要です。^[10]

1992 年に公開された Microsoft の TrueType 仕様のバージョン 1.0 では、命名テーブルのプラットフォーム ID に「Unicode」ではなく「Apple Unicode」という名前が使用されていました。

Unicodeコンソーシアムは、Unicodeの開発を調整する非営利団体です。正会員には、Adobe、Apple、Google、IBM、Meta（旧Facebook）、Microsoft、Netflix、SAPなど、テキスト処理標準に関心を持つほとんどの主要なコンピュータソフトウェアおよびハードウェア企業（および他の少数の企業）が含まれます。^[11]

長年にわたり、いくつかの国や政府機関がユニコードコンソーシアムの会員となってきました。現在、投票権を持つ正会員はオマーンの宗教省のみです。 ^[11]

コンソーシアムは、既存の文字エンコード方式を最終的に Unicode とその標準 Unicode 変換形式 (UTF) 方式に置き換えるという野心的な目標を掲げています。これは、既存の方式の多くはサイズと範囲が制限されており、多言語環境と互換性がないためです。

Unicodeは現在使用されている主要な表記体系のほとんどをカバーしています。^{[12] [より良い情報源が必要]}

2024年現在、最新バージョンのUnicodeには^{[アップデート]}合計168の文字^{[13]が含まれています（}アルファベット、アブギダ、音節文字をカバー）が、特に歴史的、典礼的、学術的な文脈で主に使用される文字など、まだエンコードされていない文字が残っています。すでにエンコードされている文字への文字の追加や、特に数学や音楽用の記号（音符やリズム記号の形式）の追加も行われています。

Unicodeロードマップ委員会（マイケル・エバーソン、リック・マクゴーワン、ケン・ウィスラー、VS・ウママヘスワラン）^[14]は、エンコードの候補または潜在的候補となっている文字のリストと、それらの暫定的なコードブロック割り当てを、UnicodeコンソーシアムのウェブサイトのUnicodeロードマップ^[15]ページで管理している。ロードマップ上の一部の文字、例えば女真文字や契丹大文字については、エンコードの提案がなされており、承認プロセスが進められている。ヌミディア文字やロンゴロンゴ文字など、他の文字についてはまだ提案がなされておらず、文字のレパートリーやその他の詳細について、関係するユーザーコミュニティからの合意を待っている。

まだ Unicode に含まれていない (例:テングワール) または実世界で使用されていないために Unicode に含める資格がない (例:クリンゴン) 現代の発明文字の一部は、非公式だが広く使用されている私的使用領域のコード割り当て とともに、ConScript Unicode レジストリにリストされています。

また、特殊な中世ラテン文字に焦点を当てた 中世 Unicode フォント イニシアチブもあります。これらの提案の一部はすでに Unicode に含まれています。

スクリプトエンコーディングイニシアチブ^[16]は、カリフォルニア大学バークレー校のデボラ・アンダーソンが運営するプロジェクトで、まだ標準にエンコードされていないスクリプトの提案に資金を提供することを目的として2002年に設立されました。このプロジェクトは近年、標準への追加提案の主要な情報源となっています。^[17]

Unicode コンソーシアムは、 Unicode 標準の最初の公開に続いてISO と共同で共有レパートリーを開発しました。Unicode と ISO のUniversal Coded Character Set (UCS) は、同一の文字名とコード ポイントを使用します。ただし、Unicode バージョンは、ISO の同等バージョンとは 2 つの重要な点で異なります。

UCS は単純な文字マップですが、Unicode は異なるプラットフォームや言語間の相互運用性を実現するために必要なルール、アルゴリズム、プロパティを規定しています。したがって、Unicode 標準には、ビット単位のエンコード、照合、レンダリングなどの詳細なトピックを網羅したより多くの情報が含まれています。また、双方向テキストのサポートに必要な文字プロパティを含む包括的な文字プロパティカタログや、実装者を支援するための視覚的なチャートと参照データ セットも提供しています。以前は、Unicode 標準は、完全なコア仕様、標準の付録、^{[注 2]、}およびコードチャートを含む印刷物として販売されていました。ただし、2006 年に発行されたバージョン 5.0 が、この方法で印刷された最後のバージョンでした。バージョン 5.2 からは、オンデマンド印刷のペーパーバックとして発行されたコア仕様のみを購入できます。^[18]一方、全文は Unicode の Web サイトで無料の PDF として公開されています。

この公開方法の実際的な理由は、UCS と Unicode の 2 つ目の大きな違い、つまり更新バージョンのリリースと新しい文字の追加頻度を浮き彫りにしています。Unicode標準は、毎年定期的に拡張バージョンをリリースしており、暦年に複数のバージョンがリリースされることもあれば、予定されていたリリースを延期しなければならないこともまれにあります。たとえば、バージョン 13.0 が公開されてから 1 か月後の 2020 年 4 月、Unicode コンソーシアムは、COVID-19 パンデミックの影響でバージョン 14.0 のリリース予定日を 6 か月延期し、2021 年 9 月にすると発表しました。

最新バージョンのUnicode 16.0は、2024年9月10日にリリースされました。5,185の文字と7つの新しいスクリプト（ガライ、グルン・ケマ、キラット・ライ、オル・オナル、スヌワール、トドリ、トゥル・ティガラリ）が追加されました。^[19]

これまでに、 Unicode標準の以下のバージョンが公開されています。文字レパートリーの変更を含まない更新バージョンは、3番目の数字（例：バージョン4.0.1）で示され、以下の表では省略されています。^[20]

ユニコードコンソーシアムは通常、年に1回ユニコード標準の新バージョンをリリースします。次のメジャーバージョンであるバージョン17.0には、4301の新しい統合CJK文字が含まれる予定です。^{[57] [58]}

ユニコード標準では、コード空間^[59]を定義しています。これは、0から12の範囲のコードポイント^[60]と呼ばれる整数の列です。1 114 111、標準ではU+0000 – U+10FFFFと表記されます。^[61]コードスペースは、Unicode標準の体系的でアーキテクチャに依存しない表現です。実際のテキストは、 UTF-8などのいくつかのUnicodeエンコーディングのいずれかを介してバイナリデータとして処理されます。

この規範的表記では、2文字のプレフィックスはU+常にコードポイントの前に付けられ、^[62]コードポイント自体は16進数で書かれる。少なくとも4桁の16進数が常に書かれ、必要に応じて先頭にゼロが付けられる。たとえば、コードポイントU+00F7 ÷ DIVISION SIGNは先頭に2つのゼロが付けられるが、U+13254 𓉔 EGYPTIAN HIEROGLYPH O004 ( ）はパディングされていない。^[63]

合計は 2 ²⁰ + (2 ¹⁶ − 2 ¹¹ ) =コードスペース内の有効なコード ポイントは1 112 064 個です。(この数は、 UTF-16文字エンコードの制限から生じます。UTF-16 文字エンコードは、U+0000からU+FFFFの範囲の2 ^{16個のコード ポイントをエンコードできますが、} U+D800からU+DFFFの範囲の2 ^{11 個の}コード ポイントはエンコードできません。これらのコードは、U+10000からU+10FFFFの範囲の2 ^{20 個の}コード ポイントをエンコードするためのサロゲート ペアとして使用されます。)

Unicode コード空間は 0 から 16 までの 17 のプレーンに分かれています。プレーン 0 は基本多言語プレーン(BMP) で、最もよく使用される文字が含まれています。BMP 内のすべてのコード ポイントは、UTF-16 エンコードでは単一のコード ユニットとしてアクセスされ、UTF-8 では 1、2、または 3 バイトでエンコードできます。プレーン 1 から 16 (補助プレーン) のコード ポイントは、UTF-16ではサロゲート ペアとしてアクセスされ、 UTF-8では 4 バイトでエンコードされます。

各プレーン内では、文字は関連する文字の名前付きブロック内に割り当てられます。ブロックのサイズは常に 16 の倍数で、多くの場合 128 の倍数ですが、それ以外は任意です。特定のスクリプトに必要な文字は、コード空間内の複数の異なる、分離する可能性のあるブロックに分散している場合があります。

各コード ポイントには分類が割り当てられ、コード ポイントの一般カテゴリプロパティとしてリストされます。ここで、最上位レベルでは、コード ポイントは文字、マーク、数字、句読点、記号、区切り文字、その他のいずれかに分類されます。各カテゴリの下で、各コード ポイントはさらにサブカテゴリ化されます。ほとんどの場合、特定のコード ポイントのすべての特性を適切に記述するには、他のプロパティを使用する必要があります。

のU+D800～U+DBFFの範囲の1024ポイントはハイサロゲートコードポイントと呼ばれ、U+DC00～U+DFFFの範囲のコードポイントはハイサロゲートコードポイントと呼ばれます（上位サロゲートコード ポイント(1024コード ポイント以上) は、下位サロゲート コード ポイントと呼ばれます。上位サロゲート コード ポイントの後に下位サロゲート コード ポイントが続くと、 UTF-16 でサロゲート ペアが形成され、 U+FFFFより大きいコード ポイントを表します。原則として、これらのコード ポイントはそれ以外の場合は使用できませんが、実際には、特に UTF-16 を使用しない場合は、このルールが無視されることがよくあります。

少数のコードポイントは文字に割り当てられないことが保証されているが、第三者が独自の判断でそれらを独立して使用する場合がある。これらの非文字は66個ある：U+FDD0～U+FDEFと、17のプレーンのそれぞれの最後の2つのコードポイント（例：U+FFFE、U+FFFF、U+1FFFE、U+1FFFF、...、U+10FFFE、U+10FFFF）。非文字のセットは安定しており、新しい非文字が定義されることはない。^{[64]サロゲートと同様に、これらを使用できないという規則は無視されることが多いが、}バイトオーダーマークの操作では、U+FFFEがテキストの最初のコードポイントになることは決してないと想定されている。サロゲートと非文字の除外により、1 111 998 個のコード ポイントが使用可能です。

私的使用コードポイントは割り当てられているとみなされますが、Unicode標準^[65]で意図的に解釈が指定されていないため、そのようなコードポイントを交換するには、送信者と受信者の間でその解釈に関する独立した合意が必要です。Unicodeコードスペースには3つの私的使用領域があります。

• 私的使用エリア: U+E000 – U+F8FF (6400文字）、
• 補助私的利用エリアA: U+F0000 – U+FFFFD (65,534文字）、
• 補足私的利用領域B: U+100000 – U+10FFFD (65,534文字)。

グラフィック文字は、 Unicode標準によって特定の意味を持つように定義されており、目に見えるグリフの形を持つか、目に見えるスペースを表します。Unicode 16.0の時点では、154,826個のグラフィック文字。

フォーマット文字は、目に見える外観を持たない文字ですが、隣接する文字の外観や動作に影響を与える可能性があります。たとえば、U+200C ZERO WIDTH NON-JOINERとU+200D ZERO WIDTH JOINER は、隣接する文字のデフォルトの形状動作を変更するために使用できます (合字を禁止したり、合字の形成を要求したりするなど)。Unicode 16.0 には 172 個のフォーマット文字があります。

65 個のコード ポイント (範囲U+0000 – U+001FおよびU+007F – U+009F ) は、制御コードとして予約されており、ISO/IEC 6429で定義されているC0 および C1 制御コードに対応しています。U +0089 LINE TABULATION、U+008A LINE FEED、およびU+000D CARRIAGE RETURNは、 Unicodeを使用するテキストで広く使用されています。mojibake と呼ばれる現象では、C1 コード ポイントは、以前は西ヨーロッパのコンテキストで広く使用されていたWindows-1252コード ページに従って不適切にデコードされます。

グラフィック文字、フォーマット文字、制御コード文字、私的使用文字は、まとめて割り当て文字と呼ばれます。予約コードポイントは、有効で使用可能ですが、まだ割り当てられていないコードポイントです。Unicode 15.1の時点では、819 467予約済みコード ポイント。

Unicode で定義されたグラフィック文字と書式文字のセットは、Unicode で表現できる抽象文字のレパートリーに直接対応しているわけではありません。Unicode は、抽象文字を特定のコード ポイントに関連付けることで文字をエンコードします。 ^[66]ただし、すべての抽象文字が単一の Unicode 文字としてエンコードされるわけではなく、一部の抽象文字は Unicode で 2 つ以上の文字のシーケンスで表現される場合があります。たとえば、リトアニア語で必須の、オゴネク、上にドット、鋭アクセントが付いたラテン小文字の「i」は、文字シーケンスU+012F、U+0307、U+0301で表現されます。Unicode は、Unicode で直接エンコードされていない抽象文字に対して、一意に名前が付けられた文字シーケンスのリストを維持しています。^[67]

割り当てられたすべての文字には、一意かつ不変の名前があり、それによって文字が識別されます。この不変性は、Unicode 標準のバージョン 2.0 以降、名前の安定性ポリシーによって保証されています。^[64]名前に重大な欠陥があり誤解を招く場合、または重大な誤植がある場合は、正式な別名を定義して、アプリケーションが正式な文字名の代わりに使用することを推奨する場合があります。たとえば、U +A015 ꀕ YI SYLLABLE WU の正式な別名はYI SYLLABLE ITERATION MARKであり、U+FE18 ︘ PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRA CK ETの正式な別名はPRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRA CK ETです。^[68]

Unicode には、サポートされるグリフのレパートリーを大幅に拡張する文字変更のメカニズムが含まれています。これは、ユーザーが基本文字の後に追加できる結合発音区別符号の使用をカバーしています。複数の結合発音区別符号を同じ文字に同時に適用できます。また、Unicode には、通常使用されるほとんどの文字/発音区別符号の組み合わせの合成バージョンが含まれています。これらにより、レガシー エンコーディングとの変換が簡単になり、アプリケーションは結合文字を実装しなくても Unicode を内部テキスト形式として使用できるようになります。たとえば、はéUnicode ではU+0065 e LATIN SMALL LETTER Eの後にU+0301 ◌́ COMBINING ACUTE ACCENTが続く形で表すことができ、合成文字U+00E9 é LATIN SMALL LETTER E WITH ACUTEとして同等に表すことができます。したがって、ユーザーには同じ文字をエンコードする同等の方法が複数あることがよくあります。Unicode標準内の正規等価性のメカニズムにより、これらの同等のエンコーディングの実用的な互換性が保証されます。

一例として、韓国語のアルファベットであるハングルが挙げられます。Unicodeは、ハングル文字の個々のサブコンポーネントからハングル音節を構成するメカニズムを提供しています。しかし、最も一般的な字母から作られた、あらかじめ構成された音節の 11,172の組み合わせ。

CJK 文字は現在、合成不可能な部首と合成済みの形式に対するコードしか持っていません。ほとんどの漢字は、部首と呼ばれるより単純な綴りの要素から意図的に合成されるか、またはその合成として再構成されているため、原理的には Unicode はハングルの場合と同様に漢字の合成を可能にすることができたはずです。これにより、必要なコード ポイントの数が大幅に削減され、多くの任意の新しい文字をアルゴリズムで合成できるようになりましたが、文字の語源の複雑さと部首システムの事後的な性質により、提案は非常に複雑になっています。実際、合成部首に基づいて CJK エンコーディングを設計する試みは、漢字がハングルほど単純または規則的に分解されないという現実から生じる困難に直面しています。

CJK部首補足ブロックはU+2E80 – U+2EFFの範囲に割り当てられ、康熙部首はU+2F00 – U+2FDFに割り当てられます。表意文字記述シーケンスブロックはU+2FF0 – U+2FFBの範囲をカバーしますが、Unicode 標準では、その文字を他の場所でエンコードされた文字の代替表現として使用しないよう警告しています。

このプロセスは、表意文字の正式なエンコードとは異なります。エンコードされていない表意文字の標準的な説明はありません。説明された表意文字には意味論が割り当てられていません。説明された表意文字の同等性は定義されていません。概念的には、表意文字の説明は、文字シーケンス <U+0065、U+0301> よりも、英語のフレーズ「鋭アクセントが付いた 'e'」に似ています。

アラビア語やデーヴァナーガリー語を含む多くの文字には、特殊な綴り規則があり、特定の文字の組み合わせを特殊な合字形式に組み合わせる必要があります。合字の形成を規定する規則は非常に複雑で、ACE（1980年代のDecoType社によるアラビア語書道エンジンで、 Unicode標準の印刷版のすべてのアラビア語の例を生成するために使用されました）などの特殊な文字形成技術が必要になります。ACEは、OpenType（AdobeおよびMicrosoft社）、Graphite（SIL International社）、またはAAT （Apple社）の概念実証となりました。

フォントには、異なる文字シーケンスを適切に出力する方法をオペレーティング システムに指示する命令も埋め込まれています。結合記号や発音区別符号の配置に関する簡単な解決策は、記号の幅を 0 に割り当て、グリフ自体を左サイドベアリングの左または右に配置することです (使用するスクリプトの方向によって異なります)。この方法で処理された記号は、その前に来る文字の上に表示されますが、基本グリフの幅や高さに対する位置は調整されません。そのため、見た目が不自然になり、一部のグリフと重なる場合があります。実際のスタッキングは不可能ですが、限られたケースで近似することはできます (たとえば、タイ語の上部結合母音と声調記号は、最初から高さが異なる場合があります)。一般に、この方法は等幅フォントでのみ有効ですが、より複雑な方法が失敗した場合のフォールバック レンダリング方法として使用できます。

Unicode のいくつかのサブセットが標準化されています。Microsoft Windows はWindows NT 4.0以降、 657 文字のWGL-4 をサポートしています。これは、ラテン文字、ギリシャ文字、キリル文字を使用するすべての現代ヨーロッパ言語をサポートしていると考えられています。Unicode のその他の標準化されたサブセットには、多言語ヨーロッパ サブセットがあります。 ^[70] MES-1 (ラテン文字のみ、335 文字)、MES-2 (ラテン文字、ギリシャ文字、キリル文字、1062 文字) ^[71]、および MES-3A と MES-3B (2 つの大きなサブセット、ここには示されていません)。MES-2 には、MES-1 と WGL-4 のすべての文字が含まれています。

標準DIN 91379 ^[72]は、名前を正しく表現し、ヨーロッパでのデータ交換を簡素化するために、Unicode文字、特殊文字、文字と発音区別符号のシーケンスのサブセットを規定しています。この標準は、すべての欧州連合諸国のすべての公用語、ドイツ語の少数言語、アイスランド、リヒテンシュタイン、ノルウェー、スイスの公用語をサポートしています。他の表記体系の名前を関連するISO標準に従ってラテン文字に翻字できるように、基本文字と発音区別符号の必要な組み合わせがすべて提供されています。

Unicode 文字を適切に処理できないレンダリング ソフトウェアは、多くの場合、認識できない文字の位置を示すために、開いた四角形またはU+FFFDとして文字を表示します。一部のシステムでは、このような文字についてさらに情報を提供する試みが行われています。Apple のLast Resort フォントでは、文字の Unicode 範囲を示す代替グリフが表示され、SIL InternationalのUnicode フォールバック フォントでは、文字の 16 進スカラー値を示すボックスが表示されます。

一連のコード ポイントを一連のバイトとして保存するためのメカニズムがいくつか指定されています。

Unicode は、 Unicode Transformation Format (UTF) エンコーディングとUniversal Coded Character Set (UCS) エンコーディングの2 つのマッピング方式を定義しています。エンコーディングは、Unicodeコード ポイントの範囲 (場合によってはそのサブセット) を、コード ユニットと呼ばれる固定サイズの範囲の値のシーケンスにマッピングします。すべての UTF エンコーディングは、コード ポイントを一意のバイト シーケンスにマッピングします。^[73]エンコーディング名の数字は、コード ユニットあたりのビット数 (UTF エンコーディングの場合) またはコード ユニットあたりのバイト数 (UCS エンコーディングおよびUTF-1の場合) を示します。UTF-8 と UTF-16 は最も一般的に使用されるエンコーディングです。UCS -2 はUTF-16 の廃止されたサブセットです。UCS-4 と UTF-32 は機能的に同等です。

UTF エンコーディングには次のものがあります:

• UTF-8はコードポイントごとに1～4個の8ビット単位を使用し、^[注3] ASCIIとの互換性が最大限に確保されている。
• UTF-16はコードポイントごとに1つまたは2つの16ビット単位を使用しますが、サロゲート文字をエンコードすることはできません。
• UTF-32はコードポイントごとに32ビット単位を使用します。
• UTF-EBCDIC は、 Unicode 標準の一部として指定されておらず、コード ポイントごとに 1 ～ 5 個の 8 ビット単位を使用し、EBCDICとの互換性を最大限にすることを目的としています。

UTF-8 はコード ポイントごとに 1 ～ 4 つの 8 ビット単位 (バイト) を使用し、ラテン文字用にコンパクトで ASCII と互換性があるため、Unicode テキストの交換における事実上の標準エンコードを提供します。これは、FreeBSDおよび最新のLinux ディストリビューションで、一般的なテキスト処理における従来のエンコードの直接的な代替として使用されています。

UCS-2 および UTF-16 エンコーディングは、テキスト ファイルの先頭で使用するUnicodeバイト オーダー マーク(BOM) を指定します。これは、バイト オーダー検出 (またはバイト エンディアン検出) に使用できます。 U+FEFF ZERO WIDTH NO-BREAK SPACEとしてエンコードされた BOM には、使用されている Unicode エンコーディングに関係なく、バイトの並べ替えが明確であるという重要な特性があります。U+FFFE (バイト スワップU+FEFFの結果) は有効な文字とはみなされず、テキストの先頭以外の場所にあるU+FEFF は、ゼロ幅の非改行スペースを表します。

同じ文字をUTF-8に変換すると、バイトシーケンスになりますEF BB BF。Unicode標準では、BOMが「文字セットがマークされていないUTF-8でエンコードされたテキストの署名として機能することができる」ことが許可されています。^{[74]一部のソフトウェア開発者は、UTF-8をローカルの8ビット}コードページと区別するために、UTF-8を含む他のエンコードにBOMを採用しています。ただし、UTF-8標準のRFC  3629では、UTF-8を使用するプロトコルでバイトオーダーマークを禁止することを推奨していますが、これが不可能な場合についても説明しています。さらに、UTF-8で可能なパターンに大きな制限があるため（たとえば、上位ビットが設定された孤立したバイトは存在できません）、BOMに頼らずにUTF-8を他の文字エンコードと区別できるはずです。

UTF-32 および UCS-4 では、1 つの32 ビットコード ユニットが、任意の文字のコード ポイントをかなり直接的に表現します (ただし、プラットフォームによって異なるエンディアンによって、コード ユニットがバイト シーケンスとしてどのように表現されるかが左右されます)。その他のエンコーディングでは、各コード ポイントは、可変数のコード ユニットで表現される場合があります。UTF-32 は、プログラム内のテキストの内部表現として広く使用されています (保存または送信されるテキストではなく)。これは、gccコンパイラを使用してソフトウェアを生成するすべての Unix オペレーティング システムが、これを標準の「ワイド文字」エンコーディングとして使用するためです。Seed7などの一部のプログラミング言語では、文字列と文字の内部表現として UTF-32 を使用します。Python プログラミング言語の最近のバージョン( 2.2 以降) では、Unicode 文字列の表現として UTF-32 を使用するように構成することもできます。これにより、高レベルのコード化ソフトウェアでこのようなエンコーディングが効果的に普及します。

別のエンコード形式であるPunycode は、 Unicode 文字列をASCIIベースのドメイン ネーム システム(DNS) でサポートされている限定された文字セットにエンコードできるようにします。このエンコードはIDNAの一部として使用されます。IDNA は、Unicode でサポートされているすべてのスクリプトで国際化ドメイン名を使用できるようにするシステムです。以前の提案と現在は歴史的な提案には、 UTF-5とUTF-6があります。

GB18030 は、中国標準化管理局による Unicode の別のエンコード形式です。これは中華人民共和国 (PRC) の公式文字セットです。BOCU -1とSCSU はUnicode 圧縮方式です。2005年のエイプリルフールの RFC では、UTF-9とUTF-18 という2 つのパロディ UTF エンコードが指定されました。

UTF-8形式の Unicode は、 2008 年以来、ワールド ワイド ウェブで最も一般的なエンコーディングとなっています。^[75]ほぼ普遍的に採用されており、非 UTF-8 コンテンツの多くは他の Unicode エンコーディング、たとえばUTF-16で見つかります。2024 年の時点で^{[アップデート]}、UTF-8 はすべてのウェブページの平均 98.3% を占めています (上位 1,000 のウェブページのうち 983 ページ)。^{[76]多くのページではコンテンツの表示に}ASCII文字のみを使用していますが、UTF-8 は 8 ビット ASCII をサブセットとして設計されており、現在ではエンコーディングを UTF-8 ではなく ASCII のみにすることを宣言しているウェブサイトはほとんどありません。^[77]追跡対象の言語の 3 分の 1 以上で、100% UTF-8 が使用されています。

インターネットエンジニアリングタスクフォースによって管理されているすべてのインターネットプロトコル（FTPなど）^{[78]は、 1998年の}RFC 2277の発行以来、UTF-8のサポートを要求しており 、RFC 2277では、すべてのIETFプロトコルが「UTF-8文字セットを使用できなければならない」と規定されています。^[79]

Unicode は、テキストの内部処理と保存に使用される主要な方式となっています。大量のテキストが依然として従来のエンコーディングで保存されていますが、Unicode は新しい情報処理システムの構築にほぼ独占的に使用されています。早期導入者はUCS-2 (UTF-16 の前身で、現在は固定長の 2 バイト) を使用する傾向があり、後にUTF-16 (可変長の現在の標準) に移行しました。これは、これが非 BMP 文字のサポートを追加する最も混乱の少ない方法であったためです。最もよく知られているそのようなシステムはWindows NT (およびその後継である2000、XP、Vista、7、8、10、および11 ) で、UTF-16 を唯一の内部文字エンコーディングとして使用しています。Javaおよび.NETバイトコード環境、macOS、およびKDEでも、内部表現にこれを使用しています。Windows 9xでは、 Microsoft Layer for Unicodeを通じてUnicode の部分的なサポートをインストールできます。

UTF-8（もともとPlan9用に開発された）^{[80]は、従来の}拡張ASCII文字セットを比較的簡単に置き換えることができるため、ほとんどのUnix系オペレーティングシステム（一部のライブラリでは他の文字セットも使用されています）の主要なストレージエンコーディングになりました。UTF-8は、 World Wide Web上のHTMLドキュメントで使用される最も一般的なUnicodeエンコーディングでもあります。

Unicode を使用する多言語テキスト レンダリング エンジンには、Microsoft Windows 用のUniscribeとDirectWrite 、macOS 用のATSUIとCore Text、GTK+とGNOMEデスクトップ用のPangoなどがあります。

キーボード レイアウトではすべての文字に対して単純なキーの組み合わせを使用できないため、いくつかのオペレーティング システムでは、全レパートリーにアクセスできる代替入力方法を提供しています。

ISO/IEC 14755 ^[81]は、Unicode文字をコードポイントから入力する方法を標準化しており、いくつかの方法が指定されています。最初のシーケンスの後にコードポイントの16進表現と終了シーケンスが続く基本方式があります。また、文字マッププログラムなどを使用して画面上の表に文字がリストされる 画面選択入力方式も指定されています。

既知の文字のコードポイントを見つけるためのオンラインツールには、Jonathan Hedley によるUnicode Lookup ^{[82]や Benjamin Milde による Shapecatcher [83]}などがあります。Unicode Lookup では、検索キー (例: 「分数」) を入力すると、対応する文字のリストとそのコードポイントが返されます。Shapecatcher では、Shape コンテキストに基づいて、ボックス内に文字を描画すると、描画に近い文字のリストとそのコードポイントが返されます。

MIME は、電子メール内の非 ASCII 文字をエンコードするための 2 つの異なるメカニズムを定義します。これは、文字が電子メール ヘッダー (「件名:」など) にあるか、メッセージのテキスト本文にあるかによって異なります。どちらの場合も、元の文字セットと転送エンコードが識別されます。Unicode の電子メール送信では、メッセージの大部分がASCII文字で構成されているかどうかに応じて、 UTF-8文字セットとBase64またはQuoted-printable転送エンコードが推奨されます。2 つの異なるメカニズムの詳細は MIME 標準で指定されており、通常、電子メール ソフトウェアのユーザーには表示されません。

IETFはUTF-8を使用した国際化された電子メールのフレームワークを定義し^{[84] [85]}、そのフレームワークに従っていくつかのプロトコルを 更新しました^{[86] [87] [88] [89] 。}

電子メールにおける Unicode の採用は非常に遅い。^[要出典]東アジアのテキストの一部は依然としてISO-2022などのエンコードでエンコードされており、携帯電話などの一部のデバイスは^{[要出典]依然として Unicode データを正しく処理できません。ただし、サポートは改善されています。Yahoo} ! メール、Gmail、Outlook.comなど、多くの主要な無料メール プロバイダーがこれをサポートしています。

HTML 4.0以降、W3Cの勧告はすべてUnicodeを文書の文字セットとして使用しています。Webブラウザは長年Unicode、特にUTF-8をサポートしています。以前は主にフォント関連の問題から生じる表示上の問題がありました。たとえば、Microsoft Internet Explorerのバージョン6以前では、明示的にそれらを含むフォントを使用するように指示されない限り、多くのコードポイントがレンダリングされませんでした。^[90]

構文規則は文字の出現順序に影響を与える可能性があるが、XML（XHTMLを含む）文書は、定義上^[91] 、以下の例外を除くほとんどのUnicodeコードポイントの文字で構成される。

• FFFE または FFFF。
• C0制御コードのほとんどは、
• 永久的に未割り当てのコードポイントD800～DFFF、

HTML 文字は、文書のエンコーディングがサポートしている場合はそのエンコーディングに従って直接バイトとして表現されますが、文字の Unicode コード ポイントに基づいて数値文字参照として記述することもできます。たとえばΔ、、、、、、、、、、および(または をプレフィックスとして 16 進数で表現した同じ数値Й)の参照はק、すべてのブラウザーでمΔ 、Й、ק 、م、๗、あ、叶、葉、および 말 として表示されます。 ๗あ叶葉말&#x

HTTPリクエスト内のURLなどのURI を指定する場合、非 ASCII 文字はパーセントエンコードする必要があります。

Unicodeは原則としてフォント自体には関心がなく、実装上の選択肢と見なしています。^[92]任意の文字には、より一般的な太字、斜体、基本字体から複雑な装飾スタイルまで、多くの異字体があります。フォントのグリフがUnicode標準で定義されているコードポイントを使用してアクセスできる場合、フォントは「Unicode準拠」です。^[93]この標準では、フォントに含める必要がある文字の最小数は指定されていません。一部のフォントでは、レパートリーが非常に小さいです。

TrueTypeとOpenType はUnicode をサポートしているため ( Web Open Font Format (WOFF とWOFF2 ) はこれらに基づいています) 、Unicode に基づく無料フォントや市販フォントは広く入手可能です。これらのフォント形式は Unicode コード ポイントをグリフにマッピングしますが、OpenType と TrueType フォント ファイルは 65,535 グリフに制限されています。コレクション ファイルには、単一のフォント ファイルでこの制限を克服するための「ギャップ モード」メカニズムが用意されています (ただし、コレクション内の各フォントには 65,535 の制限が残っています)。TrueType コレクション ファイルのファイル拡張子は通常、「.ttc」です。

市場には何千ものフォントが存在しますが、Unicode の文字レパートリーの大部分をサポートしようとしているフォントは 12 種類未満 (「汎 Unicode」フォントと呼ばれることもあります) です。代わりに、Unicode ベースのフォントは通常、基本的な ASCII と特定のスクリプトまたは文字や記号のセットのみをサポートすることに重点を置いています。このアプローチを正当化する理由はいくつかあります。アプリケーションやドキュメントでは、1 つまたは 2 つの書記体系以上の文字をレンダリングする必要はほとんどありません。フォントはコンピューティング環境でリソースを要求する傾向があります。また、オペレーティング システムとアプリケーションでは、必要に応じて別のフォント ファイルからグリフ情報を取得する (つまり、フォントの置換)という点で、ますますインテリジェントになっています。さらに、何万ものグリフに対して一貫したレンダリング命令のセットを設計することは途方もない作業です。このような試みは、ほとんどの書体では収穫逓減の限界を超えています。

Unicode は、異なるプラットフォームでテキスト ファイルを読み取ろうとするときに発生する改行の問題を部分的に解決します。Unicode は、準拠するアプリケーションが行末文字として認識する必要がある 多数の文字を定義します。

改行に関しては、Unicode はU+2028 LINE SEPARATORとU+2029 PARAGRAPH SEPARATOR を導入しました。これは、段落と行を意味的にエンコードする Unicode ソリューションを提供し、さまざまなプラットフォーム ソリューションをすべて置き換える試みでした。そうすることで、Unicode は、従来のプラットフォーム依存のソリューションを回避する方法を提供します。とはいえ、これらの Unicode 行区切り文字と段落区切り文字を唯一の正規の行終了文字として採用している Unicode ソリューションはほとんどありません。ただし、この問題を解決するための一般的な方法は、改行の正規化です。これは、macOSのCocoa テキスト システム、および W3C XML および HTML 推奨事項で実現されています。この方法では、考えられるすべての改行文字が内部的に共通の改行に変換されます (これはレンダリングのみの内部操作であるため、どれが 1 つであるかは実際には重要ではありません)。つまり、テキスト システムは、入力の実際のエンコードに関係なく、文字を改行として正しく扱うことができます。

表意文字研究グループ（IRG）は、コンソーシアムとISOに対し、漢字統一、特にCJK統一表意文字と互換表意文字のレパートリーへのさらなる追加について助言する役割を担っている。IRGは、歴史的に漢字を使用してきた各地域の専門家によって構成されている。しかし、委員会内での審議にもかかわらず、漢字統一は、プロジェクト発足以来、一貫してUnicode標準の最も論争の多い側面の一つとなっている。 ^[94]

既存の文字セット標準、例えば日本語のJIS X 0208 ( Shift JISでエンコード) では、統一基準が定義されています。統一基準とは、漢字の異体字を筆跡やフォントの違いと見なして統一するか、それとも綴りの違いと見なして別々にエンコードするかを決定するルールです。Unicode の CJK 文字の文字モデルは、JIS X 0208 で使用される統一基準と、中国の中国語共通コード協会が開発した基準に基づいています。^[95]この標準では、文体上の異体字ではなく意味上の異体字をエンコードするという原則があるため、Unicode は、一部の珍しい古風な漢字異体にコードポイントを割り当てていないという批判を受けており、古代の珍しい日本語名の処理が複雑になっている可能性があります。中国語、日本語、韓国語が多くの文字を共有していることに特に重点が置かれているため、漢字統一は、3 つを同じものとして扱っていると認識されることもあります。^[96]

あまり使用されていない代替エンコーディングも存在し、多くの場合はUnicodeより前から存在し、文字モデルはこのパラダイムとは異なり、地域や非標準の文字形式間のさまざまな文体の違いを保存することを目的としている。1つの例は、一部のユーザーが歴史的な日本語テキストの処理に好んで使用しているTRONコードであるが、日本の一般大衆に広く採用されているわけではない。もう1つは、香港、台湾、米国の図書館システムで採用されているCCCIIエンコーディングである。これらには一般的な使用において独自の欠点があり、図書館システム以外では、 Big5エンコーディング（CCCIIの4年後の1984年に導入）がCCCIIよりも一般的になった。^[97] Appleでの作業は、 CCCIIのEACCバリアントを維持するために使用されたResearch Libraries GroupのCJKシソーラスに基づいており、UnicodeのUnihanセットの直接の前身の1つであったが、UnicodeはJISスタイルの統合モデルを採用した。^[95]

最も初期のバージョンの Unicode には 21,000 文字未満の漢字しか収録されておらず、主に比較的一般的に現代で使用されているものに限られていました。バージョン 16.0 の時点で、この標準では 97,000 文字を超える漢字がエンコードされており、さらに数千文字を追加する作業が続けられています。その多くは、中国語圏全体で使用されている歴史的および方言的な異体文字です。

現代の書体は、統一された漢字を様々な地域のグラフィック表現で表現する際の実際的な問題のいくつかに対処する手段を提供します。OpenTypeの「locl」テーブルにより、レンダラーはテキストのロケールに基づいて各コードポイントに異なるグリフを選択できます。^[98] Unicodeのバリエーションシーケンスは、必要なグリフ選択のためのテキスト内注釈を提供することもできます。これには、表意文字バリエーションデータベースに特定のバリエーションを登録する必要があります。

同じ文字体系の文字の適切なグリフがイタリック体のみ異なる場合、Unicode は一般的にそれらを統一しており、これは右のロシア語、伝統的なブルガリア語、マケドニア語、セルビア語のテキストに典型的に現れる 7 つの文字のイタリック体グリフの比較に見られるように、違いはスマートフォント技術または手動でフォントを変更することによって表示されることを意味します。同じ OpenType の「locl」技術が使用されています。^[99]

トルコ語アルファベットとアゼルバイジャン語アルファベットで使用するために、Unicodeにはドットなし小文字のI (ı)とドット付き大文字のI ( İ )が別々に含まれている。ただし、ドット付き小文字のIとドットなし大文字のIには、以前のISO 8859-9での扱いに合わせて、通常のASCII文字が使用される。そのため、これらの言語の大文字と小文字を区別しない比較では、ラテン文字を使用する他の言語の大文字と小文字を区別しない比較とは異なるルールを使用する必要があります。^[100]

対照的に、アイスランド語のeth (ð)、横棒付きD (đ)、屈折D (ɖ)は、通常^[注4]大文字(Đ)では同じに見えるが、逆の扱いを受け、大文字と小文字で別々にエンコードされる（大文字形式を統一した以前のISO 6937とは対照的）。この方法では、テキストの言語を知らなくても大文字と小文字を区別しない比較が可能になるが、このアプローチにも問題があり、同形異義語攻撃に関するセキュリティ対策が必要になる。 ^[101]

小文字のIに分音記号が適用される場合にその文字のタイトルが保持されるかどうかも、地域の慣習によって異なります。

Unicodeには多数のホモグリフがあり、その多くはASCII文字と非常に似ているか同一です。これらを置き換えると、正しく見える識別子やURLが作成されますが、予想とは異なる場所に誘導されます。^{[102]さらに、ホモグリフは}自然言語処理（NLP）システムの出力を操作するためにも使用できます。 ^[103]軽減するには、これらの文字を許可しないか、別の方法で表示するか、同じ識別子に解決するように要求する必要があります。^[104]これらすべては、文字セットが膨大で常に変化するため複雑です。^{[105] [106]}

2021年にケンブリッジ大学とエディンバラ大学の2人の研究者によってセキュリティ勧告が発表され、BiDiマークを使用すると、コードの大部分が見た目とは異なる動作をするようにすることができると主張した。この問題は「トロイの木馬ソース」と名付けられた。 ^[107]これを受けて、コードエディターは強制的なテキスト方向の変更を示すマークを強調表示し始めた。^[108]

Unicode は、既存の文字エンコーディングとの間でコードポイントごとのラウンドトリップ形式変換を提供するように設計されており、古い文字セットのテキスト ファイルを Unicode に変換してから、コンテキスト依存の解釈を使用せずに同じファイルに戻すことができます。つまり、分音記号の組み合わせや合成文字などの一貫性のないレガシー アーキテクチャがUnicode に存在し、テキストを表す方法が複数存在することになります。これは、韓国語のハングルの 3 つの異なるエンコーディング形式で最も顕著です。バージョン 3.0 以降、異なるバージョンの Unicode を使用するソフトウェア間の相互運用性を維持するために、既存の文字の組み合わせシーケンスで表すことができる合成文字は、標準に追加できなくなりました。

既存のレガシー文字セットの文字と Unicode の文字の間には、Unicode への変換を容易にし、レガシーソフトウェアとの相互運用性を可能にするために、注入マッピングが提供される必要があります。Shift -JISやEUC-JPなどの以前の日本語エンコーディングと Unicode間のさまざまなマッピングに一貫性がないため、ラウンドトリップ形式の変換の不一致が発生しました。特に、レガシーデータベースデータで頻繁に使用される文字 JIS X 0208 '～' (1-33、WAVE DASH) をU+FF5E～FULLWIDTH TILDE ( Microsoft Windowsの場合) またはU+301C〜WAVE DASH (他のベンダーの場合) にマッピングする場合に顕著でした。^[109]

日本のコンピュータプログラマーの中には、UnicodeではU+005C \ REVERSE SOLIDUS（バックスラッシュ）とU+00A5 ¥ YEN SIGN（JIS X 0201で0x5Cにマッピングされていた）を区別する必要があり、この用法を使ったレガシーコードが多数存在するため、Unicodeに反対する者もいた。^[110]（このエンコーディングでは、チルダ「~」0x7Eもマクロン「¯」に置き換えられ、現在は0xAFとなっている。）これらの文字の区別は、Unicodeよりずっと前から ISO 8859-1に存在している。

タミル語やデーヴァナーガリー語などのインド系文字には、 ISCII標準に合わせてそれぞれ128のコードポイントしか割り当てられていない。Unicodeインド系テキストを正しく表示するには、格納されている論理順序の文字を視覚順序に変換し、構成要素から合字（接続詞とも呼ばれる）を形成する必要がある。一部の地元の学者は、他の表記体系の慣例に反して、これらの合字にUnicodeコードポイントを割り当てることを支持したが、Unicodeには下位互換性のためだけにアラビア語やその他の合字が含まれている。^{[111] [112] [113]} Unicodeで新しい合字をエンコードすることは行われないだろう。その理由の1つは、合字のセットがフォントに依存し、Unicodeはフォントの違いに依存しないエンコードであるためである。2003年に中国標準化局が956のチベット語合成音節のエンコードを提案した際にも、同様の問題がチベット文字で発生したが^[114]、関連するISO委員会（ISO/IEC JTC 1/SC 2）によってエンコードが拒否された。^[115]

タイ語アルファベットのサポートは、タイ語文字の順序について批判されてきた。先行する子音の左側に書かれる母音เ、แ、โ、ใ、ไは、他のインド系文字のUnicode表現とは異なり、音声順ではなく視覚順になっている。この複雑さは、Unicodeが同じように機能し、タイ語が常にキーボードで書かれてきた方法であるタイ工業規格620を継承しているためである。この順序の問題により、Unicodeの照合プロセスがわずかに複雑になり、照合のためにタイ語の文字を並べ替えるためのテーブル参照が必要になる。 ^[96] Unicodeが話し言葉の順序に従ったエンコードを採用したとしても、辞書の順序で単語を照合することは依然として問題である。例えば、 แสดง [sa dɛːŋ] 「実行する」という単語は、子音連結「สด」（子音「ส」に固有の母音を含む）で始まり、母音แ-は、話し言葉ではดの後に来ますが、辞書では、単語は書かれたとおりに照合され、母音はสの後に来ます。

発音区別符号付きの文字は、一般に、単一の合成文字として、または基本文字と 1 つ以上の非スペーシング マークの分解されたシーケンスとして表すことができます。たとえば、ḗ (マクロンとアキュートが上に付いた合成済みの e) と ḗ (e の後に結合マクロンと結合アキュートが上に続く) は、同じようにレンダリングされ、どちらもマクロン(◌̄) とアキュート アクセント(◌́)付きのeとして表示されますが、実際には、文字を表示するために使用されているレンダリング エンジンとフォントによって、外観が異なる場合があります。同様に、インド語派の言語のローマ字化に必要な下点も、多くの場合、正しく配置されません。^[要出典]多くの場合、合成済みグリフにマップされる Unicode 文字を使用できるため、問題を回避できますが、合成済み文字がエンコードされていない場合は、高度なレンダリング機能のためにGraphite、OpenType ('gsub')、またはAATテクノロジを使用するCharis SILなどの特殊な Unicode フォントを使用することで、問題を解決できる場合がよくあります。

Unicode 標準では、安定性を保証することを目的とした規則が課されています。^[116]規則の厳しさに応じて、変更が禁止または許可される場合があります。たとえば、コード ポイントに与えられた「名前」は変更できず、変更されることはありません。ただし、「スクリプト」プロパティは、Unicode 独自の規則により、より柔軟です。バージョン 2.0 では、Unicode はバージョン 1 から多くのコード ポイント「名前」を変更しました。同時に、Unicode は、それ以降、コード ポイントに割り当てられた名前は決して変更されないと述べました。これは、間違いが公開された場合、たとえ些細な間違いであっても、これらの間違いを修正できないことを意味します (文字名でBRACKETをBRAKCETと綴った場合など)。2006 年に文字名の異常のリストが初めて公開され、2021 年 6 月の時点で、問題が特定された文字は 104 個ありました。^[117]たとえば、次のとおりです。

• U+034F ͏ 結合グラフィムジョイナー: グラフィムを結合しない。 ^[117]
• U+2118 ℘ SCRIPT CAPITAL P : これは小文字です。大文字はU+1D4AB 𝒫 MATHEMATICAL SCRIPT CAPITAL Pです。 ^[118]
• U+A015 ꀕ YI SYLLABLE WU : これは Yi 音節ではなく、 Yi 繰り返し記号です。
• U+FE18 ︘ 垂直右白レンズ状括弧の表示形式：括弧のスペルが間違っています。 ^{[119] （スペルエラーは}Unicode別名を使用して解決されます。）

Unicodeではスクリプト指定子（名前）を「Phags_Pa」と定義していますが、そのスクリプトの文字名にはハイフンが追加されています：U+A840 ꡀ PHAGS-PA LETTER KA。^{[120] [121]}ただし、これは例外ではなく、スクリプト指定子ではハイフンはアンダースコアに置き換えられるという規則です。^[120]

• Unicode エンコーディングの比較
• 国際Unicodeコンポーネント（ICU）、現在はICU- TCとしてUnicodeの一部となっている。
• バイナリコードのリスト
• Unicode文字の一覧
• XML および HTML 文字実体参照のリスト
• 同様の意図で並行して開発されたLotus Multi-Byte Character Set (LMBCS)
• オープンソースの Unicode 書体
• Unicode の宗教的および政治的シンボル
• Unicodeに関連する標準
• ユニコードシンボル
• ユニバーサルコード化文字セット

• ハラランボス、ヤニス; マーティン・デュルスト (2019)。「言語学的観点から見たユニコード」。ハラランボス、ヤニス (編)。21世紀のグラフェミクスの議事録、ブレスト 2018。ブレスト: フルクサス エディション。pp. 167–183。doi : 10.36824 /2018-graf-hara1。ISBN 978-2-9570549-1-6。

• ユニコード株式会社
  • Unicode 技術サイト
    • ユニコード標準
      • Unicode 文字コード表
      • Unicode 文字名インデックス
• Alan Wood の Unicode リソース – Unicode 対応のワード プロセッサのリストが含まれています。フォントと文字はタイプ別にグループ化されており、文字はグリッドではなくリストで表示されます。
• Curlieの Unicode
• Unicode BMP フォールバック フォント - グリフ自体ではなく、私的使用領域を含むドキュメント内の任意の文字の Unicode 6.1 値を表示します。
• 世界の文字体系、293 の既知の文字体系すべてとその Unicode ステータス (2024 年 6 月時点で 128 はまだエンコードされていません^{[アップデート]})