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

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

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

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

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

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

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

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

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

* 第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と混同されることはない。

• ASCII文字コードのテキストを処理するソフトウェアの多くがそのまま使える^[8]。
• バイトストリーム中の任意の位置から、その文字、前の文字、あるいは次の文字の先頭バイトを容易に判定することができる。
• 文字列の検索を単なるバイト列の検索として行っても、文字境界と異なる個所でマッチしてしまうことがない。たとえばShift_JISで「¥」(0x5C) を検索すると「表」(0x95 0x5C) の2バイト目にマッチしたり、EUC-JPで「海」(0xB3 0xA4) を検索すると「ここ」(0xA4 0xB3 0xA4 0xB3) にマッチしたりするのと同様のことが起きない。このため、マルチバイト文字を意識せず、ISO 8859-1などの8ビット文字向けに作られた膨大なプログラム資産を、比較的少ない修正で再利用できる。
  • ただし、他のUnicodeの符号化と同様に、単にバイト列の比較では文字列が同一か判断できない場合がある。詳細は、Unicodeの等価性および正規化を参照のこと。
• UTF-16やUTF-32と異なり、バイト単位の入出力を行うため、バイト順の影響がない。
• 21ビットまで表現できるため、サロゲートペアを使用する必要がない。
• ASCII文字が主体の文書であれば、ほとんどデータサイズを増やさずにUnicodeのメリットを享受できる。UTF-16やUTF-32では、データサイズはほぼ2倍、4倍となる。
• 複数のUTF-8文字列を、単なる符号なし8ビット整数の配列とみなして辞書順ソートした結果は、Unicodeの符号位置の辞書順のソート結果（すなわちUTF-32に変換した後にソートした結果）と等しくなる。これに対して、サロゲートペアを含むUTF-16文字列を符号なし16ビット整数の配列とみなしてソートした結果は、Unicodeの符号位置の辞書順のソート結果と異なりうる。

• UTF-8による符号化では、漢字や仮名などの表現に3バイトを要する。このように、東アジアの従来文字コードではマルチバイト符号を用いて1文字2バイトで表現されていたデータが、1.5倍かそれ以上のサイズとなる。同様に、ISO/IEC 8859-1では1バイトで表現できた非ASCIIのラテン文字（ウムラウト付きの文字など）も2バイトとなるし、その他のISO/IEC 8859シリーズに属する文字符号ではデータ量がさらに増大しうる。
  • なお、1バイトが9ビットである処理系では、この問題をあまり発生させずに符号化できるはずである。このアイディアに基づいたジョークRFCがRFC 4042 "UTF-9" として2005年のエイプリルフール（4月1日）に公開された。
• 最短ではない符号やサロゲートペアなど、UTF-8の規格外だがチェックを行わないプログラムでは一見正常に扱われるバイト列が存在する。これらのバイト列を入力として受け入れてしまうと、プログラムが予期しない範囲のデータを生成するため、セキュリティ上の脅威となりうる^[9]。

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以降でないと使用できない^[10]）。

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

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

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

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

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

• この３バイトは、ZERO WIDTH NON-BREAKING SPACE を表すが、データ先頭ではバイト順マークの機能を持たせている。
• なお、日本の特殊事情として、このシーケンスがある方をUTF-8、ない方を特にUTF-8Nと呼び分けることもあるが^[12]、日本以外ではほとんど知られておらず、また公的規格などによる裏付けもない^[13]。

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

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

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

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

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

• 文字コード

