前のページ 1/2 次のページ

UTF-8(旧UTF-2)はISO/IEC 10646(UCS)とUnicodeで使える8ビット符号単位の文字符号化形式及び文字符号化スキーム。

正式名称は、ISO/IEC 10646では'UCS Transformation Format 8'、Unicodeでは'Unicode Transformation Format-8'という。

両者はISO/IEC 10646とUnicodeのコード重複範囲で互換性がある。

2バイト目以降に'/'などのコードが現れないように工夫されていることから、'UTF-FSS'(File System Safe)ともいわれる。

RFCにも仕様がある。

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

LinuxやMac OS Xのように、OSの標準文字エンコードとして使用される例も増えている。

当初は、ベル研究所において Plan 9で用いるエンコードとして、ロブ・パイクによる設計指針のもと、ケン・トンプソンによって考案された[外部リンク] RFC 3629 Page-3。

◆エンコード体系

ASCII文字と互換性を持たせるために、ASCIIと同じ部分は1バイト、その他の部分を2〜6バイトで符号化する。4バイトのシーケンスでは21bit(0x1FFFFF)まで表現することができるが、Unicodeの範囲外となる17面以降を表すもの(U+10FFFFより大きなもの)は受け付けない。また5〜6バイトの表現は、ISO/IEC 10646による定義[外部リンク] ISO/IEC 10646:2003 Information technology -- Universal Multiple-Octet Coded Character Set (UCS)とIETFによるかつての定義RFC 2279 UTF-8, a transformation format of ISO 10646で、Unicodeの範囲外を符号化するためにのみ使用するが、Unicodeによる定義[外部リンク] The Unicode Standard, Version 5.0とIETFによる最新の定義RFC 3629 UTF-8, a transformation format of ISO 10646では、5〜6バイトの表現は不正なシーケンスである。

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

0xxxxxxx (00-7f) 7bit

110yyyyx 10xxxxxx (c0-df)(80-bf) 11bit

1110yyyy 10yxxxxx 10xxxxxx (e0-ef)(80-bf)(80-bf) 16bit

11110yyy 10yyxxxx 10xxxxxx 10xxxxxx (f0-f7)(80-bf)(80-bf)(80-bf) 21bit

111110yy 10yyyxxx 10xxxxxx 10xxxxxx 10xxxxxx (f8-fb)(80-bf)(80-bf)(80-bf)(80-bf) 26bit

1111110y 10yyyyxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx (fc-fd)(80-bf)(80-bf)(80-bf)(80-bf)(80-bf) 31bit

Unicodeの符号位置を2進表記したものを、上のビットパターンのx, yに右詰めに格納する。

最短のバイト数で符号化するため、yの部分には最低1回は1が出現する。

符号化されたバイト列は、バイト順に関わらず左から順に出力する。

これにより4バイトで21bit、6バイトで31bitまで表現することができる。

1バイト目の上位ビットの1の個数でその文字のバイト数が判るようになっている。また、2バイト目以降は10で始まり、1バイト目と2バイト目以降では値の範囲が重ならないので、文字境界を確実に判定できる。

7バイト以上の文字は規定されないため、fe, ffは使用されない。このため、バイト順マーク[外部リンク] Unicode Terminology English - Japanese, B, Unicode, Inc. (BOM) にfeとffを使用するUTF-16が、UTF-8と混同されることはない。

◆特徴

◇メリット

・バイトストリーム中の任意の位置から、その文字、前の文字、あるいは次の文字の先頭バイトを容易に判定することができる。

・文字列の検索を単なるバイト列の検索として行っても、文字境界と異なる個所でマッチしてしまうことがない。たとえばShift_JISで「?」を検索すると「表」の2バイト目にマッチしたり、EUC-JPで「海」を検索すると「ここ」にマッチしたりするのと同様のことが起きない。このため、マルチバイト文字を意識せず、ISO 8859-1などの8bit文字向けに作られた膨大なプログラム資産を、比較的少ない修正で再利用できる。

  ・但し、他のUnicodeの符号化と同様に、単にバイト列の比較では文字列が同一か判断できない場合がある。詳細は、Unicodeの等価性及び正規化を参照のこと。

