UTF-8

UTF-8 （ユ?ティ?エフはち、ユ?ティ?エフエイト）は ISO/IEC 10646 (UCS) と Unicode で使える8 ビット符??位（1?4 バイトの可?長）の文字符?化形式および文字符?化スキ?ム。

正式名?は、ISO/IEC 10646では “UCS Transformation Format 8”、Unicodeでは “Unicode Transformation Format-8” という。?者はISO/IEC 10646とUnicodeのコ?ド重複範?で互換性がある。 RFC にも仕?がある ^[1]。

2バイト目以降に「/」などの ASCII 文字が現れないように工夫されていることから、 UTF-FSS (File System Safe) ともいわれる。?名?はUTF-2。

UTF-8は、デ?タ交換方式?ファイル形式として一般的に使われる傾向にある。

?初は、ベル?究所において Plan 9 で用いるエンコ?ドとして、ロブ?パイクによる設計指針のもと、ケン?トンプソンによって考案された ^[2]^[3]。

エンコ?ド?系 [ 編集 ]

ASCII 文字と互換性を持たせるために、ASCIIと同じ部分は1バイト、その他の部分を2?6バイトで符?化する。4バイトのシ?ケンスでは21ビット (0x1FFFFF) まで表現することができるが、Unicodeの範?外となる17面以降を表すもの（U+10FFFFより大きなもの）は受け付けない。

また、5?6バイトの表現は、ISO/IEC 10646による定義 ^[4]と IETF によるかつての定義 ^[5]で、Unicodeの範?外を符?化するためにのみ使用するが、Unicodeによる定義 ^[6]とIETFによる最新の定義 ^[7]では、5?6バイトの表現は不正なシ?ケンスである。

後述のセキュリティの項に詳細はあるが、符?化は最少のバイト?で表現しなければならない。そのため、バイト?ごとにUnicodeの符?位置の最小値（下限）も設けている。

例えば、1バイトで表現するASCII文字は2バイト以上でも表現できるが、バイト?ごとの下限によってこれを回避している。

ビットパタ?ンは以下のようになっている。

バイト?	有?ビット	Unicode		2進?表記				16進?表記
1	0 7 bit			0 xxx-xxxx				00..7F
		下限	U+0000	0 000-0000				00
		上限	U+007F	0 111-1111				7F
2	11 bit			110 y-yyyx	10 xx-xxxx			C2..DF	80..BF
		下限	U+0080	110 0-0010	10 00-0000			C2	80
		上限	U+07FF	110 1-1111	10 11-1111			DF	BF
3	16 bit			1110 -yyyy	10 yx-xxxx	10 xx-xxxx		E0..EF	80..BF	80..BF
		下限	U+0800	1110 -0000	10 10-0000	10 00-0000		E0	80 ^*	80
		上限	U+FFFF	1110 -1111	10 11-1111	10 11-1111		EF	BF ^*	BF
4	21 bit			1111 - 0 yyy	10 yy-xxxx	10 xx-xxxx	10 xx-xxxx	F0..F4	80..BF	80..BF	80..BF
		下限	U+10000	1111 - 0 000	10 01-0000	10 00-0000	10 00-0000	F0	80 ^*	80	80
		上限	U+10FFFF	1111 - 0 100	10 00-1111	10 11-1111	10 11-1111	F4	BF ^*	BF	BF

* 第1バイトがE0のときに第2バイトが80-9Fの範?を、または同F0のときに80-8Fの範?を取るものは冗長な符?化となるため許されない。第1バイトがEDのときに第2バイトがA0以上となるものはサロゲ?トペアのための符?位置にあたり、また同F4のときに90以上となるものはUnicodeの範?外となるため、UTF-8ではやはり許されない。

Unicodeの符?位置を2進表記したものを、上のビットパタ?ンのx, yに右詰めに格納する（最少のバイト?で表現するため、yの部分には最低1回は1が出現する）。符?化されたバイト列は、バイト順に?わらず左から順に出力する。

