Unicode

Hashtags #Unicode

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ検索にジャンプ

Microsoftのドキュメントで「Unicode」という用語が何を意味するかについては、UTF-16を参照してください。
Unicode
New Unicode logo.svg
ユニコードコンソーシアムのロゴ
エイリアス国際符号化文字集合（UCS）
言語インターナショナル
標準Unicode標準
エンコーディング形式UTF-8、UTF-16、GB18030
あまり一般的ではありません：UTF-32、BOCU、SCSU、UTF-7（廃止）
前任者ISO / IEC 8859、その他さまざま

Unicodeは、世界のほとんどの書記体系で表現されるテキストの一貫したエンコード、表現、および処理のための情報技術 標準です。この規格はUnicodeコンソーシアムによって維持されており、2020年3月の時点で、合計143,859文字で、Unicode 13.0（これらの文字は143,696のグラフィック文字と163のフォーマット文字で構成されています）が154の現代的および歴史的なスクリプトと複数をカバーしています。シンボルセットと絵文字。

Unicode文字レパートリーはISO / IEC 10646と同期されており、それぞれが互いにコードごとに同一です。ただし、Unicode標準には、基本コードだけではありません。コンソーシアムの公式出版物には、文字エンコードに加えて、スクリプトとその表示方法に関するさまざまな詳細が含まれています。正規化ルール、分解、照合、レンダリング、多言語テキストの双方向テキスト表示順序などです。[1]この規格には、開発者と設計者がレパートリーを正しく実装するのに役立つ参照データファイルとビジュアルチャートも含まれています。

文字セットの統合におけるUnicodeの成功は、コンピュータソフトウェアの国際化とローカリゼーションにおけるUnicodeの普及と主流化につながりました。この標準は、最新のオペレーティングシステム、XML、Java（およびその他のプログラミング言語）、. NET Frameworkなど、最近の多くのテクノロジに実装されています。

Unicodeは、さまざまな文字エンコードで実装できます。 Unicode標準では、Unicode変換形式（UTF）UTF-8、UTF-16、UTF-32、およびその他のいくつかのエンコーディングが定義されています 。最も一般的に使用されるエンコーディングは、UTF-8、UTF-16、およびUCS -2（Unicodeを完全にサポートしていないUTF-16の前身）です。GB18030は中国で標準化されており、Unicodeを完全に実装していますが、公式のUnicode標準ではありません。

UTF-8は、World Wide Web（2020年の時点で95％以上のWebサイトで使用され、一部の言語では最大100％で使用されています）[2]およびほとんどのUnixライクなオペレーティングシステムで1バイトを使用します[注1]（8 ビット）最初の128コードポイントの場合、および他の文字の場合は最大4バイト。[3]最初の128個のUnicodeコードポイントはASCII文字を表します。つまり、ASCIIテキストもUTF-8テキストです。

UCS-2は各文字に2バイト（16ビット）を使用しますが、エンコードできるのは最初の65,536コードポイント、いわゆる基本多言語プレーン（BMP）のみです。17平面上の文字（以下を参照）に対応する1,112,064の可能なUnicodeコードポイントと、バージョン13.0の時点で定義された143,000を超えるコードポイントでは、UCS-2はエンコードされたすべてのUnicode文字の半分未満しか表現できません。したがって、UCS-2は古くなっていますが、ソフトウェアではまだ広く使用されています。 UTF-16は、基本多言語プレーン用にUCS-2と同じ16ビットエンコーディングを使用し、他のプレーン用に4バイトエンコーディングを使用することにより、UCS-2を拡張します。予約範囲U + D800–U + DFFFのコードポイントが含まれていない限り、[明確化が必要]UCS-2テキストは有効なUTF-16テキストです。

UTF-32（UCS-4とも呼ばれます）は、4バイトを使用して、特定のコードポイントをエンコードしますが、ユーザーが認識した文字（大まかに言えば、書記素）は、ユーザーが認識した文字が書記素クラスター（複数のコードポイントのシーケンス）。[4] UCS-2と同様に、コードポイントあたりのバイト数は固定されており、文字のインデックス作成が容易になります。ただし、UCS-2とは異なり、UTF-32はすべてのUnicodeコードポイントをエンコードできます。ただし、各文字は4バイトを使用するため、UTF-32は他のエンコーディングよりもかなり多くのスペースを使用し、広く使用されていません。 UTF-32のコードポイントごとのサイズは固定されていますが、ユーザーが認識する文字に関しては可変長でもあります。例：デバナーガリ kshi 4つのコードポイント、及び2つのコード・ポイントで構成されている国旗の絵文字、によってコードされます、。[5]結合文字シーケンスはすべて書記素ですが、他にも同様のコードポイントのシーケンスがあります（例：\ r \ n）。[6] [7] [8] [9]

起源と発展[編集]

Unicodeには、ISO / IEC 8859標準で定義されているような、世界のさまざまな国で広く使用されているものの、相互にほとんど互換性がない従来の文字エンコードの制限を超えるという明確な目的があります。多くの従来の文字エンコードは、バイリンガルのコンピューター処理（通常はラテン文字とローカルスクリプトを使用）を許可しますが、多言語のコンピューター処理（互いに混合された任意のスクリプトのコンピューター処理）を許可しないという共通の問題を共有します。

Unicodeは、意図的に、そのような文字のバリアントグリフ（レンダリング）ではなく、基になる文字（書記素および書記素のような単位）をエンコードします。漢字の場合、これにより、基になる文字をそのバリアントグリフから区別することについて論争が生じることがあります（ハンユニフィケーションを参照）。

テキスト処理では、Unicodeは、ユニークな提供の役割取るコードポイント-aの番号ではなく、グリフのための各文字を。言い換えると、Unicodeは文字を抽象的な方法で表し、視覚的なレンダリング（サイズ、形状、フォント、またはスタイル）をWebブラウザやワードプロセッサなどの他のソフトウェアに任せます。ただし、Unicodeのより迅速な採用を促進することを期待して、Unicodeの設計者が譲歩したため、この単純な目的は複雑になります。

最初の256個のコードポイントは、既存の西洋のテキストを簡単に変換できるように、ISO / IEC8859-1の内容と同じになりました。多くの本質的に同一の文字は、レガシーエンコーディングで使用される区別を維持するために、異なるコードポイントで複数回エンコードされたため、情報を失うことなく、それらのエンコーディングからUnicodeへの変換（およびその逆）が可能です。たとえば、中国語、日本語、韓国語（CJK）のフォントには、CJK文字の幅に一致する「全角」の2つのバージョンが含まれているため、コードポイントの「全角フォーム」セクションにはラテンアルファベットの完全な複製が含まれます。通常の幅。他の例については、Unicodeの重複文字を参照してください。

Unicodeのブルドッグ受賞者は、Unicodeの開発にinfluentual多くの名前を分類し、含ま達夫小林、トーマス・ミロ、Roozbeh Pournader、ケン・ランド、そしてマイケル・エバーソンを[10]

歴史[編集]

経験に基づいて、ゼロックスの文字コード規格1980年以降（のX ccs）、[11] 1987年にUnicodeの日の起源ジョー・ベッカーからゼロックスとリー・コリンズとマーク・デイビスからAppleが汎用文字セットを作成するための実用性を検討し始めました。[12] PeterFenwickとDaveOptadからの追加の入力により、[11] Joe Beckerは、「1988年8月に、暫定的にUnicodeと呼ばれる国際/多言語テキスト文字エンコードシステム」の提案案を発表しました。彼は、「「Unicode」という名前は、独自の統一されたユニバーサルエンコーディングを提案することを目的としています」と説明しました。[11]

Unicode 88というタイトルのこのドキュメントで、Beckerは16ビット文字モデルの概要を説明しました。[11]

Unicodeは、実行可能で信頼性の高いワールドテキストエンコーディングの必要性に対応することを目的としています。Unicodeは、世界のすべての生きている言語の文字を包含するように16ビットに拡張された「ワイドボディASCII」として大まかに説明できます。適切に設計された設計では、この目的には1文字あたり16ビットで十分です。

彼の元の16ビット設計は、現代で使用されているスクリプトと文字のみをエンコードする必要があるという仮定に基づいていました。[11]

Unicodeは、過去の古物を保存するよりも、将来の有用性を確保することを優先します。 Unicodeは、最初に、現代のテキストで公開されている文字（たとえば、1988年に世界で印刷されたすべての新聞や雑誌の和集合）を対象としています。その数は間違いなく2 14 = 16,384をはるかに下回っています。それらの現代的な使用文字を超えて、他のすべては時代遅れまたはまれであると定義されるかもしれません。これらは、一般的に有用なUnicodeの公開リストを混雑させるよりも、私的使用の登録に適しています。

