ユニバーサル文字セット文字

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

ユニコードコンソーシアム(UC)および国際標準化機構(ISO)がで協力ユニバーサル文字セット(UCS)。UCSは、自然言語、数学、音楽、およびその他のドメインで使用される文字を機械可読値にマッピングするための国際標準です。このマッピングを作成することにより、UCSは、コンピュータソフトウェアベンダーが相互運用し、UCSでエンコードされたテキスト文字列を相互に送信できるようにしますユニバーサルマップであるため、同時に複数の言語を表すために使用できます。これにより、複数のレガシー文字エンコーディングを使用する際の混乱を回避できます。、これは、複数の意味を持つ同じコードシーケンスをもたらす可能性があり、したがって、間違ったものが選択された場合、不適切にデコードされる可能性があります。

UCSには、100万文字を超える文字をエンコードする潜在的な容量があります。各UCS文字は抽象的に表されるコードポイントテキスト処理ソフトウェア(1,114,112 = 2の内部ロジック内の各文字を表すために使用0と1114111の間の整数であり、20 + 2 16 または17×2 16、又は110,000コードポイント)。2021年9月にリリースされたUnicode14.0の時点で、これらのコードポイントの288,512(26%)が割り当てられています。これには、144,762(13%)の割り当て文字、137,468(12.3%)が私用予約され、2,048が代理に、66が指定された非文字、825,600(74%)が未割り当てのままになります。エンコードされた文字の数は次のように構成されます。

  • 144,532のグラフィック文字(一部には表示されるグリフがありませんが、グラフィックとしてカウントされます)
  • 制御とフォーマットのための230の特別な目的の文字

ISOは、文字名からコードポイントへの文字の基本的なマッピングを維持します。多くの場合、「文字」と「コードポイント」という用語は同じ意味で使用されます。ただし、区別する場合、コードポイントは文字の整数、つまりアドレスと考えることができるものを参照します。UCS 10646の文字にはコードポイントとその名前の組み合わせが含まれていますが、Unicodeは、ブロック、カテゴリ、スクリプト、方向性など、他の多くの便利なプロパティを文字セットに追加します。

Unicodeは、UCSに加えて、次のような他の実装の詳細も提供します。

  1. UCSと他の文字セット間のマッピングを超越する
  2. さまざまな言語の文字と文字列のさまざまな照合
  3. 同じ行のテキストが左から右と右から左の間でシフトする可能性がある双方向テキストをレイアウトするためのアルゴリズム
  4. ケースフォールディングアルゴリズム

コンピュータソフトウェアのエンドユーザーは、さまざまな入力方法でこれらの文字をプログラムに入力します。入力方法は、キーボードまたはグラフィカル文字パレットを使用できます。

UCSは、平面、ブロック、文字カテゴリ、文字プロパティなど、さまざまな方法で分割できます。[1]

文字リファレンスの概要

アンHTMLXML、数値文字参照は、そのことにより、文字を指し、ユニバーサル文字セット/ Unicodeコードポイント、およびフォーマットを使用しています

&#nnnn;

また

&#xhhhh;

ここで、nnnn10進形式のコード・ポイントであり、hhhh16進形式のコード・ポイントです。xは、XML文書に小文字にする必要があります。NNNNまたはHHHHは、桁の任意の数であってもよいし、先行ゼロを含んでいてもよいです。HHHHは大文字がいつものスタイルですが、大文字と小文字を混在させることがあります。

対照的に、文字エンティティ参照置換テキストとして目的の文字を持つエンティティの名前で文字を参照しますエンティティは、事前定義(マークアップ言語に組み込まれている)するか、ドキュメントタイプ定義(DTD)で明示的に宣言する必要があります形式は、他のエンティティ参照の場合と同じです。

&名前;

ここで、nameは、エンティティの大文字と小文字を区別する名前です。セミコロンが必要です。

飛行機

UnicodeとISOは、コードポイントのセットを17の平面に分割し、それぞれが65536の異なる文字または合計1,114,112の文字を含むことができます。2021年(Unicode 14.0)の時点で、ISOとUnicodeコンソーシアムは、17のプレーンのうち7つに文字とブロックのみを割り当てています。その他は空のままで、将来の使用のために予約されています。

現在、ほとんどの文字が最初の平面である基本多言語面に割り当てられています。これは、基本多言語面が2オクテットでアドレス指定できるため、レガシーソフトウェアの移行を容易にするためです。最初の飛行機の外のキャラクターは通常、非常に特殊な、またはまれな用途です。

各平面は、最後の4桁のにある1または2桁の16進数(0〜9、A〜F)の値に対応します。したがって、U + 24321は平面2にあり、U + 4321は平面0にあります(暗黙的にU + 04321と読み取られます)。 )、およびU + 10A200は平面16にあります(16進数10 = 10進数16)。1つの平面内では、コードポイントの範囲は16進数の0000〜FFFFであり、最大65536のコードポイントが生成されます。平面は、コードポイントをその範囲のサブセットに制限します。

ブロック

UnicodeはUCSにブロックプロパティを追加し、各プレーンをさらに個別のブロックに分割します。各ブロックは、「数学演算子」や「ヘブライ文字」などの使用法による文字のグループです。以前に割り当てられていないコードポイントに文字を割り当てる場合、コンソーシアムは通常、類似した文字のブロック全体を割り当てます。たとえば、同じスクリプトに属するすべての文字または同様の目的のすべての記号が1つのブロックに割り当てられます。コンソーシアムがブロックに追加の割り当てが必要であると予想する場合、ブロックは未割り当てまたは予約済みのコードポイントを維持することもあります。

ものとUCSの対応の最初の256個のコード・ポイントISO 8859-1、最も人気のある8ビットの文字コード西洋世界その結果、最初の128文字もASCIIと同じになります。Unicodeはこれらをラテン文字ブロックと呼びますが、これら2つのブロックには、ラテン文字以外で一般的に役立つ多くの文字が含まれています。一般に、特定のブロック内のすべての文字が同じスクリプトである必要はなく、特定のスクリプトは複数の異なるブロックで発生する可能性があります。

カテゴリ

Unicodeは、すべてのUCS文字に一般的なカテゴリとサブカテゴリを割り当てます。一般的なカテゴリは、文字、マーク、数字、句読点、記号、またはコントロール(つまり、書式設定または非グラフィック文字)です。

