- UCS-2 または UCS-4 を 8bit の可変長文字列として変換する。
- U+0000〜U+007F は変換されないので、ASCII で書いたものがそのまま通用する。
- "/"(0x2f) や "\"(0x5c) が変換文字列中に現れないので、ファイルシステムに直接使うことができる。
- 非常に単純なマッピングルール。
- マルチバイトの先頭、中間のビットパターンがはっきりしている。
- 万が一、一部データが欠落しても、すぐに復旧できる。(バイトのズレが発生しない。)
- 後ろから前に向かって文字単位でさかのぼれる。
- 先頭バイトを見るだけでその文字のバイト数がわかる。
| 領域 | ビット表現 | | U+0000_0000 〜 U+0000_007F | 0 B(06-00) | | U+0000_0080 〜 U+0000_07FF | 110 B(10-06), 10 B(05-00) | | U+0000_0800 〜 U+0000_FFFF | 1110 B(15-12), 10 B(11-06), 10 B(05-00) | | U+0001_0000 〜 U+001F_FFFF | 11110 B(19-17), 10 B(17-12), 10 B(11-06), 10 B(05-00) | | U+0020_0000 〜 U+03FF_FFFF | 111110 B(25-24), 10 B(23-18), 10 B(17-12), 10 B(11-06), 10 B(05-00) | | U+0400_0000 〜 U+7FFF_FFFF | 1111110 B(30-30), 10 B(29-24), 10 B(23-18), 10 B(17-12), 10 B(11-06), 10 B(05-00) |
- U+0001_0000 以降は UCS-2 では存在しない。
- Unicode 規格、RFC 3629 では、U+0010_FFFF 以降は存在しない。(UTF-16 のサロゲートペアで表現できる最大範囲までが定義されている。)
- UTF-16 のサロゲートペアのまま UTF-8 にエンコードするのは反則。(二重エンコード) Unicode 3.2 以降は間違いなく違反。
- しかし、UCS-2 として単純に扱っているシステムではそのままエンコードされている可能性がある。
- 「UTF-8 は最大3バイト」というのは間違いなので要注意。(間違ったまま3バイト固定長にしているプログラムがたくさんあるので要注意。)
- 0x00 〜 0x7f を 2 〜 4 バイトで表現することができてしまう(元より長いバイト数で表現できる)ことに注意。
- 0x00 と 0xc0 0x80 と 0xe0 0x80 0x80 と 0xf0 0x80 0x80 0x80 はすべて U+00000000 を示してしまう。
- 短いコードで表現できるのに長いコードで表現しているものは不正である。必ずはじくこと。デコードしてはならない。
デコードする場合の取り扱い †
先頭オクテット(lead byte) †
| 0x00 〜 0x7f | そのまま | | 0x80 〜 0xbf | エラー | | 0xc0 〜 0xdf | 下位5ビット取得。次1オクテット取得。 | | 0xe0 〜 0xef | 下位4ビット取得。次2オクテット取得。 | | 0xf0 〜 0xf7 | 下位3ビット取得。次3オクテット取得。 | | 0xf8 〜 0xfb | 下位2ビット取得。次4オクテット取得。 | | 0xfc 〜 0xfd | 下位1ビット取得。次5オクテット取得。 | | 0xfe 〜 0xff | エラー |
- 0xf0 〜 0xfd は UCS-2 ではあり得ない。
- 0xf8 〜 0xfd は Unicode 規格、RFC 3629 ではあり得ない。
- エラーの場合、先頭文字(0x00-0x7f, 0xc0-0xfd)まで読み飛ばすのが一般的だと思う。
2オクテット目以降(trail byte) †
| 0x00 〜 0x7f | エラー | | 0x80 〜 0xbf | 下位6ビット取得。 | | 0xc0 〜 0xff | エラー |
- エラーの場合、先頭文字(0x00-0x7f, 0xc0-0xfd)まで読み飛ばす(自身が先頭文字ならそこからデコード)が一般的だと思う。
|
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
