仕様書

特性

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

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

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

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

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

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

• [23] 単純特性simple propertyは、 他の特性から計算できない特性です >>22。
• [24] 派生特性derived propertyは、 他の特性から一定の規則で導出される特性です >>22。

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

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

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

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

特性値

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

• [88] カタログCatalog (C) 特性は、 列挙値のいずれかを取る特性です。 列挙値は Unicode の改訂で順次追加されていくことが予期されています。 >>84
  • [69] ファイルで省略されていたときの既定値は、 ファイルのコメントで説明されます。 >>45
• [89] 列挙Enumeration (E) 特性は、 列挙値のいずれかを取る特性です。 通常は新しい値が追加されることはありません。 >>84
  • [96] ファイルで省略されていたときの既定値は、 ファイルのコメントで説明されます。 >>45
  • [35] 列挙特性の特性値の中には、どの符号位置でも使用されていないものが含まれる場合もあります。 過去の版で使用されていたものが、 使用されなくなったことがあります。 >>30
• [90] 二値バイナリーBinary (B) 特性は、 真 (Y, Yes, True) と偽 (N, No, False) の2値の特殊な列挙特性です。 >>84
  • [71] ファイルでは真を表すために特性名を書きます >>45。
  • [95] ファイルで省略されていたときの既定値は、偽です。 ファイルでは偽を記述せず、必ず省略します。 (ただし Extended_Pictographic は例外です。) >>45
• [91] 文字列String (S) 特性は、 通常は Unicode 符号位置から他の符号位置またはその列への写像です。 >>84
  • [94] ファイルで省略されていたときの既定値は、 その符号位置自身です >>45。
• [92] 数値Numeric (N) 特性は、 数字関連の文字に数値を指定する特性です。 >>84
  • [99] 値の一致は数値として行われます (>>141)。
• [93] その他Miscellaneous (M) 特性は、 他の種類に収まらない特性です。 >>84
  • [119] 複数の異なる値の順序のない集合のことがあります. >>118
    • [109] 例えば Script_Extensions の値は集合です。
  • [120] 複数の値の順序のある並びのことがあります. >>118
  • [72] その他miscellaneous特性で値が文字列となるものでは、 ファイルで省略されていたときの既定値は null 文字列です。 >>45

[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] 私用域の符号位置にも、 他の符号位置と同じように特性値が決められています。

[490] Unicode の多くのアルゴリズムは、 General_Category やそれから派生した特性を参照しています。 私用文字に関するその特性値は、 特に禁じた場合を除き、 私的な同意に基づき上書きして設定できます。 >>444

[491] その他の特性についても、 正規化に関係するものを除き、 UCD で定められた特性値は既定値であって、 参考とします。 この既定値は、 典型的な用例に基づき決められたもので、 私的な同意なき場合の一貫した挙動を定めることと、 一般的な利用を簡単化することを意図したものであります。 実装は、その私用に関する要件に従い適宜変更・上書きして構いません。 >>444

[4100] NFC など Unicode で規定された正規化は、 私用文字を変化させません。 私的な同意があってもこの挙動を変化させてはなりません。 (もちろん独自の正規化手法を採用する場合はこの限りではありません。) >>444

[4101] 特性値をどの程度変更しても良いかについて、 The Unicode Standard は特に言及していません。 しかし Unicode で規定される各アルゴリズムや、 特性値を参照するそれ以外の仕様書の規定、 特性値を参照するアプリケーション固有の挙動などは、 必ずしもあらゆる特性値の組み合わせを扱えるわけではありません。 他のどの Unicode文字でも起こり得ない組み合わせに対する挙動は想定されていない可能性があります。 仕様上は想定されていても、実装上は除去して最適化されていることがあり得ます。

[4102] とりわけ、 他の特性値から導出されるいくつかの特性値を扱うアルゴリズムは、 各特性値の一貫性を前提にしているかもしれません。 導出は Unicode の仕様書上の概念に過ぎず、 実装上は一方から他方が計算されるとは限りません 特性 。

[4103] 特性は既に相当数規定されている上に、 Unicode の改正のたびにどんどん追加されています。 私用文字のそれぞれについて、 すべての特性を適切な値に保ち続けるのは困難です。

[4104] そう考えると、 私用文字の定義の時に特性を1つ1つ設定していく方法より、 予め用意した特性値の組み合わせの中から適当なものを1つ選択する方法の方が、 現実的な実装手段ではないでしょうか。 「予め用意した特性値の組み合わせ」 も、 新たに独自に用意するよりは、 既存の Unicode符号位置を1つ選ぶことで記述するとした方が簡単そうです。 既存のどの Unicode符号位置とも特性が一致しない私用文字を使いたい可能性は、 それほど高くないでしょうから、 多くの利用はカバーできそうです。

[4105] 例えばアルファベット系の外字なら「A」、 漢字系の外字なら「一」 のように性質の似た既存の文字を選ぶ形にすればいいということです。

[4106] ただしこの手法でも、 大文字・小文字の変換の特性値や Unihan 系の特性値など、 すべての特性値を丸々コピーするわけにはいきません。

[4108] アプリケーションによっては、 相互運用性のため、 私用文字が使えたとしても特性値の変更までは認めない、 または特定の場面では特性値の変更を関知しないような制限があるかもしれません。