タイプは次のとおりです。

  • 現代、歴史、および古代のスクリプト2021年(Unicode 14.0)の時点で、UCSは、世界中で使用されている、または使用されている159個のスクリプトを識別します。さらに多くの企業が、UCSを将来含めるためのさまざまな承認段階にあります。[2]
  • 国際音声記号UCSは、国際音声記号の文字にいくつかのブロック(300文字以上)を割り当てます。
  • 分音記号の組み合わせテキストを処理するためのUCSおよび関連するアルゴリズムの設計においてUnicodeによって考案された重要な進歩は、発音区別符号の組み合わせの導入でした。UnicodeとUCSは、任意の文字と組み合わせることができるアクセントを提供することにより、必要な文字数を大幅に削減します。UCSには合成済み文字も含まれていますが、これらは主に、Unicode以外のテキスト処理システムのUCS内でのサポートを容易にするために含まれています。
  • 句読点UCSは、発音区別符号を統一するとともに、スクリプト間で句読点を統一しようとしました。多くのスクリプトには句読点も含まれていますが、その句読点に他のスクリプトで同様のセマンティクスがない場合。
  • 記号多くの数学、技術、幾何学、その他の記号がUCSに含まれています。これにより、フォントの切り替えに依存してシンボリックグリフを提供するのではなく、独自のコードポイントまたは文字を持つ個別のシンボルが提供されます。
    • 通貨
    • 文字のようなこれらの記号は、℅などの多くの一般的なラテン文字の組み合わせのように見えます。Unicodeは、文字様記号の多くを互換性文字として指定します。これは、通常、文字の構成シーケンスをグリフに置き換えることでプレーンテキストにすることができるためです。たとえば、文字c / oの構成シーケンスをグリフ℅に置き換えます。
    • ナンバーフォーム。数詞は、主に合成済みの分数とローマ数字で構成されています。文字のシーケンスを構成する他の領域と同様に、Unicodeアプローチでは、文字を組み合わせて分数を構成する柔軟性が優先されます。この場合、分数を作成するには、数値と分数のスラッシュ文字(U + 2044)を組み合わせます。このアプローチが提供する柔軟性の例として、UCSには19個の合成済み小数文字が含まれています。ただし、可能な分数は無限にあります。構成文字を使用することにより、分数の無限大は11文字(0〜9および分数スラッシュ)で処理されます。合成済みのすべての分数のコードポイントを文字セットに含めることはできません。理想的には、テキストシステムは、合成済みの分数(1/3など)の1つであろうと、合成文字のシーケンス(1⁄3など)であろうと、分数に対して同じグリフを表示する必要があります。ただし、Webブラウザーは通常、Unicodeとテキスト処理でそれほど洗練されていません。そうすることで、合成済みの分数と結合シーケンスの分数が互いに隣り合って互換性があるように見えることが保証されます。
    • 矢印
    • 数学
    • 幾何学模様
    • レガシーコンピューティング
    • 制御画像多くの制御文字のグラフィック表現。
    • ボックス図面
    • ブロック要素
    • 点字パターン
    • 光学式文字認識
    • テクニカル
    • 絵記号
    • その他の記号
    • 絵文字
    • 記号と絵文字
    • 錬金術記号
    • ゲームの駒(チェス、チェッカー、ゴー、サイコロ、ドミノ、麻雀、トランプ、その他多数)。
    • チェスのシンボル
    • Tai XuanJing
    • 易経記号記号
  • CJK中国、日本、韓国(CJK)、台湾、ベトナム、タイの言語をサポートするために表意文字やその他の文字に専念しています。
    • ラジカルとストローク
    • 表意文字UCSの大部分は、東アジアの言語で使用される表意文字に専念しています。これらの表意文字のグリフ表現がそれらを使用する言語に分岐しているが、UCSは、これらの統一漢字をUnicodeは(統一漢のための)Unihanと言及するもので。Unihanでは、テキストレイアウトソフトウェアは、使用可能なフォントおよびこれらのUnicode文字と連携して、適切な言語に適切なグリフを生成する必要があります。これらの文字を統一しているにもかかわらず、UCSには92,000を超えるUnihan表意文字が含まれています。
  • 記譜法
  • デュプロワエ式速記
  • サットン手話表記
  • 互換文字UCSのいくつかのブロックは、ほぼ完全に互換文字に専念しています。互換性文字は、Unicodeのように文字とグリフを区別しないレガシーテキスト処理システムをサポートするために含まれている文字です。たとえば、多くのアラビア文字は、文字が単語の先頭に表示される場合と単語の先頭に表示される場合で、異なるグリフで表されます。Unicodeのアプローチでは、内部のマシンテキスト処理と保存を容易にするために、これらの文字を同じ文字にマップすることを好みます。このアプローチを補完するために、テキストソフトウェアは、コンテキストに基づいて文字を表示するためにさまざまなグリフバリアントを選択する必要があります。このような互換性の理由から、4000文字を超える文字が含まれています。
  • 制御文字
  • サロゲートUCSには、代理コードポイントペアの基本多言語面(BMP)に2048個のコードポイントが含まれています。これらのサロゲートを一緒に使用すると、2つのサロゲートコードポイントを使用して、他の16のプレーン内の任意のコードポイントをアドレス指定できます。これにより、UTF-16などの16ビットエンコーディング内で20.1ビットUCSをエンコードするための簡単な組み込みメソッドが提供されます。このようにして、UTF-16は単一の16ビットバイトでBMP内の任意の文字を表すことができます。次に、BMPの外側の文字は、サロゲートペアを使用して2つの16ビットバイト(合計4オクテット)を使用してエンコードされます。
  • 私用コンソーシアムは、さまざまなコミュニティ内で文字を割り当てることができるいくつかのプライベート使用ブロックとプレーン、およびオペレーティングシステムとフォントベンダーを提供します。
  • 文字以外コンソーシアムは、特定のコードポイントに文字が割り当てられないことを保証し、これらの非文字コードポイントを呼び出します。各平面の最後の2つのコードポイント(FEとFFで終わる)は、そのようなコードポイントです。最初の平面である基本多言語面全体に散在している他のいくつかがあります。

専用キャラクター

Unicodeは10万文字以上をコード化します。それらのほとんどは、線形テキストとして処理するための書記素を表します。ただし、書記素を表さないものや、書記素として例外的な処理が必要なものもあります。[3] [4]従来のラウンドトリップ機能に含まれているASCII制御文字やその他の文字とは異なり、これらの他の特殊目的の文字は、プレーンテキストに重要なセマンティクスを与えます。

