Unicodeの版

[1] 色々な仕様が参照している Unicode の版の一覧です。 ISO/IEC 10646の版も参照してください。

[6] Living Standard の概念がなかった時代には、各種仕様書は特定の版を参照することが多くありました。今でもそのような仕様書が一部残存しています。

[7] その場合に新しい版に自動的に読み替えることが可能か、それとも特定の版に固定されていると理解するべきか、実装者に判断が委ねられることになり、相互運用性問題の温床となっております。

Unicode の版と文字の追加の関係は Age

Unicode の更新

[26] Unicode は数ヶ月に一度のペースで更新されており、新しい文字が追加されたり、 UCD に情報が追加・変更されたりしています。

[27] 基本的には Unicode の新しい版は古い版をすべて含み、それを拡張したものとなっていますが、非互換な変更が行われたことも何度かあります。

[28] Unicode 1.1 よりも前には多くの変更が行われていました。 Unicode 1.1 は ISO/IEC 10646-1:1993 に相当するもので、この版で Unicode がはじめて完成したと考えることができます。

[29] Unicode 2.0 では Korean mess などと呼ばれるハングルの大規模な非互換変更が行われました。

[30] 現在では Unicode Consortium は文字の符号化やいくつかの特性についての安定性に関する方針を設けており、その範囲においては新しい版になっても非互換性なく利用できるとされています。

[31] Unicode を参照している仕様の中には、このような安定性に関する問題のため、あるいは構文チェックなどのために未割当の符号位置の範囲を確定する必要があるためなどの理由で、特定の Unicode の版を要求しているものがあります。

[32] 例えば第5版以前の XML 1.0 は、第1版当時の Unicode 2.0 に基づき名前文字が決められていました。 Stringprep は、 Unicode 3.2 に基づき変換する文字や利用できる文字が決められており、正規化も Unicode 3.2 により行うとしています。

[33] しかし特定の Unicode の版に固定することで、それ以後追加された文字が使えないなど実用上の問題が生じているため (最初からちょっと考えればわかりそうなものですがw)、版の指定は外すようになってきています。 OS や実行環境に含まれる Unicode の実装に処理を委ねている場合、プロトコルや言語によって異なる Unicode の版を併用することが困難という事情もあります。

[34] 例えば IDNA2003 仕様は Stringprep により Unicode 3.2 に固定されていましたが、 IDNA2008 は Unicode が改訂される度に追随することになっていますし、 Webブラウザーが実装している IDNA は最新版の Unicode を使っています。

[48] XML 1.0 5e は XML 1.0 4e までの Unicode 2.0 ベースの定義を廃して改版のたびに改訂せずに済む定義に変更しています。

[49] HTML Standard は最新版の Unicode を参照しています。 JavaScript は特定の版の Unicode またはそれ以降の版を実装することを要求しています。

[8] ISO/IEC 10646の版も参照してください。

[12] NTFS はファイルシステムに大文字と小文字の対応表を格納しています。ファイルシステムの初期化時にそのプラットフォームの対応表を反映させる形で作成されます。ファイル名同じストレージをプラットフォームによって異なるUnicodeの版に従って処理することでの非互換性を抑止する方策ですが、同一プラットフォームでもストレージごとに扱いが違ってしまう可能性があるという問題も孕んでいます。 (例えば同じストレージで大文字・小文字不区別で一致したりしなかったりするファイル名が生じることはこの方針で防がれます。しかしストレージをまたいだファイル移動で問題が生じる危険性があります。)