初期の1989年には、Unicodeのワーキンググループはケンウィスラーとメタファーのマイク・カーナガン、カレン・スミス・吉村とのジョアンAliprand含むように拡張RLG、とのグレン・ライトサン・マイクロシステムズから、そして1990年に、ミシェルSuignardとAsmusフライタークマイクロソフトとリック・マッゴーワンをNeXTのグループに参加しました。1990年の終わりまでに、既存の文字エンコード標準のマッピングに関する作業のほとんどが完了し、Unicodeの最終レビュードラフトの準備が整いました。

ユニコードコンソーシアムは、1991年1月3日にカリフォルニアで設立された[13]と1991年10月に、Unicode標準の最初のボリュームが公開されました。漢字の表意文字を扱った第2巻は、1992年6月に出版されました。

1996年に、代理文字メカニズムがUnicode 2.0に実装されたため、Unicodeは16ビットに制限されなくなりました。これにより、Unicodeコードスペースが100万を超えるコードポイントに増加し、多くの歴史的なスクリプト（エジプトの象形文字など）と、エンコードが必要であるとは予想されていなかった数千のめったに使用されない、または廃止された文字のエンコードが可能になりました。もともとUnicodeを対象としていない文字の中には、漢字や漢字がほとんど使用されておらず、その多くは個人名や地名の一部であるため、ほとんど使用されていませんが、Unicodeの元のアーキテクチャで想定されているよりもはるかに重要です。[14]

1992年のMicrosoftTrueType仕様バージョン1.0では、ネーミングテーブルのプラットフォームIDにUnicodeではなくAppleUnicodeという名前が使用されていました。

Unicodeコンソーシアム[編集]

主な記事：Unicodeコンソーシアム

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

何年にもわたって、いくつかの国または政府機関がユニコードコンソーシアムのメンバーになっています。現在、投票権を持つ正会員は、養老宗教省（オマーン）のみです。[15]

コンソーシアムは、既存の文字エンコードスキームの多くがサイズと範囲に制限があり、多言語環境と互換性がないため、最終的に既存の文字エンコードスキームをUnicodeおよびその標準のUnicode変換形式（UTF）スキームに置き換えるという野心的な目標を持っています。

カバーされたスクリプト[編集]

主な記事：スクリプト（Unicode）
OpenOffice.orgアプリケーションのこのスクリーンショットに示されているように、多くの最新のアプリケーションは、Unicodeで多くのスクリプトの実質的なサブセットをレンダリングできます。

Unicodeは、現在使用されているほとんどすべてのスクリプト（書記体系）をカバーしています。[16] [より良い情報源が必要]

合計154の[17] スクリプトが最新バージョンのUnicodeに含まれています（アルファベット、アブギダ、音節文字をカバー）が、まだエンコードされていないスクリプト、特に主に歴史的、典礼的、学術的文脈で使用されるスクリプトがまだあります。特に数学や音楽（音符やリズム記号の形で）の記号だけでなく、すでにエンコードされたスクリプトへの文字の追加も発生します。

Unicodeロードマップ委員会（Michael Everson、Rick McGowan、Ken Whistler、VS Umamaheswaran [18]）は、UnicodeコンソーシアムWebサイトのUnicodeロードマップページで、エンコードの候補または潜在的な候補であるスクリプトのリストとそれらの暫定的なコードブロック割り当てを維持しています。 。JurchenやKhitanの小さなスクリプトなど、ロードマップ上の一部のスクリプトについては、エンコードの提案が行われ、承認プロセスを進めています。マヤ語（数字以外）やロンゴロンゴなどの他のスクリプトの場合、まだ提案は行われておらず、関係するユーザーコミュニティからのキャラクターレパートリーやその他の詳細についての合意を待っています。

まだUnicodeに含まれていない（例：Tengwar）、または実際に使用されていないためにUnicodeに含める資格がない（例：Klingon）いくつかの最新の発明されたスクリプトは、非公式とともにConScriptUnicodeレジストリにリストされています。しかし、広く使用されている私用領域のコード割り当て。

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

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

バージョン[編集]

Unicodeコンソーシアムと国際標準化機構は、1991年のUnicode標準の最初の発行に続いて、共有レパートリーを共同で開発しました。実際、UnicodeとISOの国際符号化文字集合は同一の文字名とコードポイントを使用します。ただし、Unicodeバージョンは、2つの重要な点で同等のISOバージョンとは異なります。

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

この公開方法の実際的な理由は、UCSとUnicodeの2番目の重要な違い、つまり更新されたバージョンがリリースされ、新しい文字が追加される頻度を浮き彫りにします。Unicode標準は定期的に年次拡張バージョンをリリースしており、暦年に複数のバージョンがリリースされることもあり、スケジュールされたリリースを延期しなければならないこともまれにあります。たとえば、バージョン13.0が公開されてからわずか1か月後の2020年4月、Unicodeコンソーシアムは、COVID-19のパンデミックにより、バージョン14.0のリリース予定日を2021年3月から2021年9月まで6か月延期したと発表しました。 Unicode 14.0には、少なくとも5つの新しいスクリプトと、37の新しい絵文字が含まれることが約束されています。[21]

これまでに、Unicode標準の次のメジャーバージョンとマイナーバージョンが公開されています。文字レパートリーへの変更を含まない更新バージョンは、3番目の番号（「バージョン4.0.1」など）で示され、以下の表では省略されています。[22]

  • v
  • t
  • e
Unicodeバージョン
バージョン日付本対応するISO / IEC10646エディションスクリプトキャラクター
合計[表注1]注目すべき追加
1.0.0 [23]1991年10月ISBN  0-201-56788-1（Vol。1）247,129 [表注2]初期のレパートリーは、これらのスクリプトをカバー：アラビア語、アルメニア語、ベンガル語、ボポモフォ、キリル文字、デーヴァナーガリー、グルジア、ギリシャ語とコプト語、グジャラート語、グルムキー、ハングル、ヘブライ語、ひらがな、カンナダ語、カタカナ、ラオス、ラテン語、マラヤーラム語、オリヤー語、タミル語、テルグ語、タイ語、およびチベット語。[23]
1.0.1 [24]1992年6月ISBN  0-201-60845-6（Vol。2）2528,327
（21,204が追加、
6が削除）		20,902個のCJK統合漢字の初期セットが定義されています。[24]
1.1 [25]1993年6月ISO / IEC 10646-1：19932434,168
（5,963が追加され、
89が削除され、
33
が制御
文字として再分類されました）		オリジナルの2,350文字のセットに4,306個のハングル音節文字が追加されました。チベット人は削除されました。[25]
2.0 [26]1996年7月ISBN  0-201-48345-9ISO / IEC 10646-1：1993に加えて、修正5、6、および72538,885
（11,373追加、
6,656削除）		ハングル音節の元のセットが削除され、11,172個のハングル音節の新しいセットが新しい場所に追加されました。チベット人は新しい場所に、異なるキャラクターのレパートリーで追加し直しました。代理文字メカニズムが定義され、プレーン15とプレーン16の私用面が割り当てられます。[26]
2.1 [27]1998年5月ISO / IEC 10646-1：1993に加えて、修正5、6、7、および修正18の2文字2538,887
（2追加）		ユーロ記号とオブジェクト置換文字が追加されました。[27]
3.01999年9月ISBN  0-201-61633-5ISO / IEC 10646-1：20003849,194
（10,307追加）		Cherokee、Ethiopic、Khmer、Mongolian、Burmese、Ogham、Runic、Sinhala、Syriac、Thaana、Unified Canadian Aboriginal Syllabics、Yi Syllables、および一連のBrailleパターンが追加されました。[28]
3.12001年3月ISO / IEC 10646-1：2000

ISO / IEC 10646-2：2001

4194,140
（44,946追加）		Deseret、Gothic、Old Italicが追加され、西洋音楽とビザンチン音楽の記号のセット、および42,711個のCJK統合漢字が追加されました。[29]
3.22002年3月ISO / IEC 10646-1：2000プラス修正1

ISO / IEC 10646-2：2001

