10． ＵＴＦ
10−１ UTFとは
Unicode の「コード」＝ U+0000 〜 U+10FFFF 自体は、各文字に割り当てられた背番号、つまり値抽象的な'値'です。
Unicode で表現した文字の集まり（文字列〜文章）を、ネットワーク上に流したり、ディスクに書きこむ実際上のデータ列にするには、
「符号化」すなわちエンコードについての決まりが別途必要になります。
先述のシフトＪＩＳでは、文字コードを１バイト刻みで並べたもの、コンピュータの内部メモリ上のバイト列、
ファイル化したデータ（符号）のバイト列がほぼ一致しています。
ASCII相当が１バイト、かな漢字は２バイトと決まっていたからです。
１文字あたりのコードが７ビット〜21ビットまで幅広く変化する Unicode はさすがにそういうわけにはいかず、
複雑な手続きのエンコードが必要です。
Unicode 及び ISO/IEC 10646 で符号化方式として規定されているのが「UTF」です。
UTF には UTF-7、UTF-8、UTF-16、UTF-32 というふうに複数種類あり、それぞれに一長一短があります。
10−２ UTF-7
７ビットデータまでしか扱えない（一部の）ネットワーク上でメール・ニュースをやりとりするための符号化方式です。
アルファベット（７ビット）はそのまま１バイトで符号化し、
漢字等、１文字で16〜21ビット（≒２〜３バイト）必要なコードは、後述する UTF-16(BE)で符号化 → さらにBase64という方式で符号化する、
という三段構えの方式です。
英数字のみからなる文字列（文章）以外ではむしろデータ量が増えることが多い、
最終的に作られるデータ列に'/'相当のバイトを含むためＵＲＬ表現の中に含めづらい、といった問題点もあます。
要するに上述のメール・ニュース配信以外では使わないほうがよい、非推奨の方式のようです。
10−３ UTF-8
2018年時点では、インターネット経由のデータ通信をはじめ、データ交換のフォーマットとして主流といえる方式です。
Winodows、多くのUnix系、Android など多くのＯＳで利用されています。
ひとつの符号を８ビット[xxxxxxxx]１単位で表現しています。
|
＜ Unicode ビット列 → UTF-8 によるバイト列化 ＞
U+0000〜U+007F [0yyy zzzz]7bitコード → [0yyy zzzz]1byte符号
例:'Z'(U+005A) [0101 1010]→[0101 1010]（0x5A）
U+0080〜U+07FF [0000 0xxx yyyy zzzz]8〜11bitコード → [110x xxyy][10yy zzzz]2byte符号
例:'π'(U+03C0)[0000 0011 1100 0000]→[1100 1111][1000 0000]（0xCF 0x80）
U+0800〜U+FFFF [wwww xxxx yyyy zzzz]12〜16bitコード → [1110wwww][10xx xxyy][10yy zzzz]3byte符号
例:'愛'(U+611B)[0110 0001 0001 1011]→[1110 0110][1000 0100][1001 1011]（0xE5 0x84 0x9B）
---- 上までが第０面、下は追加多言語面の領域 -----
U+010000〜U+1FFFFF [000u vvvv wwww xxxx yyyy zzzz]17〜21bitコード → [1111 0uvv][10vv wwww][10xx xxyy][10yy zzzz]4byte符号
例:'🐧'（U+01F427）[0000 0001 1111 0100 0010 0111]→[1111 0000][1001 1111][1001 0000][1010 0111]（0xF0 0x9F 0x90 0xA7）
英語圏の人は通常ASCIIコード部分しか使わないので、UTF-8でもデータ量≒文字数×１byteとなります。
ギリシャ文字、ロシア文字あたりだとデータ量≒文字数×２byte、かな漢字は１字あたり３〜４byteのデータ量となります。
ファイルの先頭にBOM（Byte Order Mark）
という特殊なデータを付加して、UTF-8 のデータであることを明示する場合があります。
規約上必須ではないのですが、それがないとUTFと解釈してくれないソフトもあったりします。
ところが逆に、BOMがあることによって「テキストデータではない」と処理を蹴ってしまうソフトもあり……。
10−４ UTF-16
ひとつの符号を１６ビット[xxxx xxxx xxxx xxxx]１単位で表現します。
Unicode のほとんどの文字を１単位２バイトで表せます。そのかわり、ASCII文字の表現にも２バイト使います。
追加多言語面に設定された文字は２単位使わないと表現できないので、２バイト×２単位＝４バイト必要です。
|
U+0000〜U+FFFF 7〜16bitコード → 2byte符号
例:'Z'(U+005A) [0101 1010] → [0000 0000][0101 1010]（0x00 0x5A）
例:'π'(U+03C0)[0000 0011 1100 0000] → [0000 0011][1100 0000]（0x03 0xC0）
例:'愛'(U+611B)[0110 0001 0001 1011] → [0110 0001][0001 1011]（0x61 0x1B）
---- 上までが第０面、下は追加多言語面の領域 -----
U+010000〜U+10FFFF
[000v vvvv wwww xxxx yyyy zzzz] 17〜21bitコード vvvvv：[0 0000](0x01) 〜 [1 0000](0x10)
↓
[1101 10uu][uuww wwxx][1101 11xx][yyyy zzzz]4byte符号 uuuu ＝ vvvvv - 1：[0000](0x00) 〜 [1111](0x0F)
例:'🐧'（U+01F427）
[0000 0001 1111 0100 0010 0111]
↓
[1101 1000][0011 1101][1101 1100][0010 0111]（0xD8 0x3D 0xDC 0x27）
英文主体のデータだとASCIIコードテキストの２倍のデータ量となってしまうため、容量的に（英語圏の人にとっては）は無駄の多い記録方式です。
でもその分、データ処理を２バイト刻みに統一できるので、内部処理的にはシンプルで高速な仕組みにできます。
日本語版 Windows の内部処理が Shift-JIS から Unicode（UTF-16）となったのもうなずけます。
また MacOS X、iOS などにも採用されています。
UTF-16には、ビッグ・エンディアン Big Endian ／リトル・エンディアン Little Endidan の区別があります。
Big Endian（BE） ビット列… [wwww xxxx yyyy zzzz] → 符号の並び順…前方 [wwww xxxx] [yyyy zzzz] 後方
Little Endidan（LE） ビット列… [wwww xxxx yyyy zzzz] → 符号の並び順…前方 [yyyy zzzz] [wwww xxxx] 後方
Windows で「Unicodeテキスト」と呼ばれるものは、特に明記のない場合、UTF-16(LE)形式だそうです。
Windows 内部処理用の UTF-16 はリトル・エンディアン(LE)です。
「UTF-16BE」、「UTF-16LE」というふうにエンディアンを明記してある場合はそれに従います（ BOM が付加されません）。
プログラミングをしないような一般ユーザーにはあまり関係ありませんが、テキストファイルの保存形式でその区別を選択させられるので、
「何を選ぶのが正解なんだ？？？」と迷った人もいるのではないでしょうか。
◆ 何を選べば…… ◆
区別のために、ファイルの先頭にBOM（Byte Order Mark）が付加されることがあります。
10−５ UTF-32
新しいUnicodeのすべての文字を１単位で表せるので、関連するプログラミングは非常にシンプルにできます。
そのかわり、ASCII文字の表現にも32ビット＝４バイト使います。
ほとんどが英数字のテキストだと、ASCIIベースの４倍の容量となってしまいます。
そのためテキストの外部メディア記録に用いることはまずなく、一部のシステムの内部処理などに採用されています。
あるいは、データ容量を気にするより文字列検索速度優先、例えばデータベース構築などに威力を発揮するのでしょう。
|
