UTF-8
UTF-8
標準ユニコード標準
分類Unicode変換形式、拡張ASCII、可変長エンコード
拡張アスキー
変換/エンコードISO/IEC 10646 (ユニコード)
先行UTF-1

UTF-8は、電子通信に使用される文字エンコード規格です。Unicode標準によって定義され、その名称はUnicode Transformation Format – 8-bitに由来しています。[ 1 ] 2026年現在、ほぼすべてのウェブページ（99%）はUTF-8で送信されています。[ 2 ]

UTF-8は、1～4バイト（8ビット）のコード単位 の可変幅エンコーディングを使用して、1,112,064 [ 3 ]の有効なUnicodeコードポイントすべてをサポートします。

数値の低いコードポイントは、より頻繁に出現する傾向があり、より少ないバイト数でエンコードされます。これはASCIIとの下位互換性のために設計されました。Unicodeの最初の128文字はASCIIと1対1で対応し、ASCIIと同じバイナリ値を持つ1バイトでエンコードされます。そのため、これらの文字のみを使用してUTF-8でエンコードされたファイルはASCIIファイルと同一です。拡張ASCII用に設計されたほとんどのソフトウェアはUTF-8の読み書きが可能であり、これにより、代替テキストエンコードよりも国際化の問題が少なくなります。[ 4 ] [ 5 ]

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

歴史

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

1992年7月、X/Open委員会XoJIGはより優れた符号化方式を模索していた。Unix System LaboratoriesのDave Prosserは、実装速度が向上し、7ビットASCII文字は文字そのもののみを表現し、マルチバイトシーケンスは上位ビットがセットされたバイトのみを含むという改良点を導入した符号化方式を提案した。File System Safe UCS Transformation Format ( FSS-UTF ) [ 6 ]という名称と、この提案の大部分は、後に最終仕様書に採用された。[ 7 ] [ 8 ] [ 9 ] 1992年8月、この提案はIBM X/Openの代表者によって関係者に 配布された。

ベル研究所のPlan 9 オペレーティングシステムグループのKen Thompsonによる修正により、以前の提案よりもビット効率がいくぶん悪くなるが、自己同期が可能になり、リーダーはどこからでも開始でき、すぐに文字の境界を検出できるようになった。また、長すぎるエンコードを防ぐバイアスの使用も中止された。[ 9 ] [ 10 ] Thompson の設計は 1992 年 9 月 2 日にニュージャージーのダイナーでRob Pikeとともにプレースマットの上で概要が説明された。その後数日で、Pike と Thompson はそれを実装し、Plan 9全体でそれを使用するように更新し、[ 11 ]その成功を X/Open に報告し、 FSS-UTFの仕様としてそれが採用された。[ 9 ] UTF-8は、1993年1月25日から29日までサンディエゴで開催されたUSENIX会議で初めて公式に発表されました。 [ 12 ]インターネットエンジニアリングタスクフォースは、1998年1月にRFC 2277（ BCP 18）の文字セットと言語に関するポリシーで将来のインターネット標準作業のためにUTF-8を採用し、古いRFCのLatin-1などのシングルバイト文字セットに取って代わりました。[ 13 ]

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

説明

UTF-8は、コードポイントの値に応じて、1～4バイトでコードポイントをエンコードします。次の表では、16進数を表す文字uからzが、 U+ uvwxyz の位置にある、その構成ビットであるuuuuからzzzzに置き換えられています。

コードポイント↔UTF-8変換
最初のコードポイント 最後のコードポイント バイト1 バイト2 バイト3 バイト4
0000U+007F0 yyyzzzz
U+0080U+07FF110 xxxyy10ええええええ
U+0800U+FFFF1110 wwww10 xxxxyy10ええええええ
U+010000U+10FFFF11110 uvv10うわあああああ10 xxxxyy10ええええええ

たとえば、文字「 桁 」の16進コードポイントはU+6841で、これは2進数では0110 1000 0100 0001となり、UTF-8エンコードでは11100110 10100001 10000001となります。