4595,156
（1,016追加）		フィリピンの文字ブヒッド文字、ハヌノオ文字、タガログ語、タグバヌワ文字が追加されました。[30]
4.0 4.02003年4月ISBN  0-321-18578-1ISO / IEC 10646：20035296,382
（1,226追加）		キプロス五十音、リンブ、リニアB、オスマニア語、シャヴィアン文字、タイル、及びウガリットを加え、並びに六芒星シンボル。[31]
4.12005年3月ISO / IEC 10646：2003と修正15997,655
（1,273追加）		ブギス、グラゴル、カローシュティー文字、新しいタイルー、旧ペルシャ、シロティナグリ文字、およびティフィナグ文字が追加され、コプトがからdisunifiedたギリシャ。古代ギリシャの数字と楽譜も追加されました。[32]
5.02006年7月ISBN  0-321-48091-0ISO / IEC 10646：2003に加えて、修正1と2、および修正3の4文字6499,024
（1,369追加）		バリ、楔形文字、ンコ文字、Phags-PA、およびフェニキアを追加しました。[33]
5.12008年4月ISO / IEC 10646：2003に加えて、修正1、2、3、および475100,648
（1,624追加）		Carian、Cham、Kayah Li、Lepcha、Lycian、Lydian、Ol Chiki、Rejang、Saurashtra、Sundanese、Vaiが追加され、ファイストスの円盤、麻雀牌、ドミノ牌の記号セットも追加されました。ビルマ語の重要な追加、中世の写本で使用されている文字と書記の略語の追加、および大文字の追加ẞもありました。[34]
5.22009年10月ISBN  978-1-936213-00-9ISO / IEC 10646：2003に加えて、修正1、2、3、4、5、および690107,296
（6,648追加）		アヴェスタ、バムン文字、エジプトの象形文字（ガーディナーセット1071個の文字を含む）、インペリアル・アラム語、碑文パーレビ国王、碑文パルティア、ジャワ、カイティー文字、リス族、マニプリ文字、オールドサウスアラビア、オールド・テュルク、サマリア人、タイタムとタイベトナムを追加しました。4,149個の追加のCJK統合漢字（CJK-C）、および古ハングル用の拡張Jamo 、およびヴェーダ語サンスクリット語。[35]
6.02010年10月ISBN  978-1-936213-01-6ISO / IEC 10646：2010とインドルピー記号93109,384
（2,088追加）		バタク、ブラーフミー、マンダ文字、カード遊ぶシンボル、輸送およびマップのシンボル、錬金術記号、顔文字や絵文字を。222個のCJK統合漢字（CJK-D）が追加されました。[36]
6.12012年1月ISBN  978-1-936213-02-3ISO / IEC 10646：2012100110,116
（732追加）		チャクマ、メロエの筆記体、メロエ象形文字、ミャオ族、シャラダ文字、ソラソンペン文字、およびタクリ文字。[37]
6.22012年9月ISBN  978-1-936213-07-8ISO / IEC 10646：2012とトルコリラ記号100110,117
（1追加）		トルコリラサイン。[38]
6.32013年9月ISBN  978-1-936213-08-5ISO / IEC 10646：2012プラス6文字100110,122
（5追加）		5つの双方向フォーマット文字。[39]
7.02014年6月ISBN  978-1-936213-09-2ISO / IEC 10646：2012に加えて、修正1と2、およびルーブル記号123112,956
（2,834追加）		バッサVAH、白人アルバニア、Duployan、エルバサン、Grantha、Khojki、Khudawadi、リニアA、Mahajani、マニ教、メンデKikakui、モディ、MRO、ナバテア、旧北アラビア、旧Permic、Pahawhモン族、Palmyrene、パウ・シン・ハウ、詩篇パーレビ国王、Siddham、Tirhuta、Warang Citi、および絵記号。[40]
8.02015年6月ISBN  978-1-936213-10-8ISO / IEC 10646：2014に加えて、修正1、ラリ記号、9つのCJK統合表意文字、および41の絵文字[41]129120,672
（7,716追加）		Ahom、アナトリア象形文字、Hatran、Multani、旧ハンガリー、SignWriting、5771のCJK統合漢字、小文字のための文字の集合チェロキー、及び5個の絵文字肌色修飾子。[42]
9.02016年6月ISBN  978-1-936213-13-9ISO / IEC 10646：2014に加えて、修正1と2、およびAdlam、Newa、日本のTVシンボル、74の絵文字とシンボル[43]135128,172
（7,500追加）		Adlam、Bhaiksuki、Marchen、Newa、Osage、Tangut、72絵文字。[44] [45]
10.02017年6月ISBN  978-1-936213-16-0ISO / IEC 10646：2017に加えて、56個の絵文字、285個の変体仮名、3個のザナバザールスクエア文字[46]139136,690
（8,518追加）		ザナバザールスクエア、ソヨンボ、マサラムゴンディ、女書、変体仮名（非標準ひらがな）、7,494 CJK統合漢字、56絵文字。
11.02018年6月ISBN  978-1-936213-19-1ISO / IEC 10646：2017に加えて、修正1、46のMtavruliグルジア大文字、5つのCJK統合表意文字、および66の絵文字。[47]146137,374
（684追加）		Dogra、グルジアMtavruliの大文字、Gunjala Gondi、Hanifiロヒンギャ、インド語Siyaq番号、マカッサル、Medefaidrin、旧ソグドとソグド、マヤの数字、5つの緊急に必要とCJK統合漢字、のシンボルシャンチー（中国将棋）と星評価、および145絵文字。[48]
12.02019年3月ISBN  978-1-936213-22-1ISO / IEC 10646：2017に加えて、修正1と2、および62の追加文字。[49]150137,928
（554追加）		Elymaic、Nandinagari、Nyiakeng Puachueモン族、Wancho、ミャオ族のスクリプト中国のいくつかのミャオ族と李方言のための追加、ひらがなとカタカナ古風な日本人を書くための小さな文字、タミル語、歴史画分と記号、ラオスのための文字パーリ、Egyptologicalとウガリット音訳のためのラテン文字、象形文字形式のコントロール、および61個の絵文字。[50]
12.12019年5月ISBN  978-1-936213-25-2150137,929
（1追加）		令和時代の名前の四角い合字形式のU + 32FFに1文字を追加します。[51]
13.0 [52]2020年3月ISBN  978-1-936213-26-9ISO / IEC 10646：2020 [53]154143,859
（5,930追加）		Chorasmian、ダイブAkuru、契丹小さなスクリプト、Yezidi、（に4939を含む添加4,969 CJK統合漢字拡張。G）、書き込みに使用アラビア語スクリプト追加ハウサ、ウォロフアフリカ及び他の添加で、および他の言語を書くために使用Hindkoとパンジャブ語でのパキスタン、広東語に使用されるBopomofoの追加、Creative Commonsライセンス記号、1970年代と1980年代のテレテキストおよび家庭用コンピューターシステムとの互換性のためのグラフィック文字、および55の絵文字。[52]
  1. ^ ユニコードのバージョンごとにリストされた文字の数（すなわち、除くグラフィックフォーマット文字の総数でプライベート用文字、制御文字、 noncharacters及びサロゲートコードポイント）。
  2. ^ 「スペース」または33の非印刷文字（合計7,163文字）はカウントされません[23]

アーキテクチャと用語[編集]

参照：ユニバーサル文字セット文字

Unicode標準が定義するコードスペースを、[54] 0から10FFFFまでの範囲の数値の組16、[55]と呼ばれるコードポイント[56]と表記としてU + 0000 U + 10FFFFを通して（「U +」プラスのコードポイント値に進で付加先行ゼロ4桁、の最小値をもたらすために必要に応じて例えば、U + 00F7は、除算記号のために、÷、U + 13254対のためのエジプトヒエログリフ指定リードシェルター又は巻壁 （）[57 ]）、それぞれ。これらの2の16 + 2 20定義されたコードポイント、UTF-16で代理ペアをエンコードするために使用されるU + D800からU + DFFFまでのコードポイントは、標準によって予約されており、有効な文字をエンコードするために使用できないため、合計2 16 − 2 11 + 2 20 = 1,112,064有効なUnicode文字に対応する可能なコードポイント。これらのコードポイントのすべてが必ずしも表示文字に対応しているわけではありません。たとえば、いくつかはキャリッジリターンなどの制御コードに割り当てられます。

コードプレーンとブロック[編集]

主な記事：平面（ユニコード）

Unicodeコードスペースは、0から16までの番号が付けられた17のプレーンに分割されています。

  • v
  • t
  • e
Unicode プレーン、および使用されるコードポイント範囲
基本補足
平面0平面1平面2平面3平面4–13平面14飛行機15–16
0000– FFFF10000– 1FFFF20000– 2FFFF30000– 3FFFF40000– DFFFFE0000– EFFFFF0000– 10FFFF
基本的な多言語面補足多言語面補足漢字面第三漢字面未割り当て補助特殊目的面補足私用エリア飛行機
BMPSMPSIPヒント—SSPSPUA-A / B

0000- 0FFF
1000- 1FFF
2000- 2FFF
3000- 3FFF
4000 - 4FFF
5000- 5FFF
6000- 6FFF
7000- 7FFF

8000- 8FFF
9000- 9FFF
A000- AFFF
B000- BFFF
C000- CFFF
D000- DFFF
E000- EFFF
F000- FFFF

10000– 10FFF
11000– 11FFF
12000– 12FFF
13000– 13FFF
14000– 14FFF

16000– 16FFF
17000– 17FFF

18000– 18FFF


1B000– 1BFFF

1D000– 1DFFF
1E000– 1EFFF
1F000– 1FFFF

20000– 20FFF
21000– 21FFF
22000– 22FFF
23000– 23FFF
24000– 24FFF
25000– 25FFF
26000– 26FFF
27000– 27FFF

