ユニコード

ユニコード
Unicodeコンソーシアムのロゴ
エイリアス
言語168 個のスクリプト(リスト)
標準ユニコード標準
エンコード形式
（珍しい）
（廃止）
先行ISO/IEC 8859など
  • 公式サイト
  • 技術ウェブサイト
この記事には一般的ではないUnicode文字が含まれています。適切なレンダリングサポートがないため、疑問符、ボックス、その他の記号が表示される場合があります。

Unicode（Unicode標準、TUS [1] [2]とも呼ばれる）は、Unicodeコンソーシアムが管理する文字符号化規格であり、世界中のあらゆる書記体系のテキストをデジタル化して利用できるように設計されています。バージョン17.0 [A]では、日常、文学、学術、技術の様々な分野で使用される159,801文字と172のスクリプト[3]が定義されています。

Unicodeは、異なるロケールや異なるコンピュータアーキテクチャで使用されていた、互換性のない無数の文字セットという従来の環境をほぼ置き換えました。これらの文字セットの全レパートリーに加え、多くの追加文字が単一のUnicodeセットに統合されました。Unicodeは、ほとんどのウェブページを含むインターネット上のテキストの大部分をエンコードするために使用されており、関連する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の14乗= 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日にカリフォルニア州で設立され、[8]同年10月にユニコード標準の第1巻が出版されました。漢字を追加した第2巻は1992年6月に出版されました。

1996年、Unicode 2.0にサロゲート文字機構が実装され、Unicodeは16ビットに制限されなくなりました。これによりUnicodeのコード空間は100万コードポイント以上に拡大し、エジプトの象形文字などの多くの歴史的文字や、標準規格への組み込みが想定されていなかった数千の稀少文字や廃止文字のエンコードが可能になりました。これらの文字の中には、稀少なCJK文字も含まれており、その多くは主に固有名詞に使用されているため、Unicodeの当初のアーキテクチャが想定していたよりも、ユニバーサルエンコードにとってはるかに重要なものとなっています。[9]

ユニコードコンソーシアム

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

長年にわたり、いくつかの国や政府機関がUnicodeコンソーシアムの会員となっています。[10]

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

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

対象となるスクリプト

OpenOffice.orgアプリケーションのこのスクリーンショットが示すように、多くの最新アプリケーションは、Unicode の多数のスクリプトのかなりのサブセットをレンダリングできます。

2025年9月現在、Unicodeには合計172 [12]の 文字（アルファベット、アブギダ、音節文字）が含まれており、現在使用されている主要な表記体系のほとんどをカバーしています。 [13] [14]歴史的、典礼的、学術的な文脈で主に使用される文字など、まだエンコードされていない文字も存在します。また、既にエンコードされている文字への文字の追加や、特に数学や音楽用の記号の追加も行われています。

スクリプト追加の提案

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

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

中世の特殊なラテン文字に焦点を当てた「中世Unicodeフォント・イニシアチブ」も存在します。これらの提案の一部は既にUnicodeに含まれています。

スクリプト・エンコーディング・イニシアティブ（SEI）[17]は、カリフォルニア大学バークレー校のデボラ・アンダーソンによって創設されたプロジェクトで、まだ標準規格にエンコードされていない文字の提案に資金を提供することを目的として2002年に設立されました。現在はアヌーシャ・ホセインによって運営されており、近年では標準規格への追加提案の主要な情報源となっています。[18] SEIはUnicodeコンソーシアムおよびISO/IEC 10646標準化プロセスと協力しながらも、独立した活動として、正式な提案の準備に必要な技術的、言語的、歴史的研究を支援しています。SEIは、プロジェクトのウェブサイトで、まだUnicode標準規格にエンコードされていない文字のデータベースを管理しています。[19]

バージョン

Unicodeコンソーシアムは、 Unicode標準の最初の発行に続いてISOと共同で共通のレパートリーを開発しました。UnicodeとISOのUniversal Coded Character Set（UCS）は、同一の文字名とコードポイントを使用しています。しかし、Unicode版はISO版とは2つの重要な点で異なります。

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

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

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

Unicodeのバージョン履歴と文字とスクリプトの注目すべき変更
バージョン日付出版物
（書籍、テキスト）		UCS版合計詳細
スクリプトキャラクター[b]
1.0.0 [22]1991年10月ISBN 0-201-56788-1（第1巻）—247129カバーされている初期の文字:アラビア語、アルメニア語、ベンガル語、ボポモフォ、キリル文字、デーヴァナーガリー文字、グルジア語、ギリシャ語とコプト語、グジャラート語、グルムキー語、ハングル語、ヘブライ語、ひらがな、カンナダ語、カタカナ、ラオス語、ラテン語、マラヤーラム語、オディア語、タミル語、テルグ語、タイ語、チベット語
1.0.1 [23]1992年6月ISBN 0-201-60845-6（第2巻）2528 327+21 204
−6		最初の20,902個のCJK統合漢字
1.1 [24]1993年6月—ISO/IEC 10646 -1:1993

[c]

2434 168+5963
−9		33文字が制御文字として再分類された。ハングル4,306音節、チベット語が削除された。
2.0 [25]1996年7月ISBN 0-201-48345-92538,885​+11 373
−6656		ハングル音節の元のセットを削除し、新しい場所に 11,172 個のハングル音節の新しいセットを追加し、チベット語を新しい場所に別の文字レパートリーで追加し、代理文字のメカニズムを定義し、第 15 面と第 16 面の私的使用領域を割り当てました。
2.1 [26]1998年5月—38 887+2
U+20AC € ユーロ記号、 U+FFFC オブジェクト置換文字[26]
3.0 [27]1999年9月ISBN 0-201-61633-5ISO/IEC 10646-1:20003849 194+10 307
チェロキー語、ゲズ語、クメール語、モンゴル語、ビルマ語、オガム語、ルーン文字、シンハラ語、シリア語、ターナ語、カナダ先住民の音節文字、イ語の音節、点字パターン
3.1 [28]2001年3月—ISO/IEC 10646-1:2000 [d]
ISO/IEC 10646-2:2001		4194 140+44 946
デゼレト、ゴシック体と古代イタリック体、西洋音楽とビザンチン音楽の記号セット、追加のCJK統合表意文字42,711個
3.2 [29]2002年3月4595 156+1016
フィリピン文字 (ブヒド、ハヌヌー、タガログ、タグバンワ)、数学記号
4.0 [30]2003年4月ISBN 0-321-18578-1ISO/IEC 10646:2003

[e]

