Unicode® Standard Annex #44

Unicode Character Database

[7] Unicode Character Database は、 Unicode文字に関するデータを集めたデータベースです。 Unicode の仕様の一部を構成する規定のデータと、それ以外の参考のデータが共に含まれています。 UCDUnicode Consortium により管理、配布されていて、 Unicode 本体と連動して改訂されています。

[8] 現代の言語プロトコルの多くは、利用可能な文字の定義や正規化照合順序などのアルゴリズムで利用するデータとして、 直接的または間接的に UCD のデータを参照しています。最近の多くの OSプログラミング言語の実行環境には UCD やそこから派生したデータが含まれています。

仕様書

特性

[11] Unicode Standard および Unicode Character Database では、文字に関するデータを文字 (符号位置) の (とく) (せい) (プロパティー) (property) と呼んでいます。

[21] 特性にはそれぞれ General_CategoryAge のような名前がついています。 特性の名前は最低1つありますが、 別名が定義されているものもあります >>98 >>121

[2] 例えば Bidi_Mirroring_Glyph には bmg という略称があり、 関連する文書で使われることがある他、 別名リストにも掲載されています >>1

[19] UCD特性
[104] Unihan も参照。

[85] 特性規定 (N, Normative), 参考 (I, Informative), Contributory (C), 予備的 (P, Provisional) に分類されています >>84。 もっとも実用上はこの違いは然程重要ではありません。

[12] 文字特性のデータは >>9 の各ファイルに含まれています。どのように記述されているかはそれぞれの特性により異なり、 UAX #44 >>4 などに説明があります。

[37] 特性とその利用法については、 Unicode Standard 本体、 UCDUAX #44UCD の各ファイル、 参照している各 UAX/UTS に分散して記述されています。 あちこちに情報が少しずつあって、 しかも相互のリンクが不十分なので、 苦労することも多いです。


[86] 特性単純特性派生特性に分けられます。

[26] 単純特性派生特性の違いは、 その特性規定であるか参考であるかとは無関係です。 特性の重要度とも関係しません。

[25] contributory properties は、 単純特性のうち、 派生特性の規則の記述を簡潔にしたり一般化したりするために敢えて設けられたものです。 例外リストの記述の便法として使ったり、 重要な派生特性の安定性の保証に関係して使ったりされます。 >>22

[28] 派生特性の導出方法は、 UCD の各ファイルに注釈として説明がありますが、 改訂されることがあります >>22。 注釈の説明は参考です >>40。 導出方法と示された特性値が矛盾する場合、 示された特性値の方が規定と解釈されるべき (should) です >>22。 実装は、誤りを防ぐため、単純特性から派生特性を導出するのではなく、 直接派生特性を使うべき (should) です >>22

[27] つまり単純特性派生特性の違いは、 仕様 (Unicode 自体や、それを使うプロトコル) を検討する人達には意味があっても、 Unicode を実装する人達や、 Unicode を実装したプログラムUnicode を使ったプロトコルを使う人達には重要ではありません。

[115] Unicode符号点はただでさえ [ U+0000, U+10FFFF ] という大きな集合なので、 特性値を他の特性値の組み合わせで記述できるなら、 それで保存データ量を削減したいと思ってしまいます。 しかし実際派生特性の計算はかなり複雑だったりしますから、 素直に公式データをそのまま使った方が安全です。

[29] Unicode 10.0 から Unicode 12.1 まで、 segmentation 関係の特性が外部 (UCD 以外) の仕様の特定の版に依存する形で定義されていました。 UAX #14, UAX #29, UTS #51 で説明されていました。 Unicode 13.0 から UCD だけで完結するように改められました。 >>22

特性値

[87] 特性は値により次のように分類されています。 >>84

[150] この特性値データ型\p では少し違うので注意.

[116] ほとんどの特性には既定値が決められていて、 ファイルで省略されているときはその既定値特性値となります。 既定値UCDファイルの解釈に使うためのもので、 特性を使う処理の性質とは必ずしも関係ありません。

[74] 既定値ファイルコメント@missing 行に機械可読に書かれることがあります。 >>45 いくつかの特性既定値は例外的なものや複雑な方法で決定されるもので、 個別に説明があります >>75, >>76

