[7] Unicode Character Database は、 Unicode の文字に関するデータを集めたデータベースです。 Unicode の仕様の一部を構成する規定のデータと、それ以外の参考のデータが共に含まれています。 UCD は Unicode Consortium により管理、配布されていて、 Unicode 本体と連動して改訂されています。
[8] 現代の言語やプロトコルの多くは、利用可能な文字の定義や正規化・照合順序などのアルゴリズムで利用するデータとして、 直接的または間接的に UCD のデータを参照しています。最近の多くの OS やプログラミング言語の実行環境には UCD やそこから派生したデータが含まれています。
[9] UCD のデータはテキストファイルとして提供されています。その書式はファイルにより異なり、 UAX #44 >>4 で説明されています。
NamesList.txtNamesList.htmlPropertyAliases.txtCompositionExclusions.txtDerivedBinaryProperties.txtBidiMirroring.txtBidiBrackets.txtStandardizedVariants.txtJamo.txtDerivedAge.txtDerivedCombiningClass.txtDerivedDecompositionType.txtArabicShaping.txtDerivedJoiningGroup.txtDerivedJoiningType.txtBlocks.txt[83] これらのファイルの多くは文字の特性を記述したものですが、 それ以外のものもあります。 特性以外の各ファイルは規定 (N, Normative), 参考 (I, Informative), 予備的 (P, Provisional) に分類されています >>82。 特性にもそれぞれの状態が定められています (>>85)。 もっともこの分類は仕様書としての形式的なもので、 実用上気にする場面はありません。
[46] 比較的古いファイルは独特の形式で、 比較的新しいファイルはできるだけ共通の形式を採用しているようです。 ファイルと特性の関係に規則性はなく、 個別に調べていくしかありません。 1つのファイルで複数の特性が定義されていることがあります。
[47] 多くのファイルは次のような構造をしています。 >>45
LF 区切りの行指向のファイルです。# から行末まではコメントです。
構文解析時にまず除去します。; で区切られた欄で構成されます。
0起算で数えます。[65] コメントには、
行頭に # があって欄がないものもあります。
ファイルの先頭にはファイル情報が書かれています。
派生特性はその導出方法が書かれています (>>28)。
既定値についての説明が書かれていることもあります
(>>73, >>74)。
@missing
は構文解析して使えることになっています。
[66] 欄の後にコメントが続くこともあります。 一定の書式で参考になる情報が書かれている場合もあります >>45。 しかしあくまで参考であって、 変更されることもあり得るので、 構文解析して使うべきではありません >>45。
[11] Unicode Standard および Unicode Character Database では、文字に関するデータを文字 (符号位置) の特性と呼んでいます。
[21]
特性にはそれぞれ General_Category
や Age のような名前がついています。
特性の名前は最低1つありますが、
別名が定義されているものもあります >>73。
PropertyAliases.txt には、
特性の別名に関する情報が収録されています >>1, >>73。
一致には別名も考慮するべきです
>>98。
更に緩い一致の規則があります >>98。
[2] 例えば Bidi_Mirroring_Glyph には
bmg という略称があり、
関連する文書で使われることがある他、
別名リストにも掲載されています >>1。
[12] 文字と特性のデータは >>9 の各ファイルに含まれています。どのように記述されているかはそれぞれの特性により異なり、 UAX #44 >>4 などに説明があります。
[85] 特性は規定 (N, Normative), 参考 (I, Informative), Contributory (C), 予備的 (P, Provisional) に分類されています >>84。 もっとも実用上はこの違いは然程重要ではありません。
[26] 単純特性と派生特性の違いは、 その特性が規定であるか参考であるかとは無関係です。 特性の重要度とも関係しません。
[25] contributory properties は、 単純特性のうち、 派生特性の規則の記述を簡潔にしたり一般化したりするために敢えて設けられたものです。 例外リストの記述の便法として使ったり、 重要な派生特性の安定性の保証に関係して使ったりされます。 >>22
[28] 派生特性の導出方法は、 UCD の各ファイルに注釈として説明がありますが、 改訂されることがあります >>22。 注釈の説明は参考です >>40。 導出方法と示された特性値が矛盾する場合、 示された特性値の方が規定と解釈されるべきです >>22。 実装は、誤りを防ぐため、単純特性から派生特性を導出するのではなく、 直接派生特性を使うべきです >>22。
[29] Unicode 10.0 から Unicode 12.1 まで、 segmentation 関係の特性が外部 (UCD 以外) の仕様の特定の版に依存する形で定義されていました。 UAX #14, UAX #29, UTS #51 で説明されていました。 Unicode 13.0 から UCD だけで完結するように改められました。 >>22
[37] 特性とその利用法については、 Unicode Standard 本体、 UCD の UAX #44、 UCD の各ファイル、 参照している各 UAX/UTS に分散して記述されています。 あちこちに情報が少しずつあって、 しかも相互のリンクが不十分なので、 苦労することも多いです。
[68] 第0欄には符号位置またはその範囲が指定されます。 また特性の値に符号位置が指定されることがあります。 次のように記述されます >>45。
U+ はつけません。).. で連結して表します。[87] 特性は値により次のように分類されています。 >>84
[35] 列挙特性の特性値の中には、どの符号位置でも使用されていないものが含まれる場合もあります。 過去の版で使用されていたものが、 使用されなくなったことがあります。 >>30
[72] その他特性で値が文字列となるものでは、 ファイルで省略されていたときの既定値は null 文字列です。 >>45
[74] 既定値はファイルのコメントの
@missing
行に機械可読に書かれることがあります。 >>45
いくつかの特性の既定値は例外的なものや複雑な方法で決定されるもので、
個別に説明があります
>>75, >>76。
# @missing: 0000..10FFFF; <none>
... のように、 # @missing:
の後に欄が続きます。
第0欄が適用対象の符号位置 (の範囲)、
第1欄が特性値を表します。
>>45
[78] ただし、一部のファイルには複数の特性が書かれているため、 第1欄が特性名、 第2欄が特性値を表します。 >>45
[79]
値には、
special tag
が使われることがあります。
<node>
は空文字列、
<code point>
は符号位置の値の文字列表現、
<script>
は符号位置の
Script
特性値を表します。
>>45
[97] 値には、 別名が定義されていることもあります >>73。 各仕様書などで使われることがあります。 一致には別名を考慮するべきです >>98。 更に緩い一致の規則があります >>98。
[13] UCD は Unicode が改版される度に併せて改訂されています。特に小改訂は UCD の更新が主目的であることもあります。
[14] Unicode の版によって値が変化する(可能性のある)特性もあれば、 不変であることが保証されている特性もあります。特性自体も改版により増えたり、減ったりしています。
[15] >>8 の通り、多くの言語やプロトコルには何らかの形で UCD のデータや Unicode の演算の実装が含まれています。それぞれが対応している Unicode の版に違いがあると、 正しくない結果が得られる可能性もあります。
[31] UCD のある特定の版は、 安定であって、出版後変更されることがありません >>30。 誤りは Errata で公表され、必要に応じて次の版で修正されます >>30。 しかしその特定の版のファイル自体は変更されません。
[32] UCD は、 Unicode の Webサイトで版ごとに公開されています。 この URL は安定で、 恒久的に提供されるとされています。 >>30 UCD の各ファイルは Webサイトから誰でも無償で入手可能です。
[42] 版が指定されない、最新版の UCD にアクセスできる URL もあります >>6。 UCD を使ったプログラムのための元データとして取得するときは、 この URL を使うのが便利です。
[33] (版をまたいだ) 特性の安定性は、 Unicode Consortium Stability Policies にまとめられています。 >>30 UAX #44 で変更しないと定められているものもあります >>100。 一度決めた値が変更されることはない特性もあれば、 変更される可能性があるものもあります。
[34]
U+200B
ZERO WIDTH SPACE
の
General_Category
は、
Zs
から
Cf
に改正されました。
>>30
[36] 特性は、 廃止されることがあります >>30。 廃止特性は、 重ねて非推奨や安定化されることがあります >>30。 状況の変化によって不要となったものが指定されるようです。 ただし特性自体は削除されることはない >>30 とされ、恒久的に残されるようです。
[39] 非推奨の特性は、 使うべきではありません >>30。
Deprecated という名前の特性もありますが、また別です。[38] 安定化された特性は、 値が凍結されて以後メンテナンスされません >>30。
[43]
UCD
に含まれる説明の .html
ファイルは、
廃止されることがあります
>>41。
廃止されると新しい版の
UCD
にはファイル自体が含まれなくなるようです。
[17] UCD のデータは EXHIBIT 1 UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND SOFTWARE の対象となっています。示された条件に従う限り、ソフトウェアへの組み込みなど自由に利用できるようです。
UnicodeData.txt[58] UnicodeData.txt
は、
UCD
のファイルの1つです。
古くからある基礎的な特性が記述されています。
[60] UnicodeData.txt のデータは他のファイルにも含まれていて、
そちらの方が使いやすいかもしれません。
[62] このファイルの形式は、 UCD の新しいファイルの形式 (>>46) と少し違うところもあります。
[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
[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