UTF-8
読み：ユーティーエフ-エイト
外語：UTF-8: Unicode Transformation Format-8

　ISO/IEC 10646およびUnicode文字を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文字が表現可能となる。
　従来の英語圏環境の文字コードと互換性が保たれ、プログラミング面でも扱いが容易であるため、従来は英語専用だったソフトウェアを新規に多国語対応化する場合などには有用である。
技術
BOM
　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まで)。
UCS-4 (16進)UTF-8 (2進)
00000000〜0000007F0xxxxxxx
00000080〜000007FF110xxxxx 10xxxxxx
00000800〜0000FFFF1110xxxx 10xxxxxx 10xxxxxx
00010000〜001FFFFF11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
00200000〜03FFFFFF111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
04000000〜7FFFFFFF1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
　UTF-8は、文字が次の範囲に限定されるため、途中の1文字を読むだけで、それが1文字目か2文字目以降かが識別可能である。
　また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では、次のような例が紹介されている。
再検索