ゼロ幅ジョイナーやゼロ幅非ジョイナーなど、一部の特殊文字はテキストのレイアウトを変更できますが、その他の特殊文字はテキストレイアウトにまったく影響を与えませんが、代わりにテキスト文字列の照合、照合、またはその他の処理方法に影響を与えます。数学的インビジブルなどの他の特殊用途の文字は、一般にテキストレンダリングに影響を与えませんが、高度なテキストレイアウトソフトウェアがそれらの周囲の間隔を微妙に調整することを選択する場合があります。

Unicodeは、Unicodeテキストをレンダリングするときに、フォントとテキストレイアウトソフトウェア(または「エンジン」)の間の分業を指定しません。OpenTypeAppleAdvanced Typographyなどのより複雑なフォント形式は、グリフのコンテキスト置換と配置を提供するため、単純なテキストレイアウトエンジンは、グリフの選択と配置のすべての決定をフォントに完全に依存する場合があります。同じ状況で、より複雑なエンジンは、フォントからの情報を独自のルールと組み合わせて、最良のレンダリングという独自のアイデアを実現する場合があります。 Unicode仕様のすべての推奨事項を実装するには、テキストエンジンを準備して、あらゆるレベルの洗練されたフォントを処理する必要があります。これは、コンテキストの置換と配置のルールが一部のフォント形式には存在せず、その他の形式ではオプションであるためです。 NS分数スラッシュはその一例です。複雑なフォントは、分数スラッシュ文字が存在する場合に位置規則を提供する場合と提供しない場合がありますが、単純な形式のフォントは提供できません。

バイト順マーク

テキストファイルまたはストリームの先頭に表示される場合、バイト順序マーク(BOM)U + FEFFは、エンコード形式とそのバイト順序を示唆します。

ストリームの最初のバイトが0xFEで2番目のバイトが0xFFの場合、これらのバイトはUTF-8では無効であるため、ストリームのテキストはUTF-8エンコードされない可能性があります。また、16ビットのリトルエンディアンワードとして読み取られる0xFE、0xFFはU + FFFEになるため、リトルエンディアンのバイト順UTF-16なる可能性は低くなります。これは無意味です。このシーケンスは、UTF-32エンコーディングのどの配置でも意味がないため、要約すると、テキストストリームがビッグエンディアンでUTF-16としてエンコードされていることを示すかなり信頼できる指標として機能します。バイトオーダー。逆に、最初の2バイトが0xFF、0xFEの場合、テキストストリームはUTF-16LEとしてエンコードされていると見なすことができます。これは、16ビットのリトルエンディアン値として読み取られると、バイトが期待される0xFEFFバイト順マークを生成するためです。ただし、次の2バイトが両方とも0x00の場合、この仮定は疑わしいものになります。テキストがヌル文字(U + 0000)で始まるか、正しいエンコーディングが実際にはUTF-32LEであり、完全な4バイトシーケンスFF FE 0000が1文字のBOMです。

U + FEFFに対応するUTF-8シーケンスは、0xEF、0xBB、0xBFです。このシーケンスは、他のUnicodeエンコード形式では意味がないため、そのストリームがUTF-8としてエンコードされていることを示すのに役立つ場合があります。

Unicode仕様では、テキストストリームでバイト順マークを使用する必要はありません。さらに、エンコード形式を通知する他の方法がすでに使用されている状況では使用しないでください。

数学的不可視

主に数学の場合、Invisible Separator(U + 2063)は、i⁣jのような2次元インデックスのように、句読点やスペースを省略できる文字間の区切り文字を提供します。Invisible Times(U + 2062)と関数適用(U + 2061)は、演算を示すグリフなしで項の乗算または関数の適用が暗示される数学テキストで役立ちます。Unicode 5.1では、Mathematical Invisible Plus文字(U + 2064)も導入されています。これは、整数の後に分数が続く場合は、積ではなく合計を示す必要があることを示している場合があります。

分数スラッシュ

分数スラッシュの使用この書体Apple Chancery)は、プレーンテキスト文字列「1 1⁄41¼」をレンダリングするものとして、左側に合成された共通の分数、右側に合成済みの分数のグリフを示しています。テキスト環境に応じて、単一の文字列「1 1⁄4」はいずれかの結果を生成する可能性があります。右側の結果は、分数シーケンスを単一の合成済み分数グリフに置き換えることによって得られます。
プレーンテキストでレンダリングされた「4 225分の221」:分数のスラッシュの使用状況のより精巧な例アップルチャンセリーこのフォントは、このセクションで説明されているUnicodeルールに従って分数を合成するための命令をテキストレイアウトソフトウェアに提供します

分数スラッシュ文字(U + 2044)は、Unicode標準で特別な動作をします:[5](セクション6.2、その他の句読点)

分数スラッシュを使用して作成された分数の標準形式は、次のように定義されます。1つ以上の10進数のシーケンス(一般カテゴリ= Nd)、小数スラッシュ、1つ以上の10進数のシーケンス。このような分数は、3/4などの単位で表示する必要があります。表示ソフトウェアが分数を単位にマッピングできない場合は、フォールバックとして単純な線形シーケンスとして表示することもできます(たとえば、3/4)。分数を前の数値から分離する場合は、スペースを使用して、適切な幅(通常、細い、ゼロ幅など)を選択できます。たとえば、1 + ZERO WIDTH SPACE + 3 + FRACTION SLASH +4は1¾として表示されます。

このUnicodeの推奨事項に従うことにより、テキスト処理システムはプレーンテキストのみから洗練された記号を生成します。ここで、分数スラッシュ文字の存在は、スラッシュの前後のすべての連続する数字から分数を合成するようにレイアウトエンジンに指示します。実際には、フォントとレイアウトエンジン間の複雑な相互作用のため、結果は異なります。単純なテキストレイアウトエンジンは、分数をまったく合成しない傾向があり、代わりに、Unicodeフォールバックスキームで説明されているように、グリフを線形シーケンスとして描画します。

より洗練されたレイアウトエンジンは、Unicodeの推奨に従うか、分数を合成するためにフォント独自の指示に依存するかの2つの実用的な選択に直面します。フォントの指示を無視することにより、レイアウトエンジンはUnicodeの推奨動作を保証できます。フォントの指示に従うことにより、数字の配置と形状がその特定のサイズでその特定のフォントに調整されるため、レイアウトエンジンはより良いタイポグラフィを実現できます。