28000– 28FFF
29000– 29FFF
2A000– 2AFFF
2B000– 2BFFF
2C000– 2CFFF
2D000– 2DFFF
2E000– 2EFFF
2F000– 2FFFF

30000– 30FFF
31000– 31FFF

E0000– E0FFF

15：SPUA-A
F0000– FFFFF

16：SPUA-B
100000– 10FFFF

BMPのすべてのコードポイントは、UTF-16エンコーディングでは単一のコードユニットとしてアクセスされ、UTF-8では1、2、または3バイトでエンコードできます。プレーン1から16（補助プレーン）のコードポイントは、UTF-16では代理ペアとしてアクセスされ、UTF-8では4バイトでエンコードされます。

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

一般カテゴリプロパティ[編集]

各コードポイントには、単一の一般カテゴリプロパティがあります。主なカテゴリは、文字、マーク、数字、句読点、記号、区切り文字、その他です。これらのカテゴリ内には、細分化があります。ほとんどの場合、コードポイントの特性を十分に指定するには、他のプロパティを使用する必要があります。可能な一般カテゴリは次のとおりです。

一般カテゴリ（Unicode文字プロパティ）[a]
  • v
  • t
  • e
値カテゴリメジャー、マイナーベーシックタイプ[b]割り当てられた文字[b]カウント（13.0現在）
備考
 
L、手紙
ルー文字、大文字グラフィックキャラクター1,791
Ll文字、小文字グラフィックキャラクター2,155
Lt手紙、タイトルケースグラフィックキャラクター31大文字とそれに続く小文字を含む合字（例：Dž、Lj、Nj、およびDz）
Lmレター、モディファイアグラフィックキャラクター260修飾子手紙
Lo手紙、その他グラフィックキャラクター127,004表意文字または文字でunicaseアルファベット
M、マーク
Mnマーク、間隔なしグラフィックキャラクター1,839
マックマーク、間隔の組み合わせグラフィックキャラクター443
私マーク、囲みグラフィックキャラクター13
N、番号
Nd数字、10進数グラフィックキャラクター650これらすべて、そしてこれらだけが、数値タイプ= De [c]を持っています。
Nl数字、文字グラフィックキャラクター236文字または文字様記号で構成される数字（例：ローマ数字）
番号番号、その他グラフィックキャラクター895例えば、下品な画分、上付き文字と下付き数字
P、句読点
PC句読点、コネクタグラフィックキャラクター10「_」アンダースコアを含む
Pd句読点、ダッシュグラフィックキャラクター25いくつかのハイフン文字が 含まれています
追伸句読点、オープングラフィックキャラクター75開き角かっこ文字
Pe句読点、閉じるグラフィックキャラクター73角かっこ文字を閉じる
円周率句読点、最初の引用グラフィックキャラクター12開始引用符。ASCIIの「ニュートラル」引用符は含まれません。使用法に応じて、PsまたはPeのように動作する場合があります
Pf句読点、最終見積もりグラフィックキャラクター10引用符を閉じます。使用法に応じて、PsまたはPeのように動作する場合があります
ポー句読点、その他グラフィックキャラクター593
S、記号
Sm記号、数学グラフィックキャラクター948数学記号（例：+、−、=、×、÷、√、∊、≠）。カテゴリPsおよびPeにある括弧と括弧は含まれません。また、含まれていません！、*、-、または/は、数学演算子として頻繁に使用されますが、主に「句読点」と見なされます。
Sc記号、通貨グラフィックキャラクター62通貨記号
Sk記号、修飾子グラフィックキャラクター123
そうシンボル、その他グラフィックキャラクター6,431
Z、セパレーター
Zsセパレーター、スペースグラフィックキャラクター17スペースは含まれますが、CcであるTAB、CR、またはLFは 含まれません
Zlセパレーター、ラインフォーマットキャラクター1唯一のU + 2028 LINE SEPARATOR（LSEP）
Z Pセパレータ、段落フォーマットキャラクター1唯一のU + 2029段落セパレータ（PSEP）
C、その他
Ccその他、コントロールコントロールキャラクター65（変更されることはありません）[c]名前なし、[d] <コントロール>
Cfその他、フォーマットフォーマットキャラクター161含まソフトハイフンを制御文字（参加、ZWNJとzwjサポートするために）、制御文字を双方向テキストを、および言語タグの文字
Csその他、代理サロゲートありません（UTF-16でのみ使用されます）2,048（変更されることはありません）[c]名前なし、[d] <代理>
Coその他、私的使用個人使用文字（ただし、解釈は指定されていません）合計137,468（変更されることはありません）[c]（BMPで6,400 、プレーン15〜16で131,068 ）名前なし、[d] <私用>
Cnその他、割り当てられていませんキャラクター以外ない66（変更されることはありません）[c]名前なし、[d] <文字以外>
予約済みない830,606名前なし、[d] <予約済み>
  1. ^ 「表4-4：一般的なカテゴリ」（PDF）。Unicode標準。Unicodeコンソーシアム。2020年3月。
  2. ^ a b 「表2-3：コードポイントの種類」（PDF）。Unicode標準。Unicodeコンソーシアム。2020年3月。
  3. ^ a b c d e Unicode文字エンコードの安定性ポリシー：プロパティ値の安定性安定性ポリシー：一部のgcグループは変更されません。gc = Ndは、Numeric Type = De（10進数）に対応します。
  4. ^ a b c d e 「表4-9：コードポイントラベルの作成」（PDF）。Unicode標準。Unicodeコンソーシアム。2020年3月。 コードポイントのラベルは、無名のコード・ポイントを識別するために使用することができます。例：< control- hhhh >、<control-0088>。名前は空白のままです。これにより、ドキュメント内でコントロール名が誤って真のコントロールコードに置き換えられるのを防ぐことができます。 Unicodeは、<noncharacter>に<not acharacter>も使用します。

U + D800–U + DBFF（1,024コードポイント）の範囲のコードポイントは高サロゲートコードポイントと呼ばれ、U + DC00–U + DFFF（1,024コードポイント）の範囲のコードポイントは低サロゲートと呼ばれます。コードポイント。高サロゲートコードポイントとそれに続く低サロゲートコードポイントは、UTF-16でサロゲートペアを形成し、U + FFFFより大きいコードポイントを表します。それ以外の場合、これらのコードポイントは使用できません（このルールは、特にUTF-16を使用しない場合、実際には無視されることがよくあります）。

アプリケーションが必要に応じてこれらのコードポイントを内部で使用する場合もありますが、コードポイントの小さなセットが文字のエンコードに使用されないことが保証されています。これらの六十から六ありますnoncharactersは：U + FDD0-U + FDEFと値FFFEまたはFFFF（すなわち、U + FFFE、U + FFFF、U + 1FFFE、U + 1FFFF、... Uで終わる任意のコードポイント+ 10FFFE、U + 10FFFF）。非文字のセットは安定しており、新しい非文字が定義されることはありません。[58]サロゲートと同様に、これらを使用できないという規則はしばしば無視されますが、バイト順マークの操作では、U + FFFEがテキストの最初のコードポイントになることはないと想定しています。

サロゲートと非文字を除外すると、1,111,998個のコードポイントを使用できるようになります。

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

  • 私用面：U + E000–U + F8FF（6,400文字）、
  • 補足私用エリア-A：U + F0000–U + FFFFD（65,534文字）、
  • 補足私用エリア-B：U + 100000–U + 10FFFD（65,534文字）。

グラフィック文字は、特定のセマンティクスを持つようにUnicodeによって定義された文字であり、目に見えるグリフの形を持っているか、目に見える空間を表します。Unicode 13.0の時点で、143,696のグラフィック文字があります。

フォーマット文字は、外観が見えない文字ですが、隣接する文字の外観や動作に影響を与える可能性があります。たとえば、U + 200C ZERO WIDTHNON-JOINERおよびU + 200D ZERO WIDTH JOINERを使用して、隣接する文字のデフォルトのシェーピング動作を変更できます（たとえば、合字を禁止したり、合字の形成を要求したりするため）。 Unicode13.0には163のフォーマット文字があります。

65個のコードポイント（U + 0000–U + 001FおよびU + 007F–U + 009F）は制御コードとして予約されており、ISO / IEC6429で定義されているC0およびC1制御コードに対応しています。 U + 0009（タブ）、U + 000A（改行）、およびU + 000D（キャリッジリターン）は、Unicodeでエンコードされたテキストで広く使用されています。実際には、C1コードポイントは、一部の英語および西ヨーロッパのテキストで使用されている従来のWindows-1252文字として不適切に翻訳されることがよくあります（mojibake）。

グラフィック文字、フォーマット文字、制御コード文字、および私用文字は、まとめて割り当て文字と呼ばれます。予約済みコードポイントは、使用可能であるがまだ割り当てられていないコードポイントです。Unicode 13.0の時点で、830,606の予約済みコードポイントがあります。

抽象文字[編集]

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