5296 382+1226
キプロス文字、リンブー文字、線文字B、オスマニヤ文字、シャーヴィア文字、タイ・レ文字、ウガリット文字、六十四卦
4.1 [31]2005年3月—5997 655+1273
ブギス語、グラゴル語、カローシュティー語、新タイ・ルー語、古代ペルシア語、シレット・ナグリ語、ティフィナグ語、コプト語がギリシャ語から分離し、古代ギリシャの数字と音楽記号、初めて名前の付いた文字のシーケンスが導入されました。[32]
5.0 [33]2006年7月ISBN 0-321-48091-06499 024+1369
バリ文字、楔形文字、ンコ文字、パグスパ文字、フェニキア文字[34]
5.1 [35]2008年4月—75100 648+1624
カリア語、チャム語、カヤー・リ語、レプチャ語、リュキア語、リディア語、オル・チキ語、レジャン語、サウラシュトラ語、スンダ語、ヴァイ語、ファイストス・ディスクの記号セット、麻雀牌、ドミノ牌、ビルマ語への追加、筆写略語、U+1E9E ẞラテン大文字シャープS
5.2 [36]2009年10月ISBN 978-1-936213-00-990107 296+6648
アヴェスター語、バムム語、ガーディナーのエジプト象形文字一覧、帝国アラム語、碑文パフラヴィー語、碑文パルティア語、ジャワ語、カイティ語、リス語、ミーテイ・マエク語、古代南アラビア語、古代テュルク語、サマリア語、タイ・タム語およびタイ・ヴィエット語、追加のCJK統合表意文字、古代ハングルの字母、ヴェーダ・サンスクリット語
6.0 [37]2010年10月ISBN 978-1-936213-01-6ISO/IEC 10646:2010

[女性]

93109 384+2088
バタク文字、ブラーフミー文字、マンダ文字、トランプの記号、交通機関や地図の記号、錬金術の記号、顔文字、[38]その他のCJK統合表意文字
6.1 [39]2012年1月ISBN 978-1-936213-02-3ISO/IEC 10646:2012

[グラム]

100110 116+732
チャクマ、メロイティック筆記体、メロイティック象形文字、ミャオ族、シャラダ、ソラ・ソンペン、およびタクリ
6.2 [40]2012年9月ISBN 978-1-936213-07-8110 117+1
U+20BA ₺ トルコリラ記号
6.3 [41]2013年9月ISBN 978-1-936213-08-5110 122+5
5つの双方向書式設定文字
7.0 [42]2014年6月ISBN 978-1-936213-09-2123112,956​+2834
Bassa Vah、白人のアルバニア人、Duployan、Elbasan、Grantha、Khojki、Khudawadi、Linear A、Mahajani、Manichaean、Mende Kirakui、Modi、Mro、Nabatean、古北アラビア、Old Permic、Pahawh Hmong、Palmyrene、Pau Cin Hau、パフラヴィー詩篇、シッダム、ティルフタ、ワランシティ、および絵文字
8.0 [43]2015年6月ISBN 978-1-936213-10-8ISO/IEC 10646:2014

[h]

129120 672+7716
アホム文字、アナトリア象形文字、ハトラ文字、ムルタニ文字、古代ハンガリー文字、手話、追加のCJK統合表意文字、チェロキー語の小文字、5つの肌の色修飾子
9.0 [46]2016年6月ISBN 978-1-936213-13-9135128 172+7500
アドラム、バイスキスキ、メルヘン、ネワ、オセージ、タングート、72 絵文字[47]
10.0 [48]2017年6月ISBN 978-1-936213-16-0ISO/IEC 10646:2017

[私]

139136 690+8518
ザナバザール広場、ソヨンボ、マサラム・ゴンディ、ヌーシュ文字、ヘンタイガナ、7,494 CJK統合表意文字、56 絵文字、U+20BF ₿ビットコイン記号
11.0 [49]2018年6月ISBN 978-1-936213-19-1146137 374+684
ドグラ文字、グルジア語ムタヴルリ大文字、グンジャラ・ゴンディー文字、ハニーフィー文字、ロヒンギャ文字、インド諸語シヤーク数字、マカッサル文字、メデファイドリン文字、古代ソグド文字とソグド文字、マヤ数字、5つのCJK統合表意文字、シャンチーと星評価の記号、145個の絵文字
12.0 [50]2019年3月ISBN 978-1-936213-22-1150137,928​+554
エリュマイ語、ナンディナガリ文字、ニャイアケン・プアチュエ・モン語、ワンチョ文字、ミャオ文字、ひらがなとカタカナの小文字、タミル語の歴史的分数と記号、パーリ語のラオ文字、エジプト語とウガリット語の翻字のラテン文字、象形文字の書式コントロール、61個の絵文字
12.1 [51]2019年5月ISBN 978-1-936213-25-2137,929​+1
U+32FF ㋿ 元号 令和
13.0 [52]2020年3月ISBN 978-1-936213-26-9ISO/IEC 10646:2020

[53]

154143 859+5930
コーラス文字、ディヴェス・アクル文字、契丹小文字、ヤジディ文字、4,969個のCJK表意文字、ハウサ語、ウォロフ語、その他のアフリカ言語の表記に使用されるアラビア文字の追加、パキスタンのヒンドゥ教とパンジャブ語の表記に使用される追加、広東語に使用されるボポモフォの追加、クリエイティブ・コモンズ・ライセンス・シンボル、テレテキストおよび家庭用コンピュータシステムとの互換性のためのグラフィック文字、55個の絵文字
14.0 [54]2021年9月ISBN 978-1-936213-29-0159144 697+838
Toto、Cypro-Minoan、Vithkuqi、Old Uyghur、Tangsa、拡張 IPA、アフリカ全土およびイラン、パキスタン、マレーシア、インドネシア、ジャワ、ボスニアの言語で使用するためのアラビア文字の追加、敬語とコーランの使用の追加、北米、フィリピン、インド、モンゴルでのサポート言語の追加、U+20C0 ⃀ SOM SIGN、Znamenny Musical表記、絵文字 37 個
15.0 [55]2022年9月ISBN 978-1-936213-32-0161149 186+4489
カウィ文字とムンダリ文字、20個の絵文字、4,192個のCJK表意文字、エジプトの象形文字の制御文字
15.1 [56]2023年9月ISBN 978-1-936213-33-7149 813+627
追加のCJK表意文字
16.0 [57]2024年9月ISBN 978-1-936213-34-4168154,998​+5185
ガライ、グルン・ケマ、キラット・ライ、オル・オナル、スヌワール、トドゥリ、トゥル・ティガラリ、 7 絵文字、 3,995 エジプト象形文字
17.0 [58]2025年9月ISBN 978-1-936213-35-1172159 801+4803
Beria Erfe、Tai Yo、Sidetic、Tolong Siki、U+20C1 ⃁ SAUDI RIYAL SIGN、 7 絵文字、 4,316 CJK 統一表意文字
  1. ^ Windows に関する多くのドキュメントでは、「Unicode」という用語がUTF-16 エンコードのみを意味するものとして誤って使用されています。
  2. ^ 私用文字、制御文字、非文字、およびサロゲート コード ポイントを除くグラフィック文字と書式文字の合計数。
  3. ^
    • 2.0 修正事項 5、6、7 を追加
    • 2.1 修正第 18 号から 2 つの文字を追加しました。
  4. ^ 3.2 修正案 1 を追加しました。
  5. ^
    • 4.1 修正1を追加
    • 5.0では、修正第2条と修正第3条の4文字が追加されました。
    • 5.1 修正第4号を追加
    • 5.2 修正案5および6を追加
  6. ^ インドルピー記号を追加
  7. ^
  8. ^ さらに修正第1号、ラリ文字、9つのCJK統合表意文字、41の絵文字を追加。[44]
    9.0では修正第2号、アドラム文字、ネワ文字、日本のテレビ記号、74の絵文字と記号を追加しました。[45]
  9. ^
    • さらに56個の絵文字、285個の変体仮名文字、3個のザナバザールスクエア文字
    • 11.0では、ムタヴルリ語の大文字46個、CJK統合表意文字5個、絵文字66個が追加されました。
    • 12.0 では 62 個の追加文字が追加されました。