フォントの指示に従うことの問題は、単純なフォント形式では分数合成の動作を指定する方法がないことです。一方、より複雑な形式では、フォントで分数合成の動作を指定する必要がないため、多くの場合必要ありません。複雑な形式のほとんどのフォントは、「1⁄2」などのプレーンテキストシーケンスを合成済みの「½」グリフに置き換えるようにレイアウトエンジンに指示できます。ただし、それらの多くは分数を合成するための命令を発行しないため、「221⁄225」などのプレーンテキスト文字列は22½25としてレンダリングされる可能性があります(½は合成ではなく、置換された合成済み分数です)。このような問題に直面した場合、推奨されるUnicodeの動作に依存したい人は、分数を合成することが知られているフォントまたはUnicodeを生成することが知られているテキストレイアウトソフトウェアを選択する必要があります。フォントに関係なく推奨される動作。

双方向ニュートラルフォーマット

書き込み方向は、Unicode文字列内の文字の順方向進行に関連してグリフがページに配置される方向です。英語およびその他のラテン文字の言語には、左から右への書き込み方向があります。アラビア語ヘブライ語などのいくつかの主要な書き込みスクリプトには、右から左への書き込み方向があります。Unicode仕様では、各文字に方向タイプ割り当てて、ページ上で文字のシーケンスをどのように順序付けるかをテキストプロセッサに通知します。

字句文字(つまり、文字)は通常、単一の書き込みスクリプトに固有ですが、一部の記号と句読点は、多くの書き込みスクリプトで使用されます。 Unicodeは、方向タイプのみが異なるレパートリー内の重複シンボルを作成する可能性がありますが、代わりにそれらを統合してニュートラル方向タイプを割り当てることを選択しました。それらは、レンダリング時に隣接するキャラクターから方向を取得します。これらの文字の一部には、右から左へのテキストで使用する場合にグリフを鏡像でレンダリングする必要があることを示す、bidi-mirroredプロパティもあります。

ニュートラル文字のレンダリング時の方向タイプは、方向の変更の境界にマークが配置されている場合、あいまいなままになる可能性があります。これに対処するために、Unicodeには、強い方向性があり、グリフが関連付けられておらず、双方向テキストを処理しないシステムでは無視できる文字が含まれています。

  • アラビア文字マーク(U + 061C)
  • 左から右へのマーク(U + 200E)
  • 右から左へのマーク(U + 200F)

双方向ニュートラルな文字を左から右のマークで囲むと、文字は左から右の文字として動作し、右から左のマークで囲むと、文字は右から左の文字として動作します。キャラクター。これらの文字の動作については、Unicodeの双方向アルゴリズムで詳しく説明されています。

双方向の一般的なフォーマット

Unicodeは、複数の言語、複数の書記体系、さらには作成者の介入を最小限に抑えて左から右または右から左に流れるテキストを処理するように設計されていますが、双方向テキストの混合が複雑になる可能性がある特別な状況があります。著者の管理。このような状況では、Unicodeには、右から左へのテキスト内の左から右へのテキストの複雑な埋め込みを制御するために、他に5つの文字が含まれています。

  • 左から右への埋め込み(U + 202A)
  • 右から左への埋め込み(U + 202B)
  • ポップ方向フォーマット(U + 202C)
  • 左から右へのオーバーライド(U + 202D)
  • 右から左へのオーバーライド(U + 202E)
  • 左から右への分離(U + 2066)
  • 右から左への分離(U + 2067)
  • 最初の強力な分離株(U + 2068)
  • ポップ指向性アイソレート(U + 2069)

インターリニアアノテーション文字

  • インターリニアアノテーションアンカー(U + FFF9)
  • インターリニアアノテーションセパレーター(U + FFFA)
  • インターリニアアノテーションターミネーター(U + FFFB)