すべてのグラフィック、フォーマット、および私的使用の文字には、それらを識別するための一意で不変の名前があります。この不変性は、Unicodeバージョン2.0以降、NameStabilityポリシーによって保証されています。[58]名前に重大な欠陥があり誤解を招く場合、または重大な誤植がある場合は、正式なエイリアスを定義できます。アプリケーションでは、正式な文字名の代わりに正式なエイリアスを使用することをお勧めします。例えば、U + A015 ꀕ YI音節WUは、正式なエイリアス有するYI音節ITERATION MARKを、そしてU + FE18 ︘ PRESENTATION FORM垂直RIGHT WHITEレンチキュラーBRA KC ET（SICは）正式なエイリアスを有します VERTICAL RIGHT WHITEレンチキュラーBRAのプレゼンテーションFORM CK ET。[62]

既製のキャラクターと合成キャラクター[編集]

Unicodeには、サポートされているグリフレパートリーを大幅に拡張する文字を変更するメカニズムが含まれています。これは、ユーザーが基本文字の後に追加する可能性のある発音区別符号の組み合わせの使用を対象としています。複数の合成発音区別符号を同じキャラクターに同時に適用することができます。 Unicodeには、通常使用されるほとんどの文字/発音区別符号の組み合わせの合成済みバージョンも含まれています。これらにより、レガシーエンコーディングとの間の変換が簡単になり、アプリケーションは、結合文字を実装しなくても、内部テキスト形式としてUnicodeを使用できます。たとえば、éはUnicodeでU + 0065（ラテン小文字E）の後にU + 0301（アキュートアクセントの組み合わせ）として表すことができます。）、ただし、合成済み文字U + 00E9（ラテン小文字E WITH ACUTE）として表すこともできます。したがって、多くの場合、ユーザーは同じ文字をエンコードする複数の方法があります。これに対処するために、Unicodeは標準的な等価性のメカニズムを提供します。

この例は、韓国語のアルファベットであるハングルで発生します。Unicodeは、ハングル音節を個々のサブコンポーネントで構成するためのメカニズムを提供します。これは、ハングルジャモと呼ばれます。ただし、最も一般的なジャモから作成された合成済み音節の11,172の組み合わせも提供します。

CJKの文字は、現在だけでその合成済みフォームのコードを持っています。それでも、これらの文字のほとんどはより単純な要素（部首と呼ばれる）で構成されているため、原則として、Unicodeはハングルの場合と同じようにそれらを分解できます。これにより、必要なコードポイントの数が大幅に削減され、考えられるほぼすべての文字を表示できるようになります（これにより、ハンユニフィケーションによって引き起こされる問題の一部が解消される可能性があります）。同様のアイデアは、CangjieやWubiなどの一部の入力方法でも使用されます。ただし、文字エンコードに対してこれを実行しようとすると、漢字がハングルほど単純にまたは定期的に分解されないという事実に遭遇しました。

ラジカルのセットはUnicode3.0で提供されていました（U + 2E80とU + 2EFFの間のCJKラジカル、U + 2F00からU + 2FDFまでのKangXiラジカル、およびU + 2FF0からU + 2FFBまでの漢字構成記述文字）が、Unicode標準（Unicode 5.2のch。12.2）は、以前にエンコードされた文字の代替表現として漢字構成記述文字を使用しないように警告しています。

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

合字[編集]

アラビア語やデーヴァナーガリーを含む多くのスクリプトには、文字形式の特定の組み合わせを特別な合字形式に組み合わせる必要がある特別な正書法の規則があります。結紮の形成を支配するルールは、ACEのような特殊なスクリプト整形技術を必要とする非常に複雑である（アラビア語書道エンジンができるDecoTypeを1980およびUnicode標準の印刷版における全てアラビア語の例を生成するために使用される）、となっている証拠コンセプトのためのOpenType、（アドビシステムズ社とMicrosoftによる）グラファイト（によるSILインターナショナル）、またはAAT（Apple社によります）。

オペレーティングシステムに指示するための指示もフォントに埋め込まれていますさまざまな文字シーケンスを適切に出力する方法。結合マークまたは発音区別符号の配置の簡単な解決策は、マークに幅0を割り当て、グリフ自体を左側のサイドベアリングの左側または右側に配置することです（使用するスクリプトの方向によって異なります）。このように処理されたマークは、その前にある文字の上に表示されますが、ベースグリフの幅または高さに対する位置は調整されません。視覚的にぎこちなく、一部のグリフと重なる場合があります。実際のスタッキングは不可能ですが、限られた場合に概算することができます（たとえば、タイのトップコンビネーション母音とトーンマークは、最初は異なる高さにすることができます）。通常、このアプローチは等幅フォントでのみ有効ですが、より複雑な方法が失敗した場合のフォールバックレンダリング方法として使用できます。

標準化されたサブセット[編集]

ユニコードのいくつかのサブセットが標準化されています。MicrosoftのWindows以来のWindows NT 4.0をサポートWGL-4ラテン語、ギリシャ語、またはキリル文字のスクリプトを使用して、すべての現代的なヨーロッパの言語をサポートするために考えられている657の文字、と。Unicodeの他の標準化されたサブセットには、多言語ヨーロッパサブセットが含まれます。[63]

MES-1（ラテン文字のみ、335文字）、MES-2（ラテン、ギリシャ語、およびキリル文字1062文字）[64]、およびMES-3AとMES-3B（2つの大きなサブセット、ここには示されていません）。MES-2には、MES-1およびWGL-4のすべての文字が含まれていることに注意してください。

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）
1F00–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）
7F、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、0C、10、14、18、1C、24、2C、34、3C、50–6Cボックスドローイング（00–7F）
80、84、88、8C、90〜93ブロック要素（80–9F）
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 ...）
FB01–02アルファベットのプレゼンテーションフォーム（00–4F）
FFFD特別

Unicode文字を適切に処理できないレンダリングソフトウェアは、認識されない文字の位置を示すために、それを開いた長方形、またはUnicodeの「置換文字」（U + FFFD、 ）として表示することがよくあります。一部のシステムは、そのような文字に関するより多くの情報を提供しようと試みました。Appleのラストリゾートフォントは、文字のUnicodeの範囲を示す代替グリフが表示され、国際SILのUnicodeのフォールバックフォントは、文字の16進スカラー値を示すボックスが表示されます。

マッピングとエンコーディング[編集]

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

Unicodeは、Unicode変換形式（UTF）エンコーディングとユニバーサルコード化文字セット（UCS）エンコーディングの2つのマッピング方法を定義します。エンコーディングは、Unicodeコードポイントの範囲（おそらくそのサブセット）を、コードユニットと呼ばれる固定サイズの範囲の値のシーケンスにマップします。すべてのUTFエンコーディングは、コードポイントを一意のバイトシーケンスにマップします。[65]エンコーディング名の数字は、コードユニットあたりのビット数（UTFエンコーディングの場合）またはコードユニットあたりのバイト数（UCSエンコーディングおよびUTF-1の場合）を示します。UTF-8およびUTF-16は、最も一般的に使用されるエンコーディングです。UCS-2はUTF-16の廃止されたサブセットです。UCS-4とUTF-32は機能的に同等です。

UTFエンコーディングには次のものが含まれます。

  • UTF- 8の前身であるUTF-1は、Unicode標準の一部ではなくなったISO2022との互換性を最大化します。
  • UTF-7、電子メールで使用されることがある廃止された7ビットエンコーディング（Unicode標準の一部ではありませんが、情報RFCとしてのみ文書化されています。つまり、インターネット標準トラックにはありません）。
  • UTF-8は、各コードポイントに1〜4バイトを使用し、ASCIIとの互換性を最大化します
  • UTF-EBCDIC、UTF-8に似ていますが、EBCDICとの互換性のために設計されています（Unicode標準の一部ではありません）
  • UTF-16は、コードポイントごとに1つまたは2つの16ビットコードユニットを使用し、サロゲートをエンコードできません
  • UTF-32は、コードポイントごとに1つの32ビットコードユニットを使用します

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

UCS-2およびUTF-16エンコーディングは、テキストファイルの先頭で使用するUnicodeバイト順序マーク（BOM）を指定します。これは、バイト順序の検出（またはバイトエンディアンの検出）に使用できます。 BOM、コードポイントU + FEFFには、使用されているUnicodeエンコーディングに関係なく、バイトの並べ替えが明確であるという重要な特性があります。 U + FFFE（バイトスワッピングU + FEFFの結果）は正当な文字と同等ではなく、テキストの先頭以外の場所にあるU + FEFFは、ゼロ幅の改行なしスペース（外観のない文字と合字の形成を防ぐ以外の効果はありません）。

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

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

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

GB18030は、中国標準化管理委員会によるUnicodeのもう1つのエンコード形式です。中華人民共和国（PRC）の公式文字セットです。BOCU-1とSCSUはUnicode圧縮方式です。エイプリルフールRFC 2005の指定された2つのパロディ、UTFエンコーディングをUTF-9とUTF-18。

