UTF-8

UTF-8は電子通信に使用される文字エンコード規格です。Unicode標準によって定義され、その名前はUnicode Transformation Format – 8-bitに由来しています。^[1]ほぼすべてのWebページはUTF-8で保存されています。

UTF-8 は、1 から 4 の 1バイト(8 ビット) コード単位の可変幅エンコードを使用して、1,112,064 ^{[2] の}有効な Unicode スカラー値すべてをエンコードできます。より頻繁に出現する傾向にある数値の低いコード ポイントは、より少ないバイトを使用してエンコードされます。これはASCIIとの下位互換性のために設計されました。ASCII と 1 対 1 に対応する Unicode の最初の 128 文字は、ASCII と同じバイナリ値を持つ 1 バイトを使用してエンコードされるため、それらの文字のみを使用して UTF-8 でエンコードされたファイルは ASCII ファイルと同一になります。拡張 ASCII用に設計されたほとんどのソフトウェアはUTF-8 を読み書きでき ( Microsoft Windowsを含む)、これにより、他のテキスト エンコードよりも国際化の問題が少なくなります。^{[3] [4]}

UTF-8 はインターネット上のすべての国/言語で主流であり、ほとんどの標準で使用され、許可されている唯一のエンコードであることが多く、すべての最新のオペレーティング システムとプログラミング言語でサポートされています。

国際標準化機構(ISO) は、1989 年にユニバーサルなマルチバイト文字セットの作成に着手しました。ISO 10646 標準の草案には、32 ビットコード ポイントのバイト ストリーム エンコーディングを提供するUTF-1と呼ばれる必須ではない付録が含まれていました。このエンコーディングは、他の問題の中でもパフォーマンスの点で満足のいくものではありませんでした。最大の問題は、ASCII と非 ASCII が明確に区別されていないことでした。新しい UTF-1 ツールは ASCII でエンコードされたテキストと下位互換性がありますが、UTF-1 でエンコードされたテキストには、ASCII では別の意味を持つ 0x21～0x7E の範囲の継続バイト (たとえば、Unix のパスディレクトリ区切り文字である の場合は 0x2F) が含まれる可能性があるため、ASCII (または拡張 ASCII ) を想定している既存のコードを混乱させる可能性があります。 /

1992年7月、X/Open委員会のXoJIGは、より優れたエンコード方式を模索していた。Unix System LaboratoriesのDave Prosserは、実装特性がより高速で、7ビットASCII文字はそれ自身のみを表し、マルチバイトシーケンスは上位ビットが設定されたバイトのみを含むという改良を導入したエンコード方式の提案を提出した。File System Safe UCS Transformation Format ( FSS-UTF ) ^[5]という名前と、この提案のほとんどのテキストは、後に最終仕様に残された。^{[6] [7] [8]} 1992年8月、この提案はIBM X/Openの代表者によって関係者に回覧された。ベル研究所のPlan 9オペレーティングシステムグループのKen Thompsonによる修正により、自己同期が可能になり、リーダーはどこからでも開始でき、すぐに文字境界を検出できるようになったが、以前の提案よりもビット効率がいくらか低下した。^{[8] [9]}トンプソンの設計は1992年9月2日、ニュージャージー州のダイナーでロブ・パイクと共にプレースマットの上で概要が説明された。その後数日でパイクとトンプソンはそれを実装し、Plan 9を全面的に使用するように更新し、^[10]その成功をX/Openに報告し、FSS-UTFの仕様として採用された。^[8]

UTF-8は、1993年1月25日から29日までサンディエゴで開催されたUSENIXカンファレンスで初めて公式に発表されました。 ^[11]インターネット技術タスクフォースは、1998年1月に将来のインターネット標準作業のためにRFC 2277（ BCP 18）の文字セットと言語に関するポリシーでUTF-8を採用し、古いRFCのLatin-1などのシングルバイト文字セットを置き換えました。^[12]

2003年11月、UTF-8はUTF-16文字エンコーディング の制約と一致するようにRFC 3629によって制限されました。高サロゲート文字と低サロゲート文字に対応するコードポイントを明示的に禁止すると、3バイトシーケンスの3％以上が削除され、U+10FFFFで終わると4バイトシーケンスの48％以上とすべての5バイトおよび6バイトシーケンスが削除されました。^[13]