1バイト目の先頭の連?するビット "1"（その後にビット "0" が1つ付く）の個?で、その文字のバイト?がわかるようになっている。また、2バイト目以降はビットパタ?ン " 10 " で始まり、1バイト目と2バイト目以降では値の範?が重ならないので、文字境界を確?に判定できる。すなわち、任意のバイトの先頭ビットが " 0 " の場合は1バイト文字、" 10 " の場合は2バイト以上の文字の2番目以降のバイト、" 110 " の場合は2バイト文字の先頭バイト、" 1110 " の場合は3バイト文字の先頭バイト、" 11110 " の場合は4バイト文字の先頭バイトであると判定できる。

7バイト以上の文字は規定されないため、 0xFE, 0xFFは使用されない。このため、バイト順マ?ク (BOM) に 0xFEと 0xFFを使用する UTF-16 や UTF-32 が、UTF-8と混同されることはない。

特? [ 編集 ]

利点 [ 編集 ]

ASCII文字コ?ドのテキストを?理するソフトウェアの多くがそのまま使える ^[8]。
バイトストリ?ム中の任意の位置から、その文字、前の文字、あるいは次の文字の先頭バイトを容易に判定することができる。
文字列の?索を?なるバイト列の?索として行っても、文字境界と異なる個所でマッチしてしまうことがない。たとえば Shift_JIS で「￥」(0x5C) を?索すると「表」(0x95 0x5C) の2バイト目にマッチしたり、 EUC-JP で「海」(0xB3 0xA4) を?索すると「ここ」(0xA4 0xB3 0xA4 0xB3) にマッチしたりするのと同?のことが起きない。このため、マルチバイト文字を意識せず、 ISO 8859-1 などの8ビット文字向けに作られた膨大なプログラム資産を、比較的少ない修正で再利用できる。
- ただし、他のUnicodeの符?化と同?に、?にバイト列の比較では文字列が同一か判?できない場合がある。詳細は、 Unicodeの等?性および正規化を?照のこと。
UTF-16 や UTF-32 と異なり、バイト?位の入出力を行うため、バイト順の影響がない。
21ビットまで表現できるため、サロゲ?トペアを使用する必要がない。
ASCII文字が主?の文書であれば、ほとんどデ?タサイズを?やさずにUnicodeのメリットを享受できる。UTF-16やUTF-32では、デ?タサイズはほぼ2倍、4倍となる。
複?のUTF-8文字列を、?なる符?なし8ビット整?の配列とみなして?書順ソ?トした結果は、Unicodeの符?位置の?書順のソ?ト結果（すなわちUTF-32に?換した後にソ?トした結果）と等しくなる。これに?して、サロゲ?トペアを含むUTF-16文字列を符?なし16ビット整?の配列とみなしてソ?トした結果は、Unicodeの符?位置の?書順のソ?ト結果と異なりうる。

欠点 [ 編集 ]

UTF-8による符?化では、漢字や ?名などの表現に3 バイトを要する。このように、東アジアの??文字コ?ドではマルチバイト符? を用いて1文字2バイトで表現されていたデ?タが、1.5倍かそれ以上のサイズとなる。同?に、 ISO/IEC 8859-1 では1バイトで表現できた非ASCIIのラテン文字（ウムラウト付きの文字など）も2バイトとなるし、その他の ISO/IEC 8859シリ?ズに?する文字符?ではデ?タ量がさらに?大しうる。
- なお、1バイトが9ビットである?理系では、この問題をあまり?生させずに符?化できるはずである。このアイディアに基づいたジョ?クRFC が RFC 4042 "UTF-9" として 2005年のエイプリルフ?ル（ 4月1日）に公開された。
最短ではない符?やサロゲ?トペアなど、UTF-8の規格外だがチェックを行わないプログラムでは一見正常に扱われるバイト列が存在する。これらのバイト列を入力として受け入れてしまうと、プログラムが予期しない範?のデ?タを生成するため、セキュリティ上の脅威となりうる ^[9]。

サロゲ?トペアの扱い [ 編集 ]

