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にも仕様がある。

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

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

当初は、ベル研究所においてPlan 9で用いるエンコードとして、ロブ・パイクによる設計指針のもと、ケン・トンプソンが考案した。

エンコード体系

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

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

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

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

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

バイト数 有効ビット Unicode 2進数表記 16進数表記
1 7 bit 0xxx-xxxx 00..7F
下限 U+0000 0000-0000 00
上限 U+007F 0111-1111 7F
2 11 bit 110y-yyyx 10xx-xxxx C2..DF 80..BF
下限 U+0080 1100-0010 1000-0000 C2 80
上限 U+07FF 1101-1111 1011-1111 DF BF
3 16 bit 1110-yyyy 10yx-xxxx 10xx-xxxx E0..EF 80..BF 80..BF
下限 U+0800 1110-0000 1010-0000 1000-0000 E0  80* 80
上限 U+FFFF 1110-1111 1011-1111 1011-1111 EF  BF* BF
4 21 bit 1111-0yyy 10yy-xxxx 10xx-xxxx 10xx-xxxx F0..F4 80..BF 80..BF 80..BF
下限 U+10000 1111-0000 1001-0000 1000-0000 1000-0000 F0  80* 80 80
上限 U+10FFFF 1111-0100 1000-1111 1011-1111 1011-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と混同されることはない。

特徴

利点

欠点

サロゲートペアの扱い

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 以降でないと使用できない。

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

セキュリティ

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

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

文字種

BUnicodeスクリプトJIS X 0201JIS X 0208JIS X 0212JIS X 0213
1U+0000–U+007FASCIIRoman（円記号・オーバーライン以外）   
2U+0080–U+07FF 円記号非漢字の一部非漢字の一部非漢字の一部
3U+0800–U+FFFF オーバーライン、Kana残りの全て残りの全て大半
4U+10000–U+10FFFF古代文字、3に含まれない漢字   第3・第4水準漢字の一部

バイト順マークの使用

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

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

プログラム・アプリケションソフトの対応状況の問題

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

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

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

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

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

Microsoft WindowsのUTF-8対応

→「en:Unicode in Microsoft Windows」も参照

Windows 11 25H2 現在、標準ストリーム（標準入出力）のエンコーディングはレガシーエンコーディングを継続している。日本語の場合はMicrosoftコードページ932を使用している。Windows 10 Version 1803 以降はこれを UTF-8 に変えることができる。Windows 11 25H2 では、設定の 時刻と言語 > 言語と地域 > Windows の表示言語 > ベータ版: 世界中の言語に対応するために Unicode UTF-8 を使用します をオンにすると UTF-8 に変わる。Windows 以外の OS は UTF-8 が基本となっていて、標準入出力を使用するマルチOS対応のアプリで、UTF-8 でないと文字化けするアプリがこれにより正常に動作するようになる。

脚注

[脚注の使い方]

注釈

  1. ↑ ただし、バイト順マーク (BOM) が付加されている場合や、テキストを7ビットで処理するソフトウェア、内部的に最上位ビットを使用しているソフトウェアなど、使えないものも存在する。
  2. ↑ このため、UTF-8という呼び名を使っていれば情報交換の相手が文書先頭にこのシーケンスがあると見なすと期待すべきではないし、UTF-8Nの呼称は情報交換の際に用いるべきではない。[独自研究?]
  3. ↑ TeraPad、EmEditor、MIFESのようにBOMを付加するかどうかを選択できるものもある。

出典

  1. ↑ 文字数カウントス. “文字数とバイト数の違い｜UTF-8・Shift_JIS のカウント方法”. 文字数カウントス. 2026年3月27日閲覧。
  2. ↑ RFC 3629 UTF-8, a transformation format of ISO 10646
  3. ↑ RFC 3629 Page-3
  4. ↑ Rob Pike's UTF-8 history
  5. ↑ ISO/IEC 10646:2003 Information technology -- Universal Multiple-Octet Coded Character Set (UCS)
  6. ↑ RFC 2279 UTF-8, a transformation format of ISO 10646
  7. ↑ The Unicode Standard, Version 5.2
  8. ↑ RFC 3629 UTF-8, a transformation format of ISO 10646
  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-01T02:10:55時点のオリジナルよりアーカイブ。2015年12月11日閲覧。
  11. ↑ “Corrigendum #1: UTF-8 Shortest Form” (英語). ユニコードコンソーシアム (2000年11月9日). 2024年9月16日閲覧。
  12. ↑ “MSC10-C. 文字の符号化 - UTF8 に関連する問題”. JPCERT/CC (2014年4月16日). 2024年9月16日閲覧。
  13. ↑ Windowsにおける有名なワームであるNimdaウイルスは、IISにおけるUTF-8の脆弱性をもちいたものである。(はせがわようすけ 2009)
  14. ↑ Mark Davis. “Forms of Unicode” (英語). IBM. 2005年5月6日時点のオリジナルよりアーカイブ。2013年9月18日閲覧。
  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)
  19. ↑ “Windows 10ミニTips(444) 「ワールドワイド言語サポートでUnicode UTF-8を使用」は有効にすべき？”. マイナビニュース. 2025年12月17日閲覧。

参考資料

関連項目