アーキテクチャと用語

コードスペースとコードポイント

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

この規範的な記法では、2文字の接頭辞はU+常にコードポイントの前に付き、コードポイント自体は16進数で表記されます。[注 2]少なくとも4桁の16進数が常に表記され、必要に応じて先頭にゼロが付加されます。例えば、コードポイントU+00F7 ÷ DIVISION SIGNは先頭に2つのゼロが付加されますが、U+13254 𓉔 EGYPTIAN HIEROGLYPH 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の倍数ですが、それ以外は任意です。特定のスクリプトに必要な文字は、コード空間内の複数の異なる、場合によっては分離したブロックに分散している場合があります。

一般カテゴリプロパティ

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

一般カテゴリ（Unicode文字プロパティ）[a]
価値カテゴリー メジャー、マイナー基本型[b]割り当てられた文字[b]カウント[c] （17.0時点）
備考
 
L , レター; LC , 大文字小文字（Lu、Ll、Lt のみ）[d]
ルー文字、大文字グラフィックキャラクター1,886
Ll文字（小文字）グラフィックキャラクター2,283
中尉文字、タイトルケースグラフィックキャラクター31大文字の後に小文字が続く二重字（例：Dž、Lj、Nj、Dz）
ルム文字、修飾語グラフィックキャラクター410修飾文字
ロ手紙、その他グラフィックキャラクター141,062表意文字または一文字アルファベットの文字
M、マーク
マンマーク、非スペースグラフィックキャラクター2,059
マックマーク、スペース結合グラフィックキャラクター471
自分マーク、同封グラフィックキャラクター13
N、番号
ンド数値、小数点グラフィックキャラクター770これらすべて、そしてこれらだけが数値型= De [e]です。
Nl数字、文字グラフィックキャラクター239文字または文字のような記号で構成される数字（例：ローマ数字）
いいえ番号、その他グラフィックキャラクター915例：普通分数、上付き数字と下付き数字、20進数字
P、句読点
パソコン句読点、接続詞グラフィックキャラクター10「_」などのスペースアンダースコア文字やその他のスペースタイ文字が含まれます。他の句読点文字とは異なり、これらは正規表現ライブラリによって「単語」文字として分類される場合があります。[f]
パッド句読点、ダッシュグラフィックキャラクター27複数のハイフン文字を含む
追伸句読点、開くグラフィックキャラクター79開き括弧文字
ペ句読点、終了グラフィックキャラクター77閉じ括弧文字
円周率句読点、最初の引用符グラフィックキャラクター12開始引用符。ASCIIの「中立」引用符は含まれません。使用方法によってはPsまたはPeのように動作する場合があります。
Pf句読点、最後の引用符グラフィックキャラクター10閉じ引用符。使用法に応じてPsまたはPeのように動作する場合がある。
ポー句読点、その他グラフィックキャラクター641
S、シンボル
小記号、数学グラフィックキャラクター960数学記号（例：+、-、=、×、÷、√、∊、≠ ）。括弧と角括弧はPsおよびPeカテゴリに属し、含まれません。また、 !、*、-、/も含まれません。これらは数学演算子として頻繁に使用されますが、主に「句読点」とみなされます。
Sc記号、通貨グラフィックキャラクター64通貨記号
スク記号、修飾語グラフィックキャラクター125
それでシンボル、その他グラフィックキャラクター7,468
Z、セパレーター
Zs区切り文字、スペースグラフィックキャラクター17スペースを含みますが、TAB、CR、LFは含みません。これらはCcです。
Zl区切り線形式キャラクター1U+2028行区切り文字(LSEP)のみ
Zp区切り文字、段落形式キャラクター1U+2029段落区切り文字(PSEP)のみ
C、その他
CCその他、コントロールコントロールキャラクター65（決して変わらない）[e]名前なし、[g] <コントロール>
参照その他、フォーマット形式キャラクター170ソフトハイフン、結合制御文字（ZWNJとZWJ ）、双方向テキストをサポートする制御文字、言語タグ文字が含まれます。
Csその他、代理出産代理母いいえ（ UTF-16でのみ使用）2,048（決して変わらない）[e]名前なし、[g] <代理>
共同その他、私的使用私的使用キャラクター（ただし解釈は指定されていない）合計137,468（変更なし）[e]（BMPで6,400 、プレーン15～16で131,068 ）名前なし、[g] <私用>
CNその他、割り当てられていない非キャラクターない66（Unicodeコードポイントの範囲が拡張されない限り変更されない）[e]名前なし、[g] <非文字>
予約済みない814,664名前なし、[g] <予約済み>
  1. ^ 「表4-4: 一般カテゴリ」. Unicode標準. Unicodeコンソーシアム. 2025年9月.
  2. ^ ab 「表2-3: コードポイントの種類」. Unicode標準. Unicodeコンソーシアム. 2025年9月.
  3. ^ "DerivedGeneralCategory.txt". Unicodeコンソーシアム. 2025年7月24日.
  4. ^ 「5.7.1 一般カテゴリ値」。UTR #44: Unicode文字データベース。Unicodeコンソーシアム。2024年8月27日。
  5. ^ abcde Unicode 文字エンコーディングの安定性ポリシー: プロパティ値の安定性 安定性ポリシー: 一部の gc グループは決して変更されません。gc=Nd は、数値型 = De (10 進数) に対応します。
  6. ^ 「付録C：互換性特性（§単語）」. Unicode正規表現. バージョン23. Unicodeコンソーシアム. 2022年2月8日. Unicode技術標準#18.
  7. ^ abcde 「表4-9: コードポイントラベルの構成」。Unicode標準。Unicodeコンソーシアム。2025年9月。コードポイントラベルは、名前のないコードポイントを識別するために使用できます。例：<control- hhhh >、<control-0088>。名前は空白のままにしておくことで、ドキュメント内で誤ってコントロール名を実際のコントロールコードに置き換えてしまうことを防ぐことができます。Unicodeでは、<非文字>の代わりに<文字ではない>も使用されます。

その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つの私的使用領域があります。

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

図形文字とは、Unicode標準によって特定の意味を持つように定義されている文字であり、目に見えるグリフ形状を持つか、目に見える空間を表すかのいずれかです。Unicode 17.0時点では、159,629個のグラフィック文字。

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

65個のコードポイント（ U+0000～U+001FおよびU+007F～U+009Fの範囲）は制御コードとして予約されており、ISO/IEC 6429で定義されているC0およびC1制御コードに対応しています。U +0009 （タブ）、U+000A （ラインフィード）、U+000D （キャリッジリターン）は、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 BRA CK ETの正式な別名は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部首補足ブロックは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にはいくつかのサブセットが標準化されています。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規格に従ってラテン文字に翻字できるように、必要な基本文字と分音記号の組み合わせがすべて提供されています。