[77] 既定値を表す @missing は、

# @missing: 0000..10FFFF; <none>

... のように、 # @missing: の後にが続きます。 第0欄が適用対象の符号位置 (の範囲)、 第1欄が特性値を表します。 >>45

[78] ただし、一部のファイルには複数の特性が書かれているため、 第1欄が特性名、 第2欄が特性値を表します。 >>45

[79] 値には、 special tag が使われることがあります。 <node>空文字列<code point>符号位置の値の文字列表現、 <script>符号位置Script 特性値を表します。 >>45


[97] 値には、 別名が定義されていることもあります >>98。 各仕様書などで使われることがあります。 (>>122)

私用文字

[102] 私用文字特性値については、 一部の例外を除き、 私的な同意に基づく変更が認められます。 私用文字

別名

[123] UCD特性やその値には、大量の (べつ) (めい) (alias) があります。

[126] 別名には次のような構文上の要件があります。 >>98 オリジナルの特性特性値については明言されていませんが、 それらも等しく“別名”であるとして同じ規則が適用されるものと思われます。

[125] 特性特性値一致には、 別名も考慮するべき (should) です >>98

[138] 特性別名は、それが1つの名前空間となります。 特性値別名は、各特性が1つの名前空間となります。 >>98

[151] Unicode正規表現\p においては、二値特性の名前を記述するべき欄に特例で General_CategoryScript特性値を記述できます。 \p ということは将来にわたってこれらが衝突しないことが望まれますが、 それが保証されているのかどうかは定かではありません。
[155] Unicode正規表現\p においては、 特性の名前として UCD特性の他にもいくつかの値が指定できます。 また、特別な意味を持つ identity という値も指定できることがあります。

[106] 先頭の is の有無 (>>148) だけの違いで別名の解釈が変わることもありません。 >>73

[107] 別名は他の値と互いに等価です。 UCD の各ファイルにはオリジナルの値が使われていることもあれば、 別名が使われていることもあります。 UCD を読み取る実装はすべての値に対応する必要があります。 UCD特性を使う実装も、普通はすべての値に対応する必要があります。

[108] 正規表現\pUCD特性名特性値別名も区別なく使えます。

[117] 具体的には各特性の項を参照。

[131] プラットフォームに応じて別名を変換したり、 他の別名を追加したりしても構いません。 しかしながら、 データ形式等では相互運用性のため UCD別名を使うことが推奨されます。 >>98

[132] プラットフォームの慣習に応じて _- に置き換えたり、 CamelCase にしたり、 といった変形があっても差し支えないようです。

[156] Perl正規表現 \p における General_Category では、 UCD別名に加えて L& が使えます。 General_Category

別名の比較

[124] 特性特性値別名 (記号値 (symbolic value) ) の一致 (等価性) は、 次によります。 >>73 UAX44-LM3

[130] UCD データファイルでは長い別名titlecase好ましい (preferred form) とされています。 >>98 引用等では UCD データファイル中の表記を踏襲するのが望ましいと思われます。

[149] なお、 Line_BreakIS がありますが、 値全体であって接頭辞ではないこと、 null value (ここでは空文字列のことか) は有効な値ではないことに注意されています。 >>73

[152] Unicode正規表現\p では、 この一致によることが推奨または要求されます。 ただし、 is を無視する件は要求されないことがあります。 \p

[153] \p では特性値ワイルドカード比較できます。 このとき無視は行われず、元の値と比較されます。 \p ということはその実装に使う UCD のデータの保存は、 無視による同一化を前提とした最適化を行えないということになります。

[154] 厳密には Unicode正規表現は必ずしも UCD のオリジナルの特性値そのものに対する一致を判定することを要求してはいないと読めますから、 最適化しても実装適合性には影響しないのでしょうが、 正規表現実装相互運用性利用者 (正規表現を書く開発者) の驚き最小化のためには、各実装の勝手な最適化が可視化されるべきではなさそうです。

別名の安定性

[134] 通常の別名安定性が保証されています。 >>98 改訂によって変更・削除されることがありません。