UTF-16 ではサロゲ?トペアで表されるような、基本多言語面外の符?位置をUTF-8で表す時は、?換元がUTF-16でサロゲ?トペアの時には U+D800? U+DBFF, U+DC00? U+DFFF を表すUTF-8にそのまま?換したりはせず、 U+10000? U+10FFFF の符?位置にデコ?ドしてから?換する。そのままUTF-8で符?化したような列は不正なUTF-8とされる。

サロゲ?トペアのままUTF-8と同等の符?化を行う符?化は、 CESU-8 ( Compatibility Encoding Scheme for UTF-16: 8-Bit ) として別途定義されている。?用に供されている例としては、 Oracle Database のバ?ジョン8以前において、UTF-8として3オクテットまでのオクテット列しか扱えなかったために定義されたものである。本?のUTF-8における4オクテット列の代わりに、サロゲ?ト符?位置を表す3オクテット列のペア（上位が ED A0 80? ED AF BF、下位が ED B0 80? ED BF BF）で表現される。

現在のOracle Databaseでも、CESU-8を「UTF8」として、「普通のUTF-8」を「AL32UTF8」として扱っているため注意を要する。 MySQL でも「utf8」を指定した場合は4オクテット列が扱えず、CESU-8相?の符?化を必要とする（4オクテット列??のUTF-8は「utf8mb4」として別途定義されているが、MySQL 5.5.3以降でないと使用できない ^[10]）。

また、 Java の一部の?部??で用いられている Modified UTF-8 も、サロゲ?トペアをそのまま?す仕?となっている。ただし、NULL文字を C0 80とエンコ?ドする（これもUTF-8規格外）点で、CESU-8とも異なる??となっている。

セキュリティ [ 編集 ]

UTF-8のエンコ?ド?系には冗長性があり、同じ文字を符?化するのに複?の表現が考えられる（例: スラッシュ記?である「/」を 0x2F という1バイトで表現するのではなく、0xC0 0xAF という2バイトもしくはそれより大きなバイト?で表現する）。かつてはそのような表現も許容されていたが、ディレクトリトラバ?サルなどの?策として行われる文字列?査を冗長な表現によりすり?ける手法が知られるようになったため、現在の仕?では最少のバイト?による表現以外は不正なUTF-8シ?ケンスとみなさなければならない ^[11]。

ISO/IEC 10646の定義が5バイト以上の表現を許容していることにより、正しくない??を行ったバグのあるシステムにおいてエンコ?ド時にバッファオ?バ?フロ? が?生する可能性も指摘されている。

文字種 [ 編集 ]

B	Unicode	スクリプト	JIS X 0201	JIS X 0208	JIS X 0212	JIS X 0213
1	U+0000?U+007F	ASCII	Roman（円記? ? オ?バ?ライン以外）
2	U+0080?U+07FF	ラテンダイアクリティカルギリシャキリルアルメニアヘブライアラビアシリアタ?ナンコ	円記?	非漢字の一部	非漢字の一部	非漢字の一部
3	U+0800?U+FFFF	インド系諸文字句?点 ?術記? ?文字東アジアの諸文字全角半角形など	オ?バ?ライン、Kana	?りの全て	?りの全て	大半
4	U+10000?U+10FFFF	古代文字、3に含まれない漢字				第3?第4水準漢字の一部

バイト順マ?クの使用 [ 編集 ]

UTF-8で符?されたテキストデ?タはバイト順マ?ク (BOM) の付加は不要である（エンディアンに?わらず同じ?容になるので）。

しかし、テキストデ?タがUTF-8で符?化されていることの標識として、デ?タの先頭にEF BB BF（16進。UCSでのバイト順マ?ク U+FEFFのUTF-8での表現）のシ?ケンスをBOMとして付加することが許される（推?はされない）。

この３バイトは、ZERO WIDTH NON-BREAKING SPACE を表すが、デ?タ先頭ではバイト順マ?クの機能を持たせている。
なお、日本の特殊事情として、このシ?ケンスがある方を UTF-8 、ない方を特に UTF-8N と呼び分けることもあるが ^[12]、日本以外ではほとんど知られておらず、また公的規格などによる裏付けもない ^[13]。