WGL-4、MES-1、MES-2
行細胞範囲
0020～7E基礎ラテン語（00～7F）
A0～FFラテン語1補足（80–FF）
0100–13、14–15、16–2B、2C –2D、2E–4D、 4E–4F、50–7E、 7Fラテン語拡張A（00～7F）
8F、92、 B7、DE-EF、FA-FFラテン語拡張-B (80–FF ... )
0218–1B、1E–1Fラテン語拡張B（... 00～4F）
59、7C、92IPA拡張（50～AF）
BB–BD、C6、C7、 C9、 D6、D8–DB、 DC、DD、 DF、EE間隔修飾文字（B0～FF）
0374–75、7A、7E、84–8A、8C、8E–A1、A3–CE、 D7、DA–E1ギリシャ語（70～FF）
0400–5F、90–91、92 –C4、C7–C8、CB–CC、D0–EB、EE–F5、F8–F9キリル文字（00～FF）
1E02–03、0A–0B、1E–1F、40–41、56–57、60–61、6A–6B、80–85、9B、 F2 –F3ラテン語拡張追加（00～FF）
1階00–15、18–1D、20–45、48–4D、50–57、59、5B、5D、5F–7D、80–B4、B6–C4、C6–D3、D6–DB、DD–EF、F2–F4、F6–FEギリシャ語拡張（00～FF）
2013–14, 15, 17, 18–19, 1A–1B, 1C–1D, 1E, 20–22, 26, 30, 32–33, 39–3A, 3C, 3E, 44, 4A一般的な句読点（00～6F）
7階、82上付き文字と下付き文字（70～9F）
A3～A4、A7、AC、 AF通貨記号（A0～CF）
2105、13、16、22、26、2E​​文字のような記号（00～4F）
5B～5E数形（50～8F）
90～ 93、94～95、A8矢（90～FF）
2200、02、03、06、08 ～ 09、0F 、11～ 12、15、19 ～1A、1E～1F、27～ 28、29、2A、2B、 48、59、60～61、64～65、82～83、95、97数学演算子(00～FF)
2302、0A、20～21、29～ 2Aその他技術（00～FF）
2500、02、0℃、10、14、18、1℃、24、2℃、34、3℃、50～6℃ボックスドローイング（00～7F）
80、84、88、8C、90～93ブロックエレメント（80～9階）
A0～A1、AA～AC、B2、BA、BC、C4、CA～CB、CF、D8～D9、E6幾何学図形（A0～FF）
263A～3C、40、42、60、63、65～66、6A 、 6Bその他の記号(00～FF)
F0（01～02）私的利用エリア（00～FF…）
フェイスブック01～02アルファベット順プレゼンテーションフォーム（00～4F）
FFFDスペシャル

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

マッピングとエンコーディング

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