[4109] 例えば正規表現の \p は特性値によって文字の一致を判定します。 ネットワークで配布する条件記述ファイル中に含める正規表現で、 一致するか否かが変わると相互運用性に支障が出るまら、 必ず UCD の特性値通りに動作すると定めるべきでしょう。

[4110] 逆に、テキスト編集アプリケーションで、 選択した文字列の大文字を小文字に変換するボタンなら、 相互運用性には支障がなさそうですから、 利用者の便宜を優先するのが良さそうです。

[4113] 関連して非文字の場合については、非文字参照。

非Unicode文字

[157] Unicode は Unicode符号位置について規定していますが、 それ以外については規定していません。しかし実際には、

• [158] Unicode 以外の文字コードの文字や符号位置
• [159] 文字コード以外の方法で記述された文字や文字と同等のオブジェクト

が存在しています。現代においては Unicode をまったく無視したシステムは非現実的なので、 多かれ少なかれ Unicode の文字特性を活用することになりますが、 その場合の Unicode 以外との接続が問題となります。

• [161] Unicode 以外の文字コードのうち、 Unicode文字と対応関係が定まっているものは、 対応するUnicode符号位置の特性を準用すれば十分のことが多いと思われます。
• [162] Unicode 以外の文字コードのうち、 未割当の符号位置は、 Unicode の未割当符号位置の特性を準用するのがいいと思われますが、 どの符号位置の性質に近いか判断が必要となるかもしれません。
• [163] Unicode 以外の文字コードにあって Unicode に相当する文字がないものは、 個別に検討が必要です。
• [164] U-00110000 以上の符号位置は、 PUP は私用文字、それ以外は非文字の特性を準用するのがいいと思われます。
• [4107] マーク付け言語やプロトコルに依存した、 Unicode符号位置以外の方法で外字を表現・交換することもあります 外字 。
  • [160] そのような外字も、 Unicode の私用文字と同様に、 自然に扱うためには適切な特性値の情報が与えられていなければなりません。
  • [4111] それに対応した交換形式は Missing Characters in XML くらいしか見たことがありません。 しかしこの提案はほとんど使われていないようです。
• [165] 文字以外のオブジェクトは、 その性質に応じて個別に検討が必要になります。

別名

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

• [121] PropertyAliases.txt には、 特性の別名が収録されています >>1, >>98。
  • [135] 第1欄が省略された記号名abbreviated symbolic name、 第2欄が長い記号名long symbolic name (公式な名前) で、 その2つが好ましい別名preferred aliasとされます。 第3欄以後はその他の別名です。 >>98
• [122] PropertyValueAliases.txt には、 特性値の別名が収録されています >>105。
  • [136] 第2欄が省略された記号名abbreviated symbolic name、 第3欄が長い記号名long symbolic name (公式な名前) で、 その2つが好ましい別名preferred aliasとされます。 第4欄以後はその他の別名です。 >>98
    • [137] Canonical_Combining_Class は例外で、 省略名の前に数値名が入ります。 >>98
  • [139] 古い UCD では Age, Block, Joining_Group に該当なしを表す特殊値 n/a がありました。現在は使われていません。 >>98
• [140] 省略名と長い名前が同じこともあります。 >>98

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

• [128] ASCII英数字、_ のみを使います。 >>98
• [127] 別名の比較では大文字と小文字の違いは重要ではありません。 >>98
  • [129] つまり大文字と小文字の違いだけをもって異なる意味が割り当てられることがないということです。

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

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

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

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

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

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

数値の比較

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

文字の名前の比較

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

Unicode の版

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

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

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

[31] UCD のある特定の版は、 安定stableであって、出版後変更されることがありません >>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。 一度決めた値が変更されることはない特性もあれば、 変更される可能性があるものもあります。

[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 で説明されています。

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

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

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

• [48] UTF-8 です。
• [49] LF 区切りの行指向のファイルです。
• [50] # から行末まではコメントです。 構文解析時にまず除去します。
• [51] 各行は、 ; で区切られた欄fieldで構成されます。 0起算で数えます。
• [54] 欄の先頭と末尾の空白は、意味を持ちません。除去して解釈します。 (ただし、古めのファイルには例外あり。)
• [67] 欄の値は、 複数の値の間隔区切りのリストとなっていることがあります。 値の順序に意味があることも、ないこともあります。
• [81] 欄の値が空になることがあります。 意味はファイルにより異なります。
• [52] 第0欄は符号位置またはその範囲を表します。
• [53] 第1欄は第0欄の符号位置についての情報を表します。
• [70] 特性値が既定値default valueと同じとき、その符号位置の記述は省略できます。

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

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

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

• [55] 符号位置は、4桁から6桁の16進数列で表します。 (U+ はつけません。)
• [56] 符号位置の列は、 符号位置の間隔区切りで表します。
• [57] 符号位置の範囲は、先頭と末尾の符号位置を .. で連結して表します。

[166] GitHub - unicode-org/unicodetools: home of unicodetools and https://util.unicode.org JSPs · GitHub, 2026-03-19T09:49:36.000Z https://github.com/unicode-org/unicodetools

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

文脈

[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 (2015-05-28 05:51:30 +09:00 版) http://unicode.org/reports/tr23/

[18] Remove Unicode database version requirement · whatwg/javascript@4f1a517 (2016-02-19 22:53:52 +09:00 版) https://github.com/whatwg/javascript/commit/4f1a517f02bc15e934aafae0ec2b47c80786ab7f