■UTFとは何か■

最近unicodeに対応したソフトが増加してくるにつれ、用語の混乱も一部には見られるようになってきました。そこで特に触れることの多い、UTF-7,UTF-8,UTF-16 についてここで少し取り上げておきたいと思います。

UnicodeとUCS

UnicodeはThe Unicode Consortiumが定めた文字コードの規格である。UCSはISOとIECが共同で制定したもので、ISO/IEC 10646 の規格番号が付いている。両者は大雑把にいえば同じものと考えてもよいのだが、違う機関が定めたものである故に、微妙に(?)差があるのも事実である。

UTF-16

UTF-16とはサロゲートの処理のことである。サロゲートについて詳しいことは新unicodeの項を参照のこと。つまり3バイト以上の文字コードをUCS2相当の世界に押し込むための仕様である。

UTF-8

UTF-8とは要するにUnicodeの世界をASCIIの世界に押し込むための仕様である。Unicodeがそのまま使用できると(BMPの)全ての文字が16bitで取り扱うことができて、ひじょうに便利なのだが、どうしても8bit単位で考えたい場面も多いし、そもそも現在数字や英字などを8bit単位で処理できているものをわざわざ16bitにしてしまうとコンピュータの処理速度も大幅にダウンする。そこで極めて不愉快なこういうコードが生まれてしまったのである。

UTF-8ではUnicodeを下記のようにして、8bit文字の列に変換する

0000〜007f (ASCII)	→	00〜7fに変換する
0080〜07ff (各国アルファベット)	→	c080〜dfbfに変換する
0800〜ffff (記号やCJK文字)	→	e08080〜efbfbfに変換する
サロゲート文字	→	f0808080〜f7bfbfbfに変換する

つまりUTF-8ではASCII文字は1バイトで表されるが、その他の文字は2〜4バイトであらわされることになる。特に日本語の文字はほとんど3バイト（特殊な文字ではそれ以上必要なものもある）になってしまうため、極めて効率の悪いエンコーディングである。なお具体的な変換の仕方は下記の通り。

1バイト	0000 0000 0aaa bbbb	→	0aaa bbbb
2バイト	0000 0aaa bbbb cccc	→	110a aabb 10bb cccc
3バイト	aaaa bbbb cccc dddd	→	1110 aaaa 10bb bbcc 10cc dddd

バリエーション

さて困ったことに、このUnicodeやUTF-8でファイルを記録する時にバリエーションが存在する。その主な点は下記の通りである。

305419896=0x12345678を0100番地に記録
Little Endian	Big Endian
0100 0101 0102 0103 7 5 3 1 8 6 4 2	0100 0101 0102 0103 1 3 5 7 2 4 6 8

(1)Little EndianかBig Endianか
(2)BOMを付加するのか。

Endianというのは数をメモリーに格納する時に下位の数値を下位に置くのか、それとも上位の数値を先に書くのかという話であり、PentiumやAlphaはLittle Endian, SPARCやPowerPCはBig Endianである。ARMはどちらにでも切り替えられるようになっている。Unicodeでは複数のバイトを使用して文字をあらわすため、このEndian問題が生じるのである。

ここで生まれた考え方がBOM(Byte Order Mark)というものである。これはファイルの先頭にわざとFEFFという文字を書いておくのである。すると、Little Endianなら先頭の2バイトは ff, fe になり、Big Endianなら fe,ff になるから、ファイルがどちらのコードで書かれているかが分かるというものである。

しかしこのような変なコードを先頭に付けられると、いろいろな場所でひじょうに多くの問題が発生する。しばしばコンピュータシステム上の処理はファイルの先頭数文字でその種類その他を判定するようにできているのである。このため、BOMは基本的に嫌われることが多く、現在のところこれを付けるべきだと主張する人はそれほど多くない。

なおUTF-8の場合は8bitコードなのでEndian問題は生じないがBOM(UTF-8の場合は EF BB BF)を付けるかどうかの問題はある。ここでBOM無しのUTF-8のことを『UTF-8n』と呼ぶ人もいるのだが、この付近でかなりの名前の混乱がある。大雑把にいうと

• BOMがあろうとなかろうと、UTF-8と呼ぶ人がいる。
• BOMのあるものをUTF-8と呼び、無いものをUTF-8nと呼ぶ人がいる。
• UTF-8(BOMがあってもなくても)のことをUnicodeと呼ぶ人がいる。
• BOMのことを知らない人も多い。
• UTFとUnicode(の生コード)の区別の付いてない人も多い。

実際に各仕様でデータがどのように記録されるのかの例を次節にあげる。

各仕様の出力例

下記は「TOKYO東京24時」という文字列を各仕様で出力した例である。

Code	BOM	Endian	出力バイト列
Unicode(UCS2)	○	Little	FFFE 5400 4F00 4B00 5900 4F00 7167 AC4E 3200 3400 4266 BOM T O K Y O 東 京 2 4 時
		Big	FEFF 0054 004F 004B 0059 004F 6771 4EAC 0032 0034 6642 BOM T O K Y O 東 京 2 4 時
	×	Little	5400 4F00 4B00 5900 4F00 7167 AC4E 3200 3400 4266 T O K Y O 東 京 2 4 時
		Big	0054 004F 004B 0059 004F 6771 4EAC 0032 0034 6642 T O K Y O 東 京 2 4 時
UTF-8	○		EFBBBF 54 4F 4B 59 4F E69DB1 E4BAAC 32 34 E69982 BOM T O K Y O 東 京 2 4 時
UTF-8 (UTF-8n)	×		54 4F 4B 59 4F E69DB1 E4BAAC 32 34 E69982 T O K Y O 東 京 2 4 時
UTF-7	×		54 4F 4B 59 4F 2B 5A 33 46 4F 72 41 2D 32 34 2B 5A 6B 49 T O K Y O ＋ 東京 − 2 4 ＋ 時

各文字の変換過程(UTF-8)

文字	unicode(4進)	変換	16進
東	6771(12131301)	(32) 12 (2)1 31 (2)3 01	E6 9D B1
京	4EAC(10322230)	(32) 10 (2)3 22 (2)2 30	E4 BA AC
時	6642(12121002)	(32) 12 (2)1 21 (2)0 02	E6 99 82

各文字の変換過程(UTF-7)

文字	unicode(4進)	64進	Base64
東京	6771 4EAC(1213 1301 1032 2230)	(121 313 011 032 223 0)25 55 5 14 43 0	Z3FOrA(5A 33 46 4F 72 41)
時	6642(1212 1002)	(121 210 02[0])25 36 8	ZkI(5A 6B 49)

UTF-7について

前節の最後に付けたUTF-7というのは、電子メールなどでunicodeを送信するための規格として生まれたものであるが、現実にはこの規格は普及しなかったため、現在では事実上の消滅規格となり、IETFでも非推奨規格としている。基本的なやり方は、非ASCIIの部分をBase64でエンコードして、前後に＋と−を付けるというものである。非ASCIIの文字で終了している場合は最後の−は無くても良い。

この規格は若干内容に曖昧な部分もあり、それもあって数多くのバリエーションが生まれている。しかし基本的には消えていく規格であろうから、あまり気にする必要はないであろう。

---

(2010年頃の文書)

---