Loading article…
Unicode（Unicode StandardおよびTUS [ 1 ] [ 2 ]としても知られる）は、Unicodeコンソーシアムによって維持されている文字エンコーディング標準であり、デジタル化可能な世界中のすべての文字体系でのテキストの使用をサポートするように設計されています。バージョン17.0 [ A ]は、さまざまな日常、文学、学術、および技術的な文脈で使用される159,801文字と172のスクリプト[ 3 ]を定義しています。
Unicodeは、異なる地域や異なるコンピュータアーキテクチャで使用されていた、互換性のない無数の文字セットという従来の環境を大きく置き換えました。これらの文字セットの全レパートリーに加え、多くの追加文字が単一のUnicodeセットに統合されました。Unicodeは、ほとんどのWebページを含むインターネット上のテキストの大部分をエンコードするために使用されており、適切なUnicodeサポートは現代のソフトウェア開発において一般的な考慮事項となっています。Unicodeは最終的に110万文字以上をエンコードすることが可能です。
Unicode文字レパートリーはISO/IEC 10646と同期しており、それぞれコード単位で同一です。しかし、Unicode 標準は文字を割り当てるレパートリー以上のものです。開発者や設計者を支援するために、この標準はチャートや参照データ、さまざまなスクリプトに関連する概念を説明し、実装のガイダンスを提供する付属文書も提供しています。これらの付属文書で扱われるトピックには、文字の正規化、文字の構成と分解、照合、方向性などがあります。[ 4 ]
Unicodeは3,790の絵文字をエンコードしており、その継続的な開発はコンソーシアムによって標準の一部として行われています。[ 5 ] Unicodeの普及は、日本国外での絵文字の初期の人気に大きく貢献しました。
Unicode テキストは、いくつかのエンコーディングのいずれかを使用してバイナリ データとして処理および保存されます。これらのエンコーディングは、標準の抽象化された文字コードをバイト シーケンスに変換する方法を定義します。Unicode標準自体は、UTF-8、UTF-16、[ a ]、UTF-32の 3 つのエンコーディングを定義していますが、他にもいくつか存在します。UTF-8 は、 ASCIIとの下位互換性があるため、圧倒的に広く使用されています。
Unicodeは、それまでに設計されたすべてのテキストエンコーディングに存在する制約を克服することを目的として設計されました。各エンコーディングはそれぞれのコンテキストでの使用を想定していましたが、他のエンコーディングとの互換性は特に期待されていませんでした。実際、選択された2つのエンコーディングを一緒に使用すると、多くの場合、全く機能せず、一方のエンコーディングでエンコードされたテキストが他方では意味不明な文字として解釈されました。ほとんどのエンコーディングは、少数のスクリプト間（多くの場合、特定のスクリプトとラテン文字の間）の相互運用を容易にするために設計されただけであり、多数のスクリプト間、あるいはサポートされているすべてのスクリプトが一貫した方法で扱われるようには設計されていませんでした。
Unicodeの根底にある理念は、文字の基本的な要素である文字素や文字素に似た単位を符号化することを目指しており、単なる文字の異体字とみなされる図形的な違いは、書体、マークアップ、またはその他の手段によって処理するのが最適である。特に複雑なケース、例えば漢字の正書法上の異体字の扱いなどでは、どの違いが独自の符号化を正当化するのか、どれが他の文字の単なる図形的な異体字なのかについて、かなりの意見の相違がある。
最も抽象的なレベルでは、Unicodeは各文字にコードポイントと呼ばれる固有の番号を割り当てます。サイズ、形状、スタイルなど、視覚的な表現に関する多くの問題は、Webブラウザやワープロソフトなど、実際にテキストを表示するソフトウェアの裁量に委ねられることを意図しています。しかし、迅速な普及を促進するという意図もあって、この当初のシンプルなモデルは時間の経過とともにやや複雑化し、規格開発の過程で様々な実用的な妥協がなされてきました。
最初の 256 個のコード ポイントはISO/IEC 8859-1規格に準拠しており、西ヨーロッパの文字で既に書かれているテキストの変換を容易にすることを目的としています。異なる従来のエンコーディングによる区別を維持し、情報損失なしにそれらと Unicode との間で変換できるようにするため、外観と意図された機能の両方で他の文字とほぼ同じ多くの文字に、個別のコード ポイントが割り当てられました。たとえば、半角形と全角形のブロックには、ラテン アルファベットの完全な意味的複製が含まれています。これは、従来のCJK エンコーディングには、「全角」（CJK 文字の幅に一致）と「半角」（通常のラテン文字の幅に一致）の両方の文字が含まれていたためです。
Unicode の起源は 1980 年代に遡り、ゼロックスの文字コード標準(XCCS)に関係のあるグループにたどり着きます。 [ 6 ] 1987 年、ゼロックスの従業員であるジョー・ベッカーは、アップルの従業員であるリー・コリンズとマーク・デイビスとともに、ユニバーサル文字セットを作成する実用性について調査を開始しました。[ 7 ]ピーター・フェンウィックとデイブ・オプスタッドからの追加の意見も得て、[ 6 ]ベッカーは 1988 年 8 月に、「国際的/多言語テキスト文字エンコーディング システム、仮称 Unicode」の草案を発表しました。彼は、「Unicode という名前は、ユニークで統一されたユニバーサル エンコーディングを示唆することを意図している」と説明しました。[ 6 ]
Unicode 88と題されたこの文書の中で、ベッカーは16 ビット文字を使用したスキームの概要を説明しました。 [ 6 ]
Unicodeは、実用的で信頼性の高い世界共通のテキストエンコーディングのニーズに応えることを目的としています。Unicodeは、おおまかに言えば、世界中のあらゆる言語の文字を網羅するために16ビットに拡張された「ワイドボディASCII 」と表現できます。適切に設計されたシステムでは、1文字あたり16 ビットでこの目的には十分すぎるほどです。
この設計上の決定は、「現代的」な使用におけるスクリプトと文字のみがエンコードを必要とするという仮定に基づいて行われた。[ 6 ]
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 が加わった。Research Libraries Group は東アジア文字セットの既存のソリューションを持っており、それが Unicode 文字セットの入力の 1 つとなった。[ 7 ] 1990 年には、 Microsoftの Michel Suignard と Asmus Freytag 、NeXTの Rick McGowan もグループに加わった。1990 年末までに、既存の標準を再マッピングする作業のほとんどが完了し、Unicode の最終レビュー草案が準備できた。
Unicodeコンソーシアムは1991年1月3日にカリフォルニア州で設立され[ 8 ] 、 Unicode標準の第1巻が同年10月に発行された。漢字を追加した第2巻は1992年6月に発行された。
1996年にUnicode 2.0でサロゲート文字メカニズムが実装され、Unicodeは16ビットに制限されなくなりました。これによりUnicodeコード空間は100万以上のコードポイントに拡大し、エジプト象形文字などの多くの歴史的な文字や、標準への組み込みが想定されていなかった数千のまれにしか使用されない、または廃止された文字のエンコードが可能になりました。これらの文字の中には、さまざまなまれにしか使用されないCJK文字があり、その多くは主に固有名詞で使用されているため、当初のUnicodeアーキテクチャが想定していたよりも、普遍的なエンコードにははるかに必要不可欠となっています。[ 9 ]
Unicode Consortium は Unicode の開発を調整する非営利団体です。正会員には、Adobe、Apple、Google、IBM、Meta (以前は Facebook)、Microsoft、Netflix、SAPなど、テキスト処理標準に関心のある主要なコンピュータ ソフトウェアおよびハードウェア企業のほとんど (およびその他少数の企業) が含まれます。[ 10 ]
長年にわたり、いくつかの国や政府機関がユニコードコンソーシアムのメンバーであった。[ 10 ]
このコンソーシアムは、既存の文字エンコーディング方式の多くは規模や範囲が限られており、多言語環境との互換性がないため、最終的にはUnicodeとその標準Unicode変換フォーマット（UTF）方式に置き換えるという野心的な目標を掲げている。
Unicode Bulldog Awardは、Unicodeの開発に影響力があるとみなされる人々に贈られる賞で、受賞者には小林達夫、トーマス・ミロ、ルーズベ・プルナダー、ケン・ルンデ、マイケル・エバーソンなどがいる。[ 11 ]
2025年9月現在Unicodeには合計172 [ 12 ]の文字体系（アルファベット、アブギダ、音節文字）が含まれており、現在使用されている主要な文字体系のほとんどを網羅しています。 [ 13 ] [ 14 ]まだエンコードされていない文字体系も存在し、特に歴史的、典礼的、学術的な文脈で主に使用されているものが挙げられます。既にエンコードされている文字体系への文字の追加や、特に数学や音楽のための記号の追加も行われています。
Unicodeロードマップ委員会（Michael Everson、Rick McGowan、Ken Whistler、VS Umamaheswaran）[ 15 ]は、UnicodeコンソーシアムのウェブサイトのUnicodeロードマップ[ 16 ]ページで、エンコードの候補または潜在的な候補となっているスクリプトのリストと、それらの暫定的なコードブロック割り当てを管理しています。JurchenやKhitan大文字など、ロードマップに掲載されているスクリプトの中には、エンコードの提案がなされ、承認プロセスが進められているものがあります。NumidianやRongorongoなど、他のスクリプトについては、まだ提案がなされておらず、関係するユーザーコミュニティからの文字レパートリーやその他の詳細に関する合意を待っています。
Unicodeにまだ含まれていない現代の創作文字（例：テングワール文字）や、実用性が低いためUnicodeへの登録資格を満たさない文字（例：クリンゴン文字）は、非公式ながら広く使用されている私的使用エリアコード割り当てとともに、ConScript Unicode Registryに記載されています。
また、中世ラテン語の特殊文字に焦点を当てた中世ユニコードフォントイニシアチブも存在します。これらの提案の一部は既にユニコードに組み込まれています。
カリフォルニア大学バークレー校のデボラ・アンダーソンが創設した スクリプトエンコーディングイニシアチブ（SEI）[ 17 ]プロジェクトは、標準にまだエンコードされていないスクリプトの提案に資金を提供することを目的として2002年に設立されました。現在アヌシャ・ホサインが運営するSEIは、近年、標準への追加提案の主要な情報源となっています。[ 18 ] SEIはUnicodeコンソーシアムおよびISO/IEC 10646標準化プロセスと協力していますが、正式な提案を作成するために必要な技術的、言語的、歴史的研究を支援するために独立して運営されています。SEIは、プロジェクトのWebサイトで、Unicode標準にまだエンコードされていないスクリプトのデータベースを維持しています。[ 19 ]
UnicodeコンソーシアムはISOと共同で、Unicode標準の初版発行後、共通の文字体系を開発しました。UnicodeとISOのUniversal Coded Character Set（UCS）は、同一の文字名とコードポイントを使用しています。ただし、Unicode版はISO版とは2つの重要な点で異なります。
UCSは単純な文字マップですが、Unicodeは異なるプラットフォームや言語間の相互運用性を実現するために必要なルール、アルゴリズム、プロパティを規定しています。そのため、Unicode標準には、ビット単位のエンコーディング、照合、レンダリングなどの詳細なトピックを網羅したより多くの情報が含まれています。また、双方向テキストのサポートに必要なものを含む文字プロパティの包括的なカタログ、実装者を支援するためのビジュアルチャートや参照データセットも提供しています。以前は、Unicode標準は、完全なコア仕様、標準付属書[注1 ]、コードチャートを含む印刷版として販売されていました。しかし、2006年に発行されたバージョン5.0が、この形式で印刷された最後のバージョンとなりました。バージョン5.2以降は、オンデマンド印刷のペーパーバックとして発行されたコア仕様のみを購入できます。[ 20 ]一方、全文はUnicodeウェブサイトで無料のPDFとして公開されています。
この出版方法の実際的な理由は、UCSとUnicodeの2つ目の重要な違い、つまり更新版のリリース頻度と新文字の追加頻度を浮き彫りにしています。Unicode規格は、毎年定期的に拡張版をリリースしており、1暦年に複数のバージョンがリリースされることもあれば、予定されていたリリースが延期されるケースもまれにあります。例えば、2020年4月、バージョン13.0が公開された1か月後、Unicodeコンソーシアムは、COVID-19パンデミックのため、バージョン14.0のリリース予定日を6か月延期し、2021年9月とすることを発表しました。
これまでに、 Unicode 標準の以下のバージョンが公開されています。文字レパートリーに変更が加えられていない更新バージョンは、3 番目の数字 (例: "バージョン 4.0.1") で示され、以下の表では省略されています。[ 21 ]
Unicode 標準では、コード空間が定義されています。[ 59 ]コードポイントと呼ばれる整数のシーケンス[ 60 ]は、0から1 114 111は、標準に従ってU+0000 – U+10FFFFと表記されます。[ 61 ]コード空間は、Unicode 標準の体系的でアーキテクチャに依存しない表現です。実際のテキストは、 UTF-8などの複数の Unicode エンコーディングのいずれかを介してバイナリ データとして処理されます。
この規範表記では、2文字の接頭辞がU+常に記述されたコードポイントの前に付き、コードポイント自体は16進数で記述されます。[注2 ]常に少なくとも4桁の16進数が記述され、必要に応じて先頭にゼロが追加されます。たとえば、コードポイントU+00F7 ÷除算記号には2つの先頭ゼロが追加されますが、U+13254 𓉔エジプト象形文字O004 ( )には追加されません。[ 63 ]
合計コード空間内には 1,112,064 個の有効なコードポイントがあります。[ 64 ]この数は、 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 ) です。非文字のセットは安定しており、新しい非文字が定義されることはありません。[ 65 ]サロゲートと同様に、これらが使用できないという規則はしばしば無視されますが、バイトオーダーマークの動作は、U+FFFE がテキストの最初のコードポイントになることは決してないことを前提としています。サロゲートと非文字の除外により、使用可能なコードポイントは1,111,998個です。
私的使用コードポイントは割り当てられているとみなされますが、Unicode標準[ 66 ]では意図的に解釈が指定されていないため、そのようなコードポイントの交換には、送信者と受信者の間で解釈に関する独立した合意が必要となります。Unicodeコード空間には、3つの私的使用領域があります。
グラフィック文字とは、Unicode標準で特定の意味を持つように定義されている文字であり、目に見えるグリフ形状を持つか、目に見える空間を表します。Unicode 17.0の時点では、159,629文字。
書式文字とは、目に見える形では現れないものの、隣接する文字の見た目や動作に影響を与える可能性のある文字です。例えば、U+200C ZERO WIDTH NON-JOINERやU+200D ZERO WIDTH JOINERは、隣接する文字のデフォルトの形状変更動作を変更するために使用できます（合字を禁止したり、合字の生成を要求したりする場合など）。Unicode 17.0 には 172 種類の書式文字があります。
U+0000～U+001FおよびU+007F～U+009Fの範囲の65個のコードポイントは、ISO/IEC 6429で定義されているC0およびC1制御コードに対応する制御コードとして予約されています。U +0009 TAB、U+000A LINE FEED、およびU+000D CARRIAGE RETURNは、Unicodeを使用するテキストで広く使用されています。文字化けとして知られる現象では、C1コードポイントは、以前は西ヨーロッパの文脈で広く使用されていたWindows-1252コードページに従って不適切にデコードされます。
グラフィック文字、フォーマット文字、制御コード文字、およびプライベート使用文字はまとめて割り当て済み文字と呼ばれます。予約済みコードポイントとは、有効で使用可能であるが、まだ割り当てられていないコードポイントのことです。Unicode 17.0 の時点で、814,664の予約済みコードポイント。
Unicode で定義されているグラフィック文字と書式文字のセットは、Unicode で表現可能な抽象文字のレパートリーに直接対応していません。Unicode は、抽象文字を特定のコードポイントに関連付けることによって文字をエンコードします。 [ 67 ]ただし、すべての抽象文字が単一の Unicode 文字としてエンコードされるわけではなく、一部の抽象文字は、Unicode では 2 つ以上の文字のシーケンスで表現される場合があります。たとえば、リトアニア語で必要な、オゴネク、上の点、および鋭アクセントが付いたラテン小文字「i」は、文字シーケンスU+012F ; U+0307 ; U+0301で表現されます。Unicode は、Unicode で直接エンコードされていない抽象文字に対して、一意の名前の文字シーケンスのリストを保持しています。[ 68 ]
割り当てられたすべての文字には、識別するための一意で不変の名前があります。この不変性は、Unicode 標準のバージョン 2.0 以降、その名前安定性ポリシーによって保証されています。[ 65 ]名前が重大な欠陥や誤解を招く場合、または重大なタイプミスがある場合は、アプリケーションが公式の文字名の代わりに使用することが推奨される正式なエイリアスが定義される場合があります。たとえば、U+A015 ꀕ YI SYLLABLE WUには正式なエイリアスYI SYLLABLE ITERATION MARK があり、U+FE18 ︘ PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRAKCET ( sic )には正式なエイリアスPRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRA CK ET があります。[ 69 ]
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は、ハングル音節を個々のハングル字母音から構成するメカニズムを提供しています。しかし、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 Standard』の印刷版に掲載されているすべてのアラビア文字の例を生成するために使用されました）のような特別な文字整形技術が必要となります。ACEは、 OpenType（Adobe社とMicrosoft社）、Graphite（SIL International社）、AAT（Apple社）の概念実証となりました。
フォントには、オペレーティングシステムにさまざまな文字シーケンスを正しく出力する方法を指示する命令も埋め込まれています。結合記号や発音記号の配置に関する簡単な解決策は、記号の幅をゼロに設定し、グリフ自体を左サイドベアリングの左または右に配置することです（使用するスクリプトの方向によって異なります）。このように処理された記号は、その前の文字の上に表示されますが、ベースグリフの幅や高さに対して位置を調整しません。視覚的に不自然になる場合があり、一部のグリフと重なることもあります。実際の重ね合わせは不可能ですが、限られたケースでは近似できます（たとえば、タイ語の上位結合母音と声調記号は、最初から異なる高さにすることができます）。一般的に、この方法は等幅フォントでのみ有効ですが、より複雑な方法が失敗した場合のフォールバックレンダリング方法として使用できます。
Unicode のいくつかのサブセットは標準化されています。Windows NT 4.0以降の Microsoft Windows は、657 文字のWGL-4をサポートしており、これはラテン文字、ギリシャ文字、またはキリル文字を使用するすべての現代ヨーロッパ言語をサポートすると考えられています。Unicode のその他の標準化されたサブセットには、多言語ヨーロッパサブセットがあります。 [ 71 ] MES-1 (ラテン文字のみ、335 文字)、MES-2 (ラテン文字、ギリシャ文字、およびキリル文字、1062 文字) [ 72 ]、および MES-3A と MES-3B (ここでは示されていない 2 つのより大きなサブセット)。MES-2 には、MES-1 と WGL-4 のすべての文字が含まれています。
規格DIN 91379 [ 73 ]は、ヨーロッパにおける名前の正しい表現とデータ交換の簡素化を可能にするために、Unicode 文字、特殊文字、文字シーケンス、および発音記号のサブセットを規定しています。この規格は、すべての欧州連合加盟国の公用語、ドイツ語の少数言語、およびアイスランド、リヒテンシュタイン、ノルウェー、スイスの公用語をサポートしています。関連する ISO 規格に従って、他の表記体系の名前をラテン文字に翻字できるように、必要なすべての基本文字と発音記号の組み合わせが提供されています。
Unicode文字を適切に処理できないレンダリングソフトウェアは、多くの場合、その文字を開いた四角形として表示するか、認識されない文字の位置を示すためにU+FFFDと表示します。一部のシステムは、そのような文字に関するより詳細な情報を提供しようと試みています。AppleのLast Resortフォントは、文字のUnicode範囲を示す代替グリフを表示し、SIL Internationalのフォールバックフォントは、文字の16進スカラー値を示すボックスを表示します。
一連のコードポイントをバイト列として格納するためのいくつかのメカニズムが規定されている。
Unicode は、Unicode 変換フォーマット(UTF) エンコーディングとユニバーサルコード化文字セット(UCS) エンコーディングという 2 つのマッピング方法を定義しています。エンコーディングは、Unicodeコード ポイントの範囲を、コード ユニットと呼ばれる固定サイズの範囲内の値のシーケンスにマッピングします。各コード ポイントは一意のシーケンスに対応します。[ 74 ]エンコーディング名の数字は、コード ユニットあたりのビット数 (UTF エンコーディングの場合) またはコード ユニットあたりのバイト数 (UCS エンコーディングとUTF-1の場合) を示します。UTF-8 と UTF-16 は最も一般的に使用されているエンコーディングです。UCS -2は UTF-16 の廃止されたサブセットです。UCS-4 と UTF-32 は機能的に同等です。
UTFエンコーディングには以下が含まれます。
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 エンコード テキストの署名として機能できる」とされています。[ 75 ]一部のソフトウェア開発者は、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オペレーティングシステムが、 UTF - 32を標準の「ワイド文字」エンコーディングとして使用しているためです。Pythonプログラミング言語の最近のバージョン（2.2以降）も、Unicode文字列の表現としてUTF-32を使用するように構成でき、高レベルのコード化されたソフトウェアでこのエンコーディングを効果的に普及させています。
Punycodeは、別のエンコード形式であり、Unicode文字列をASCIIベースのドメインネームシステム（DNS）でサポートされている限られた文字セットにエンコードすることを可能にします。このエンコードは、Unicodeでサポートされているすべてのスクリプトで国際化ドメイン名を使用できるようにするシステムであるIDNAの一部として使用されます。以前の、そして現在では歴史的な提案には、UTF-5とUTF-6があります。
GB18030 は、中国国家標準化管理委員会による Unicode の別のエンコーディング形式です。これは中華人民共和国 (PRC) の公式文字セットです。BOCU -1とSCSUは Unicode の圧縮方式です。2005年のエイプリルフール RFC では、 UTF-9とUTF-18という2 つのパロディ UTF エンコーディングが指定されました。
UTF-8の形式の Unicode は、2008 年以来、ワールド ワイド ウェブで最も一般的なエンコーディングとなっています。 [ 76 ]ほぼ普遍的に採用されており、UTF-8 以外のコンテンツの多くは、 UTF-16などの他の Unicode エンコーディングで使用されています。2024年現在UTF-8 は、平均してすべてのウェブページの 98.3% (上位 1,000 位のウェブページのうち 983 位) を占めています。[ 77 ]多くのページではコンテンツの表示にASCII文字のみを使用していますが、UTF-8 は 8 ビット ASCII をサブセットとして設計されており、現在ではエンコーディングを UTF-8 ではなく ASCII のみと宣言しているウェブサイトはほとんどありません。[ 78 ]追跡対象の言語の 3 分の 1 以上が 100% UTF-8 を使用しています。
インターネット技術タスクフォースが管理するすべてのインターネットプロトコル、例えばファイル転送プロトコル（FTP）[ 79 ]は、 1998年にRFC 2277が公開されて以来、UTF-8のサポートが必須となっています。RFC 2277では、すべてのIETFプロトコルは「UTF-8文字セットを使用できなければならない」と規定されています。[ 80 ]
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（元々はPlan 9用に開発された）[ 81 ]は、従来の拡張 ASCII文字セットの比較的簡単な代替手段であるため、ほとんどのUnix ライクなオペレーティングシステムで主要なストレージ エンコーディングとなっています（ただし、一部のライブラリでは他のエンコーディングも使用されています） 。UTF-8 は、ワールド ワイド ウェブ上のHTMLドキュメントで使用される最も一般的な Unicode エンコーディングでもあります。
Unicodeを使用する多言語テキストレンダリングエンジンには、Microsoft Windows向けのUniscribeとDirectWrite 、 macOS向けのATSUIとCore Text 、 GTK+およびGNOMEデスクトップ向けのPangoなどがある。
キーボードのレイアウトではすべての文字を単純なキーの組み合わせで対応させることはできないため、いくつかのオペレーティングシステムでは、すべての文字にアクセスできる代替入力方法を提供している。
ISO/IEC 14755 [ 82 ]は、Unicode 文字をコードポイントから入力する方法を標準化しており、いくつかの方法を規定しています。基本方式では、開始シーケンスの後にコードポイントの 16 進数表現と終了シーケンスが続きます。また、文字マップ プログラムのように、画面上のテーブルに文字を一覧表示する画面選択入力方式も規定されています。
既知の文字のコードポイントを検索するためのオンラインツールには、Jonathan Hedley によるUnicode Lookup [ 83 ]と Benjamin Milde による Shapecatcher [ 84 ]があります。Unicode Lookup では、検索キー (例: "fractions") を入力すると、対応する文字とそのコードポイントのリストが返されます。Shapecatcher はShape contextに基づいており、ボックス内に文字を描画すると、描画に近似する文字とそのコードポイントのリストが返されます。
MIMEは、電子メールのヘッダー（「件名」など）に非ASCII文字が含まれているか、本文に含まれているかに応じて、電子メール内の非ASCII文字をエンコードするための2つの異なるメカニズムを定義しています。どちらの場合も、元の文字セットと転送エンコーディングが識別されます。Unicodeの電子メール送信には、メッセージの大部分がASCII文字で構成されているかどうかに応じて、 UTF-8文字セットとBase64またはQuoted-printable転送エンコーディングが推奨されます。これら2つの異なるメカニズムの詳細はMIME規格で規定されており、通常は電子メールソフトウェアのユーザーには隠されています。
IETFはUTF-8を使用した国際化電子メールのフレームワークを定義し[ 85 ] [ 86 ] 、そのフレームワークに従っていくつかのプロトコルを更新しました[ 87 ] [ 88 ] [ 89 ] [ 90 ] 。
メールにおけるUnicodeの普及は非常に遅れています。東アジアのテキストの中には、依然としてISO-2022などのエンコーディングでエンコードされているものがあり、携帯電話などの一部のデバイスではUnicodeデータを正しく処理できないものもあります。しかし、サポートは徐々に改善されており、 Yahoo!メール、Gmail、Outlook.comなど、多くの主要な無料メールプロバイダーがUnicodeをサポートしています。
HTML 4.0以降、W3Cのすべての勧告は文書の文字セットとしてUnicodeを使用しています。Webブラウザは、特にUTF-8を中心に、長年にわたりUnicodeをサポートしています。以前は、主にフォント関連の問題に起因する表示上の問題がありました。たとえば、Microsoft Internet Explorerのv6以前のバージョンでは、明示的に指定しない限り、多くのコードポイントがレンダリングされませんでした。[ 91 ]
構文規則によって文字の出現順序が影響を受ける場合があるものの、XML（XHTMLを含む）文書は、定義上、[ 92 ]ほとんどのUnicodeコードポイントの文字で構成されており、例外として以下の文字が含まれる。
HTML 文字は、ドキュメントのエンコーディングがサポートしている場合は、そのエンコーディングに従ってバイトとして直接表現されるか、文字の Unicode コード ポイントに基づいて数値文字参照として記述されます。たとえば、参照Δ、Й、ק、م、๗、あ、叶、葉、말（または、 を接頭辞として 16 進数で表した同じ数値&#x）は、すべてのブラウザで Δ、Й、ק 、م、๗、あ、叶、葉、 、 말 と表示されるはずです。
HTTPリクエストのURLなど、URIを指定する場合、非ASCII文字はパーセントエンコードする必要があります。
Unicode は原則としてフォント自体には関心を持たず、フォントは実装上の選択肢とみなしています。[ 93 ]特定の文字には、より一般的な太字、斜体、基本文字から複雑な装飾スタイルまで、多くの異体字が存在する可能性があります。フォント内のグリフがUnicode 標準で定義されたコードポイントを使用してアクセスできる場合、そのフォントは「Unicode 準拠」です。[ 94 ]標準では、フォントに含める必要のある文字の最小数は規定されていません。フォントによっては、文字数が非常に少ないものもあります。
TrueTypeとOpenTypeがUnicodeをサポートしているため（Web Open Font Format（WOFFおよびWOFF2 ）はこれらをベースとしている） 、Unicodeベースの無料フォントと市販フォントが広く入手可能です。これらのフォント形式はUnicodeコードポイントをグリフにマッピングしますが、OpenTypeおよびTrueTypeフォントファイルは65,535グリフに制限されています。コレクションファイルは、単一のフォントファイル内でこの制限を克服するための「ギャップモード」メカニズムを提供します。（ただし、コレクション内の各フォントには依然として65,535の制限があります。）TrueTypeコレクションファイルのファイル拡張子は通常「.ttc」です。
市場には数千ものフォントが存在するが、Unicodeの文字レパートリーの大部分をサポートしようとするフォントは、10数種類にも満たない（いわゆる「パン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勧告で実現されています。このアプローチでは、考えられるすべての改行文字が内部的に共通の改行文字に変換されます（レンダリングのための内部操作なので、どの文字であるかは実際には重要ではありません）。つまり、テキストシステムは、入力の実際のエンコードに関係なく、文字を改行として正しく処理できます。
漢字研究グループ（IRG）は、コンソーシアムとISOに対し、漢字の統一、すなわちユニハン、特にCJK統一漢字と互換性漢字をレパートリーにさらに追加することについて助言する任務を負っています。IRGは、歴史的に漢字を使用してきた各地域の専門家で構成されています。しかし、委員会内での議論にもかかわらず、漢字の統一は、プロジェクトの開始以来、ユニコード標準の中で最も議論の的となっている側面の1つであり続けています。[ 95 ]
既存の文字セット規格、例えば日本語のJIS X 0208 （ Shift JISでエンコード）は、統一基準、つまり中国語の異体字が手書き/フォントの違い（したがって統一される）とみなされるか、綴りの違い（別々にエンコードされる）とみなされるかを決定するためのルールを定義しました。UnicodeのCJK文字の文字モデルは、JIS X 0208で使用されている統一基準と、中国共通中国語コード協会によって開発された基準に基づいています。[ 96 ]
標準の原則は、様式的な変種ではなく意味的な変種を符号化することであるため、Unicode は、特定の稀少で古風な漢字の変種にコード ポイントを割り当てていないため、古代の珍しい日本語名の処理が複雑になる可能性があるとして批判を受けています。中国語、日本語、韓国語は多くの文字を共有していることに特に重点を置いているため、漢統一は、3 言語を同じものとして扱っていると見なされることもあります。[ 97 ]活字の慣習や手書きのカリキュラムに関して、文字の期待される形式の地域差は、必ずしも言語の境界に沿っているわけではありません。香港と台湾はどちらも繁体字を使用して中国語を表記しますが、香港と台湾では、場合によっては好ましい文字の形式が異なります。[ 98 ]
あまり使用されていない代替エンコーディングが存在し、多くの場合、Unicode より前に存在し、文字モデルはこのパラダイムとは異なり、地域的および/または非標準的な文字形式間のさまざまなスタイルの違いを維持することを目的としています。 1 つの例は、一部のユーザーが歴史的な日本語テキストを扱うために好む TRON コードですが、日本の一般の人々の間では広く採用されていません。もう 1 つは、香港、台湾、および米国の図書館システムで採用されている CCCII エンコーディングです。これらは一般的に使用する上で独自の欠点があり、図書館システム以外ではBig5エンコーディング (CCCII の 4 年後の 1984 年に導入) が CCCII より一般的になっています。[ 99 ] Appleでの作業は、Research Libraries Groupの CJK Thesaurusに基づいており、CCCII の EACC バリアントを維持するために使用されていましたが、Unicode のUnihanセットの直接の前身の 1 つは、
Unicodeの初期バージョンでは、収録されている漢字は2万1000字未満で、主に現代で比較的よく使われるものに限られていました。バージョン17.0の現在では、10万1000字以上の漢字が収録されており、さらに数千字を追加する作業が続けられています。追加される文字は、主に中国語圏全体で使用されている歴史的な文字や方言による異体字です。
現代の書体は、統一された漢字をさまざまな地域的なグラフィック表現で表示する際の実際的な問題に対処する手段を提供します。「locl」OpenTypeテーブルを使用すると、レンダラーはテキストのロケールに基づいて各コードポイントに異なるグリフを選択できます。[ 100 ] Unicodeのバリエーションシーケンスは、目的のグリフの選択に対してテキスト内の注釈を提供することもできます。これには、特定のバリエーションを表意文字バリエーションデータベースに登録する必要があります。
同じスクリプトの文字の適切なグリフがイタリック体のみで異なる場合、Unicode は一般的にそれらを統一しています。右側のロシア語、伝統的なブルガリア語、マケドニア語、セルビア語のテキストで通常表示される 7 つの文字のイタリック グリフの比較からわかるように、違いはスマート フォント テクノロジーまたは手動でフォントを変更することによって表示されます。同じ OpenType 'locl' 技術が使用されます。[ 101 ]
トルコ語アルファベットとアゼルバイジャン語アルファベットで使用するために、Unicode にはドットのない小文字のI (ı) とドットのある大文字のI ( İ ) が別々に含まれています。ただし、小文字のドット付き i と大文字のドットなしIには、以前のISO 8859-9での処理方法に合わせて、通常の ASCII 文字が使用されます。そのため、これらの言語の大文字小文字を区別しない比較では、ラテン文字を使用する他の言語の大文字小文字を区別しない比較とは異なるルールを使用する必要があります。[ 102 ] [ 103 ]これは、たとえばサニタイズコードやアクセス制御が大文字小文字を区別しない比較に依存している場合、セキュリティ上の問題を引き起こす可能性があります。[ 103 ]
対照的に、アイスランド語のeth (ð)、横棒付きのD (đ)、そり舌音のD (ɖ)は、通常[注 4 ]大文字 (Đ) では同じように見えるが、逆の処理がされ、両方の文字ケースで別々にエンコードされる (以前のISO 6937では大文字の形が統一されていたのとは対照的)。このアプローチは、テキストの言語を知らなくても大文字小文字を区別しない比較を可能にするが、ホモグリフ攻撃に関連するセキュリティ対策が必要となるという問題もある。[ 104 ]
小文字の「i」に発音記号が付いた場合に、その文字がそのままの形で表記されるかどうかは、地域的な慣習によっても異なります。
Unicodeには多数の同形文字があり、その多くはASCII文字と非常によく似ているか、または同一です。これらの文字を置き換えると、正しく見える識別子やURLが作成されますが、実際には予想とは異なる場所に誘導される可能性があります。[ 105 ]さらに、同形文字は自然言語処理（NLP）システムの出力を操作するためにも使用できます。[ 106 ]対策としては、これらの文字の使用を禁止するか、異なる方法で表示するか、同じ識別子に解決されるようにする必要があります。[ 107 ]文字セットが膨大で常に変化しているため、これらすべては複雑です。[ 108 ] [ 109 ]
2021年に、ケンブリッジ大学とエジンバラ大学の2人の研究者によってセキュリティ勧告が発表され、BiDiマークを使用すると、コードの大部分が本来の動作とは異なる動作をする可能性があると主張されました。この問題は「トロイの木馬ソース」と名付けられました。[ 110 ]これを受けて、コードエディタは強制的なテキスト方向の変更を示すためにマークを強調表示し始めました。[ 111 ]
UTF -8およびUTF-16エンコーディングは、すべての可能なコード ユニットのシーケンスを受け入れるわけではありません。無効なシーケンスを読み取ったときの処理は実装によって異なり、セキュリティ バグにつながっています。[ 112 ] [ 113 ]
Unicodeは、既存の文字エンコーディングとの間でコードポイントごとの往復フォーマット変換を提供するように設計されているため、古い文字セットのテキストファイルをUnicodeに変換し、その後元に戻しても、コンテキスト依存の解釈を使用せずに同じファイルを取得できます。そのため、ダイアクリティカルマークと合成文字の組み合わせなど、一貫性のない従来のアーキテクチャがUnicodeに存在し、一部のテキストを表現する方法が複数存在します。これは、韓国語ハングルの3つの異なるエンコーディング形式で最も顕著です。バージョン3.0以降、異なるバージョンのUnicodeを使用するソフトウェア間の相互運用性を維持するために、既存の文字の組み合わせシーケンスで表現できる合成文字は、標準に追加されなくなりました。
既存のレガシー文字セットの文字と Unicode の文字の間には、Unicode への変換を容易にし、レガシー ソフトウェアとの相互運用性を可能にするために、直接マッピングを提供する必要があります。Shift-JISやEUC-JPなどの以前の日本語エンコーディングと Unicodeの間のさまざまなマッピングに一貫性がなかったため、特にレガシー データベース データで多用される文字 JIS X 0208 '〜' (1-33、波線) のマッピングがU+FF5E ~ FULLWIDTH TILDE ( Microsoft Windowsの場合) またはU+301C 〜 WAVE DASH (他のベンダーの場合) のいずれかにマッピングされ、ラウンドトリップ フォーマット変換の不一致が発生しました。[ 114 ]
一部の日本のコンピュータプログラマーは、Unicode ではU+005C \逆スラッシュ(バックスラッシュ)とU+00A5 ¥円記号(JIS X 0201 では 0x5C にマッピングされていた) の使用を分離する必要があるため、Unicode に反対しました。この使用法で書かれたレガシーコードが多数存在します。[ 115 ] (このエンコーディングでは、チルダ '~' 0x7E もマクロン '¯' (現在は 0xAF) に置き換えられます。) これらの文字の分離は、Unicode よりずっと前のISO 8859-1に存在します。
タミル語やデーヴァナーガリー語などのインド系文字には、 ISCII標準に準拠した 128 個のコード ポイントしか割り当てられていません。Unicode インド系テキストを正しくレンダリングするには、格納されている論理順序の文字を視覚的な順序に変換し、コンポーネントから合字 (結合子とも呼ばれる) を形成する必要があります。一部の地元の学者は、他の表記体系の慣例に反して、これらの合字に Unicode コード ポイントを割り当てることを主張しましたが、Unicode には、後方互換性のためだけにアラビア語やその他の合字が含まれています。[ 116 ] [ 117 ] [ 118 ]合字のセットはフォントに依存しており、Unicode はフォントのバリエーションに依存しないエンコーディングであるため、Unicode に新しい合字をエンコードすることはありません。2003年にチベット文字でも同様の問題が発生しました。中国国家標準化管理局が956個のチベット語の音節を事前に構成することを提案しましたが[ 119 ] 、関連するISO委員会（ ISO/IEC JTC 1/SC 2）によってエンコードが却下されました[ 120 ] 。
タイ文字のサポートは、タイ文字の順序付けに関して批判を受けています。前の子音の左側に書かれる母音 เ、แ、โ、ใ、ไ は、他のインド系文字の Unicode 表現とは異なり、音声順ではなく視覚的な順序になっています。この複雑さは、Unicode がタイ工業規格 620を継承したことに起因しており、この規格も同様に機能し、キーボード上でタイ語が常に書かれていた方法でした。この順序付けの問題により、Unicode の照合プロセスが少し複雑になり、照合のためにタイ文字を並べ替えるにはテーブル参照が必要になります。[ 97 ] Unicode が音声順に従ってエンコードを採用したとしても、辞書順で単語を照合することは依然として問題になります。例えば、 แสดง[ sa dɛːŋ ] 「perform」という単語は、子音クラスター「สด」（子音「ส」には固有の母音が付いています）で始まり、母音 แ- は、発音上は ด の後に来ますが、辞書では、母音が ส の後に来るように、単語は書かれたとおりにまとめられています。
発音記号付きの文字は、一般的に、単一の合成文字として、または基本文字と1つ以上の非間隔記号の分解されたシーケンスとして表現できます。たとえば、ḗ（マクロンとアキュートが上に付いた合成e）とḗ （ eの後にマクロンとアキュートが上に付いたもの）は、どちらもマクロン（◌̄）とアキュートアクセント（◌́ ）が付いたeとして同じようにレンダリングされるべきですが、実際には、文字の表示に使用されるレンダリングエンジンとフォントによって表示が異なる場合があります。同様に、インド系言語のローマ字表記に必要な下付きドットも、しばしば誤った位置に配置されます。多くの場合、事前に合成されたグリフにマッピングされるUnicode文字を使用することで問題を回避できますが、事前に合成された文字がエンコードされていない場合は、Graphite、OpenType（「gsub」）、またはAATテクノロジーを使用して高度なレンダリング機能を提供するCharis SILなどの特殊なUnicodeフォントを使用することで問題を解決できることがよくあります。
Unicode 標準は、安定性を保証することを目的とした規則を課しています。[ 121 ]規則の厳格さによって、変更が禁止または許可される場合があります。たとえば、コード ポイントに割り当てられた「名前」は変更できませんし、変更されることはありません。しかし、「スクリプト」プロパティは、Unicode 独自の規則により、より柔軟です。バージョン 2.0 では、Unicode はバージョン 1 から多くのコード ポイントの「名前」を変更しました。同時に、Unicode は、それ以降、コード ポイントに割り当てられた名前は決して変更されないと述べました。これは、間違いが公開された場合、たとえ些細な間違いであっても (文字名でBRACKETをBRAKCETと綴った例のように)、これらの間違いは修正できないことを意味します。2006 年に文字名の異常のリストが初めて公開され、2021 年 6 月の時点で、問題が特定された文字が 104 個ありました。[ 122 ]
Unicodeではスクリプト指定子（名前）を「Phags_Pa」と定義していますが、そのスクリプトの文字名にはハイフンが追加されます。U +A840 ꡀ PHAGS-PA LETTER KA。[ 125 ] [ 126 ]しかし、これは異常ではなく規則です。スクリプト指定子ではハイフンはアンダースコアに置き換えられます。[ 125 ]
U+のASCII近似として選択されました。 [ 62 ]Xerox PARC
の
Bob Belleville
が「ユニバーサル サイン」のセットの最初の提案を行いました
。多くの人が新しいエンコーディング設計の開発にアイデアを提供しました。1980 年以降、これらの取り組みは、現在の著者による
Xerox Character Code Standard
(XCCS) に発展しました。これは、Ed Smura、Ron Pellar らの努力により、1982 年以降 Xerox が社内標準として維持している多言語エンコーディングです。Unicode
は、XCCS での 8 年間の作業経験の結果として生まれました。 Unicodeは、ピーター・フェンウィックとデイブ・オプスタッド（純粋な16ビットコード）および
リー・コリンズ
（表意文字の統合）によって、XCCSとの根本的な違いが提唱されました
。Unicodeは、国際的な多言語通信システム製品において長年にわたりその有用性が証明されてきたXCCSの多くの機能を保持しています。
各エンコーディング形式は、UnicodeコードポイントU+0000..U+D7FFとU+E000..U+10FFFFをマッピングします。
システムが可変フォントをサポートし、1 つの言語のみを使用することを希望するが、完全な文字カバレッジ、または他の言語に適したグリフを使用するための言語タグ付きテキストの機能も必要とする場合は、この展開形式を選択してください (これには、言語タグ付けと OpenType の「locl」GSUB 機能をサポートするアプリが必要です)。