UTF-8

Unicodeを1〜4オクテットに、または、ISO/IEC 10646を1〜6オクテットの不定長に変換する。

前者はRFC 3629で標準化されており、後者はこのRFCによって破棄された古いRFCであるRFC 2279にて仕様が規定されている。

このように、RFC 2279では1〜6オクテットまでの規定があったが、RFC 3629ではUnicode文字(U+0000〜U+10FFFF)だけの対応となり、1〜4オクテットの範囲だけしか規定されなくなった。

Javaでは実行ファイル(Javaバイトコードと呼ばれる)内部で実際に用いられている文字コードの符号化方法であり、Java以外でもInternet ExplorerやMicrosoft Wordなどで広く対応している。

ASCIIと互換性があり、かつ世界中の言語を容易に扱えるということで徐々に人気が高まった。

この方法を用いるとASCII文字の範囲(0x00〜0x7f)を保存したまま、8ビット長でUnicode文字が表現可能となる。

従来の英語圏環境の文字コードと互換性が保たれ、プログラミング面でも扱いが容易であるため、従来は英語専用だったソフトウェアを新規に多国語対応化する場合などには有用である。

UTF-16などでは、符号のバイト順が自在のため、バイト順を機械的に識別可能なように文書の先頭にはBOMと呼ばれる記号(U+FEFF, ZWNBSP)を付ける。

UTF-8の場合はバイト順序は常に固定で変化することはないので、このような目印は本来は不要であるが、その文書がUTF-8であるかどうかを識別するために同様に使われることが多い。

U+FEFF(ZWNBSP)は、UTF-8では「0xEF 0xBB 0xBF」という3オクテットになり、これが先頭にあればそれはUTF-8であると判断できる。

日本のローカルな俗称として、このZWNBSPが先頭に無いUTF-8をUTF-8Nと呼ぶ。

古いRFC 2279で表現できる全範囲を以下に示す。新しいRFC 3629では、このうち最初の4つ、001FFFFFまでの範囲に対応する(より正確には、U+0000からU+10FFFFまで)。

UTF-8は、文字が次の範囲に限定されるため、途中の1文字を読むだけで、それが1文字目か2文字目以降かが識別可能である。

• 1文字目: 0x00〜0x7F,0xC0〜0xFD
• 2文字目以降: 0x80〜0xBF

また0xFEと0xFFは予約されており、現時点では使用してはならない。

なお、UTF-16の範囲内に限定されているRFC 3629の仕様では、0xC0、0xC1、0xF5〜FFまでは使用されない。

UTF-8は、同じ番号を、複数の方法(長さ)で表現できる、という仕様上の問題がある。

例えば空白(U+0020)なら、UTF-8は次のいずれかで符号化できる。

1. 0x20
2. 0xc0 0xa0
3. 0xe0 0x80 0xa0
4. 0xf0 0x80 0x80 0xa0
5. 0xf8 0x80 0x80 0x80 0xa0
6. 0xfc 0x80 0x80 0x80 0x80 0xa0

このため、これらの文字の処理を適切に行なわないと、Unicode Directory Traversalというセキュリティホールを産む。

ちなみにRFC 3629では、次のような例が紹介されている。

• 0041:2262:0391:002E(A≢Α.) → 41 E2 89 A2 CE 91 2E
• D55C:AD6D:C5B4(한국어) → ED 95 9C EA B5 AD EC 96 B4
• 65E5:672C:8A9E(日本語) → E6 97 A5 E6 9C AC E8 AA 9E
• 233B4(𣎴) → F0 A3 8E B4