・UTF-16やUTF-32と異なり、バイト単位の入出力を行うため、バイト順の影響が無い。

・31bitまで表現できるため、サロゲートペアを使用する必要がない。

・ASCII文字が主体の文書であれば、ほとんどデータサイズを増やさずにUnicodeのメリットを享受できる。UTF-16やUTF-32では、データサイズはほぼ2倍、4倍となる。

・複数のUTF-8文字列を、単なる符号無し8bit整数の配列とみなして辞書順ソートした結果は、Unicodeの符号位置の辞書順のソート結果(すなわちUTF-32に変換した後にソートした結果)と等しくなる。

◇デメリット

・UTF-8による符号化では、漢字や仮名などの表現に3バイトを要する。このように、東アジアの従来文字コードではマルチバイト符号を用いて1文字2バイトで表現されていたデータが、1.5倍かそれ以上のサイズとなる。同様に、ISO/IEC 8859-1では1バイトで表現できた非ASCIIのラテン文字 (ウムラウト付きの文字など) も2バイトとなるし、その他のISO/IEC 8859シリーズに属する文字符号ではデータ量がさらに増大しうる。

  ・ なお、1バイトが9ビットである処理系では、この問題をあまり発生させずに符号化できるはずである。このアイディアに基づいたジョークRFCがRFC4042 “UTF-9” として2005年4月1日に公開された。

・文字数とデータサイズが比例しないため、文字数を調べるには先頭から全データを読み取る必要がある。

・最短ではない符号やサロゲートペアなど、UTF-8の規格外だがチェックを行わないプログラムでは一見正常に扱われるバイト列が存在する。これらのバイト列を入力として受け入れてしまうと、プログラムが予期しない範囲のデータを生成するため、セキュリティ上の脅威となりうるRFC 3629, pp.9f.。

◆サロゲートペアの扱い

UTF-16のサロゲートペア(代用対)で表されるBMP外の文字をUTF-8に変換するときは、まず4バイトのサロゲートペア(代用対)(上位代用符号単位[外部リンク] Unicode Terminology English - Japanese, H, Unicode, Inc. 0xD800〜0xDBFF, 下位代用符号単位[外部リンク] Unicode Terminology English - Japanese, L, Unicode, Inc. 0xDC00〜0xDFFF)をU+10000からU+10FFFFまでの符号位置にデコードしてからUTF-8に符号化しなければならない。サロゲートペア(代用対)に使われるU+D800からU+DFFFまでの符号位置を、UTF-8でそのまま符号化することは禁止されており、不正なシーケンスとみなされる。

サロゲートペア(代用対)を残したままUTF-8と同等の符号化を行う規格は、CESU-8(Compatibility Encoding Scheme for UTF-16: 8-Bit)として別途定義されている。

これは、Oracle Databaseのバージョン8以前において、UTF-8文字は3バイトまでしか扱えなかったために便宜的に定義されている。4バイトのサロゲートペア(代用対)は使用せず、代わりに6バイトのサロゲートペア(代用対)(上位代用符号単位がED A0 80〜ED AF BF、下位代用符号単位が ED B0 80〜ED BF BF)で表現される。

なお、現在のOracle Databaseでは、CESU-8を「UTF8」として、「普通のUTF-8」を「AL32UTF8」として扱っているため注意を要する。

また、Javaの一部の内部実装で用いられているModified UTF-8も、サロゲートペアをそのまま残す仕様となっている。

但し、NULL文字をC0 80とエンコードする(これもUTF-8規格外)点で、CESU-8とも異なる実装となっている。

◆セキュリティ

前のページ 1/2 次のページ

・UTF-8 page1

・UTF-8 page2