採用[編集]

オペレーティングシステム[編集]

Unicodeは、テキストの内部処理と保存のための主要なスキームになりました。大量のテキストがまだレガシーエンコーディングで保存されていますが、Unicodeは新しい情報処理システムを構築するためにほぼ独占的に使用されています。初期の採用者は、UCS-2（UTF-16の固定幅2バイトの前身）を使用する傾向があり、その後、UTF-16（可変幅の現在の標準）に移行しました。これは、非サポートを追加するための最も混乱の少ない方法であったためです。 -BMP文字。最もよく知られているそのようなシステムは、Windows NT（およびその子孫であるWindows 2000、Windows XP、Windows Vista、Windows 7、Windows 8、およびWindows 10）です。）、UTF-16を唯一の内部文字エンコーディングとして使用します。ジャワおよび.NETのバイトコードの環境、MacOSの、およびKDEはまた、内部表現のためにそれを使用します。 Unicodeの部分的なサポートは、Microsoft Layer forUnicodeを介してWindows9xにインストールできます。

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

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

入力方法[編集]

主な記事：Unicode入力

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

ISO / IEC 14755、[68] 、それらのコードポイントからUnicode文字を入力するための方法を標準化し、いくつかの方法を指定します。基本的な方法があります。この方法では、開始シーケンスの後にコードポイントの16進表現と終了シーケンスが続きます。文字コード表プログラムなどを使用して、画面内のテーブルに文字を一覧表示する画面選択入力方法も指定されています。

既知の文字のコードポイントを見つけるためのオンラインツールには、JonathanHedleyによるUnicodeLookup [ 69]とBenjaminMildeによるShapecatcher [70]があります。Unicodeルックアップでは、検索キー（「分数」など）を入力すると、対応する文字とそのコードポイントのリストが返されます。Shapecatcherでは、Shapeコンテキストに基づいて、ボックスに文字を描画し、その描画に近い文字のリストとそのコードポイントを返します。

メール[編集]

主な記事：Unicodeと電子メール

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

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

Web [編集]

主な記事：UnicodeとHTML

W3Cのすべての推奨事項では、HTML 4.0以降、ドキュメントの文字セットとしてUnicodeが使用されています。Webブラウザは長年Unicode、特にUTF-8をサポートしてきました。以前は、主にフォント関連の問題に起因する表示の問題がありました。たとえば、v6以前のMicrosoftInternet Explorerは、コードポイントを含むフォントを使用するように明示的に指示されない限り、多くのコードポイントをレンダリングしませんでした。[71]

構文規則は文字の表示順序に影響を与える可能性がありますが、XML（XHTMLを含む）ドキュメントは、定義上、[72]は、以下を除くほとんどのUnicodeコードポイントの文字で構成されます。

  • ほとんどのC0制御コード、
  • 永続的に割り当てられていないコードポイントD800–DFFF、
  • FFFEまたはFFFF。

HTML文字は、エンコーディングがサポートしている場合は、ドキュメントのエンコーディングに従ってバイトとして直接表示されるか、ユーザーは文字のUnicodeコードポイントに基づいて数値文字参照として書き込むことができます。例えば、参考文献&#916;、&#1049;、&#1511;、&#1605;、&#3671;、&#12354;、&#21494;、&#33865;、及び&#47568;（又はと、進数で表現同じ数値&#x接頭辞として）などのすべてのブラウザ上に表示されるはずΔ、Й、ק、م、7、あ、叶、葉、および말。

指定する場合のURIをとして、たとえば、URLの中のHTTPリクエストは、非ASCII文字でなければなりませんパーセントエンコード。

フォント[編集]

主な記事：Unicodeフォント

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

TrueTypeとOpenTypeはUnicodeをサポートしているため、Unicodeに基づく無料の小売フォントが広く利用できます。これらのフォント形式はUnicodeコードポイントをグリフにマップしますが、TrueTypeフォントは65,535グリフに制限されています。

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

改行[編集]

Unicodeは、さまざまなプラットフォームでテキストファイルを読み取ろうとしたときに発生する改行の問題に部分的に対処します。Unicodeは、適合アプリケーションが行末記号として認識すべき多数の文字を定義します。

改行に関しては、UnicodeはU + 2028 LINESEPARATORとU + 2029 PARAGRAPHSEPARATORを導入しました 。これは、段落と行を意味的にエンコードするためのUnicodeソリューションを提供する試みであり、さまざまなプラットフォームソリューションのすべてを置き換える可能性があります。そうすることで、Unicodeは歴史的なプラットフォーム依存のソリューションを回避する方法を提供します。それにもかかわらず、UnicodeソリューションがこれらのUnicode行および段落区切り文字を唯一の正規の行終了文字として採用している場合はほとんどありません。ただし、この問題を解決するための一般的なアプローチは、改行の正規化によるものです。これは、Mac OS XのCocoaテキストシステムと、W3CXMLおよびHTMLの推奨事項によって実現されます。このアプローチでは、考えられるすべての改行文字が内部で共通の改行に変換されます（これは、レンダリングのためだけの内部操作であるため、実際には問題ではありません）。言い換えると、テキストシステムは文字を改行として正しく扱うことができます。入力の実際のエンコーディングに関係なく。

問題[編集]

哲学的および完全性の批判[編集]

ハンユニフィケーション（同じ歴史的特徴の文体のバリエーションとして扱うことができる東アジア言語の形式の識別）は、Unicodeの3つの地域すべてからの専門家の大多数の存在にもかかわらず、Unicodeの最も物議を醸す側面の1つになりました。レパートリーへの追加とハンユニフィケーションについてコンソーシアムとISOに助言するIdeographicResearch Group（IRG）。[75]

Unicodeは、古くて代替の漢字を別々にエンコードできなかったために批判されてきました。批評家は、古代の日本語と珍しい日本語の名前の処理を複雑にしていると主張しています。これは多くの場合、Unicodeがグリフ（言語ごとに異なることが多い基本文字の視覚的表現）ではなく文字をエンコードするという事実によるものです。グリフの統合は、基本的な文字表現だけでなく、言語自体がマージされているという認識につながります。[76] [説明が必要]Unicodeのハンユニフィケーションのポリシーに反して、中国語、日本語、韓国語の文字間のスタイルの違いを保持する代替エンコーディングを作成する試みがいくつかありました。その一例がTRONです（日本ではあまり採用されていませんが、日本語の歴史的なテキストを処理して好むユーザーもいます）。

Unicodeの初期バージョンでの21,000漢字未満のレパートリーは、主に現代の一般的な使用法の文字に限定されていましたが、Unicodeには現在92,000を超える漢字が含まれており、中国で使用される数千の歴史的および方言文字を追加する作業が続けられています。日本、韓国、台湾、ベトナム。

最新のフォントテクノロジーは、Unicode異体字シーケンスの形式で、代替グリフ表現のコレクションの観点から統一された漢字を表現する必要があるという実際的な問題に対処する手段を提供します。たとえば、OpenTypeのAdvanced Typographicテーブルでは、文字からグリフへのマッピングプロセスを実行するときに、いくつかの代替グリフ表現の1つを選択できます。この場合、選択する代替文字形式を指定するための情報をプレーンテキスト内で提供できます。

イタリックの有無にかかわらず示されるさまざまなキリル文字

同じスクリプト内の2つの文字の適切なグリフの違いがイタリックのみで異なる場合、右側のロシア語（標準のラベル付き）とセルビア語の文字の比較に見られるように、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（他のベンダー）。[77]

それはの使用分離するために、それらを必要とするため、日本の一部のコンピュータプログラマは、Unicodeに反対U + 005C \ REVERSE SOLIDUS（バックスラッシュ）とU + 00A5 ¥円記号JIS X 0201に0x5Cをにマッピングされた、とレガシーコードの多くが存在しますこの使用法で。[78] （これはまた、エンコードは、「¯」長音記号で今0xAFをチルダ「〜」0x7Eをに置き換えられます。）これらの文字の分離が存在する中でISO 8859-1長いユニコード前から、。

インド語群[編集]

インド語スクリプトなどタミルとデバナーガリは、それぞれが一致のみ128のコードポイントが割り当てられISCII標準。 Unicodeインド語テキストを正しくレンダリングするには、格納されている論理順序の文字を視覚的な順序に変換し、コンポーネントから合字（別名結合）を形成する必要があります。一部の地元の学者は、Unicodeコードの割り当てがこれらの合字を指していることを支持し、他の書記体系の慣習に反していると主張しましたが、Unicodeには下位互換性の目的でのみアラビア語や他の合字が含まれています。[79] [80] [81]Unicodeでの新しい合字のエンコードは発生しません。これは、合字のセットがフォントに依存し、Unicodeがフォントのバリエーションに依存しないエンコードであるためです。2003年に中国標準化管理委員会が956個の合成済みチベット音節のエンコードを提案したときに同じ種類の問題がチベット文字で発生しましたが[82]、これらは関連するISO委員会（ISO / IEC JTC 1 / SC 2）によってエンコードが拒否されました。[83]