Unicode は、 Unicode Transformation Format (UTF) エンコーディングとUniversal Coded Character Set (UCS) エンコーディングの2 つのマッピング方式を定義しています。エンコーディングは、Unicodeコード ポイントの範囲 (場合によってはそのサブセット) を、コード ユニットと呼ばれる固定サイズの範囲にある値のシーケンスにマッピングします。すべての UTF エンコーディングは、コード ポイントを一意のバイト シーケンスにマッピングします。[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 を使用するように設定できるため、高レベルのコード化ソフトウェアで UTF-32 エンコーディングが効果的に普及しています。

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

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

採択

WikibooksにはUnicode/バージョンに関する書籍があります。

UTF-8形式の Unicode は、2008 年以来、ワールド ワイド ウェブで最も一般的なエンコーディングとなっています。 [76]これはほぼ普遍的に採用されており、非 UTF-8 コンテンツの多くは、 UTF-16などの他の Unicode エンコーディングで見つかります。2024 年の時点で、UTF-8 は平均してすべてのウェブ ページの 98.3% を占めています (上位 1,000 のウェブ ページのうち 983 ページも UTF-8 です)。[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では、検索キー（例えば「分数」）を入力すると、対応する文字とそのコードポイントのリストが返されます。Shapecatcherでは、Shapeコンテキストに基づいて、ボックス内に文字を描くと、その描画に近い文字とそのコードポイントのリストが返されます。

メール

MIMEは、電子メール内の非ASCII文字をエンコードするための2つの異なるメカニズムを定義しています。これは、文字が電子メールヘッダー（「Subject:」など）にあるか、メッセージの本文にあるかによって異なります。どちらの場合も、元の文字セットと転送エンコーディングが識別されます。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を文書文字セットとして使用しています。ウェブブラウザは長年にわたりUnicode、特にUTF-8をサポートしています。以前は、主にフォント関連の問題に起因する表示上の問題がありました。例えば、Microsoft Internet Explorerのバージョン6以前では、明示的にそれらを含むフォントを使用するように指示しない限り、多くのコードポイントがレンダリングされませんでした。[91]

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

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

HTML文字は、文書のエンコーディングがサポートしている場合はそのエンコーディングに従ってバイトとして直接表現されます。また、ユーザーは文字のUnicodeコードポイントに基づいて数値文字参照として記述することもできます。例えば&#916;、、、、、、、、、、 （または同じ数値を16進数で表し、接頭辞として&#1049;）&#1511;という参照は、すべてのブラウザで&#1605;Δ 、 &#3671;Й 、ק、م、๗、あ、叶、葉、말と表示されます。&#12354;&#21494;&#33865;&#47568;&#x

URI を、たとえばHTTPリクエスト内のURLとして指定する場合、非 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の文字レパートリーの大部分をサポートしようとしているフォントは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に対し、漢字統合（Unihan）、特にCJK統合漢字および互換漢字のレパートリーへの追加について助言する役割を担っています。IRGは、歴史的に漢字を使用してきた各地域の専門家で構成されています。しかし、委員会内での審議にもかかわらず、漢字統合は、プロジェクトの発足以来、Unicode標準において常に最も議論の的となっている側面の一つです。 [95]

日本語JIS X 0208 （ Shift JISでエンコード）などの既存の文字セット規格では、統一基準が定義されています。これは、異体字の漢字を、筆跡やフォントの違いとして（したがって統一して）扱うべきか、それとも綴りの違いとして（別々にエンコードして）扱うべきかを判断するための規則です。UnicodeのCJK文字モデルは、JIS X 0208で使用される統一基準と、中国の共通中国語コード協会（Association for a Common Chinese Code）によって開発された基準に基づいています。[96]

ユニコードは、文体上の異体ではなく意味上の異体文字を符号化するという標準原則に基づき、一部の稀少で古風な漢字異体にコードポイントを割り当てていないとして批判を受けており、古代の珍しい日本語名の処理が複雑になる可能性がある。また、中国語、日本語、韓国語が多くの共通文字を持つことに特に重点が置かれているため、漢字統一はこれら3言語を同一視していると見なされることもある。[97]活字表記の慣習や手書きのカリキュラムの観点から、期待される文字形態の地域差は、必ずしも言語の境界に沿っているわけではない。香港と台湾はどちらも中国語を繁体字で表記しているが、推奨される文字形態が異なる場合もある。[98]

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

Unicodeの初期バージョンでは、漢字の収録数は21,000字未満で、主に現代で比較的一般的に使用されている漢字に限られていました。バージョン17.0の時点で、この規格は101,000字以上の漢字をエンコードしており、さらに数千字を追加する作業が続けられています。これらの漢字は主に、漢語圏全体で使用されている歴史的および方言的な異体字です。

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

キリル文字のイタリック体または筆記体

直立、斜体、イタリック体の代替形式で示されたさまざまなキリル文字

同じ文字体系の文字の適切なグリフがイタリック体のみ異なる場合、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）

小文字のIが発音区別記号を適用したときにそのタイトルを保持するかどうかも、地域の慣習によって異なります。

安全

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

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

UTF -8およびUTF-16エンコーディングは、コード単位のあらゆるシーケンスを受け入れるわけではありません。実装によって無効なシーケンスを読み込んだ場合の対応が異なり、セキュリティ上のバグが発生しています。[112] [113]

レガシー文字セットへのマッピング

Unicode は、既存の文字エンコードとの間でコードポイントごとのラウンドトリップ形式変換ができるように設計されており、古い文字セットのテキストファイルを 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（他のベンダーの場合）にマッピングする際に顕著であった。[114]

日本のコンピュータプログラマーの中には、UnicodeではU+005C \ REVERSE SOLIDUS（バックスラッシュ）とU+00A5 ¥ YEN SIGN （円記号）を区別する必要があり、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ɛːŋ] 「実行する」という単語は、子音連結「สด」（子音「ส」に固有の母音を含む）で始まり、母音 แ- は話し言葉では ด の後に来ますが、辞書では、単語は書き言葉どおりに照合され、母音は ส の後に来ます。

文字の組み合わせ

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

異常

Unicode規格は、安定性を保証するための規則を定めています。[121]規則の厳しさに応じて、変更が禁止または許可されます。例えば、コードポイントに与えられた「名前」は変更できず、変更されることはありません。しかし、「スクリプト」プロパティは、Unicode独自の規則により、より柔軟です。Unicodeバージョン2.0では、バージョン1から多くのコードポイント「名前」が変更されました。同時に、Unicodeは、それ以降、コードポイントに割り当てられた名前は決して変更されないことを表明しました。これは、誤りが公開された場合、たとえ些細な誤りであっても（文字名でBRACKETをBRAKCETと綴った場合のように）、修正できないことを意味します。2006年に文字名の異常リストが初めて公開され、2021年6月時点で、問題が特定された文字は104文字ありました。[122]例えば、以下の通りです。

  • U+034F ͏ 結合グラフェム結合子: グラフェムを結合しない。 [122]
  • U+2118 ℘ SCRIPT CAPITAL P : これは小文字である。大文字はU+1D4AB 𝒫 MATHEMATICAL SCRIPT CAPITAL Pである。 [123]
  • U+A015 ꀕ YI SYLLABLE WU : これは Yi 音節ではなく、 Yi 繰り返し記号です。
  • U+FE18 ︘ 垂直右白レンズ状括弧の表示形式：括弧の綴りが間違っています。 [124] （綴りの誤りはUnicode別名を使用して解決されます。）

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

参照

注記

  1. ^ 「Unicode標準付録（UAX）はUnicode標準の不可欠な部分を構成しますが、別の文書として公開されています。」[1]
  2. ^ 2文字の接頭辞はU+228E ⊎ MULTISET UNIONU+のASCII近似値として選択された。[62]
  3. ^ コードポイントは、UCS文字を0から1,114,111までの整数で抽象的に表現したものです（1,114,112 = 2 20 + 2 16または 17 × 2 16 = 0x110000 コードポイント）。
  4. ^ まれに、アイスランド語の大文字のethは、特に大文字の屈曲Dと区別する必要がある場合、横棒を語幹上に置く島嶼型（Ꝺ）で書かれることがある（アフリカ参照アルファベットを参照）。

参考文献

  1. ^ Unicode標準、バージョン17.0.0。カリフォルニア州サウスサンフランシスコ：Unicodeコンソーシアム。2025年9月9日。ISBN 978-1-936213-35-1。
  1. ^ 「Unicode技術レポート #28: Unicode 3.2」. Unicodeコンソーシアム. 2002年3月27日. 2022年6月23日閲覧。
  2. ^ Jenkins, John H. (2021年8月26日). 「Unicode標準付録#45: U-source表意文字」. Unicodeコンソーシアム. §2.2 Sourceフィールド. 2022年6月23日閲覧。
  3. ^
    • 「Unicode文字カウント V17.0」。Unicodeコンソーシアム。2025年9月10日。
    • 「Unicode 17.0 バージョンチャート索引」. Unicodeコンソーシアム. 2025年9月10日.
    • 「サポートされている文字群」. Unicodeコンソーシアム. 2025年9月10日. 2025年9月10日閲覧。
  4. ^ 「Unicode標準：技術入門」2019年8月22日. 2024年9月11日閲覧。
  5. ^ “Emoji Counts, v16.0”. Unicodeコンソーシアム. 2024年9月10日閲覧。
  6. ^ abcde Becker, Joseph D. (1998-09-10) [1988-08-29]. 「Unicode 88」(PDF) . Unicode Consortium . 2016-11-25にオリジナルからアーカイブ(PDF) . 2016-10-25に閲覧。 1978年、ゼロックス研究所のボブ・ベルビルが「ユニバーサルサイン」の最初の提案を行いました。多くの人々が新しいエンコーディング設計の開発にアイデアを提供しました。1980年初頭、これらの取り組みは、著者によってゼロックス文字コード標準(XCCS) へと発展しました。これは多言語エンコーディングであり、エド・スムラ、ロン・ペラー、その他多くの人々の努力により、1982年以来ゼロックス社内標準として維持されています。Unicodeは、8年間のXCCSの実践経験の結果として生まれました。 XCCSとの根本的な違いは、ピーター・フェンウィックとデイブ・オプスタッド（純粋な16ビットコード）とリー・コリンズ（表意文字の統合）によって提案されました。UnicodeはXCCSの多くの機能を保持しており、その有用性は長年にわたり国際的なコミュニケーション多言語システム製品において実証されてきました。
  7. ^ 「Summary Narrative」. Unicode . 2006年8月31日. 2010年3月15日閲覧。
  8. ^ 「Unicodeリリースおよび発行日の履歴」Unicode . 2023年3月20日閲覧。
  9. ^ Searle, Stephen J.「Unicode Revisited」 。 2013年1月18日閲覧。
  10. ^ ab 「Unicodeコンソーシアムメンバー」 。 2024年2月12日閲覧。
  11. ^ “Unicode Bulldog Award”. Unicode . 2023年11月11日時点のオリジナルよりアーカイブ。
  12. ^ 「サポートされているスクリプト」. Unicode . 2025年9月9日閲覧。
  13. ^ Otung, Ifiok (2021-01-28). コミュニケーションエンジニアリングの原理. John Wiley & Sons. p. 12. ISBN 978-1-119-27407-0。
  14. ^ 「Unicode FAQ」 . 2020年4月2日閲覧。
  15. ^ 「BMPへのロードマップ」Unicodeコンソーシアム. 2018年7月30日閲覧。
  16. ^ “Roadmaps to Unicode”. Unicode . 2023年12月8日時点のオリジナルよりアーカイブ。
  17. ^ “Script Encoding Initiative”. Script Encoding Initiative . 2023年3月25日時点のオリジナルよりアーカイブ。
  18. ^ 「スクリプトエンコーディングイニシアチブについて」Unicodeコンソーシアム. 2012年6月4日閲覧。
  19. ^ 「エンコードするスクリプト」。
  20. ^ 「Unicode 6.1 ペーパーバック版が発売」announcements_at_unicode.org . 2012年5月30日閲覧。
  21. ^ 「Unicode標準の列挙バージョン」 。 2025年9月12日閲覧。
  22. ^
    • Unicode標準バージョン1.0.0. カリフォルニア州マウンテンビュー: Unicodeコンソーシアム. 1991年10月.
    • 「1.0.0/UnicodeData.txt（再構築）」2004年。 2010年3月16日閲覧。
  23. ^
    • Unicode標準バージョン1.0.1. カリフォルニア州マウンテンビュー: Unicodeコンソーシアム. 1992年6月.
    • 「Unicodeデータ1.0.1」 。 2010年3月16日閲覧。
  24. ^
    • Unicode標準バージョン1.1.5. カリフォルニア州マウンテンビュー: Unicodeコンソーシアム. 1995年7月.
    • 「Unicodeデータ1995」 。 2010年3月16日閲覧。
  25. ^
    • Unicode標準バージョン2.0.0. カリフォルニア州マウンテンビュー: Unicodeコンソーシアム. 1996年7月.
    • 「Unicode Data-2.0.14」 。 2010年3月16日閲覧。
  26. ^ ab
    • Unicode標準バージョン2.1.2. カリフォルニア州マウンテンビュー: Unicodeコンソーシアム. 1998年5月.
    • 「Unicode Data-2.1.2」 。 2010年3月16日閲覧。
  27. ^
    • Unicode標準バージョン3.0.0. カリフォルニア州マウンテンビュー: Unicodeコンソーシアム. 1999年9月.
    • 「Unicode Data-3.0.0」 。 2023年10月2日閲覧。
  28. ^
    • Unicode標準バージョン3.1.0. カリフォルニア州マウンテンビュー: Unicodeコンソーシアム. 2001年3月.
    • 「Unicode Data-3.1.0」 。 2023年10月2日閲覧。
  29. ^
    • Unicode標準バージョン3.2.0. カリフォルニア州マウンテンビュー: Unicodeコンソーシアム. 2002年3月.
    • 「Unicode Data-3.2.0」 。 2023年10月2日閲覧。
  30. ^
    • Unicode標準バージョン4.0.0。カリフォルニア州マウンテンビュー：Unicodeコンソーシアム。2003年4月。ISBN 0-321-18578-1。
    • 「Unicode Data-4.0.0」 。 2023年10月2日閲覧。
  31. ^
    • Unicode標準バージョン4.1.0。カリフォルニア州マウンテンビュー：Unicodeコンソーシアム。2004年3月。ISBN 0-321-18578-1。
    • 「Unicode Data-4.1.0」 。 2010年3月16日閲覧。
  32. ^ "Named Sequences-4.1.0". Unicode . 2005年. 2010年3月16日閲覧。
  33. ^ Unicode標準バージョン5.0.0. カリフォルニア州マウンテンビュー：Unicodeコンソーシアム. 2006年7月14日. ISBN 0-321-48091-0。
  34. ^ 「Unicode Data 5.0.0」 。 2010年3月17日閲覧。
  35. ^
    • Unicode標準バージョン5.1.0. カリフォルニア州マウンテンビュー: Unicodeコンソーシアム. 2008年4月4日. ISBN 0-321-48091-0。
    • 「Unicodeデータ5.1.0」 。 2010年3月17日閲覧。
  36. ^
    • Unicode標準バージョン5.2.0. カリフォルニア州マウンテンビュー: Unicodeコンソーシアム. 2009年10月1日. ISBN 978-1-936213-00-9。
    • 「Unicodeデータ5.2.0」 。 2010年3月17日閲覧。
  37. ^
    • Unicode標準バージョン6.1.0. カリフォルニア州マウンテンビュー: Unicodeコンソーシアム. 2012年1月31日. ISBN 978-1-936213-02-3。
    • 「Unicodeデータ6.0.0」 。 2010年10月11日閲覧。
  38. ^ 「Unicode 6.0 Emoji List」. emojipedia.org . 2022年9月21日閲覧。
  39. ^
    • Unicode標準バージョン6.1.0. カリフォルニア州マウンテンビュー: Unicodeコンソーシアム. 2012年1月31日. ISBN 978-1-936213-02-3。
    • 「Unicodeデータ6.1.0」 。 2012年1月31日閲覧。
  40. ^
    • Unicode標準バージョン6.2.0。カリフォルニア州マウンテンビュー：Unicodeコンソーシアム。2012年9月26日。ISBN 978-1-936213-07-8。
    • 「Unicodeデータ6.2.0」 。 2012年9月26日閲覧。
  41. ^
    • Unicode標準バージョン6.3.0。カリフォルニア州マウンテンビュー：Unicodeコンソーシアム。2013年9月30日。ISBN 978-1-936213-08-5。
    • 「Unicodeデータ6.3.0」 。 2013年9月30日閲覧。
  42. ^
    • Unicode標準バージョン7.0.0。カリフォルニア州マウンテンビュー：Unicodeコンソーシアム。2014年6月16日。ISBN 978-1-936213-09-2。
    • 「Unicodeデータ7.0.0」 。 2014年6月15日閲覧。
  43. ^
    • Unicode標準バージョン8.0.0。カリフォルニア州マウンテンビュー：Unicodeコンソーシアム。2015年6月17日。ISBN 978-1-936213-10-8。
    • 「Unicodeデータ8.0.0」 。 2015年6月17日閲覧。
  44. ^ Unicode標準バージョン8.0.0. カリフォルニア州マウンテンビュー：Unicodeコンソーシアム. 2015年6月17日. ISBN 978-1-936213-10-8。
  45. ^ Unicode標準バージョン9.0.0. カリフォルニア州マウンテンビュー：Unicodeコンソーシアム. 2016年6月21日. ISBN 978-1-936213-13-9。
  46. ^
    • Unicode標準バージョン9.0.0. カリフォルニア州マウンテンビュー：Unicodeコンソーシアム. 2016年6月21日. ISBN 978-1-936213-13-9。
    • 「Unicodeデータ9.0.0」 。 2016年6月21日閲覧。
  47. ^ Lobao, Martim (2016年6月7日). 「Unicode 9では承認されなかったものの、GoogleがAndroidに追加された2つの絵文字」. Android Police . 2016年9月4日閲覧。
  48. ^ Unicode標準バージョン10.0.0. カリフォルニア州マウンテンビュー：Unicodeコンソーシアム. 2017年6月20日. ISBN 978-1-936213-16-0。
  49. ^ Unicode標準バージョン11.0.0. カリフォルニア州マウンテンビュー：Unicodeコンソーシアム. 2018年6月5日. ISBN 978-1-936213-19-1。
  50. ^ Unicode標準バージョン12.0.0. カリフォルニア州マウンテンビュー：Unicodeコンソーシアム. 2019年3月5日. ISBN 978-1-936213-22-1。
  51. ^ 「令和時代に対応したUnicodeバージョン12.1がリリースされました」Unicodeブログ。 2019年5月7日閲覧。
  52. ^
    • Unicode標準、バージョン13.0.0。カリフォルニア州マウンテンビュー：Unicodeコンソーシアム。2020年3月10日。ISBN 978-1-936213-26-9。
    • 「Unicode標準バージョン13.0の発表」Unicodeブログ。 2020年3月11日閲覧。
  53. ^ 「Unicode標準バージョン13.0 - コア仕様付録C」（PDF） . Unicodeコンソーシアム. 2020年3月11日閲覧。
  54. ^
    • Unicode標準、バージョン14.0.0。カリフォルニア州マウンテンビュー：Unicodeコンソーシアム。2021年9月14日。ISBN 978-1-936213-29-0。
    • 「Unicode 標準バージョン 14.0 の発表」。
  55. ^ Unicode標準バージョン15.0.0. カリフォルニア州マウンテンビュー：Unicodeコンソーシアム. 2022年9月13日. ISBN 978-1-936213-32-0。
  56. ^
    • Unicode規格、バージョン15.1.0。カリフォルニア州サウスサンフランシスコ：Unicodeコンソーシアム。2023年9月12日。ISBN 978-1-936213-33-7。
  57. ^ Unicode標準、バージョン16.0.0。カリフォルニア州サウスサンフランシスコ：Unicodeコンソーシアム。2024年9月10日。ISBN 978-1-936213-34-4。
  58. ^ Unicode標準、バージョン17.0.0。カリフォルニア州サウスサンフランシスコ：Unicodeコンソーシアム。2025年9月9日。ISBN 978-1-936213-35-1。
  59. ^ 「Unicode用語集」 。 2010年3月16日閲覧。
  60. ^ 「2.4 コードポイントと文字」。Unicode標準バージョン16.0 - コア仕様。2024年。
  61. ^ 「3.4 文字とエンコーディング」。Unicode標準、バージョン16.0。2024年。
  62. ^ 「Re: U+nnnn表記の起源」Unicodeメールリストアーカイブ（メーリングリスト）2005年11月8日。
  63. ^ 「付録A：表記規則」。Unicode標準。Unicodeコンソーシアム。2024年9月。
  64. ^ 「適合性」。Unicode標準（第6.0版）。米国カリフォルニア州マウンテンビュー：Unicodeコンソーシアム。3.9 Unicodeエンコーディング形式。ISBN 978-1-936213-01-6各エンコード形式は、UnicodeコードポイントU+0000..U+D7FFとU+E000..U+10FFFFをマッピングします。
  65. ^ ab 「Unicode文字エンコーディング安定性ポリシー」 。 2010年3月16日閲覧。
  66. ^ 「プロパティ」 。 2025年9月21日閲覧。
  67. ^ 「Unicode文字エンコーディングモデル」 。 2023年9月12日閲覧。
  68. ^ 「Unicode名前付きシーケンス」 。 2025年9月21日閲覧。
  69. ^ 「Unicode名の別名」 。 2025年9月21日閲覧。
  70. ^ “JanaSanskritSans”. 2011年7月16日時点のオリジナルよりアーカイブ。
  71. ^ CWA 13873:2000 – ISO/IEC 10646-1 CENワークショップ合意13873における多言語ヨーロッパサブセット
  72. ^ Kuhn, Markus (1998). 「Multilingual European Character Set 2 (MES-2) Rationale」. ケンブリッジ大学. 2023年3月20日閲覧。
  73. ^ 「DIN 91379:2022-08: ヨーロッパにおける名前の電子処理およびデータ交換のためのUnicodeの文字および定義済み文字シーケンス（CD-ROM付き）」 Beuth Verlag . 2022年8月21日閲覧。
  74. ^ 「UTF-8、UTF-16、UTF-32 & BOM」。Unicode.org FAQ 。 2016年12月12日閲覧。
  75. ^ Unicode標準バージョン6.2 . Unicodeコンソーシアム. 2013年. 561ページ. ISBN 978-1-936213-08-5。
  76. ^ Davis, Mark (2008年5月5日). 「Unicode 5.1への移行」.公式Googleブログ. 2025年4月1日時点のオリジナルよりアーカイブ。 2025年4月12日閲覧。
  77. ^ 「ランク別文字エンコーディング使用状況調査」W3Techs . 2025年4月12日閲覧。
  78. ^ 「ウェブサイトにおけるUS-ASCIIの使用統計」W3Techs . 2020年11月1日閲覧。
  79. ^ B. Curtin (1999年7月). ファイル転送プロトコルの国際化. doi : 10.17487/RFC2640 . RFC 2640. 2025年4月12日閲覧。
  80. ^ H. Alvestrand (1998年1月). IETFの文字セットと言語に関するポリシー. doi : 10.17487/RFC2277 . BCP 18. RFC 2277. 2023年1月23日時点のオリジナルよりアーカイブ。 2025年4月12日閲覧。
  81. ^ Pike, Rob (2003-04-30). 「UTF-8の歴史」
  82. ^ 「ISO/IEC JTC1/SC 18/WG 9 N」（PDF） 。 2025年1月22日時点のオリジナルよりアーカイブ（PDF） 。 2025年4月12日閲覧。
  83. ^ Hedley, Jonathan (2009). 「Unicode Lookup」. 2025年3月30日時点のオリジナルよりアーカイブ。2025年4月12日閲覧。
  84. ^ Milde, Benjamin (2025). 「Unicode文字認識」. 2025年4月2日時点のオリジナルよりアーカイブ。
  85. ^ J. クレンシン; Y.Ko (2007 年 7 月)国際化された電子メールの概要とフレームワーク。土井: 10.17487/RFC4952。RFC 4952 。2022-08-17に取得。
  86. ^ J. クレンシン; Y.Ko (2012 年 2 月)国際化された電子メールの概要とフレームワーク。土井: 10.17487/RFC6530。RFC 6530 。2022-08-17に取得。
  87. ^ J. Yao; W. Mao (2012年2月). 国際化電子メールのためのSMTP拡張. doi : 10.17487/RFC6531 . RFC 6531. 2022年8月17日閲覧。
  88. ^ A. Yang; S. Steele; N. Freed (2012年2月). 国際化メールヘッダー. doi : 10.17487/RFC6532 . RFC 6532. 2022年8月17日閲覧。
  89. ^ C. Newman; A. Gulbrandsen; A. Melnikov (2008年6月). Internet Message Access Protocol Internationalization. doi : 10.17487/RFC5255 . RFC 5255. 2022年8月17日閲覧。
  90. ^ R. Gellens; C. Newman (2010年2月). UTF-8のPOP3サポート. doi : 10.17487/RFC5721 . RFC 5721. 2022年8月17日閲覧。
  91. ^ Wood, Alan (2005年9月13日). 「Windows Internet Explorer 5、5.5、6 の多言語および Unicode サポートの設定: Internet Explorer 5、5.5、6 で Unicode を有効にするオプション: フォント (IE 5、5.5、6)」. Alan Wood. 2025年1月20日時点のオリジナルよりアーカイブ。 2025年4月12日閲覧。
  92. ^ “Extensible Markup Language (XML) 1.1 (Second Edition)”. World Wide Web Consortium . 2006年9月29日. 2025年4月5日時点のオリジナルよりアーカイブ。 2025年4月12日閲覧。
  93. ^ Bigelow, Charles; Holmes, Kris (1993年9月). 「Unicodeフォントのデザイン」(PDF) . Electronic Publishing . 6 (3): 292. ISSN 0894-3982. 2025年2月16日時点のオリジナルより アーカイブ(PDF) . 2025年4月12日閲覧。
  94. ^ 「FAQ：フォントとキーボード：フォントとUnicode」Unicodeコンソーシアム. 2025年3月6日時点のオリジナルよりアーカイブ。 2025年4月12日閲覧。
  95. ^ 文字コードの簡潔な歴史、Steven J. Searle、初版1999年、最終更新2004年
  96. ^ ab 「付録E：漢語統一史」. Unicode標準バージョン16.0 - コア仕様. Unicodeコンソーシアム. 2024.
  97. ^ ab Topping, Suzanne (2013年6月25日). 「The secret life of Unicode」. IBM . 2013年6月25日時点のオリジナルよりアーカイブ。2023年3月20日閲覧。
  98. ^ Lu, Qin (2015-06-08). 「香港文字セット提案」(PDF) . ISO/IEC JTC1 / SC2 /WG2/ IRG N2074.
  99. ^ Wittern, Christian (1995年5月1日). 「中国語の文字コード：最新情報」. 国際禅仏教研究所 /花園大学. 2004年10月12日時点のオリジナルよりアーカイブ。
  100. ^ "Noto CJK フォント". Noto Fonts. 2023-02-18.システムが可変フォントをサポートしており、1つの言語のみを使用するものの、文字の完全なカバレッジ、または他の言語に適したグリフを使用するための言語タグテキスト機能も必要な場合は、この展開形式を選択してください（これには、言語タグとOpenTypeの「locl」GSUB機能をサポートするアプリが必要です）。
  101. ^ Preuss, Ingo. 「OpenType機能：locl – ローカライズされたフォーム」. preusstype.com .
  102. ^ 「大文字小文字変換プロパティ」. Unicode文字データベース. Unicodeコンソーシアム. 2025年7月30日.
  103. ^ ab 「正規表現オプション § インバリアントカルチャを使用した比較」. .NET の基礎ドキュメント. Microsoft . 2023年5月12日.
  104. ^ "confusablesSummary.txt". Unicode Security Mechanisms for UTS #39 . Unicode Consortium . 2023年8月11日.
  105. ^ 「UTR #36: Unicodeのセキュリティに関する考慮事項」。Unicode。
  106. ^ Boucher, Nicholas; Shumailov, Ilia; Anderson, Ross; Papernot, Nicolas (2022). 「Bad Characters: Imperceptible NLP Attacks」. 2022 IEEE Symposium on Security and Privacy (SP) . サンフランシスコ, CA, US: IEEE. pp.  1987– 2004. arXiv : 2106.09898 . doi :10.1109/SP46214.2022.9833641. ISBN 978-1-66541-316-9. S2CID  235485405。
  107. ^ エンジニアリング、Spotify (2013年6月18日). 「クリエイティブなユーザー名とSpotifyアカウントの乗っ取り」. Spotifyエンジニアリング. 2023年4月15日閲覧。
  108. ^ Wheeler, David A. (2020). 不正ソースコードの初期分析（技術レポート）. p. 4–1–4–10. JSTOR  resrep25332.7.
  109. ^ 「UTR #36: Unicodeのセキュリティに関する考慮事項」。Unicode 。2022年6月27日閲覧。
  110. ^ Boucher, Nicholas; Anderson, Ross. 「トロイの木馬の出所：目に見えない脆弱性」（PDF） . 2021年11月2日閲覧。
  111. ^ “Visual Studio Code October 2021”. code.visualstudio.com . 2021年11月11日閲覧。
  112. ^ Dittert, Dominique (2024年9月6日). 「Unicodeからエクスプロイトへ：長すぎるUTF-8エンコーディングのセキュリティリスク」 . 2024年12月26日閲覧。
  113. ^ ブーン、ケビン. 「UTF-8と長すぎる文字の問題」 . 2024年12月26日閲覧。
  114. ^ AFIIによるWAVE DASHに関する寄稿「日本語用Unicodeベンダー固有文字テーブル」。2011年4月22日。2011年4月22日時点のオリジナルよりアーカイブ。 2019年5月20日閲覧。
  115. ^ ISO 646-* 問題 Archived 2019-04-23 at the Wayback Machine、セクション 4.4.3.5 of Introduction to I18n、 Tomohiro Kubota、2001
  116. ^ 「アラビア語プレゼンテーションフォーム-A」（PDF） . 2010年3月20日閲覧。
  117. ^ 「アラビア語プレゼンテーションフォーム-B」（PDF） . 2010年3月20日閲覧。
  118. ^ 「アルファベット表記フォーム」（PDF） . 2010年3月20日閲覧。
  119. ^ 「BMPにおけるISO/IEC 10646向けチベット文字BrdaRtenエンコーディングの提案」（PDF）。2002年12月2日。
  120. ^ Umamaheswaran, VS (2003-11-07). 「WG 2会議44の決議」(PDF) . 決議M44.20.
  121. ^ “Character Encoding Stability”. Unicode . 2024年1月1日時点のオリジナルよりアーカイブ。
  122. ^ ab 「Unicodeテクニカルノート#27: Unicode文字名における既知の異常」Unicode . 2021年6月14日。
  123. ^ 「Unicode チャート: 「これは、名前にもかかわらず、実際には小文字のカリグラフィの p の形をしています」」(PDF)。
  124. ^ 「キャラクター名の括弧のスペルミスは既知の欠陥です」(PDF)。
  125. ^ ab 「Unicode標準付録#24：Unicodeスクリプトプロパティ」。Unicodeコンソーシアム。2021年。2.2 ISO 15924コードとの関係。2022年4月29日閲覧。
  126. ^ "Scripts.txt". Unicodeコンソーシアム. 2025年. 2025年9月21日閲覧。

さらに読む

  • ハラランボス、ヤニス、マーティン・デュルスト (2019). 「言語学的観点から見たUnicode」. ハラランボス、ヤニス (編). Proceedings of Graphemics in the 21st Century, Brest 2018. ブレスト: Fluxus Editions. pp.  167– 183. doi :10.36824/2018-graf-hara1. ISBN 978-2-9570549-1-6。
  • ユニコード株式会社
    • Unicode技術サイト
      • ユニコード標準
        • Unicode文字コード表
        • Unicode文字名インデックス
  • Alan Wood の Unicode リソース – Unicode 対応のワードプロセッサのリストが含まれています。フォントと文字は種類別にグループ化されており、文字はグリッドではなくリストで表示されます。
  • Unicode BMP フォールバック フォント – グリフ自体ではなく、文書内の任意の文字（私用領域を含む）の Unicode 6.1 値を表示します。
  • 世界の文字体系、Unicode ステータスを持つ 293 の既知の文字体系すべて (2024 年 6 月時点でまだエンコードされていない文字体系は 128 個)
「https://en.wikipedia.org/w/index.php?title=Unicode&oldid=1322810428」から取得