UTF-8 は、コード ポイントの値に応じて、コード ポイントを 1 ～ 4 バイトでエンコードします。次の表では、文字u～z は、コード ポイントの位置U+uvwxyzのビットに置き換えられます。

最初の 128 のコード ポイント (ASCII) には 1 バイトが必要です。次の 1,920 のコード ポイントをエンコードするには 2 バイトが必要です。これは、ほぼすべてのラテン文字アルファベットの残りと、IPA 拡張、ギリシャ文字、キリル文字、コプト文字、アルメニア文字、ヘブライ文字、アラビア文字、シリア文字、ターナ文字、N'Ko文字、および結合ダイアクリティカル マークをカバーします。ほとんどの中国語、日本語、韓国語の文字を含む基本多言語面(BMP)の残りの 61,440 のコード ポイントには 3 バイトが必要です。絵文字、あまり一般的ではないCJK 文字、さまざまな歴史的スクリプト、および数学記号を含むUnicode の他の面の 1,048,576 のコード ポイントには4 バイトが必要です。

これはプレフィックス コードであり、コード ポイントをデコードするために最後のバイト以降を読み取る必要はありません。Shift -JISなどの以前の多くのマルチバイト テキスト エンコーディングとは異なり、自己同期型であるため、短い文字列や文字の検索が可能であり、最大 3 バイトをバックアップすることでランダムな位置からコード ポイントの開始を見つけることができます。リード バイトに選択された値は、UTF-8 文字列のリストをソートすると、UTF-32文字列をソートする場合と同じ順序になることを意味します。

上記の表の行を使用して「最初のコードポイント」未満のコードポイントをエンコードする（したがって、必要以上のバイトを使用する）ことを、長すぎるエンコードと呼びます。これらは、同じコードポイントを複数の方法でエンコードできるため、セキュリティ上の問題となります。長すぎるエンコード（たとえば）は、MicrosoftのIIS Webサーバー^[14]やApacheのTomcatサーブレットコンテナ^[15]../などの注目度の高い製品で、セキュリティ検証を回避するために使用されてきました。したがって、長すぎるエンコードはエラーと見なしてデコードしないでください。修正UTF-8では、 U+0000の長すぎるエンコードが許可されています。

以下の表は、UTF-8 でエンコードされたストリーム内の各バイトの詳細な意味を示しています。

すべてのバイトシーケンスが有効な UTF-8 であるわけではありません。UTF-8 デコーダーは次のものに対応する必要があります。

• UTF - 8には決して現れないバイト: 0xC0、0xC1、0xF5 – 0xFF
• 文字の先頭の「継続バイト」（0x80 – 0xBF ）
• 文字の終わりの前の非継続バイト（または文字列の終わり）
• 長すぎるエンコード（0xE0の後に0xA0未満が続く、または0xF0の後に0x90未満が続く）
• U+10FFFFより大きい値にデコードされる 4 バイトのシーケンス( 0xF4の後に0x90以上が続く)

初期の UTF-8 デコーダの多くは、これらをデコードし、不正なビットを無視していました。 慎重に作成された無効な UTF-8 は、NUL、スラッシュ、引用符などの ASCII 文字をスキップまたは作成し、セキュリティ上の脆弱性につながる可能性があります。 エラー時に例外をスローしたり、文字列を切り捨てたりすることも一般的です^{[16]が、これにより、本来は無害なエラー (つまり、「ファイルが見つかりません」) が}サービス拒否に変わります。たとえば、Python 3.0 の初期バージョンでは、コマンドラインまたは環境変数に無効な UTF-8 が含まれているとすぐに終了していました。^[17]

RFC 3629では、「デコードアルゴリズムの実装は、無効なシーケンスのデコードから保護する必要があります。」と述べられています。 ^[18] Unicode標準では、デコーダーに次のことを要求しています。「...不正なコード単位シーケンスをエラー状態として扱います。これにより、不正なコード単位シーケンスを解釈したり出力したりしないことが保証されます。」現在、標準では、各エラーを置換文字「�」（U+FFFD）に置き換えてデコードを続行することを推奨しています。