タイ語のアルファベットのサポートは、タイ語の文字の順序について批判されています。前の子音の左側に書かれている母音เ、แ、โ、ใ、ไは、他のインド語スクリプトのUnicode表現とは異なり、音声順ではなく視覚順です。この複雑さは、UnicodeがThai Industrial Standard 620を継承しているためです。これは、同じように機能し、タイ語が常にキーボードで記述されていた方法でした。この順序付けの問題は、Unicode照合プロセスをわずかに複雑にし、照合のためにタイ文字を並べ替えるためにテーブルルックアップを必要とします。[76] Unicodeが話し言葉の順序に従ってエンコーディングを採用したとしても、辞書の順序で単語を照合することは依然として問題があります。例：แสดงという単語 [sadɛːŋ]「perform」は子音クラスター「สด」（子音「ส」に固有の母音）で始まり、母音แ-は、発話順にดの後に続きますが、辞書では、単語は書かれているとおりに、สに続く母音と照合されます。

結合文字[編集]

主な記事：結合文字
参照：Unicode正規化§正規化

分音記号付きの文字は、一般に、単一の合成済み文字として、または基本文字と1つ以上の非間隔マークの分解されたシーケンスとして表すことができます。例えば、およびE E（長音および急性上記と合成済みe）は両方ともとして現れ、同じレンダリングされるべきである（eは上記合成長音と上記組み合わせ急性続く）Eと長音及び急性のアクセントが、実際に、それらを外観は、文字の表示に使用されているレンダリングエンジンとフォントによって異なる場合があります。同様に、インド語のローマ化で必要とされるアンダードットは、しばしば誤って配置されます。[要出典]。多くの場合、合成済みグリフにマップするUnicode文字を使用できるため、問題を回避できますが、合成済み文字がエンコードされていない場合は、Graphite、OpenType、またはを使用するCharisSILなどの特殊なUnicodeフォントを使用することで問題を解決できることがよくあります。高度なレンダリング機能のためのAATテクノロジー。

異常[編集]

主な記事：Unicodeエイリアス名と略語

Unicode標準は、安定性を保証することを目的としたルールを課しています。[84]規則の厳格さに応じて、変更を禁止または許可することができます。たとえば、コードポイントに付けられた「名前」は変更できず、変更されません。ただし、「script」プロパティは、Unicode独自のルールにより、より柔軟です。バージョン2.0では、Unicodeはバージョン1から多くのコードポイントの「名前」を変更しました。同時に、Unicodeは、それ以降、コードポイントに割り当てられた名前は変更されなくなると述べました。これは、間違いが公開された場合、たとえ些細なことであっても、これらの間違いを修正できないことを意味します（BRACKETのスペルBRAKCETで発生した場合のように）文字名で）。2006年にキャラクター名の異常のリストが最初に公開され、2017年4月の時点で、問題が特定された94のキャラクターがありました[85]。

  • U + 2118℘ スクリプト大文字P：これは小文字です。資本は、 U + 1D4AB 𝒫数学SCRIPT CAPITAL P [86]
  • U + 034Fは ͏ 書記素JOINERを組み合わせる：DOESは書記素に参加しません。[85]
  • U + A015 ꀕ YISYLLABLE WU：これはYi音節ではなく、Yi踊り字です。
  • U +FE18︘ 垂直 右白レンズブラケットのプレゼンテーションフォーム：ブラケットのスペルが間違っています。[87]

スペルミスは、Unicodeエイリアス名と略語を使用して解決されます。

[編集]も参照してください

  • Unicodeエンコーディングの比較
  • Unicodeの宗教的および政治的シンボル
  • Unicodeの国際コンポーネント（ICU）、現在はICU- TCとしてUnicodeの一部
  • バイナリコードのリスト
  • Unicode文字のリスト
  • XMLおよびHTML文字エンティティ参照のリスト
  • オープンソースのUnicode書体
  • Unicodeに関連する標準
  • Unicode記号
  • ユニバーサルコード化文字集合
  • Lotus Multi-Byte Character Set（LMBCS）、同様の意図を持つ並行開発

注意事項[編集]

  1. ^ ユニコードコンソーシアムはあいまいな用語バイトを使用しています; 国際標準化機構（ISO）、国際電気標準会議（IEC）とインターネット技術タスクフォース（IETF）は、より具体的な用語の使用オクテットをUnicodeに関連する現在の文書に。