スクリプト固有

  • プレフィックス付きフォーマット制御
    • アラビア数字記号(U + 0600)
    • アラビア語記号サナ(U + 0601)
    • アラビア語の脚注マーカー(U + 0602)
    • アラビア語記号Safha(U + 0603)
    • アラビア語記号SamVat(U + 0604)
    • 上記のアラビア数字マーク(U + 0605)
    • アーヤのアラビア語の終わり(U + 06DD)
    • シリア語略語マーク(U + 070F)
    • 上記のアラビアポンドマーク(U + 0890)
    • 上記のアラビア語ピアストルマーク(U + 0891)
    • Kaithi番号記号(U + 110BD)
    • 上記のカイティ番号記号(U + 110CD)
  • エジプトの象形文字
    • エジプトの象形文字垂直ジョイナー(U + 13430)
    • エジプトの象形文字水平ジョイナー(U + 13431)
    • トップスタートでのエジプトの象形文字挿入(U + 13432)
    • 下部の開始点にあるエジプトの象形文字挿入(U + 13433)
    • 上端にエジプトの象形文字を挿入(U + 13434)
    • 下端にあるエジプトの象形文字インサート(U + 13435)
    • エジプトの象形文字オーバーレイミドル(U + 13436)
    • エジプトの象形文字開始セグメント(U + 13437)
    • エジプトの象形文字エンドセグメント(U + 13438)
  • ブラフミ
    • ブラフミナンバージョイナー(U + 1107F)
  • Brahmiから派生したスクリプトのデッドキャラクター形成(Viramaおよび同様の発音区別符号)
    • デーバナーガリーサインヴィラーマ(U + 094D)
    • ベンガルサインビラマ(U + 09CD)
    • グルムキーサインビラマ(U + 0A4D)
    • グジャラートサインビラマ(U + 0ACD)
    • オリヤーサインヴィラーマ(U + 0B4D)
    • タミルサインビラマ(U + 0BCD)
    • テルグサインビラマ(U + 0C4D)
    • カンナダ語サインヴィラーマ(U + 0CCD)
    • マラヤーラム語サインバーティカルバービラマ(U + 0D3B)
    • マラヤーラム語サインサーキュラーヴィラーマ(U + 0D3C)
    • マラヤーラム語サインビラマ(U + 0D4D)
    • シンハラサインアルラクナ(U + 0DCA)
    • タイ文字ピントゥ(U + 0E3A)
    • タイキャラクターヤマカン(U + 0E4E)
    • ラオスサインパリビラマ(U + 0EBA)
    • ミャンマーサインビラマ(U + 1039)
    • タガログ語サインヴィラーマ(U + 1714)
    • タガログ語記号Pamudpod(U + 1715)
    • ハヌノオサインパムドポッド(U + 1734)
    • クメールサインビリアム(U + 17D1)
    • クメール記号Coeng(U + 17D2)
    • タイタムサインサコット(U + 1A60)
    • タイタムサインラハーム(U + 1A7A)
    • バリのAdegAdeg(U + 1B44)
    • スンダサインパマエ(U + 1BAA)
    • スンダサインビラマ(U + 1BAB)
    • バタクパンゴラット(U + 1BF2)
    • バタクパノンゴナン(U + 1BF3)
    • シロティナグリサインハサンタ(U + A806)
    • シロティナグリサインオルタネイトハサンタ(U + A82C)
    • サウラシュトラサインヴィラーマ(U + A8C4)
    • レジャンビラマ(U + A953)
    • ジャワパンコン(U + A9C0)
    • メイテイ文字ビラマ(U + AAF6)
    • カローシュティー文字ビラマ(U + 10A3F)
    • ブラフミビラマ(U + 11046)
    • ブラフミサインオールドタミルビラマ(U + 11070)
    • Kaithi Sign Virama(U + 110B9)
    • チャクマビラマ(U + 11133)
    • シャラダサインヴィラーマ(U + 111C0)
    • ホジャ文字サインビラマ(U + 11235)
    • クダワディサインビラマ(U + 112EA)
    • グランタサインヴィラーマ(U + 1134D)
    • ニューアサインヴィラーマ(U + 11442)
    • マイティリー文字のサインヴィラーマ(U + 114C2)
    • シッダムサインヴィラーマ(U + 115BF)
    • モディサインヴィラーマ(U + 1163F)
    • タークリー文字のヴィラーマ(U + 116B6)
    • アホムサインキラー(U + 1172B)
    • ドーグラーサインヴィラーマ(U + 11839)
    • ダイブアクルサインハランタ(U + 1193D)
    • ダイブアクルビラマ(U + 1193E)
    • ナンディナガリサインヴィラーマ(U + 119E0)
    • ザナバザールスクエアサインヴィラーマ(U + 11A34)
    • ザナバザールスクエアサブジョイナー(U + 11A47)
    • ソヨンボサブジョイナー(U + 11A99)
    • バイクスキサインヴィラーマ(U + 11C3F)
    • マサラムゴンディサインハランタ(U + 11D44)
    • マサラムゴンディヴィラーマ(U + 11D45)
    • グンジャラ・ゴンディ・ビラマ(U + 11D97)
  • 他の機能を備えた歴史的なヴィラーマ
    • チベットマークハランタ(U + 0F84)
    • ミャンマーサインアサット(U + 103A)
    • リンブーサインSa-I(U + 193B)
    • Meetei Mayek Apun Iyek(U + ABED)
    • チャクママヤヤ(U + 11134)
  • モンゴルのバリエーションセレクター
    • モンゴル自由変異セレクター1(U + 180B)
    • モンゴル自由変異セレクター2(U + 180C)
    • モンゴル自由変異セレクター3(U + 180D)
    • モンゴル語母音区切り文字(U + 180E)
  • ジェネリックバリエーションセレクター
    • バリエーションセレクター-1から-16(U + FE00–U + FE0F)
    • バリエーションセレクター-17から-256(U + E0100–U + E01EF)
  • タグ文字(U + E0001およびU + E0020–U + E007F)
  • ティフィナグ
    • ティフィナグ文字の子音ジョイナー(U + 2D7F)
  • オガム文字
    • オガム文字スペースマーク(U + 1680)
  • 表意文字
    • 表意文字変動インジケーター(U + 303E)
    • 表意文字の説明(U + 2FF0–U + 2FFB)
  • 音楽フォーマット制御
    • ミュージカルシンボルビギンビーム(U + 1D173)
    • ミュージカルシンボルエンドビーム(U + 1D174)
    • ミュージカルシンボルビギンタイ(U + 1D175)
    • ミュージカルシンボルエンドタイ(U + 1D176)
    • ミュージカルシンボルビギンスラー(U + 1D177)
    • ミュージカルシンボルエンドスラー(U + 1D178)
    • 楽譜開始フレーズ(U + 1D179)
    • ミュージカルシンボルエンドフレーズ(U + 1D17A)
  • 短縮フォーマット制御
    • 省略形のレターオーバーラップ(U + 1BCA0)
    • ショートハンドフォーマット継続​​オーバーラップ(U + 1BCA1)
    • 短縮フォーマットダウンステップ(U + 1BCA2)
    • 短縮フォーマットアップステップ(U + 1BCA3)
  • 非推奨の代替フォーマット
    • 対称スワッピングを禁止する(U + 206A)
    • 対称スワッピングをアクティブにする(U + 206B)
    • アラビア語のフォームシェーピングを禁止する(U + 206C)
    • アラビア語のフォームシェーピングをアクティブにする(U + 206D)
    • National Digit Shapes(U + 206E)
    • 公称桁形状(U + 206F)

その他

  • オブジェクト置換文字(U + FFFC)
  • 置換文字(U + FFFD)

文字とコードポイント

「文字」という用語は明確に定義されておらず、私たちがほとんどの場合参照しているのは書記素です。書記素は、そのグリフによって視覚的に表されます書体(しばしば誤っと呼ばれるフォント使用)は、同じ文字の視覚的な変化を示すことができます。2つの異なる書記素がまったく同じグリフを持っているか、視覚的に非常に接近しているため、平均的な読者がそれらを区別できない可能性があります。

書記素は、ほとんどの場合、1つのコードポイントで表されます。たとえば、ラテン大文字Aは、コードポイントU +0041のみで表されます。

書記素LATINCAPITALAWITHDIAERESISÄは、文字を複数のコードポイントで表すことができる例です。U + 00C4またはU + 0041U +0308にすることができます。U + 0041はおなじみのAであり、U + 0308は結合分音記号̈結合発音区別符号です。

結合マークが非結合マークコードポイントに隣接している場合、テキストレンダリングアプリケーションは、他のコードポイントによって表されるグリフに結合マークを重ね合わせて、一連のルールに従って書記素を形成する必要があります。[6]

したがって、BÄMという単語は3つの書記素になります。実際の文字構成によっては、3つ以上のコードポイントで構成されている場合があります。

空白、ジョイナー、セパレーター