表 話 編 歴 文字コード
日本語用の 文字コード	JIS規格 符号化文字集合 JIS X 0201 JIS X 0208 JIS X 0212 JIS X 0213 JIS X 0221（日本文字部分レパートリ） 文字符号化方式 ISO-2022-JP EUC-JP Shift_JIS Shift_JISX0213 Shift_JIS-2004 EUC-JISX0213 EUC-JIS-2004 ISO-2022-JP-3 ISO-2022-JP-2004 漢字シフトコード 文字一覧 JIS X 0213非漢字一覧 JIS X 0213漢字一覧の1面 JIS X 0213漢字一覧の2面 JIS以外の公規格 MJ文字 入管正字 ARIB外字 ARIB外字の追加記号一覧 メーカーの規格 符号化文字集合 IBM拡張文字 マイクロソフト標準キャラクタセット Adobe-Japan1 iモード絵文字 EZweb絵文字 SoftBank絵文字 今昔文字鏡 JIPS EBCDIC GT書体 KEIS IBM漢字システム レコード用文字符号 ビブロス外字 文字符号化方式 Microsoftコードページ932 MacJapanese JEF漢字コード U-PRESS
日本語を含む 多言語文字集合	Unicode ISO/IEC 10646 JIS X 0221 面 基本多言語面 追加面 追加多言語面 追加漢字面 第三漢字面 追加特殊用途面 私用面 文字符号化方式 UTF-8 UTF-16/UCS-2 UTF-32/UCS-4 UTF-7 UTF-EBCDIC GB 18030 SCSU BOCU-1 文字一覧 Unicode一覧 Unicode一覧表 Unicode6.0の携帯電話の絵文字の一覧 UnicodeのEmojiの一覧 TRONコード TRONコード
日本語以外用の 文字集合	初期の文字コード ASCII Baudot Code ISO/IEC 646 ISO/IEC 6937 T.61 ISO/IEC 8859 -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 -11 -13 -14 -15 -16 書誌用 ISO 5426 ISO 5426-2 ISO 5427 ISO 5428 ISO 6438 ISO 6861 ISO 6862 ISO 9036 ISO 10585 ISO 10586 ISO 10754 ISO 11822 ANSEL MARC-8 国家標準 ArmSCII CNS 11643 GOST 10859 GB 2312 HKSCS ISCII KPS 9566 KS X 1001 PASCII TIS-620 TSCII VISCII YUSCII KOI8-R KOI8-RU KOI8-U KOI8-T KOI8-CS EUC EUC-CN EUC-KR EUC-TW ISO/IEC 2022 ISO/IEC 2022 CN ISO/IEC 2022 KR CCCII MacOS コードページ Macintosh Standard Roman Character Set アラビア語 CentralEurRoman EUC-CN Big5 クロアチア語 キリル デーヴァナーガリー Dingbats ペルシャ語 ギリシア語 グジャラート語 グルムキー ヘブライ語 アイスランド語 EUC-KR ルーマニア語 MacSymbol TIS-620 トルコ語 ウクライナ語 DOS コードページ 437 720 737 775 850 852 855 857 858 860 861 862 863 864 865 866 869 KOI8 Kamenicky Mazovia MIK Iran System Windows コードページ 874 (TIS-620) 936 (GBK) 949 (EUC-KR) 950 (Big5) 1250 1251 1252 1253 1254 1255 1256 1257 1258 1361 54936 (GB18030) EBCDIC コードページ 37 293（英語版） 300（英語版） 310（英語版） 351（英語版） 353（英語版） 355（英語版） 357（英語版） 358（英語版） 359（英語版） 360（英語版） 819 930（英語版） 933（英語版） 939（英語版） 1364（英語版） 1390（英語版） 1399（英語版） 8859（英語版） その他標準 モザイク集合 記号用 Symbol Wingdings Webdings プラットフォーム 固有 ATASCII CDC display code DEC Radix-50 Fieldata GSM 03.38 HP roman8 PETSCII TI calculator character sets ZX Spectrum character set
ソフトウェア	文字コード表 (Windows) 文字パレット KCharSelect IMEパッド
区分け	外字 図形文字 制御文字 特殊文字 C0 and C1 control codes CJK統合漢字 ワイド文字 マルチバイト文字 機種依存文字
概念	コードページ 群 面 区 点 文字コード表
関連トピック	CCSID charset detection ISO 6429/IEC 6429/ANSI X3.64 legacy encoding 文字化け モールス符号 6ビット文字コード 携帯電話の絵文字 機械彫刻用標準書体 サロゲートペア 異体字セレクタ フォント
カテゴリ