一部のデコーダーは、 E1,A0,20シーケンス(切り捨てられた 3 バイトのコードとそれに続くスペース) を単一のエラーと見なします。スペース文字を検索すると、エラーに隠れているスペース文字が見つかる可能性があるため、これは良い考えではありません。Unicode 6 (2010 年 10 月) ^[19]以降、標準 (第 3 章) では、エラーが 1 つの継続バイトであるか、または許可されていない最初のバイトで終了するという「ベスト プラクティス」が推奨されています。したがって、E1,A0,20 は2 バイトのエラーで、その後にスペースが続きます。つまり、エラーは 3 バイト以下で、有効な文字の先頭は含まれず、21,952種類のエラーが考えられます。技術的には、これにより UTF-8 はプレフィックス コード ではなくなります(エラーであることがわかるには、エラーの 1 バイト先まで読み取る必要があります)。ただし、検索対象の文字列にエラーが含まれていない場合は、検索は引き続き機能します。

各バイトをエラーにすると、E1、A0、20は2つのエラーの後にスペースが続くことになりますが、それでも有効な文字列を検索することができます。これは、エラーが128種類しかないことを意味し、エラーを出力文字列に格納するか、^[20]レガシーエンコーディングの文字で置き換えることが現実的になります。

バイト文字列のごく一部だけがエラーのない UTF-8 です。つまり、複数のバイトが出現することはなく、上位ビットが設定されたバイトが単独で存在することもできず、完全にランダムな文字列では、上位ビットが設定されたバイトが有効な UTF-8 文字で始まる可能性は1 ⁄ 15しかありません。この結果 (おそらく意図しない結果) として、UTF-8 の代わりにレガシー テキスト エンコーディングが誤って使用されているかどうかを簡単に検出できるようになり、システムを UTF-8 に変換しやすくなり、バイト オーダー マークやその他のメタデータが不要になります。

RFC 3629 (2003年11月) 以降、 UTF-16で使用される上位サロゲートと下位サロゲート( U+D800からU+DFFFまで) は有効な Unicode 値ではなく、UTF-8 エンコードは無効なバイトシーケンスとして扱われる必要があります。^{[18]これらのエンコードはすべて}0xEDで始まり、その後に0xA0以上が続きます。Windows ファイル名ではサロゲートが許可されているため、このルールは無視されることが多く、これはサロゲートを文字列に格納する方法が必要であることを意味します。^[21]これらのサロゲート半分を許可する UTF-8 は (非公式に)WTF-8 [^22]、また、BMP以外の文字をすべて2つのサロゲート（4バイトではなく6バイト）としてエンコードする別のバリ​​エーションはCESU-8と呼ばれます。

Unicodeバイト順序マーク U+FEFF がUTF-8 ファイルの先頭にある場合、最初の 3 バイトは0xEF、0xBB、0xBFになります。

Unicode 標準では、UTF-8 に BOM を使用することを必須でも推奨もしていませんが、別のエンコードからトランスコードされたファイルの先頭で BOM に遭遇する可能性があると警告しています。^[23] UTF-8 を使用してエンコードされた ASCII テキストは ASCII と下位互換性がありますが、Unicode 標準の推奨事項を無視して BOM を追加した場合は互換性がありません。BOM は、BOM に対応していないがそれ以外は UTF-8 を受け入れることができるソフトウェアを混乱させる可能性があります。たとえば、文字列リテラルでは非 ASCII バイトを許可するが、ファイルの先頭では許可しないプログラミング言語などです。それにもかかわらず、UTF-8 を書き込むときに常に BOM を挿入し、最初の文字が BOM でない限り (またはファイルに ASCII のみが含まれている場合)、UTF-8 を正しく解釈しないソフトウェアが以前も現在も存在しています。^[24]

長い間、テキストをUTF-16で処理する方がよいのか、それとも UTF-8 で処理する方がよいのかについてはかなりの議論がありました。