[133] ただし、 予備的特性や予備的データファイルについても別名は設定されることがありますが、 安定性は保証されません。 >>98

数値の比較

[141] 数値特性特性値一致は、 数値としての等価性 (numeric equivalence) によります。 >>73 UAX44-LM1

[142] "01.00" と "1" は等価です。 >>73

[143] UCD の "1.666667" は循環小数を表し、 "10/6" や "5/3" と等価です。 >>73

[144] 例示だけで具体的な比較の方法は定められていません。

文字の名前の比較

[145] 文字の名前を表す Name一致は、 特にその方法が規定されています。 >>73 UAX44-LM2 文字の名前

Unicode の版

[13] UCDUnicode が改版される度に併せて改訂されています。特に小改訂は UCD の更新が主目的であることもあります。

[14] Unicode の版によって値が変化する(可能性のある)特性もあれば、 不変であることが保証されている特性もあります。特性自体も改版により増えたり、減ったりしています。

[15] >>8 の通り、多くの言語やプロトコルには何らかの形で UCD のデータや Unicode演算の実装が含まれています。それぞれが対応している Unicode の版に違いがあると、 正しくない結果が得られる可能性もあります。

[31] UCD のある特定の版は、 安定 (stable) であって、出版後変更されることがありません >>30。 誤りは Errata で公表され、必要に応じて次の版で修正されます >>30。 しかしその特定の版のファイル自体は変更されません。

[32] UCD は、 UnicodeWebサイトで版ごとに公開されています。 この URL安定で、 恒久的に提供されるとされています。 >>30 UCD の各ファイルは Webサイトから誰でも無償で入手可能です。

[42] 版が指定されない、最新版の UCD にアクセスできる URL もあります >>6UCD を使ったプログラムのための元データとして取得するときは、 この URL を使うのが便利です。

[33] (版をまたいだ) 特性安定性は、 Unicode Consortium Stability Policies にまとめられています。 >>30 UAX #44 で変更しないと定められているものもあります >>100。 一度決めた値が変更されることはない特性もあれば、 変更される可能性があるものもあります。

[34] U+200B ZERO WIDTH SPACEGeneral_Category は、 Zs から Cf に改正されました。 >>30

[114] 具体的には各特性の項を参照。

[36] 特性は、 廃止 (obsolete) されることがあります >>30。 廃止特性は、 重ねて非推奨 (deprecated) 安定化 (stabilized) されることがあります >>30。 状況の変化によって不要となったものが指定されるようです。 ただし特性自体は削除されることはない >>30 とされ、恒久的に残されるようです。

[39] 非推奨特性は、 使うべきではありません >>30

[101] Deprecated という名前の特性もありますが、また別です。

[38] 安定化された特性は、 値が凍結されて以後メンテナンスされません >>30

[43] UCD に含まれる説明の .html ファイルは、 廃止されることがあります >>41。 廃止されると新しい版の UCD にはファイル自体が含まれなくなるようです。

UCD のライセンス

[17] UCD のデータは EXHIBIT 1 UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND SOFTWARE の対象となっています。示された条件に従う限り、ソフトウェアへの組み込みなど自由に利用できるようです。

ファイル

[9] UCD のデータはテキストファイルとして提供されています。その書式はファイルにより異なり、 UAX #44 >>4 で説明されています。

[10] UCD の主なファイル
[103] UCD 外の同様のファイル

[83] これらのファイルの多くは文字特性を記述したものですが、 それ以外のものもあります。 特性以外の各ファイル規定 (N, Normative), 参考 (I, Informative), 予備的 (P, Provisional) に分類されています >>82特性にもそれぞれの状態が定められています (>>85)。 もっともこの分類は仕様書としての形式的なもので、 実用上気にする場面はありません。

[46] 比較的古いファイルは独特の形式で、 比較的新しいファイルはできるだけ共通の形式を採用しているようです。 ファイル特性の関係に規則性はなく、 個別に調べていくしかありません。 1つのファイルで複数の特性が定義されていることがあります。

[47] 多くのファイルは次のような構造をしています。 >>45