Unicodeは、相互運用性をサポートするために空白文字と見なされる文字のリストを提供します。ソフトウェアの実装やその他の標準では、この用語を使用して、わずかに異なる文字のセットを表す場合があります。たとえば、JavaはU + 00A0 NO- BREAKSPACEまたはU + 0085 <control-0085>を考慮しません。  (次の行)Unicodeは空白ですが、空白にします。空白文字は、通常、プログラミング環境用に指定された文字です。多くの場合、これらはそのようなプログラミング環境では構文上の意味がなく、マシンインタプリタによって無視されます。Unicodeは、レガシー制御文字U +0009からU + 000DおよびU + 0085を空白文字として指定し、一般カテゴリプロパティ値が区切り文字であるすべての文字を指定します。Unicode 14.0の時点で、合計25文字の空白文字があります。

書記素ジョイナーと非ジョイナー

ゼロ幅ジョイナー(U + 200D)とゼロ幅非ジョイナー(U + 200C)は、グリフの接合および連結を制御します。ジョイナーは、他の方法では結合または結紮しない文字を発生させませんが、非ジョイナーとペアにすると、これらの文字を使用して、周囲の2つの結合または結紮文字の結合および結紮プロパティを制御できます。Combining Grapheme Joiner(U + 034F)は、主に基礎となるテキスト処理、文字列の照合、大文字小文字の区別などのために、2つのベース文字を1つの共通ベースまたは有向グラフとして区別するために使用されます。

単語の結合子と区切り文字

最も一般的な単語区切り文字はスペース(U + 0020)です。ただし、単語間の区切りを示し、改行アルゴリズムに参加する他の単語結合子と区切り文字があります。ノーブレークスペース(U + 00A0)も、グリフなしでベースラインアドバンスを生成しますが、改行を有効にするのではなく抑制します。ゼロ幅スペース(U + 200B)は改行を許可しますが、スペースを提供しません。ある意味では、2つの単語を分離するのではなく結合します。最後に、ワードジョイナー(U + 2060)は改行を抑制し、ベースラインの前進によって生成される空白も含まれません。

ベースラインアドバンス ベースラインアドバンスなし
改行を許可する
(区切り文字)
スペースU + 0020 ゼロ幅スペースU + 200B
改行を禁止する
(ジョイナー)
ノーブレークスペースU + 00A0 ワードジョイナーU + 2060

その他のセパレーター

  • ラインセパレーター(U + 2028)
  • 段落区切り文字(U + 2029)

これらは、キャリッジリターン(U + 000A)、ラインフィード(U + 000D)、ネクストライン(U + 0085)などの従来のエンコードされたASCII制御文字とは独立したネイティブの段落と行の区切り文字をUnicodeに提供します。Unicodeは、おそらくUnicodeプレーンテキスト処理モデルの一部ではない他のASCIIフォーマット制御文字を提供していません。これらの従来の書式設定制御文字には、タブ(U + 0009)、行集計または垂直タブ(U + 000B)、およびページ分割とも見なされるフォームフィード(U + 000C)が含まれます。

スペース

通常、キーボードのスペースバーによって入力されるスペース文字(U + 0020)は、多くの言語で意味的に単語区切り文字として機能します。従来の理由により、UCSには、スペース文字と互換性のある同等のさまざまなサイズのスペースも含まれています。さまざまな幅のこれらのスペースはタイポグラフィでは重要ですが、Unicode処理モデルでは、このような視覚効果をリッチテキスト、マークアップ、およびその他のそのようなプロトコルで処理する必要があります。これらは、主に他の文字セットエンコーディングからのロスレスラウンドトリップトランスコーディングを処理するためにUnicodeレパートリーに含まれています。これらのスペースには次のものが含まれます。

  1. En Quad(U + 2000)
  2. Em Quad(U + 2001)
  3. エンスペース(U + 2002)
  4. Emスペース(U + 2003)
  5. 3つあたりのスペース(U + 2004)
  6. 4つあたりのスペース(U + 2005)
  7. 6-per-Emスペース(U + 2006)
  8. 図形空間(U + 2007)
  9. 句読点(U + 2008)
  10. シンスペース(U + 2009)
  11. ヘアスペース(U + 200A)
  12. 中程度の数学的空間(U + 205F)

元のASCIIスペースを除いて、他のスペースはすべて互換文字です。このコンテキストでは、これは、テキストにセマンティックコンテンツを効果的に追加せず、代わりにスタイリング制御を提供することを意味します。Unicode内では、この非セマンティックスタイリングコントロールはリッチテキストと呼ばれることが多く、Unicodeの目標の範囲外です。さまざまなコンテキストでさまざまなスペースを使用するのではなく、このスタイリングはインテリジェントなテキストレイアウトソフトウェアを介して処理する必要があります。

他の3つの書記体系固有の単語区切り文字は次のとおりです。

  • モンゴル語母音区切り文字(U + 180E)
  • 表意文字スペース(U + 3000):表意文字セパレータとして動作し、通常、表意文字と同じ幅の空白としてレンダリングされます。
  • Ogham Space Mark(U + 1680):この文字は、グリフで表示される場合と、空白のみで表示される場合があります。

改行制御文字

いくつかの文字は、それらを落胆させる(改行なしの文字)か、ソフトハイフン(U + 00AD)(「シャイハイフン」と呼ばれることもあります)などの改行を提案することによって、改行を制御するのに役立つように設計されています。このような文字は、スタイリング用に設計されていますが、それらが可能にする複雑なタイプの改行にはおそらく不可欠です。

抑制を破る

  1. ノンブレークハイフン(U + 2011)
  2. ノーブレークスペース(U + 00A0)
  3. チベットマーク区切り文字TshegBstar(U + 0F0C)
  4. 狭いノーブレークスペース(U + 202F)

ブレーク禁止文字は、ワードジョイナーU +2060でラップされた文字シーケンスと同等であることが意図されています。ただし、単語結合子は、改行を許可してそのような改行を禁止する文字の前または後に追加できます。

ブレイクイネーブリング

  1. ソフトハイフン(U + 00AD)
  2. チベットマーク音節間Tsheg(U + 0F0B)
  3. ゼロ幅スペース(U + 200B)

ブレーク禁止文字とブレーク有効文字の両方が他の句読文字や空白文字と連携して、テキストイメージングシステムがUnicode改行アルゴリズム内の改行を判別できるようにします。[7]

特別なコードポイント

UCSで利用可能な数百万のコードポイントの中には、他の用途やサードパーティによる指定のために多くが確保されています。これらの取り分けられたコードポイントには、文字以外のコードポイント、サロゲート、および私的使用のコードポイントが含まれます。それらには、文字プロパティが関連付けられていないか、ほとんどない場合があります。

文字以外