UTF-16 の主な利点は、Windows API ではすべての Unicode 文字にアクセスするために UTF-16 を使用する必要があったことです (最近になってようやくこの問題が修正されました)。このため、 Qtなどのいくつかのライブラリでも UTF-16 文字列が使用されるようになり、この要件が Windows 以外のプラットフォームにも伝播しました。

Unicode の初期の頃は、 U+FFFFより大きい文字はなく、結合文字はほとんど使用されなかったので、16 ビット エンコーディングは固定サイズでした。これにより、テキストの処理はより効率的になりましたが、その利点は初心者のプログラマーが想像するほど大きくはありませんでした。このような利点はすべて、UTF-16 も可変幅になった途端に失われました。

コード ポイントU+0800 – U+FFFF は、UTF-8 では 3 バイトを占めますが、UTF-16 では 2 バイトしか占めません。このため、中国語やその他の言語のテキストは UTF-8 ではより多くのスペースを占めると考えられてきました。ただし、テキストが大きくなるのは、これらのコード ポイントが 1 バイトの ASCII コード ポイントより多い場合のみであり、実際のドキュメントでは、スペース、改行、数字、句読点、英語の単語、および (ドキュメント形式に応じて) マークアップが原因で、このようなことが起こることはほとんどありません。

UTF-8 には、拡張 ASCII を処理できるあらゆるシステムに簡単に後付けできる、バイト順の問題がない、主にラテン文字を使用する言語の場合、スペースを約半分しか占有しないなどの利点があります。

UTF-8は2008年以来、ワールドワイドウェブで最も一般的なエンコーディングとなっています。 ^[26] 2024年11月現在^[update]、調査対象のウェブサイトの98.4%でUTF-8が使用されています。^[27]多くのページではコンテンツの表示にASCII文字のみを使用していますが、エンコーディングがUTF-8ではなくASCIIのみであると宣言しているウェブサイトは現在ごくわずかです。^[28]事実上すべての国と言語で、ウェブ上でUTF-8エンコーディングが95%以上使用されています。

多くの標準ではUTF-8のみがサポートされており、例えばJSON交換ではUTF-8（バイトオーダーマーク（BOM）なし）が必須です。^{[29] UTF-8は}WHATWGのHTMLおよびDOM仕様の推奨事項でもあり、「UTF-8エンコーディングはUnicodeの交換に最も適したエンコーディングである」と述べており^[4]、インターネットメールコンソーシアムはすべての電子メールプログラムがUTF-8を使用してメールを表示および作成できることを推奨しています。^{[30] [31]} World Wide Web Consortiumは、 XMLおよびHTMLのデフォルトのエンコーディングとしてUTF-8を推奨しています（UTF-8を使用するだけでなく、メタデータでも宣言する必要があります）、「すべての文字がASCII範囲内にある場合でも...非UTF-8エンコーディングを使用すると予期しない結果が生じる可能性があります」。^[32]

多くのソフトウェアはUTF-8の読み取り/書き込み機能を備えています。ただし、ユーザーが通常の設定からオプションを変更する必要があったり、ファイルを読み込むための最初の文字としてBOM（バイトオーダーマーク）が必要になる場合があります。UTF-8をサポートするソフトウェアの例としては、Microsoft Word、^{[33] [34] [35]} Microsoft Excel（2016以降）、^{[36] [37]} Google Drive、LibreOffice、およびほとんどのデータベースがあります。

UTF-8を「デフォルト」とするソフトウェア（つまり、ユーザーが設定を変更しなくても書き込み、BOMなしで読み取る）は、2010年以降より一般的になっている。^[38] Windowsメモ帳は、現在サポートされているすべてのバージョンのWindowsで、デフォルトでBOMなしのUTF-8を書き込むように設定されており（Windows 7 メモ帳からの変更点）、他のほとんどのテキストエディタと一致するようになっている。^[39] Windows 11の一部のシステムファイルはBOMを必要とせず、 UTF-8を必要とする^[40]ほか、macOSとLinuxのほぼすべてのファイルはBOMなしのUTF-8であることが求められる。^[要出典] I/OのデフォルトがUTF-8であるプログラミング言語には、 Ruby  3.0、^{[41] [42]} R  4.2.2、^[43] Raku、Java  18などがあります^。[44] Pythonの現在のバージョンでは、open()UTF-8の読み取り/書き込みにオプションが必要ですが、 ^[45] Python 3.15でUTF-8 I/Oをデフォルトにする計画があります。^[46] C++23は、唯一のポータブルソースコードファイル形式としてUTF-8を採用しています（驚くべきことに、以前は存在しませんでした）。^[47]