最初の128コードポイント（ASCII）には1バイトが必要です。次の1,920コードポイントのエンコードには2バイトが必要で、ほぼすべてのラテン文字アルファベットの残りと、IPA拡張、ギリシャ文字、キリル文字、コプト文字、アルメニア文字、ヘブライ文字、アラビア文字、シリア文字、ターナ文字、ンコ文字、および結合ダイアクリティカルマークをカバーします。中国語、日本語、韓国語のほとんどの文字を含む基本多言語面（BMP）の残りの61,440コードポイントには3バイトが必要です。絵文字、あまり一般的ではないCJK文字、その他の有用な文字を含む1,048,576の非BMPコードポイントには4バイトが必要です。[ 15 ]

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

長すぎるエンコード

上記の表の行を使用して「最初のコードポイント」より小さいコードポイントをエンコードする（つまり、必要以上に多くのバイトを使用する）ことを、長すぎるエンコードと呼びます。これは、悪意のあるJavaScriptなどの文字列を許し、セキュリティ検証をバイパスする可能性があるため、セキュリティ上の問題となります。これは、MicrosoftのIISウェブサーバー[ 16 ]やApacheのTomcatサーブレットコンテナ[ 17 ]../など、多くの有名製品で報告されています。したがって、長すぎるエンコードはエラーとみなし、決してデコードしないでください。

エラー処理

すべてのバイトシーケンスが有効なUTF-8であるとは限りません。UTF-8デコーダーは、以下の点に対応する必要があります。

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

初期のUTF-8デコーダの多くは、これらのビットを無視してデコードしていました。巧妙に細工された無効なUTF-8は、NUL、スラッシュ、引用符などのASCII文字をスキップまたは作成し、セキュリティ上の脆弱性につながる可能性があります。また、エラー発生時に例外をスローしたり文字列を切り捨てたりすることも一般的です[ 18 ]が、これは本来は無害なエラー（例えば「ファイルが見つからない」など）をサービス拒否攻撃に変えてしまいます。例えば、Python 3.0の初期バージョンでは、コマンドラインまたは環境変数に無効なUTF-8が含まれていると即座に終了していました[ 19 ] 。

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

一部のデコーダーは、 E1,A0,20というシーケンス（切り捨てられた3バイトコードにスペースが続く）を単一のエラーとみなします。スペース文字を検索すると、エラーの中に隠れているスペース文字が見つかる可能性があるため、これは良い考えではありません。Unicode 6（2010年10月）[ 1 ]以降、標準規格（第3章）では、エラーが1バイトの継続であるか、または許可されていない最初のバイトで終了するという「ベストプラクティス」が推奨されています。したがって、E1,A0,20は2バイトのエラーで、スペースが続くことになります。エラーは3バイト以下で、有効な文字の先頭を含むことはなく、21,952 通りのエラーが考えられます。多くのデコーダーは各バイトをエラーとして扱います。その場合、E1,A0,20は2つのエラーとそれに続くスペースになります。現在、エラーの種類は128通りしかないため、エラーを出力文字列に格納するか、[ 21 ]、従来のエンコードの文字に置き換えることが現実的です。

エラーのないUTF-8は、バイト文字列のごく一部に限られます。複数のバイトが出現することはなく、最上位ビットがセットされたバイトが単独で出現することもできません。また、真にランダムな文字列では、最上位ビットがセットされたバイトが有効なUTF-8文字の先頭となる確率はわずか1/15です。このため、UTF-8の代わりに誤ってレガシーテキストエンコーディングが使用された場合でも容易に検出でき、システムをUTF-8に変換することが容易になり、バイトオーダーマーク（ BOM）やその他のメタデータを必要とする必要がなくなります。

代理母

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

バイトマップ

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

