UTF-8は、データ交換方式・ファイル形式として一般的に使われる傾向にある。9で用いるエンコードとして、ロブ・パイクによる設計指針のもと、ケン・トンプソンによって考案された[2][3]。関連項目エンコード体系編集ASCII文字と互換性を持たせるために、ASCIIと同じ部分は1バイト、その他の部分を2-6バイトで符号化する。まで表現することができるが、Unicodeの範囲外となる17面以降を表すもの(U+10FFFFより大きなもの)は受け付けない。10646による定義[4]とIETFによるかつての定義[5]で、Unicodeの範囲外を符号化するためにのみ使用するが、Unicodeによる定義[6]とIETFによる最新の定義[7]では、5-6バイトの表現は不正なシーケンスである。後述のセキュリティの項に詳細はあるが、符号化は最少のバイト数で表現しなければならない。そのため、バイト数ごとにUnicodeの符号位置の最小値(下限)も設けている。1バイトで表現するASCII文字は2バイト以上でも表現できるが、バイト数ごとの下限によってこれを回避している。ビットパターンは以下のようになっている。yに右詰めに格納する(最少のバイト数で表現するため、yの部分には最低1回は1が出現する)。符号化されたバイト列は、バイト順に関わらず左から順に出力する。1つ付く)の個数で、その文字のバイト数がわかるようになっている。始まり、1バイト目と2バイト目以降では値の範囲が重ならないので、文字境界を確実に判定できる。4バイト文字の先頭バイトであると判定できる。7バイト以上の文字は規定されないため、0xFE、0xFFは使用されない。0xFEと0xFFを使用するUTF-16やUTF-32が、UTF-8と混同されることはない。特徴編集メリット編集バイトストリーム中の任意の位置から、その文字、前の文字、あるいは次の文字の先頭バイトを容易に判定することができる。文字列の検索を単なるバイト列の検索として行っても、文字境界と異なる個所でマッチしてしまうことがない。マッチしたりするのと同様のことが起きない。8859-1などの8bit文字向けに作られた膨大なプログラム資産を、比較的少ない修正で再利用できる。他のUnicodeの符号化と同様に、単にバイト列の比較では文字列が同一か判断できない場合がある。詳細は、Unicodeの等価性及び正規化を参照のこと。UTF-16やUTF-32と異なり、バイト単位の入出力を行うため、バイト順の影響がない。21bitまで表現できるため、サロゲートペアを使用する必要がない。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倍かそれ以上のサイズとなる。8859シリーズに属する文字符号ではデータ量がさらに増大しうる。1バイトが9ビットである処理系では、この問題をあまり発生させずに符号化できるはずである。して2005年のエイプリルフール(4月1日)に公開された。文字数とデータサイズが比例しないため、文字数を調べるには先頭から全データを読み取る必要がある。U+309Aでも表現できる)、Unicodeを採用する場合、文字列の文字数をその文字列のバイト数から計算できないことは、UTF-8に限ったことではない。最短ではない符号やサロゲートペアなど、UTF-8の規格外だがチェックを行わないプログラムでは一見正常に扱われるバイト列が存在する。これらのバイト列を入力として受け入れてしまうと、プログラムが予期しない範囲のデータを生成するため、セキュリティ上の脅威となりうる[8]。符号位置にデコードしてから変換する。そのままUTF-8で符号化したような列は不正なUTF-8とされる。して別途定義されている。Databaseのバージョン8以前において、UTF-8として3オクテットまでのオクテット列しか扱えなかったために定義されたものである。Databaseでも、CESU-8を「UTF8」として、「普通のUTF-8」を「AL32UTF8」として扱っているため注意を要する。5.5.3以降でないと使用できない[9])。UTF-8も、サロゲートペアをそのまま残す仕様となっている。80とエンコードする(これもUTF-8規格外)点で、CESU-8とも異なる実装となっている。いう2バイトもしくはそれより大きなバイト数で表現する)。そのような表現も許容されていたが、ディレクトリトラバーサルなどの対策として行われる文字列検査を冗長な表現によりすり抜ける手法が知られるようになったため、現在の仕様では最少のバイト数による表現以外は不正なUTF-8シーケンスとみなさなければならない[10]。10646の定義が5バイト以上の表現を許容していることにより、正しくない実装を行ったバグのあるシステムにおいてエンコード時にバッファオーバーフローが発生する可能性も指摘されている。