UTF-8 - 暇つぶしWikipedia

UTF-8

□記事を途中から表示しています
[最初から表示]

デメリット

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の規格外だがチェックを行わないプラグラムでは一見正常に扱われるバイト列が存在する。これらのバイト列を入力として受け入れてしまうと、プログラムが予期しない範囲のデータを生成するため、セキュリティ上の脅威となりうる [5]。

サロゲートペアの扱い

UTF-16のサロゲートペアで表されるBMP外の文字をUTF-8に変換するときは、まずU+10000以降の値にデコードしてから符号化しなければならない。サロゲートペアに使われるU+D800からU+DFFFまでの範囲をUTF-8でそのまま符号化することは禁止されており、不正なシーケンスとみなされる。

サロゲートペアを残したままUTF-8と同等の符号化を行う規格は、CESU-8(Compatibility Encoding Scheme for UTF-16: 8-Bit)として別途定義されている。これは、Oracle Databaseのバージョン8以前において、4バイト以上のUTF-8文字を扱えなかったために便宜的に定義されている。なお、現在のOracle Databaseでは、CESU-8をUTF8として、「普通のUTF-8」をAL32UTF8として扱っているため注意を要する。

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

なお、CESU-8等では、4バイトの文字は使用せず、代わりに前半がED A0 80からED AF BF、後半がED B0 80からED BF BFの6バイトのサロゲートペアで表現される。

セキュリティ

UTF-8のエンコード体系には冗長性があり、同じ文字を符号化するのに複数の表現が考えられる。かつてはそのような表現も許容されていたが、ディレクトリトラバーサルなどの対策として行われる文字列検査を冗長な表現によりすり抜ける手法が知られるようになったため、現在の仕様では最も短いバイト数による表現以外は不正なUTF-8シーケンスとみなさなければならない。

また、ISO/IEC 10646の定義が5バイト以上の表現を許容していることにより、注意深さの足りない実装でエンコード時にバッファオーバーフローが発生する可能性も指摘されている。

日本語の文字とバイト数
1バイト

ASCIIの全て(実装系によりJIS X 0201/Windows-31Jの当該エリアの場合あり)

2バイト

JIS X 0208の非漢字の一部

3バイト

JIS X 0201の8ビット文字(半角カタカナ)

JIS X 0208の漢字エリアの全て

JIS X 0212の漢字エリアの全て

JIS X 0213の第3・4水準漢字の一部

Windows-31Jの拡張文字エリア全て

4バイト

UnicodeのBMP以外全て

JIS X 0213の第3・4水準漢字の一部

5?6バイト

Unicodeの範囲外(どんな文字が登録されるかという計画も無い)

バイトオーダーマークについて

UTF-8で符号されたテキストデータはエンディアンに関わらず同じ内容になるので、UTF-8で符号化されていることが確定しているのならバイトオーダーマーク (英: Byte Order Mark。以下BOM) を付加する必要はない。しかし、一部のテキスト処理アプリケーション (エディタなど) では、作成したテキストデータの先頭にBOMを付加する (付加するかどうかを選択できるものもある)。付加する場合は、EF BB BF (16進。U+FEFFのUTF-8での表現) をデータの先頭に付加する。なお、BOMありの方をUTF-8、なしの方をUTF-8Nと呼ぶこともあるが、このような呼び分けは日本以外ではほとんど知られておらず、また公的規格などによる裏付けもない。このため、UTF-8という呼び名を使っていれば情報交換の相手が文書先頭にBOMがあると見なすと期待すべきではないし、いっぽう、UTF-8Nという呼び名は情報交換の際に用いるべきではない。

BOMを付加する目的は、その文書がUTF-8であることを確実に認識できるようにするためだと考えられる。一方で、UTF-8のBOMを認識しない（単に8ビットスルーであるというだけの、正式にはUTF-8に対応していない）プログラムでは、BOMが余分なデータとみなされて問題となる場合もある。例えば、UNIX系OSにおける実行可能スクリプトは、ファイル先頭が「#!」から始まるとき、それに続く文字列をインタプリタのコマンドとして認識するが、現状の多くのシステムでは、BOMが存在するとこの機能が働かず実行できない。ただし、これはテキストエディタで編集可能とはいえ、あくまでも実行可能な“バイナリ形式”での事例であり、テキストファイルにおけるBOMの取り扱いとは別の問題である。

逆にBOMがないとUTF-8と認識できないプログラムも存在する (とくにASCII部以外の文字が少ない場合に誤認することが多い)。

プロトコルが常にUTF-8である事を強制しているものである場合はBOMを禁止するべきで、この場合ファイル先頭のBOMは "ZERO WIDTH NO-BREAK SPACE" と見なされる。逆にプロトコルがそれを保証しない場合BOMは禁止されずファイル先頭のそれはBOMと見なされる [6]。