下位互換性は、UTF-16 を使用しているコードや API をUTF-8 を使用するように変更する上で大きな障害となりますが、これは実際に行われています。2019 年 5 月現在^[update]、Microsoft はアプリケーションが Windows API の「コード ページ」として UTF-8 を設定する機能を追加し、UTF-16 を使用する必要性をなくしました。さらに最近では、プログラマーに UTF-8 の使用を推奨し、 ^[48]「UTF-16 [...] は、複数のプラットフォームを対象とするコードに対して Windows が課す独特の負担です」とさえ述べています。^[3] Go、^[49] Julia、Rust、Swift (バージョン 5 以降)、^[50] PyPy [ ^51] のデフォルトの文字列プリミティブは、すべてのケースで内部的に UTF-8 を使用します。 Python（バージョン3.3以降）はPython C API拡張^{[52] [53]}および場合によっては文字列^{[52] [54]}に内部的にUTF-8を使用しており、Pythonの将来のバージョンではデフォルトで文字列をUTF-8で保存する予定です。^{[55] [56]} Microsoft Visual Studioの最新バージョンは内部的にUTF-8を使用します。^[57] MicrosoftのSQL Server 2019はUTF-8のサポートを追加し、これを使用すると速度が35％向上し、「ストレージ要件がほぼ50％削減」されます。^[58]

Javaは内部 的にModified UTF-8（MUTF-8）を使用しており、ヌル文字 U+0000は単なる0x00ではなく、2バイト長すぎるエンコーディング0xC0、0x80を使用します。^[59] Modified UTF-8文字列には実際のヌルバイトは含まれませんが、U+0000を含むすべてのUnicodeコードポイントを含めることができます。[ ^60]これにより、このような文字列（ヌルバイトが追加された文字列）を従来のヌル終端文字列関数で処理できます。Javaはファイルとストリームに対して通常のUTF-8の読み取りと書き込みを行いますが、^[61]オブジェクトのシリアル化、^{[62] [63]} Java Native Interface、^[64]クラスファイルへの定数文字列の埋め込みにはModified UTF-8を使用します。^[65] Dalvikによって定義されたdex形式も、文字列値を表すために同じModified UTF-8を使用します。^[66] TclもJavaと同じ修正UTF-8 ^[67]をUnicodeデータの内部表現に使用しますが、外部データには厳密なCESU-8を使用します。既知のすべての修正UTF-8実装も、サロゲートペアをCESU-8と同様に扱います。

Rakuプログラミング言語（旧称Perl 6）は、utf-8I/Oにデフォルトでエンコーディングを使用します（Perl 5もこれをサポートしています）。ただし、Rakuでのこの選択は、「Unicode NFC（正規化形式標準）への正規化」も意味します。場合によっては、正規化が行われないようにしたい場合があります。そのためには、「」を使用できます。utf8-c8[ ^{68] Rakuによって実装された}UTF-8 Clean-8バリアントは、バイトをそのまま（不正なUTF-8シーケンスであっても）保存し、Normal Form Grapheme合成を可能にするエンコーダ/デコーダです。^[69]