0 1 2 3 4 5 6 7 8 9 あ B C D E F
0 ␀ ␁ ␂ ␃ ␄ ␅ ␆ ␇ ␈ ␉ ␊ ␋ ␌ ␍ ␎ ␏
1 ␐ ␑ ␒ ␓ ␔ ␕ ␖ ␗ ␘ ␙ ␚ ␛ ␜ ␝ ␞ ␟
2 ␠ ! 「 # $ % ＆ ' （ ） * + 、 - 。 /
3 0 1 2 3 4 5 6 7 8 9 : ; < ＝ > ?
4 @ あ B C D E F G H 私 J K L M 北 お
5 P 質問 R S T あなた V W X はい Z [ \ ] ^ _
6 ` 1つの b c d e f グラム h 私 j け l メートル n o
7 p q r s t あなた v わ × y z { | } 〜 ␡
8
9
あ
B
C 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
D 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
E 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
F 4 4 4 4 4 4 4 4 5 5 5 5 6 6
ASCII制御文字
ASCII文字
継続バイト
Nバイトのコードユニットシーケンスの最初のバイト
すべての継続バイトが許可されるわけではない
未使用

バイトオーダーマーク

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

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

UTF-16との比較

長い間、テキストをUTF-16で処理するか UTF-8 で処理するかについてはかなりの議論がありました。UTF-16 の主な利点は、Windows API がすべての Unicode 文字にアクセスするためにそれを必要としていたことです (UTF-8 は 2019 年 5 月まで Windows で完全にはサポートされていませんでした)。このため、 Qtなどのいくつかのライブラリも UTF-16 文字列を使用し、この要件が Windows 以外のプラットフォームにも伝播しました。Unicode の初期の頃には、 U+FFFFより大きい文字はなく、結合文字がほとんど使用されなかったため、16 ビット エンコーディングは実質的に固定サイズでした。固定サイズのエンコーディングによって処理がより効率的になると考える人もいましたが、UTF-16 も可変幅になるとすぐに、そのような利点は失われました。コード ポイントU+0800 – U+FFFF は、UTF-8 では 3 バイトかかりますが、UTF-16 では 2 バイトしかかかりません。このことから、中国語やその他の言語のテキストは UTF-8 の方が多くのスペースを必要とするという考えが生まれました。しかし、テキストが大きくなるのは、これらのコードポイントが1バイトのASCIIコードポイントよりも多い場合のみであり、実際の文書ではスペース、改行、数字、句読点、英語の単語、マークアップなどにより、このような事態はほとんど起こりません。[ 26 ] UTF-8には、拡張ASCIIを処理できるシステムに簡単に後付けできること、バイト順の問題がないこと、ラテン文字を主に使用する言語ではスペースが約半分になるなどの利点があります。

実装と採用

2010年から2021年までの最も人気のある1000万のウェブサイトの宣言された文字セット
Googleが記録した2001年から2012年までのウェブにおける主要エンコーディングの使用状況[ 27 ]によると、UTF-8は2008年に他のすべてのエンコーディングを上回り、2012年にはウェブの60%以上を占めています。UTF-8は（明示的に）記載されている唯一のUnicodeエンコーディングであり、残りはUnicodeのサブセットのみを提供しています。ASCIIのみの数値には、宣言されたヘッダーに関係なく、ASCII文字のみを含むすべてのウェブページが含まれます。

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

多くの標準規格はUTF-8のみをサポートしています。例えば、JSON交換ではUTF-8（バイトオーダーマーク（BOM）なし）が必要です。[ 30 ] WHATWGはHTMLとDOMの仕様にもUTF-8を必須としており、「UTF-8エンコーディングはUnicodeの交換に最も適したエンコーディングである」と述べています。[ 5 ]また、インターネットメールコンソーシアムは、すべての電子メールプログラムがUTF-8を使用してメールを表示および作成できることを推奨しています。[ 31 ] [ 32 ]ワールドワイドウェブコンソーシアムは、 XMLとHTMLのデフォルトのエンコーディングとしてUTF-8を推奨しています（UTF-8を使用するだけでなく、メタデータでも宣言する必要があります）。「すべての文字がASCII範囲内にある場合でも、UTF-8以外のエンコーディングを使用すると予期しない結果が生じる可能性があります。」 W3C HTML仕様バージョン5.3とWHATWGの現在のLiving StandardはどちらもUTF-8を必須としています。[ 33 ] [ 34 ]

多くのソフトウェアプログラムはUTF-8の読み書き機能を備えています。ただし、ユーザーが通常の設定からオプションを変更する必要がある場合や、ファイルを読み取る際に最初の文字としてBOM（バイトオーダーマーク）が必要になる場合があります。UTF-8をサポートするソフトウェアの例としては、Microsoft Word、[ 35 ] [ 36 ] Microsoft Excel（Office 2003以降）、[ 37 ] Google Drive、LibreOffice、[ 38 ]、そしてほとんどのデータベースが挙げられます。

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

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

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

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

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

Unix系システムのほとんどのファイルシステムは、ファイル名のバイト比較によってファイル名の検索が行われるため、UTF-8を使用してファイル名をエンコードできます。Linuxのext4とmacOSのAPFSファイルシステムは、大文字と小文字を区別しないファイル名検索をサポートしています。これには、ファイル名のエンコードを指定する必要があります。ext4はUTF-8をサポートしており、デフォルトでそれを使用します。 [ 76 ] APFSはUTF-8を必須とします。[ 77 ] Appleの古いHFS Plusはファイル名にUTF-16を使用しますが、シンボリックリンクではUTF-8を使用します。[ 78 ] WindowsのファイルシステムであるNTFSは、ファイル名にUTF-16を使用します。

標準

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

  • 多くの標準では大文字と小文字が区別されないため、utf-8頻繁に使用されます。
  • ウェブ標準（CSS、HTML、XML、HTTPヘッダーを含む）では、utf8他の多くのエイリアスも許可されています。[ 79 ]ただし、HTML文書では、エンコーディングを「文字列 'utf-8 'に大文字と小文字を区別しないASCII一致」として指定する必要があります。[ 33 ]
  • 公式のインターネット割り当て番号局でcsUTF8は唯一の別名としてリストされていますが、 [ 80 ]これはめったに使用されません。
  • 一部のロケールではバイトオーダーマーク（BOM）なしのUTF-8NUTF-8を意味し、この場合はBOMがあることを意味する場合があります。 [ 81 ] [ 82 ]UTF-8
  • Windowsでは、UTF-8はソースコード内のシンボル名を持つコードページ65001[ 83 ]CP_UTF8です。
  • MySQLでは、UTF-8は[ 84 ]utf8mb4と呼ばれ、およびは廃止されたCESU-8の変種を指します。[ 85 ]utf8utf8mb3
  • Oracleデータベースでは、AL32UTF8はUTF-8（バージョン9.0以降）を意味し、 はUTF8CESU-8（バージョン8.0以降）を意味します。[ 86 ] OracleのUTF8エンコーディングは、完全なUTF8/AL32UTF8のサブセットに過ぎないため、使用すべきではありません（日本語と中国語はサポートされておらず、Unicode 3.0のみをサポートし、4バイト形式ではありません。AL32UTFFSS古いOracleデータベースのもう1つの不完全なサブセットです）。[ 87 ]
  • HP PCLでは、UTF-8のシンボルIDはである18N。[ 88 ]

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

  • RFC  3629 / STD 63 (2003) は、UTF-8 を標準インターネット プロトコル要素として確立しました。
  • RFC  5198はネットワーク交換のためのUTF-8 NFCを定義しています（2008年）
  • ISO/IEC 10646:2020/改訂1:2023 [ 89 ]
  • Unicode標準、バージョン17.0.0（2025）

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

  • 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）[ 90 ]
  • ユニコード標準バージョン5.0（2006年）[ 91 ]
  • Unicode標準バージョン6.0（2010年）[ 1 ]

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

参照

参考文献

  1. ^ a b c Unicode® 6.0.0: リリース: 2010年10月11日 (アナウンス) (6.0.0版). マウンテンビュー、カリフォルニア州、米国: Unicodeコンソーシアム. ISBN 978-1-936213-01-6. 2025年7月28日時点のオリジナルよりアーカイブ。2025年8月23日閲覧。
  2. ^ a b「ランク別文字エンコーディング使用状況調査」 W3Techs 2026年1月 2026年1月3日閲覧。
  3. ^ 「適合性」 . Unicode 16.0.0: コア仕様 / 第3章(6.0.0版). カリフォルニア州マウンテンビュー: Unicodeコンソーシアム. 3.9 Unicodeエンコーディング形式. ISBN 978-1-936213-34-4. 2025年7月1日にオリジナルからアーカイブ。2025年8月23日に取得。各エンコード形式は、UnicodeコードポイントU+0000..U+D7FFとU+E000..U+10FFFFをマッピングします。
  4. ^ a b「Microsoft GDKにおけるUTF-8のサポート」。Microsoft Learn。Microsoft Game Development Kit (GDK) 。 2023年3月5日閲覧。
  5. ^ a b「Encoding Standard」 . encoding.spec.whatwg.org . 2025年11月20日閲覧。
  6. ^ 「ファイル システム セーフ UCS — 変換フォーマット (FSS-UTF) - X/Open 予備仕様」(PDF) . unicode.org .
  7. ^ 「付録F. FSS-UTF / ファイルシステムセーフUCS変換形式」(PDF)。Unicode標準1.1。2016年6月7日時点のオリジナルよりアーカイブ(PDF) 。 2016年6月7日閲覧。
  8. ^ Whistler, Kenneth (2001-06-12). 「FSS-UTF、UTF-2、UTF-8、UTF-16」 . Unicode Mail List (メーリングリスト). 2016年6月7日時点のオリジナルよりアーカイブ。 2025年11月20日閲覧。
  9. ^ a b c Pike, Rob (2003-04-30). 「UTF-8の歴史」. 2012年9月7日閲覧。
  10. ^当時、多くのコンピュータでは減算はビットロジックよりも遅く、受け入れられるためには速度が必要であると考えられていました。
  11. ^パイク、ロブ;ケン・トンプソン (1993)。「Hello World または Καλημέρα κόσμε または Hello World」(PDF)。1993 年冬の USENIX 会議の議事録。
  12. ^ 「USENIX WINTER 1993 CONFERENCE PROCEEDINGS」 . www.usenix.org . 2025年11月20日閲覧。
  13. ^ Alvestrand, Harald T. (1998年1月). IETFの文字セットと言語に関するポリシー. IETF . doi : 10.17487/RFC2277 . BCP 18. RFC 2277 .
  14. ^ Pike, Rob (2012年9月6日). 「UTF-8は昨日20周年を迎えました」 . 2012年11月30日時点のオリジナルよりアーカイブ。2012年9月7日閲覧。
  15. ^ Lunde, Dr Ken (2022年1月9日). 「2022年トップ10リスト：なぜBMP以外のコードポイントをサポートするのか？」 . Medium . 2025年11月20日閲覧。
  16. ^ Marin, Marvin (2000-10-17). Windows NT UNICODE 脆弱性分析. Webサーバーフォルダトラバーサル. SANS Institute (レポート). マルウェアに関するFAQ. MS00-078. 2014年8月27日時点のオリジナルよりアーカイブ。
  17. ^ "CVE-2008-2938" . National Vulnerability Database (nvd.nist.gov) . 米国国立標準技術研究所. 2008年. 2025年11月20日閲覧。
  18. ^ 「DataInput (Java Platform SE 8)」 . docs.oracle.com . 2025年11月20日閲覧。
  19. ^ "PEP 383 – システム文字インターフェースにおけるデコード不可能なバイト | peps.python.org" . Python Enhancement Proposals (PEPs) . 2025年11月20日閲覧。
  20. ^ a b Yergeau, F. (2003年11月). UTF-8, a transformation format of ISO 10646 . IETF . doi : 10.17487/RFC3629 . STD 63. RFC 3629 . 2020年8月20日閲覧。
  21. ^ a b von Löwis, Martin (2009-04-22). 「システム文字インターフェースにおけるデコード不可能なバイト」 . Python Software Foundation . PEP 383. 2025年11月20日閲覧。
  22. ^ "PEP 529 – WindowsファイルシステムのエンコーディングをUTF-8に変更 | peps.python.org" . Python拡張提案（PEP） . 2025年11月20日閲覧。
  23. ^ 「WTF-8エンコーディング」 . wtf-8.codeberg.page . 2025年11月30日閲覧。
  24. ^ 「第2章」（PDF）、Unicode標準バージョン15.0.0、39ページ
  25. ^ 「UTF-8とUnicodeに関するFAQ」www.cl.cam.ac.uk . 2025年11月20日閲覧。
  26. ^ "Kí tự đặc biệt" . Ki Tu GenZ。 2025-07-23 。2025 年 11 月 20 日に取得。
  27. ^ Davis, Mark (2012年2月3日). 「ウェブの60%以上がUnicode」 . Google公式ブログ. 2018年8月9日時点のオリジナルよりアーカイブ。 2020年7月24日閲覧。
  28. ^ Davis, Mark (2008年5月5日). 「Unicode 5.1への移行」 .公式Googleブログ. 2023年3月13日閲覧。
  29. ^ 「ウェブサイトにおけるASCIIの使用統計と市場シェア」 W3Techs 2025年12月 2025年12月17日閲覧。
  30. ^ Bray, Tim (2017年12月). Bray, Tim (編). JavaScript Object Notation (JSON) データ交換フォーマット. IETF. doi : 10.17487/RFC8259 . RFC 8259 . 2018年2月16日閲覧。
  31. ^ 「インターネットメールでの国際文字の使用」 . Internet Mail Consortium. 1998年8月1日. 2007年10月26日時点のオリジナルよりアーカイブ。2007年11月8日閲覧。
  32. ^ 「エンコーディング標準」 . encoding.spec.whatwg.org . 2025年11月20日閲覧。
  33. ^ a b「文書の文字エンコーディングの指定」 . HTML 5.3 (レポート).ワールド・ワイド・ウェブ・コンソーシアム. 2021年1月28日. 2026年1月6日閲覧。
  34. ^ 「文書の文字エンコーディングの指定」 . HTML標準. WHATWG . 2025年12月17日. 2026年1月6日閲覧。
  35. ^ 「ファイルを開いたり保存したりするときにテキストエンコードを選択する」。Microsoftサポート。 2021年11月1日閲覧。
  36. ^ 「 WordからUTF-8ファイルをエクスポートする」 . support.3playmedia.com . 2023年3月14日..txt
  37. ^ Abhinav, Ankit; Xu, Jazlyn (2020年4月13日). 「MacとWindowsの両方で、 ExcelでUTF-8ファイルを日本語と中国語の文字が誤って変換されることなく開く方法」 . Microsoft サポートコミュニティ. 2021年11月1日閲覧。CSV
  38. ^ 「CSVファイルをUTF-8として保存する」 . RO CSVI . LibreOffice . 2025年5月20日閲覧。
  39. ^ Galloway, Matt (2012年10月). 「iOS開発者向けの文字エンコーディング、あるいはUTF-8の今後はどうなるのか？」 . www.galloway.me.uk . 2021年1月2日閲覧. …実際には、UTF-8が圧倒的に最も一般的なエンコーディングであるため、通常はUTF-8を前提とします。
  40. ^ 「Windows 10 Notepad の UTF-8 エンコードサポートが向上」 BleepingComputer 2021年3月24日閲覧。Microsoftは現在、新規テキストファイルを BOM なしの UTF-8 で保存することをデフォルトとしています（以下参照）。
  41. ^ 「Windows 11のスタートメニューをカスタマイズする」 . docs.microsoft.com . 2021年6月29日閲覧。LayoutModification.jsonでUTF-8エンコードが使用されていることを確認してください。
  42. ^ 「WindowsでEncoding.default_externalのデフォルトをUTF-8に設定する」 . Ruby Issue Tracking System (bugs.ruby-lang.org) . Rubyマスター。機能#16604 . 2022年8月1日閲覧。
  43. ^ 「Feature #12650: WindowsのENVにUTF-8エンコードを使用する」 . Ruby Issue Tracking System . Ruby master . 2022年8月1日閲覧。
  44. ^ 「R 4.2.0の新機能」 . Rブロガー. The Jumping Rivers Blog. 2022年4月1日. 2022年8月1日閲覧。
  45. ^ 「UTF-8がデフォルト」 . openjdk.java.net . JEP 400. 2022年3月30日閲覧。
  46. ^ 「Python 3.15の新機能」 . Pythonドキュメント. 2025年12月23日閲覧。
  47. ^ 「UTF-8モードをデフォルトにする」 . peps.python.org . PEP 686. 2023年7月26日閲覧。
  48. ^ 「新しいUTF-8モードを追加する」 . peps.python.org . PEP 540. 2022年9月23日閲覧。
  49. ^ポータブルソースファイルエンコーディングとしてのUTF-8のサポート（PDF） open-std.org （レポート）2022年p2295r6。
  50. ^ 「Windows アプリで UTF-8 コード ページを使用する」 . Microsoft Learn . 2024年8月20日. 2024年9月24日閲覧。
  51. ^ 「ソースコード表現」 . Goプログラミング言語仕様. golang.org (レポート) . 2021年2月10日閲覧。
  52. ^ Tsai, Michael J. (2019年3月21日). 「Swift 5のUTF-8文字列」（ブログ投稿）. 2021年3月15日閲覧。
  53. ^ Mattip (2019年3月24日). 「PyPy v7.1 リリース; Unicode 文字列の内部処理に UTF-8 を使用するようになりました」 . PyPy ステータスブログ. 2025年11月20日閲覧。
  54. ^ a b「柔軟な文字列表現」 . Python.org . PEP 393. 2022年5月18日閲覧。
  55. ^ 「共通オブジェクト構造」 . Pythonドキュメント. 2025年11月20日閲覧。
  56. ^ 「Unicodeオブジェクトとコーデック」 . Pythonドキュメント. 2023年8月19日閲覧. UTF-8表現はオンデマンドで作成され、Unicodeオブジェクトにキャッシュされます。
  57. ^ 「PEP 623 – Unicodeからwstrを削除」 . Python.org . 2020年11月21日閲覧。
  58. ^ Wouters, Thomas (2023-07-11). 「Python 3.12.0 beta 4 リリース」 . Python Insider (ブログ投稿) . 2023-07-26閲覧. PEP 623 に従い、Unicode オブジェクトの C 実装から非推奨のおよびメンバーが削除されました。wstrwstr_length
  59. ^ "validate-charset (互換性のある文字の検証)" . docs.microsoft.com . 2021年7月19日閲覧. Visual Studioは、ソース文字セットと実行文字セット間の変換時に、内部文字エンコードとしてUTF-8を使用します。
  60. ^ 「SQL Server の UTF-8 サポートの導入」 . techcommunity.microsoft.com . 2019年7月2日. 2021年8月24日閲覧。
  61. ^ 「Character (Java SE 24 & JDK 24)」 . Oracle Corporation . 2025. 2025年4月8日閲覧。
  62. ^ 「Java SEドキュメント java.io.DataInputインタフェースの修正UTF-8に関するサブセクション」 Oracle Corporation 2015年 2015年10月16日閲覧。
  63. ^ a b「Java仮想マシン仕様、セクション4.4.7：CONSTANT_Utf8_info構造体」 Oracle Corporation、2015年。2015年10月16日閲覧。
  64. ^InputStreamReaderとOutputStreamWriter
  65. ^ 「Javaオブジェクトシリアル化仕様、第6章：オブジェクトシリアル化ストリームプロトコル、セクション2：ストリーム要素」。Oracle Corporation。2010年。 2015年10月16日閲覧。
  66. ^DataInputとDataOutput
  67. ^ 「Java Native Interface仕様、第3章：JNI型とデータ構造、セクション：修正UTF-8文字列」。Oracle Corporation。2015年。 2015年10月16日閲覧。
  68. ^ 「ARTとDalvik」。Androidオープンソースプロジェクト。2013年4月26日時点のオリジナルよりアーカイブ。2013年4月9日閲覧。
  69. ^ 「UTF-8 少しずつ」 Tcler 's Wiki 2001年2月28日2022年9月3日閲覧。
  70. ^ "encoding" . Rakuドキュメント. 2025年11月20日閲覧。
  71. ^ "Unicode" . Rakuドキュメント. 2025年11月20日閲覧。
  72. ^ 「PEP 540 – 新しいUTF-8モードの追加」 . Python拡張提案（PEP） . 2025年11月20日閲覧。
  73. ^ 「NEP 55 – NumPyにUTF-8可変幅文字列DTypeを追加」。NumPy機能強化提案。2025年11月20日閲覧。
  74. ^ "RTFM optu8to16(3), optu8to16vis(3)" . MirBSD 。2025 年 11 月 20 日に取得。
  75. ^ Davis, Mark ; Suignard, Michel (2014). 「3.7 ロスレス変換の有効化」 . Unicode セキュリティに関する考慮事項. Unicode 技術レポート #36 . 2025年11月20日閲覧。
  76. ^ 「Ext4 一般情報」 . Linux カーネルドキュメント. 2025年11月20日閲覧。
  77. ^ 「よくある質問」 . Appleファイルシステムガイド. Apple . 2025年11月20日閲覧。
  78. ^ 「テクニカルノートTN1150: HFS Plusボリュームフォーマット」 . Apple . 2025年11月20日閲覧。
  79. ^ 「Encoding Standard § 4.2. Names and labels」 . WHATWG . 2018年4月29日閲覧。
  80. ^ 「文字セット」 . Internet Assigned Numbers Authority . 2013年1月23日. 2013年2月8日閲覧。
  81. ^ "BOM" . suikawik​​i (日本語). 2009年1月17日時点のオリジナルよりアーカイブ。
  82. ^ Davis, Mark . 「Forms of Unicode」 IBM . 2005年5月6日時点のオリジナルよりアーカイブ。2013年9月18日閲覧。
  83. ^ Liviu (2014-02-07). 「Windows 7におけるUTF-8コードページ65001 - パートI」. 2018-01-30閲覧。以前はXP（未検証だがVistaでもおそらく）では、コードページ65001が有効な間はforループが動作しませんでした。
  84. ^ 「MySQL :: MySQL 8.0 リファレンスマニュアル :: 10.9.1 utf8mb4 文字セット（4バイト UTF-8 Unicode エンコーディング） 」 . MySQL 8.0 リファレンスマニュアル. Oracle Corporation . 2023年3月14日閲覧。
  85. ^ 「MySQL :: MySQL 8.0 リファレンスマニュアル :: 10.9.2 utf8mb3 文字セット（3バイト UTF-8 Unicode エンコーディング） 」 . MySQL 8.0 リファレンスマニュアル. Oracle Corporation . 2023年2月24日閲覧。
  86. ^ 「データベースグローバリゼーションサポートガイド」 . docs.oracle.com . 2023年3月16日閲覧。
  87. ^ Hood, Doug (2025年7月10日). 「データベース文字セットが重要な理由」 . blogs.oracle.com . 2025年11月20日閲覧。
  88. ^ 「HP PCLシンボルセット | プリンター制御言語（PCL & PXL）サポートブログ」 2015年2月19日。2015年2月19日時点のオリジナルよりアーカイブ。 2018年1月30日閲覧。
  89. ^ 「ISO/IEC 10646:2020/Amd 1:2023」 . ISO . 2025年11月20日閲覧。
  90. ^ 「UAX #27: Unicode 3.1」 . www.unicode.org . 2025年11月20日閲覧。
  91. ^ Unicode標準、バージョン5.0 §3.9-§3.10 ch. 3、2006年。
「 https://en.wikipedia.org/w/index.php?title=UTF-8&oldid=1334781122」より取得