プログラム?アプリケションソフトの???況の問題 [ 編集 ]

BOM付きには??しないプログラムは標準的ではある。それらは、BOMを余分なデ?タとみなすので、問題も生ずる。

例えば、 Unix系 OSにおける?行可能スクリプトは、ファイル先頭が「 #! 」から始まるとき、それに?く文字列をインタプリタのコマンドとして認識するが、多くのシステムでは、このシ?ケンスが存在するとこの機能が?かず?行できない。PHPでは、 <?PHPの前に出力されるため、 header()??の?行に失敗する原因となる。 HLSL や GLSL のシェ?ダ? プログラムコンパイラ（fxcやglslangValidator）はBOMを?理できず、コンパイルエラ?となる。

一方、一部のテキスト?理アプリケ?ション（テキストエディタなど）ではBOMを前提とした動作をする ^[14]。同?にこのシ?ケンスがない場合、UTF-8と認識できないプログラムも存在する。たとえば、 Microsoft Excel では、 CSVファイルを開くとき、このシ?ケンスが付加されていないUTF-8の場合は正常に?み?むことができず文字化けを生ずる ^[15]。 Microsoft Visual C++ は?定でBOMなしUTF-8を認識せず、システムロケ?ル設定に?じたマルチバイトエンコ?ディングとみなすが、Visual C++ 2015以降ではコンパイルオプションを指定することでBOMなしUTF-8を認識することができるようになった ^[16]。 Windows 10 のメモ帳アプリは、 2019年の 19H1アップデ?トからBOM無しUTF-8がデフォルトになった ^[17]。

また、BOMがなくともエンコ?ド自動推定によってUTF-8とShift_JISなどを?別することのできるプログラムもあるが、ASCII部以外の文字が少ない場合に誤認することが多い。

プロトコルが常にUTF-8であることを?制しているものである場合はこのシ?ケンスを禁止するべきで、この場合ファイル先頭にこのシ?ケンスが現れると “ZERO WIDTH NO-BREAK SPACE” と見なされる。逆にプロトコルがそれを保?しない場合このシ?ケンスは禁止されずファイル先頭のそれはバイト順マ?クと見なされる ^[18]。

脚注 [ 編集 ]

[ 脚注の使い方 ]

^ RFC 3629 UTF-8, a transformation format of ISO 10646
^ RFC 3629 Page-3
^ Rob Pike's UTF-8 history
^ ISO/IEC 10646:2003 Information technology -- Universal Multiple-Octet Coded Character Set (UCS)
^ RFC 2279 UTF-8, a transformation format of ISO 10646
^ The Unicode Standard, Version 5.2
^ RFC 3629 UTF-8, a transformation format of ISO 10646
^ ただし、バイト順マ?ク (BOM) が付加されている場合や、テキストを7ビットで?理するソフトウェア、?部的に最上位ビットを使用しているソフトウェアなど、使えないものも存在する
^ RFC 3629 , pp.9f.
^ “ 10.1.10.6 The utf8mb4 Character Set (4-Byte UTF-8 Unicode Encoding) ”. dev.mysql.com . MySQL 5.5 Reference Manual . Oracle. 2015年12月1日02:10:55時点のオリジナルよりア?カイブ。 2015年12月11日 ??。
^ Windowsにおける有名なワ?ムである Nimdaウイルスは、 IIS におけるUTF-8の脆弱性をもちいたものである。( はせがわようすけ 2009 )
^ Mark Davis. “ Forms of Unicode ” (英語). IBM . 2005年5月6日時点のオリジナルよりア?カイブ。 2013年9月18日 ??。
^ このため、UTF-8という呼び名を使っていれば情報交換の相手が文書先頭にこのシ?ケンスがあると見なすと期待すべきではないし、また、UTF-8Nという呼び名は情報交換の際に用いるべきではない。
^ TeraPad 、 EmEditor 、 MIFES のようにBOMを付加するかどうかを選?できるものもある。
^ マイクロソフト?サポ?ト https://support.microsoft.com/en-us/office/opening-csv-utf-8-files-correctly-in-excel-8a935af5-3416-4edd-ba7e-3dfd2bc4a032
^ /source-charset (Set Source Character Set) | Microsoft Docs
^ “ 「メモ帳」に多?の改善、BOMなしUTF-8がデフォルト保存形式に～「Windows 10 19H1」 ”. Impress. 2023年1月26日 ??。
^ RFC 3629 6. Byte order mark (BOM)