[65] コメントには、 行頭に # があってがないものもあります。 ファイルの先頭にはファイル情報が書かれています。 派生特性はその導出方法が書かれています (>>28)。 既定値についての説明が書かれていることもあります (>>74)。 @missing構文解析して使えることになっています。

[66] の後にコメントが続くこともあります。 一定の書式で参考になる情報が書かれている場合もあります >>45。 しかしあくまで参考であって、 変更されることもあり得るので、 構文解析して使うべき (should) ではありません >>45


[68] 第0欄には符号位置またはその範囲が指定されます。 また特性の値に符号位置が指定されることがあります。 次のように記述されます >>45

UnicodeData.txt

[58] UnicodeData.txt は、 UCD のファイルの1つです。 古くからある基礎的な特性が記述されています。

[60] UnicodeData.txt のデータは他のファイルにも含まれていて、 そちらの方が使いやすいかもしれません。

欄#他のファイル
0符号位置
1Name (文字名称)NamesList.txt
2General_CategoryDerivedGeneralCategory.txt
3Canonical_Combining_ClassDerivedCombiningClass.txt
4Bidi_ClassDerivedBidiClass.txt
5Decomposition_Type, Decomposition_MappingDerivedDecompositionType.txt
6-8Numeric_Type, Numeric_ValueDerivedNumericType.txt, DerivedNumericValues.txt
9Bidi_MirroredDerivedBinaryProperties.txt
10Unicode_1_Name (廃止)
11ISO_Comment (廃止)
12Simple_Uppercase_MappingCaseFolding.txt, DerivedCoreProperties.txt
13Simple_Lowercase_MappingCaseFolding.txt, DerivedCoreProperties.txt
14Simple_Titlecase_MappingCaseFolding.txt, DerivedCoreProperties.txt

[62] このファイルの形式は、 UCD の新しいファイルの形式 (>>46) と少し違うところもあります。

[63] 欄の先頭と末尾に間隔は挿入できません。 >>45

[80] 欄が空文字列のとき、 既定値であることを表します。 >>45

[61] CJK統合漢字ハングル音節私用域などは各符号位置ではなく範囲として記述されているので注意が必要です。 また、未割当の符号位置非文字は含まれていません。

[64] この範囲の記述形式は、 新しいファイルのような .. を使う形式ではなく、 範囲の先頭の符号位置と、最後の符号位置を別々に記述する形式となっています。例えば、

4E00;<CJK Ideograph, First>;Lo;0;L;;;;;N;;;;;
9FEF;<CJK Ideograph, Last>;Lo;0;L;;;;;N;;;;;

... のように <..., First>, <..., Last> と書かれた2つので範囲であることが示されます。>>45

文脈

[110] UCD やその他のUnicode符号点 (やUnicode符号点)特性の情報は、 文字のレンダリングをはじめ文字の各種の処理で参照されます。 具体的には各特性の項を参照。

[111] Unicode正規表現UCD やその他の特性の多くにアクセスできる機能 \p を提供しています。 多くのプログラミング言語等の正規表現に組み込まれています。

[113] 多くのデータ形式プロトコルが、識別子データの構文の定義のために UCD やその他の特性を直接または間接的に参照しています。

[112] そうした機能の実装のために、多くのプラットフォームや各種のプログラムUCD の一部または全部を組み込んで使っています。

メモ

[16] 符号化文字集合の実装のためには、仕様書本文だけでなく、含まれている各文字の詳細な情報が必要になります。 旧来の符号化文字集合は比較的小規模で性質の似た文字のみを含んでいたこともあり、 そのような情報をほとんど提供してきませんでした。 UCD のような形で機械可読な実装用の情報を提供する符号化文字集合は他に無く、 これが Unicode の成功の要因の1つと言えるかもしれません。 (ISO/IEC 10646 も単独では十分な実装が困難でしょう。)

[20]ISO/IEC 10646 も単独を諦めて、今では多くの項目が Unicode を参照する形になっています。

[3] UTR #23: The Unicode Character Property Model ( 版) http://unicode.org/reports/tr23/

[18] Remove Unicode database version requirement · whatwg/javascript@4f1a517 ( 版) https://github.com/whatwg/javascript/commit/4f1a517f02bc15e934aafae0ec2b47c80786ab7f