[17] Unicode は [ 0, 0x10FFFF ] の整数を符号位置とし、 これに符号化文字を割り当てる方式としています。
[18] つまり Unicode の符号空間は 0x10FFFF 以下の非負整数の1次元です。
[19] ここで、
220 - 1 < 0x10FFFF < 221 - 1
です。すなわち21ビットあれば符号位置を相互に区別できます。 そこで Unicode は21ビットの符号と言われるわけです。
[22] ただし [ 0x110000, 221 - 1 ] は Unicode では使われていないことには注意が必要です。 Unicode は21ビットの符号とはいいつつ、21ビットをすべて使っている符号ではないわけです。
[23] Unicode は符号位置を整数で表せる単純な構造をしていますが、 これが他の符号化文字集合と比べて単純だ、複雑だと簡単に比較できるものではないことには注意が必要です。
[24] 整数1つで表せるのは符号位置であり、符号位置に割り当てられた文字です。 しかし、ここでいう文字とは 「Unicode が文字と考えたもの」 です。 「他の符号化文字集合が文字と考えたもの」 「一般人が文字と言われて思い浮かべるもの」 「文字学の専門家が文字として扱うもの」 とは必ずしも一致しません。定義が異なるものを単純、複雑と比較しても正確ではありません。
[46] Unicode には色々な文字が収録されています。
[57]
Unicode
は世界中の文字を収録しているとよくいわれますが、
含まれないものも多いです。
[84] Roadmaps to Unicode® に将来構想があります。
[66] 相互運用性の問題は個々にいろいろありますが、 文字の割当のレベルでもいろいろあります。
U+3400, U+4DFF ] / [ U+AC00, U+D7A3 ])[68]
初期 Unicode では
O-zone [ U+A000, U+DFFF ]
が未使用のまま空いていたので、
都合よく使えそうな領域として狙われていたのですね。
[69] 00162 | ⿰亻庚 | WS2021v5.0, https://hc.jsecs.org/irg/ws2021/app/?id=00162
This character is also needed as the personal name character in ROK, which is included in one modern internal system in ROK as U+A0100.
[70] >>69 「one modern internal system in ROK」というのが何かわからないが (名前を出していないのは非公開だから?)、 GB 18030 以外にも空き領域を勝手に使っているシステムが動いてるということか。 同じサイトでこの文言で検索するといくつか出てくるが、他の例は U+Fhhhh。
Character code system used by the Supreme Court of South Korea (as of 2023-02-01) 韓國最高法院漢字系統用字
は A0000 - A02DA, F0000 - F34BD の文字を示しています。 Unicode符号位置だとすると後者は PUA ですが、前者は勝手割当でしょうか?
[80] そしてその >>78 に含まれる文字の1つ、 A0100 >>79 がまさに >>69 ですね。
[71] GJKV 全部勝手に使ってて草、T もそういうのやってるんか?
[11]
Unicode はそれ自身が規定しない C0 や C1 の制御文字を使えると定めています。
[12]
Unicode では ISO/IEC 2022 エスケープシーケンスや
ISO/IEC 6429 制御機能も使えます。
ただし Unicode ではこれらは符号構造に組み込まれたものではなく
Unicode文字の列に過ぎないという解釈を採用しています。
[10] サロゲート符号位置は UTF-16 の符号単位としてのみ使うことができ、
Unicode文字列には出現することはない、というのが原則ですが、実際にはしばしば紛れ込みます。
U+10FFFF の先[2]
[ U-00110000, U-7FFFFFF ]
はかつて ISO/IEC 10646
で普通に存在していましたが、
Unicode が U+10FFFF までとしたために、
ISO/IEC 10646 からもこの領域は削除されてしまいました。
[4] UCS-4, UTF-1, UTF-8 (当初仕様) などで符号化できます。
[3] 削除以前からの実装などはこの領域に対応していることがあります。
[5]
当時はこの領域の中に私用の領域がありました。それを使っていた実装もありました。
[7]
Emacs は U-003FFFFF まで対応しています。
[8] 文字列の内部の処理の一時的な符号や文字列に混在する文字以外のオブジェクトの位置の表現などで、 Unicode文字列の入出力に絶対に出現することがないこの領域が使われる場合があります。
[32] i18n Arena internal encoding は独自の符号空間に UCS-2 と他の符号化文字集合を取り込んだ内部符号という建付けですが、 UCS-4 の私用域 (当時) に他の符号化文字集合を割り当てているとの見方もできます。
U-7FFFFFFF の先[15]
UCS-4 は32ビット符号ですが、最上位1ビットを内部処理等のために使用しないことにしています。
[16]
UTF-8 は符号構造上 U-7FFFFFFF よりも大きな値を表せるように自然に拡張できます。
[6]
Perl の utf8 は上限がアーキテクチャー依存で、
U-FFFFFFFF より大きな値も扱えます。
>>27
[13] Shift-Mojikyo は PUA の符号位置を2つ組合せて文字の領域を創出しています。
[14] GB 18030 には符号構造上存在するものの Unicode符号位置との対応関係が定められていない領域があります。
[30] Unicode の拡張とは逆に、 Unicode を使える符号は、 符号空間を拡張して Unicode を取り込んだ巨大な符号空間を持つと理解できます。