?考資料 [ 編集 ]

用語の日本語表記は原則として「 “ Unicode Terminology English - Japanese ”. Unicode, Inc. 2010年1月1日 ??。」にならった。
はせがわようすけ (2009年5月8日). “ 本?は怖い文字コ?ドの話: 第4回 UTF-8の冗長なエンコ?ド ”. 技術評論社. 2014年9月10日 ??。

?連項目 [ 編集 ]

文字コ?ド

[1] RFC 3629 UTF-8, a transformation format of ISO 10646

[2] RFC 3629 Page-3

[3] Rob Pike's UTF-8 history

[4] ISO/IEC 10646:2003 Information technology -- Universal Multiple-Octet Coded Character Set (UCS)

[5] RFC 2279 UTF-8, a transformation format of ISO 10646

[6] The Unicode Standard, Version 5.2

[7] RFC 3629 UTF-8, a transformation format of ISO 10646

[8] ただし、バイト順マ?ク (BOM) が付加されている場合や、テキストを7ビットで?理するソフトウェア、?部的に最上位ビットを使用しているソフトウェアなど、使えないものも存在する

[9] RFC 3629 , pp.9f.

[10] “ 10.1.10.6 The utf8mb4 Character Set (4-Byte UTF-8 Unicode Encoding) ”. dev.mysql.com . MySQL 5.5 Reference Manual . Oracle. 2015年12月1日02:10:55時点のオリジナルよりア?カイブ。 2015年12月11日 ??。

[11] Windowsにおける有名なワ?ムである Nimdaウイルスは、 IIS におけるUTF-8の脆弱性をもちいたものである。( はせがわようすけ 2009 )

[12] Mark Davis. “ Forms of Unicode ” (英語). IBM . 2005年5月6日時点のオリジナルよりア?カイブ。 2013年9月18日 ??。

[13] このため、UTF-8という呼び名を使っていれば情報交換の相手が文書先頭にこのシ?ケンスがあると見なすと期待すべきではないし、また、UTF-8Nという呼び名は情報交換の際に用いるべきではない。

[14] TeraPad 、 EmEditor 、 MIFES のようにBOMを付加するかどうかを選?できるものもある。

[15] マイクロソフト?サポ?ト https://support.microsoft.com/en-us/office/opening-csv-utf-8-files-correctly-in-excel-8a935af5-3416-4edd-ba7e-3dfd2bc4a032

[16] /source-charset (Set Source Character Set) | Microsoft Docs

[17] “ 「メモ帳」に多?の改善、BOMなしUTF-8がデフォルト保存形式に～「Windows 10 19H1」 ”. Impress. 2023年1月26日 ??。

[18] RFC 3629 6. Byte order mark (BOM)

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

表話編 ? ロブ?パイク
オペレ?ティングシステム	Plan 9 from Bell Labs Inferno
プログラミング言語	Newsqueak （英語版） Limbo Go Sawzall （英語版）
ソフトウェア	Acme Blit Sam （英語版） rio （英語版） 8 1/2 （英語版）
書籍	プログラミング作法（英語版） UNIXプログラミング環境（英語版）
その他	ルネ?フレンチ（英語版） Mark V. Shaney （英語版） UTF-8

表話編 ? ケン?トンプソン
オペレ?ティングシステム	UNIX Plan 9 from Bell Labs
プログラミング言語	B言語 Bon Go
ソフトウェア	Belle （英語版） ed grep Sam （英語版） Space Travel （英語版） Thompson Shell
その他	UTF-8