66個の非文字コードポイント(ラベル付き<not a character>)が確保され、文字に使用されないことが保証されています。 17の平面のそれぞれには、非文字として取っておかれる2つの終了コードポイントがあります。したがって、文字以外は、BMPのU + FFFEとU + FFFF、プレーン1のU + 1FFFEとU + 1FFFFなど、プレーン16のU + 10FFFEとU + 10FFFFまで、合計34個のコードになります。ポイント。さらに、BMPには別の32個の文字以外のコードポイントの連続した範囲があります:U + FDD0..U + FDEF。したがって、ソフトウェアの実装では、これらのコードポイントを内部で自由に使用できます。非文字の特に有用な例の1つは、コードポイントU + FFFEです。このコードポイントには、バイト順マークの逆UTF-16 / UCS-2バイトシーケンスがあります(U + FEFF)。テキストのストリームにこの非文字が含まれている場合、これは、テキストが誤ったエンディアンで解釈されていることを示しています

3.1.0から6.3.0までのUnicode標準のバージョンは、文字以外は「決して交換されるべきではない」と主張していました。後に規格の正誤表#9は、これが「不適切な過剰拒否」につながると述べ、「[非文字]は交換において違法ではなく、不正な形式のUnicodeテキストを引き起こさない」ことを明確にし、元の主張を削除しました。

サロゲート

UCSはサロゲートを使用して、16ビットを超えるバイト表現に頼ることなく、最初の基本多言語面の外側の文字をアドレス指定します1024個の「高」サロゲート(D800–DBFF)と1024個の「低」サロゲート(DC00–DFFF)があります。サロゲートのペアを組み合わせることにより、他のすべてのプレーンの残りの文字をアドレス指定できます(他の16プレーンの1024×1024 = 1048576コードポイント)。UTF-16の高サロゲートは、このように一つのコードポイントを表すために32ビットを使用して、低サロゲートが続くように、彼らは常に、ペアで現れなければなりません。

サロゲートペアはコードポイントを示します