Pythonプログラミング言語のバージョン 3 では、無効な UTF-8 バイトストリームの各バイトをエラーとして扱います (Python 3.7 の新しい UTF-8 モードの変更点も参照^[70] )。これにより、128 種類のエラーが発生する可能性があります。UTF-8 であると想定されるバイト シーケンスをロスレスで UTF-16 または UTF-32 に変換できるようにするための拡張機能が作成されました。これは、128 種類のエラー バイトを予約済みのコード ポイントに変換し、それらのコード ポイントをエラー バイトに戻して UTF-8 を出力することによって行われます。最も一般的なアプローチは、コードを U+DC80...U+DCFF に変換することです。これは、 PythonのPEP 383 (または "surrogateescape") アプローチで使用される、低い (末尾の) サロゲート値であり、したがって "無効な" UTF-16 です。^[20] MirBSD OPTU-8/16と呼ばれる別のエンコーディングは、それらをPrivate Use Areaで U+EF80...U+EFFF に変換します。^[71]どちらのアプローチでも、バイト値は出力コードポイントの下位8ビットにエンコードされます。これらのエンコードは、無効なUTF-8がPythonの内部で使用されるUTF-16への変換とその後のUTF-16からの変換を生き残るために必要であり、Unixファイル名には無効なUTF-8が含まれる可能性があるため、これが機能するために必要です。^[72]

エンコーディングの正式名称は でUTF-8、これはすべての Unicode コンソーシアム文書で使用されている綴りです。ハイフン (マイナス)は必須で、スペースは使用できません。その他の名前には次のものがあります。

• ほとんどの標準では大文字と小文字が区別されないため、utf-8よく使用されます。^{[引用が必要]}
• ウェブ標準（CSS、HTML、XML、HTTPヘッダーを含む）ではutf8、他の多くのエイリアスも許可されています。^[73]
• 公式のインターネット割り当て番号局ではcsUTF8唯一の別名としてリストされていますが、 ^[74]ほとんど使用されていません。
• いくつかのロケールではバイトオーダーマーク（BOM）なしのUTF-8NUTF-8を意味し、この場合はBOMがあることを意味する場合があります。[ 75 ] ^{[ 76]}UTF-8
• Windowsでは、UTF-8はソースコード内のシンボル名を持つコードページ 65001^{[77]です。}CP_UTF8
• MySQLでは、UTF-8はutf8mb4と呼ばれます^。[78]一方utf8、およびは廃止されたCESU-8のutf8mb3変種を指します。^[79]
• Oracle Database（バージョン9.0以降）では、 AL32UTF8^[80]はUTF-8を意味し、はUTF-8CESU-8を意味します。
• HP PCLでは、UTF-8のシンボルIDはである18N。^[81]

さまざまな標準ドキュメントには、UTF-8 の現在の定義がいくつかあります。

• RFC 3629 / STD 63 (2003) は、UTF-8 を標準インターネット プロトコル要素として確立しました。
• RFC 5198 はネットワーク交換用の UTF-8 NFCを定義します(2008)
• ISO/IEC 10646:2014 §9.1 (2014) ^[82]
• ユニコード標準、バージョン15.0.0（2022）^[83]

これらは、以下の古い著作物で与えられた定義に取って代わります。

• Unicode 標準、バージョン 2.0、付録 A (1996)
• ISO/IEC 10646-1:1993 修正第2版 / 附属書R (1996)
• RFC 2044 (1996)
• RFC 2279 (1998)
• Unicode 標準、バージョン 3.0、§2.3 (2000) および訂正 #1: UTF-8 最短形式 (2000)
• ユニコード標準付録#27: ユニコード3.1 (2001) ^[84]
• ユニコード標準バージョン5.0（2006）^[85]
• ユニコード標準バージョン6.0（2010）^[86]

これらはすべて一般的なメカニズムでは同じですが、主な違いは、コード ポイント値の許容範囲や無効な入力の安全な処理などの問題にあります。

• HTML の文字エンコーディング – HTML における国際文字のエンコーディング システムの使用
• Unicode エンコーディングの比較
• GB 18030  – 公式中国語文字エンコーディング
• Iconv  – 標準 UNIX ユーティリティ
• Unicode と電子メール – Unicode と電子メールの関係
• Unicode と HTML  – Unicode 文字と HTML の関係
• UTF-EBCDIC  – EBCDIC と互換性のある Unicode の文字エンコーディング

• Bell Labs の Plan 9のオリジナル UTF-8 論文 (または pdf)
• UTF-8 の歴史 (Rob Pike 著)
• YouTubeの文字、記号、そして Unicode の奇跡