参考文献[編集]

  1. ^ 「Unicode標準：技術的な紹介」。2010年3月16日取得。
  2. ^ 「ランキングごとに分類された文字エンコーディングの使用状況調査」。w3techs.com 。2020年6月9日取得。
  3. ^ 「適合性」（PDF）。Unicode標準。2020年3月。2020年3月15日取得。
  4. ^ 「UAX＃29：Unicodeテキストセグメンテーション§3書記素クラスター境界」。unicode.org。2020-02-19 。2020年6月27日取得。
  5. ^ 「Unicode–簡単な紹介（上級）•せっかちなプログラマーのためのJavaScript」。exploringjs.com 。2020年6月14日取得。
  6. ^ 「Unicode入門」。mathias.gaunard.com 。2020年6月14日取得。
  7. ^ 「文字列と文字— Swiftプログラミング言語（Swift 5.2）」。docs.swift.org 。2020年6月14日取得。
  8. ^ 「私たちのラテン語-1の仮定を破る-怠惰を追求して」。manishearth.github.io 。2020年6月14日取得。Unicodeは、新しい国または地域が出現するたびに新しいフラグを追加することを望んでいませんでした。また、たとえば紛争地域を扱う場合など、国が何であるかを判断するというトリッキーなビジネスにも参入したくありませんでした。[..]たとえば、一部の中国のシステムでは、台湾の旗（🇹🇼）が表示されない場合があります。
  9. ^ 「コードポイントに意味を与えるのをやめましょう-怠惰を追求して」。manishearth.github.io 。2020年6月14日取得。人々は、コードポイントが何かを意味し、コードポイントの境界でのO（1）インデックス作成またはスライスが有用な操作であることをほのめかし始めます。
  10. ^ Unicode®ブルドッグ賞
  11. ^ a b c d e Becker、Joseph D.（1998-09-10）[1988-08-29]。「Unicode88」（PDF）。unicode.org（10周年記念復刻版）。Unicodeコンソーシアム。2016年11月25日にオリジナルからアーカイブ（PDF）。 2016年10月25日取得。1978年には、「ユニバーサル・サイン」のセットのための最初の提案はによって作られたボブ・ベルヴィルでゼロックスPARC。多くの人が新しいエンコーディングデザインの開発にアイデアを提供しました。 1980年以降、これらの取り組みはXerox Character CodeStandardに発展しました。 （XCCS）は、Ed Smura、Ron Pellarなどの努力により、1982年以来Xeroxが社内標準として維持している多言語エンコーディングです。
    Unicodeは、XCCSでの8年間の実務経験の結果として生まれました。XCCSとの根本的な違いは、PeterFenwickとDaveOptad（純粋な16ビットコード）、およびLee Collins（表意文字の統一）によって提案されました。Unicodeは、XCCSの多くの機能を保持しており、その有用性は、国際的な通信多言語システム製品で長年にわたって証明されています。
  12. ^ 「要約物語」。取得した2010年3月15日を。
  13. ^ Unicodeのリリースの歴史と出版の日付にunicode.org。2017年2月28日取得。
  14. ^ Searle、StephenJ。「UnicodeRevisited」。2013年1月18日取得。
  15. ^ B 「はUnicodeコンソーシアムのメンバー」。2019年1月4日取得。
  16. ^ 「UnicodeFAQ」。2020年4月2日取得。
  17. ^ 「サポートされているスクリプト」。unicode.org 。2021-05-20を取得。
  18. ^ 「BMPへのロードマップ」。Unicodeコンソーシアム。2018年7月30日取得。
  19. ^ 「スクリプトエンコーディングイニシアチブについて」。ユニコードコンソーシアム。2012年6月4日取得。
  20. ^ 「Unicode6.1ペーパーバックが利用可能」。announcements_at_unicode.org 。2012年5月30日取得。
  21. ^ 「Unicode14.0.0」。www.unicode.org 。2021-02-10を取得。
  22. ^ 「Unicode標準の列挙バージョン」。2016年6月21日取得。
  23. ^ a b c
    • 「Unicodeバージョン1.0」。1991年。
    • "1.0.0 / UnicodeData.txt（再構築）"。2004 。2010年3月16日取得。
  24. ^ a b "Unicode Data 1.0.1". Retrieved 2010-03-16.
  25. ^ a b
    • "Unicode version 1.1".
    • "Unicode Data 1995". Retrieved 2010-03-16.
  26. ^ a b
    • "Unicode version 2.0.0".
    • "Unicode Data-2.0.14". Retrieved 2010-03-16.
  27. ^ a b
    • "Unicode version 2.1.0".
    • "Unicode Data-2.1.2". Retrieved 2010-03-16.
  28. ^ "Unicode Data-3.0.0". Retrieved 2010-03-16.
  29. ^ "Unicode Data-3.1.0". Retrieved 2010-03-16.
  30. ^ "Unicode Data-3.2.0". Retrieved 2010-03-16.
  31. ^ "Unicode Data-4.0.0". Retrieved 2010-03-16.
  32. ^ "Unicode Data-4.1.0". Retrieved 2010-03-16.
  33. ^ "Unicode Data 5.0.0". Retrieved 2010-03-17.
  34. ^ "Unicode Data 5.1.0". Retrieved 2010-03-17.
  35. ^ "Unicode Data 5.2.0". Retrieved 2010-03-17.
  36. ^ "Unicode Data 6.0.0". Retrieved 2010-10-11.
  37. ^ "Unicode Data 6.1.0". Retrieved 2012-01-31.
  38. ^ "Unicode Data 6.2.0". Retrieved 2012-09-26.
  39. ^ "Unicode Data 6.3.0". Retrieved 2013-09-30.
  40. ^ "Unicode Data 7.0.0". Retrieved 2014-06-15.
  41. ^ "Unicode 8.0.0". Unicode Consortium. Retrieved 2015-06-17.
  42. ^ "Unicode Data 8.0.0". Retrieved 2015-06-17.
  43. ^ "Unicode 9.0.0". Unicode Consortium. Retrieved 2016-06-21.
  44. ^ "Unicode Data 9.0.0". Retrieved 2016-06-21.
  45. ^ Lobao, Martim (2016-06-07). "These Are The Two Emoji That Weren't Approved For Unicode 9 But Which Google Added To Android Anyway". Android Police. Retrieved 2016-09-04.
  46. ^ "Unicode 10.0.0". Unicode Consortium. Retrieved 2017-06-20.
  47. ^ "The Unicode Standard, Version 11.0.0 Appendix C" (PDF). Unicode Consortium. Retrieved 2018-06-11.
  48. ^ "Announcing The Unicode Standard, Version 11.0". blog.unicode.org. Retrieved 2018-06-06.
  49. ^ "The Unicode Standard, Version 12.0.0 Appendix C" (PDF). Unicode Consortium. Retrieved 2019-03-05.
  50. ^ "Announcing The Unicode Standard, Version 12.0". blog.unicode.org. Retrieved 2019-03-05.
  51. ^ "Unicode Version 12.1 released in support of the Reiwa Era". blog.unicode.org. Retrieved 2019-05-07.
  52. ^ a b
    • "Unicode 13.0.0".
    • "Announcing The Unicode Standard, Version 13.0". blog.unicode.org. Retrieved 2020-03-11.
  53. ^ "The Unicode Standard, Version 13.0– Core Specification Appendix C" (PDF). Unicode Consortium. Retrieved 2020-03-11.
  54. ^ "Glossary of Unicode Terms". Retrieved 2010-03-16.
  55. ^ "3.4 Characters and Encoding". The Unicode Standard, Version 13.0 (PDF). 2019. p. 19.
  56. ^ "2.4 Code Points and Characters". The Unicode Standard Version 12.0 – Core Specification (PDF). 2019. p. 29.
  57. ^ "Appendix A: Notational Conventions" (PDF). The Unicode Standard. Unicode Consortium. March 2020. In conformity with the bullet point relating to Unicode in MOS:ALLCAPS, the formal Unicode names are not used in this paragraph.
  58. ^ a b "Unicode Character Encoding Stability Policy". Retrieved 2010-03-16.
  59. ^ "Properties" (PDF). Retrieved 2020-03-15.
  60. ^ "Unicode Character Encoding Model". Retrieved 2010-03-16.
  61. ^ "Unicode Named Sequences". Retrieved 2010-03-16.
  62. ^ "Unicode Name Aliases". Retrieved 2010-03-16.
  63. ^ CWA 13873:2000 – Multilingual European Subsets in ISO/IEC 10646-1 CEN Workshop Agreement 13873
  64. ^ Multilingual European Character Set 2 (MES-2) Rationale, Markus Kuhn, 1998
  65. ^ "UTF-8, UTF-16, UTF-32 & BOM". Unicode.org FAQ. Retrieved 2016-12-12.
  66. ^ The Unicode Standard, Version 6.2. The Unicode Consortium. 2013. p. 561. ISBN 978-1-936213-08-5.
  67. ^ Pike, Rob (2003-04-30). "UTF-8 history".
  68. ^ "ISO/IEC JTC1/SC 18/WG 9 N" (PDF). Retrieved 2012-06-04.
  69. ^ Hedley, Jonathan (2009). "Unicode Lookup".
  70. ^ Milde, Benjamin (2011). "Unicode Character Recognition".
  71. ^ Wood, Alan. "Setting up Windows Internet Explorer 5, 5.5 and 6 for Multilingual and Unicode Support". Alan Wood. Retrieved 2012-06-04.
  72. ^ "Extensible Markup Language (XML) 1.1 (Second Edition)". Retrieved 2013-11-01.
  73. ^ Bigelow, Charles; Holmes, Kris (September 1993). "The design of a Unicode font" (PDF). Electronic Publishing. VOL. 6(3), 289–305: 292. |volume= has extra text (help)
  74. ^ "Fonts and keyboards". Unicode Consortium. 2017-06-28. Retrieved 2019-10-13.
  75. ^ A Brief History of Character Codes, Steven J. Searle, originally written 1999, last updated 2004
  76. ^ a b The secret life of Unicode: A peek at Unicode's soft underbelly, Suzanne Topping, 1 May 2001 (Internet Archive)
  77. ^ AFII contribution about WAVE DASH, "An Unicode vendor-specific character table for japanese". web.archive.org. 2011-04-22. Archived from the original on 2011-04-22.
  78. ^ ISO 646-* Problem, Section 4.4.3.5 of Introduction to I18n, Tomohiro KUBOTA, 2001
  79. ^ "Arabic Presentation Forms-A" (PDF). Retrieved 2010-03-20.
  80. ^ "Arabic Presentation Forms-B" (PDF). Retrieved 2010-03-20.
  81. ^ "Alphabetic Presentation Forms" (PDF). Retrieved 2010-03-20.
  82. ^ China (2002-12-02). "Proposal on Tibetan BrdaRten Characters Encoding for ISO/IEC 10646 in BMP" (PDF).
  83. ^ V. S. Umamaheswaran (2003-11-07). "Resolutions of WG 2 meeting 44" (PDF). Resolution M44.20.
  84. ^ Unicode stability policy
  85. ^ a b "Unicode Technical Note #27: Known Anomalies in Unicode Character Names". unicode.org. 2017-04-10.
  86. ^ Unicode chart: "actually this has the form of a lowercase calligraphic p, despite its name"
  87. ^ "Misspelling of BRACKET in character name is a known defect"

Further reading[edit]

  • The Unicode Standard, Version 3.0, The Unicode Consortium, Addison-Wesley Longman, Inc., April 2000. ISBN 0-201-61633-5
  • The Unicode Standard, Version 4.0, The Unicode Consortium, Addison-Wesley Professional, 27 August 2003. ISBN 0-321-18578-1
  • The Unicode Standard, Version 5.0, Fifth Edition, The Unicode Consortium, Addison-Wesley Professional, 27 October 2006. ISBN 0-321-48091-0
  • Julie D. Allen. The Unicode Standard, Version 6.0, The Unicode Consortium, Mountain View, 2011, ISBN 9781936213016, ([1]).
  • The Complete Manual of Typography, James Felici, Adobe Press; 1st edition, 2002. ISBN 0-321-12730-7
  • Unicode: A Primer, Tony Graham, M&T books, 2000. ISBN 0-7645-4625-2.
  • Unicode Demystified: A Practical Programmer's Guide to the Encoding Standard, Richard Gillam, Addison-Wesley Professional; 1st edition, 2002. ISBN 0-201-70052-2
  • Unicode Explained, Jukka K. Korpela, O'Reilly; 1st edition, 2006. ISBN 0-596-10121-X
  • Yannis Haralambous; Martin Dürst (2019). "Unicode from a Linguistic Point of View". In Haralambous, Yannis (ed.). Proceedings of Graphemics in the 21st Century, Brest 2018. Brest: Fluxus Editions. pp. 167–183. ISBN 978-2-9570549-1-6.

External links[edit]

  • Official website  · Official technical site
  • Unicode at Curlie
  • Alan Wood's Unicode Resources – contains lists of word processors with Unicode capability; fonts and characters are grouped by type; characters are presented in lists, not grids.
  • Unicode BMP Fallback Font – displays the Unicode value of any character in a document, including in the Private Use Area, rather than the glyph itself.