10000 16 +(H -D800 16)×400 16 +(L -DC00 16

ここで、HLは、それぞれ高サロゲートと低サロゲートの数値です。

DB80〜DBFFの範囲の高いサロゲート値は、常にプライベートユースプレーンで値を生成するため、高いサロゲート範囲は、(通常の)ハイサロゲート(D800〜DB7F)と「ハイプライベートユースサロゲート」(DB80〜DBFF)にさらに分割できます。 。

分離された代理コードポイントには、一般的な解釈はありません。したがって、この範囲の文字コードチャートまたは名前リストは提供されません。Pythonプログラミング言語、個々の代理コードは、Unicode文字列に埋め込む復号不可能バイトに使用されています。[8]

私的使用

UCSには、それぞれが私用領域(PUA)と呼ばれる3つの異なる範囲の私用の137468コードポイントが含まれています。 Unicode標準は、PUA内のコードポイントを正当なUnicode文字コードとして認識しますが、それらに(抽象的な)文字を割り当てません。代わりに、個人、組織、ソフトウェアベンダー、オペレーティングシステムベンダー、フォントベンダー、およびエンドユーザーのコミュニティは、適切と思われる方法でそれらを自由に使用できます。クローズドシステム内では、PUAの文字は明確に動作できるため、そのようなシステムはUnicodeで定義されていない文字またはグリフを表すことができます。パブリックシステムでは、レジストリがなく、複数の組織が異なる目的で同じコードポイントを採用するのを防ぐ方法がないため、それらの使用はより問題があります。そのような対立の一例はAppleですAppleロゴU + F8FFの使用と、ConScript UnicodeRegistryによるクリンゴンスクリプトクリンゴンミイラ化グリフとしてのU + F8FFの使用[9]

基本多言語面には、U + E000からU + F8FF(6400コードの場所)の範囲のPUAが含まれています。平面フィフティーン平面16個全てが、非文字を指定された最終的な2つのコードの位置、から成るのPUAを有しています。プレーン15のPUAは、U + F0000からU + FFFFD(65534コード位置)の範囲です。プレーン16のPUAは、U +100000からU + 10FFFD(65534コード位置)の範囲です。

PUAは、特定のアジアのエンコーディングシステムから継承された概念です。これらのシステムは、エンコードに私的使用の領域を持っていたもの、日本のコール外字アプリケーション固有の方法で、(通常のフォントには見られない珍しい文字)。

文字、書記素クラスター、グリフ

他の多くの文字セットは、文字のすべての可能なグリフ表現に文字を割り当てますが、Unicodeは文字をグリフとは別に処理しようとします。この区別は必ずしも明確ではありませんが、いくつかの例が区別を説明するのに役立ちます。多くの場合、テキストの読みやすさを向上させるために、2つの文字を活字で組み合わせることができます。たとえば、3文字のシーケンス「ffi」は単一のグリフとして扱われる場合があります。他の文字セットでは、個々の文字「f」と「i」に加えて、このグリフにコードポイントが割り当てられることがよくあります。

さらに、Unicodeは、発音区別符号の変更された文字を、レンダリングされると単一のグリフになる個別の文字としてアプローチします。たとえば、分音記号付きの「o」:「ö"。従来、他の文字セットでは、各言語で使用される発音区別符号の変更された文字ごとに一意の文字コードポイントが割り当てられていました。Unicodeは、発音区別符号の文字を任意の文字と組み合わせることができるようにすることで、より柔軟なアプローチを作成しようとしています。これにより、文字セットに必要なアクティブなコードポイントの数。例として、ラテン語のスクリプトを使用し、発音区別符号を大文字と小文字の「a」、「o」、および「u」と組み合わせた言語について考えてみます。 Unicodeアプローチでは、ラテン文字で使用する文字セットに発音区別符号文字のみを追加する必要があります:「a」、「A」、「o」、「O」、「u」、および「U」:7全部で文字。レガシー文字セットは、6つの合成済み文字を追加する必要があります 分音記号のない文字に使用される6つのコードポイントに加えて、分音記号のある文字:合計12の文字コードポイント。

互換文字

UCSには、Unicodeが互換文字として指定する数千の文字が含まれています。これらは、他の文字セットが区別する文字に個別のコードポイントを提供するために、UCSに含まれている文字ですが、Unicodeの文字アプローチでは区別されません。

この区別の主な理由は、Unicodeが文字とグリフを区別することでした。たとえば、筆記体のスタイルで英語を書く場合、文字「i」は、単語の最初、単語の終わり、単語の途中、または単独で表示されるかどうかにかかわらず、さまざまな形式をとることがあります。などの言語アラビア語アラビア文字で書かれたが、常に筆記体です。各文字にはさまざまな形式があります。 UCSには、わずか88個の固有のアラビア文字に分解される730個のアラビア語形式の文字が含まれています。ただし、これらの追加のアラビア文字は、テキスト処理ソフトウェアがテキストを他の文字セットからUCSに変換し、Unicode以外のソフトウェアにとって重要な情報を失うことなく元に戻すことができるように含まれています。

ただし、特にUCSとUnicodeの場合、単語のどこに表示されていても、常にその文字を同じ文字にエンコードまたはマップすることをお勧めします。次に、各文字の個別の形式は、フォントおよびテキストレイアウトソフトウェアの方法によって決定されます。このように、文字が単語のどこに現れるかに関係なく、文字の内部メモリは同一のままです。これにより、検索、並べ替え、その他のテキスト処理操作が大幅に簡素化されます。

文字のプロパティ

Unicodeのすべての文字は、大きく増え続けるプロパティのセットによって定義されます。これらのプロパティのほとんどは、ユニバーサル文字セットの一部ではありません。プロパティは、テキストの照合や並べ替え、単語、文、書記素の識別、テキストのレンダリングやイメージングなどのテキスト処理を容易にします。以下は、いくつかのコアプロパティのリストです。Unicode文字データベースには他にも多くの文書があります。[10]

財産 詳細
名前 ラテン大文字A これは、UnicodeとISOUCSの共同協力によって割り当てられた永続的な名前です。仕様の安定性を確保するために、いくつかの既知の不適切に選択された名前が存在し、確認されていますが、変更されません。[11]
コードポイント U + 0041 Unicodeコードポイントは、「Name」プロパティとともに永続的に割り当てられ、コンパニオンUCSに含まれる番号です。通常の習慣は、コードポイントを接頭辞「U +」を前に付けた16進数として表すことです。
代表的なグリフ LetterA.svg[12] 代表的なグリフはコードチャートで提供されます。[13]
一般カテゴリ 大文字 一般カテゴリ[14]は、大文字の場合は「Lu」、10進数の場合は「Nd」などの2文字のシーケンスとして表されます。
クラスの組み合わせ Not_Reordered(0) Unicodeでは、発音区別符号やその他の結合マークを複数の文字で表現できるため、「結合クラス」プロパティを使用すると、表現する結合文字のタイプによって文字を区別できます。結合クラスは、0〜255の整数、または名前付きの値として表すことができます。整数値を使用すると、結合マークを正規の順序に並べ替えて、同一の文字列の文字列比較を可能にすることができます。
双方向カテゴリ 左から右へ Unicode双方向アルゴリズムを適用するための文字のタイプを示します。
双方向ミラーリング 番号 双方向アルゴリズム内で文字のグリフを反転またはミラーリングする必要があることを示します。ミラー化されたグリフは、フォントメーカーによって提供されたり、「双方向ミラーリンググリフ」プロパティを介して関連する他の文字から抽出されたり、テキストレンダリングシステムによって合成されたりします。
双方向ミラーリンググリフ 該当なし このプロパティは、双方向アルゴリズム内でミラーリングするときに、そのグリフが現在の文字のミラーリングされたグリフとして機能できる別の文字のコードポイントを示します。
10進数の値 NaN 数字の場合、このプロパティは文字の数値を示します。10進数では、3つの値すべてが同じ値に設定され、表示のリッチテキスト互換文字およびその他のアラビア数字-インドの10進数以外の数字では、通常、後者の2つのプロパティのみが文字の数値に設定されますが、次のようなアラビア数字とは関係のない数字はローマ数字または漢州/蘇州の数字には、通常、「数値」のみが示されています。
桁値 NaN
数値 NaN
表意文字 NS 文字があることを示しCJKの表意文字logographにおける漢スクリプト[15]
デフォルトの無視可能 NS 文字が実装に対して無視可能であり、グリフ、最後の手段のグリフ、または置換文字を表示する必要がないことを示します。
非推奨 NS Unicodeはレパートリーから文字を削除することはありませんが、Unicodeが少数の文字を非推奨にする場合があります。

Unicodeは、さまざまなプロパティによってUnicode文字レパートリー全体をインタラクティブにクエリするためのオンラインデータベース[16]提供します。

も参照してください

参考文献

  1. ^ 「Unicode標準」ユニコードコンソーシアム2016年8月9日取得
  2. ^ 「Unicodeへのロードマップ」ユニコードコンソーシアム2021-09-15を取得しました
  3. ^ 「セクション2.13:特殊文字」(PDF)Unicode標準ユニコードコンソーシアム。2021年9月。
  4. ^ 「セクション4.12:異常な特性を持つ文字」(PDF)Unicode標準ユニコードコンソーシアム。2021年9月。
  5. ^ 「セクション6.2:一般句読点」(PDF)Unicode標準ユニコードコンソーシアム。2021年9月。
  6. ^ 「UTN#2:結合マークをレンダリングするための一般的な方法」www.unicode.org 20201216日取得
  7. ^ 「UAX#14:Unicode改行アルゴリズム」ユニコードコンソーシアム。2016-06-01 2016年8月9日取得
  8. ^ v.Löwis、Martin(2009-04-22)。「システム文字インターフェイスのデコード不可能なバイト」Python拡張提案PEP383 2016年8月9日取得
  9. ^ マイケルエバーソン(2004-01-15)。「クリンゴン:U + F8D0-U + F8FF」
  10. ^ 「Unicode文字データベース」ユニコードコンソーシアム2016年8月9日取得
  11. ^ フライターク、アスムス; マクゴーワン、リック; ウィスラー、ケン。「Unicodeテクニカルノート#27 —Unicode文字名の既知の異常」ユニコードコンソーシアム。
  12. ^ ない公式のUnicode代表グリフ、単に代表グリフ。Unicodeの公式の代表的なグリフを確認するには、コードチャートを参照してください
  13. ^ 「文字コードチャート」ユニコードコンソーシアム2016年8月9日取得
  14. ^ 「UAX#44:Unicode文字データベース」一般的なカテゴリ値ユニコードコンソーシアム。2014-06-05 2016年8月9日取得
  15. ^ デイビス、マーク; Iancu、Laurențiu; ウィスラー、ケン。「表9.プロパティテーブル§PropList.txt」Unicode標準付属書#44 —Unicode文字データベースユニコードコンソーシアム。
  16. ^ 「Unicodeユーティリティ:文字プロパティインデックス」ユニコードコンソーシアム2015年6月9日取得

外部リンク