UTF-8

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ
UTF-8
標準Unicode標準
分類Unicode変換形式拡張ASCII可変幅エンコーディング
延長US-ASCII
変換/エンコードISO 10646Unicode
前任者UTF-1

UTF-8は、電子通信に使用される可変幅の 文字エンコードです。Unicode標準で定義されているこの名前は、Unicode(またはユニバーサルコード化文字集合変換形式–8ビットから派生しています。[1]

UTF-8は、1〜4個の1バイト(8ビット)コードユニットを使用してUnicodeで1,112,064 [nb1]のすべての有効な文字コードポイントをエンコードできます。より頻繁に発生する傾向がある、数値が小さいコードポイントは、より少ないバイト数を使用してエンコードされます。ASCIIとの下位互換性ために設計されました:ASCIIと1対1で対応するUnicodeの最初の128文字は、ASCIIと同じバイナリ値を持つ1バイトを使用してエンコードされるため、有効なASCIIテキストはUTF-8でエンコードされた有効なUnicodeでもあ​​ります。非ASCIIコードポイントをUTF-8にエンコードする場合、ASCIIバイトは発生しないため、UTF-8は、ファイル名の/slash\ )などの特定のASCII文字を特別な方法で解釈するほとんどのプログラミング言語およびドキュメント言語で安全に使用できます。エスケープシーケンスおよびprintfバックスラッシュ%

UTF-8は、部分的なASCII互換性を備えた提案された可変幅エンコーディングであるUTF-1の優れた代替手段として設計されましたが、自己同期やスラッシュなどの文字の完全なASCII互換処理などの機能がありませんでした。KenThompsonRobPikeは、1992年9月にPlan9オペレーティングシステムの最初の実装を作成しました。 [2] [3]これにより、 FSS-UTFの仕様としてX / Openに採用され、 USENIXで最初に正式に発表されました。 1993年1月に、その後インターネットエンジニアリングタスクフォースに採用されました将来のインターネット標準の動作のためのRFC2277BCP 18 )の(IETF)は、古いRFCの Latin-1などのシングルバイト文字セットを置き換えます。

UTF-8は、ワールドワイドウェブ(およびインターネットテクノロジー)の主要なエンコーディングであり、2022年の時点で、すべてのWebページの98%を占め、一部の言語では最大100.0%を占めています。[4]

ネーミング

エンコーディングの公式のInternetAssigned Numbers Authority(IANA)コードは「UTF-8」です。[5]すべての文字は大文字で、名前はハイフンでつながれています。このスペルは、エンコーディングに関連するすべてのUnicodeコンソーシアムドキュメントで使用されています。

ただし、「utf-8」という名前は、IANAリストに準拠するすべての標準(CSSHTMLXML、およびHTTPヘッダーを含む)[6]で使用できます。これは、宣言で大文字と小文字が区別されないためです。[5]

ハイフンを省略したり、スペースに置き換えたりするその他のバリアント、つまり「utf8」または「UTF 8」は、準拠規格では正しいものとして受け入れられません。[7]それにもかかわらず、ほとんどのWebブラウザーはそれらを理解できるため、既存のプラクティス(HTML5など)を説明することを目的とした標準では、それらの認識が効果的に必要になる場合があります。[8]

非公式には、UTF-8-BOMUTF-8-NOBOMは、それぞれバイト順マーク(BOM)を含むまたは含まないテキストファイルに使用されることがあります。[要出典]特に日本では、BOMを使用しないUTF-8エンコーディングは「 UTF-8N 」と呼ばれることがあります。[9] [10]

サポートされているすべてのWindowsバージョンを含むWindowsXP以降には、UTF-8の同義語としてコードページ65001があります(UTF-8のWindows 7サポートの方が優れているため)。[11] Windows 10バージョン1903以降、 Windowsメモ帳のデフォルトがUTF-8に変更されました。[12] [13]

PCLでは、UTF-8はSymbol-ID "18N"と呼ばれます(PCLはSymbolセットと呼ばれる183文字エンコードをサポートします。これは潜在的に1つの18N、つまりUTF-8に減らすことができます)。[14]

エンコーディング

2003年にはUnicodeコードスペースが21ビット値に制限されていたため、UTF-8は、コードポイントの数値の有効ビット数に応じて、コードポイントを1〜4バイトでエンコードするように定義されています。次の表に、エンコーディングの構造を示します。x文字は、コードポイントのビットに置き換えられます

コードポイント<-> UTF-8変換
最初のコードポイント 最後のコードポイント バイト1 バイト2 バイト3 バイト4
U + 0000 U + 007F 0xxxxxxx
U + 0080 U + 07FF 110xxxxx 10xxxxxx
U + 0800 U + FFFF 1110xxxx 10xxxxxx 10xxxxxx
U + 10000 [nb 2] U + 10FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

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

「文字」は実際には4バイト以上かかる場合があります。たとえば、国旗文字は「Unicodeスカラー値のペアから構築されている」ため、8バイトかかります。[16] [nb 3]

ユーロ記号のエンコーディングを検討してください、€:

  1. €のUnicodeコードポイントはU + 20ACです。
  2. このコードポイントはU + 0800とU + FFFFの間にあるため、エンコードには3バイトかかります。
  3. 16進数の 20ACはバイナリ00100000 10 101100です。3バイトのエンコーディングにはコードポイントから正確に16ビットが必要なため、先行ゼロが2つ追加されます。
  4. エンコーディングは3バイトの長さになるため、先頭のバイトは3つの1で始まり、次に0(1110。。。)になります。
  5. コードポイントの最上位4ビットは、このバイトの残りの下位4ビット(1110 0010)に格納され、コードポイントの12ビットはまだエンコードされていません(... 0000 10 10 1100)。
  6. すべての継続バイトには、コードポイントから正確に6ビットが含まれます。したがって、コードポイントの次の6ビットは次のバイトの下位6ビットに格納され、 10は上位2ビットに格納されて、継続バイトとしてマークされます(つまり、10 000010)。
  7. 最後に、コードポイントの最後の6ビットは最後のバイトの下位6ビットに格納され、再び10は上位2ビット(10 101100)に格納されます。

3バイトの11100010 10 000010 10 101100は、E2 82 ACのように、 16進数でより簡潔に記述できます

次の表は、この変換と、UTF-8での長さが異なる他の変換をまとめたものです。色は、コードポイントからのビットがUTF-8バイトにどのように分散されているかを示します。UTF-8エンコーディングプロセスによって追加された追加ビットは黒で表示されます。

UTF-8エンコーディングの例
キャラクター バイナリコードポイント バイナリUTF-8 16進UTF-8
$ U + 0024 010 0100 0 0100100 24
££ U + 00A3 000 10 10 0011 110 00010 10 100011 C2 A3
U + 0939 0000 1001 00 11 1001 1110 0000 10 100100 10 111001 E0 A4 B9
€€ U + 20AC 0010 0000 10 10 1100 1110 0010 10 000010 10 101100 E2 82 AC
U + D55C 1101 0101 01 01 1100 1110 1101 10 010101 10 011100 ED 95 9C
𐍈 U + 10348 0 00 01 0000 0011 01 00 1000 11110 000 10 010000 10 001101 10 001000 F0 90 8D 88

8進数

エンコードされている実際の文字を表すためにUTF-8が1バイトあたり6ビットを使用するということは、8進表記(3ビットグループを使用)がUTF-8シーケンスの相互比較や手動変換に役立つことを意味します。[17]

8進コードポイント<-> 8進UTF-8変換
最初のコードポイント 最後のコードポイント コードポイント バイト1 バイト2 バイト3 バイト4
000 0177 xxx xxx
0200 03777 xxyy 3xx 2yy
04000 077777 xyyzz 34倍 2yy 2zz
0100000 0177777 1xyyzz 35倍 2yy 2zz
0200000 04177777 xyyzzww 36倍 2yy 2zz 2ww

8進数表記では、表でx、y、z、またはwでマークされた任意の8進数は、UTF-8との間で変換するときに変更されません。

例:Á= U + 00C1 = 0301(8進数)は、UTF-8(16進数のC3 81)では303201としてエンコードされます。
例:€= U + 20AC = 020254は、UTF-8では342 202 254としてエンコードされます(16進数ではE2 82 AC)。

コードページのレイアウト

次の表は、UTF-8コードユニット(個々のバイトまたはオクテット)の使用法をコードページ形式でまとめたものです。上半分はシングルバイトコードでのみ使用されるバイト用であるため、通常のコードページのように見えます。下半分は継続バイトと先行バイト用であり、以下の凡例でさらに説明されています。

UTF-8
0 1 2 3 4 5 6 7 8 9 A B C D E F
0x NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF CR それで SI
1x DLE DC1 DC2 DC3 DC4 NAK SYN ETB できる EM サブ ESC FS GS RS 我ら
2倍  SP  「」 $ ' (( )。 * + - /
3倍 0 1 2 3 4 5 6 7 8 9 ; < = >>
4x @ A B C D E F G H J K L M N O
5倍 P Q R S T U V W バツ Y Z [[ \ ] ^ _
6倍 ` a b c d e f g h j k l m n o
7倍 p q r s t u v w バツ y z {{ | } DEL
8倍 •• •• •• •• •• •• •• •• •• •• •• •• •• •• •• ••
9倍 •• •• •• •• •• •• •• •• •• •• •• •• •• •• •• ••
•• •• •• •• •• •• •• •• •• •• •• •• •• •• •• ••
Bx •• •• •• •• •• •• •• •• •• •• •• •• •• •• •• ••
Cx 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
Dx 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
Fx 4 4 4 4 4 4 4 4 5 5 5 5 6 6
  7ビット(シングルバイト)コードポイント。それらの後に継続バイトを続けてはなりません。[18]
  継続バイト。[19]ツールチップは、それらが追加する6ビットの値を16進数で示します。[nb 4]
  複数バイトのシーケンスの先頭のバイトの後には、正確にN -1個の継続バイトが続く必要があります。[20]ツールチップには、このバイトで始まるシーケンスによってエンコードされたコードポイント範囲とUnicodeブロックが表示されます。
  継続バイトのすべての配置が有効であるとは限らない先頭のバイト。E0F0は、長すぎるエンコーディングを開始する可能性があります。F4は、U + 10FFFFより大きいコードポイントを開始できます。EDは、U + D800–U + DFFFの範囲のコードポイントを開始できます。これは、無効なUTF-16サロゲートハーフです。[21]
  有効なUTF-8シーケンスには表示されません。C0C1は、1バイト文字の「長すぎる」エンコーディングにのみ使用できます。[22] F5からFDは、U + 10FFFFより大きいコードポイントのみをエンコードできる4バイト以上のシーケンスの先頭バイトです。[23] FEFFには意味が割り当てられていません。[24]

過度に長いエンコーディング

原則として、コードポイントを先頭の0で埋めることにより、エンコーディングのバイト数を増やすことができます。上記の例のユーロ記号€を3バイトではなく4バイトでエンコードするには、21ビット長になるまで先頭の0を埋めて– 000 000010 000010 101100、11110 000 10 000010 10 000010 10 101100 またはF0 )としてエンコードします。82 82 AC(16進数)。これは、オーバーロングエンコーディングと呼ばれます。

この規格では、コードポイントを正しくエンコードするには、コードポイントの有効ビットを保持するために必要な最小バイト数のみを使用するように指定されています。より長いエンコーディングはoverlongと呼ばれ、コードポイントの有効なUTF-8表現ではありません。このルールは、コードポイントとそれらの有効なエンコーディングの間の1対1の対応を維持するため、各コードポイントに一意の有効なエンコーディングがあります。これにより、文字列の比較と検索が明確に定義されます。

無効なシーケンスとエラー処理

すべてのバイトシーケンスが有効なUTF-8であるとは限りません。UTF-8デコーダーは次の目的で準備する必要があります。

  • 無効なバイト
  • 予期しない継続バイト
  • 文字の終わりの前の非継続バイト
  • 文字の終わりの前で終わる文字列(単純な文字列の切り捨てで発生する可能性があります)
  • 過度に長いエンコーディング
  • 無効なコードポイントにデコードするシーケンス

最初のUTF-8デコーダーの多くは、これらをデコードし、誤ったビットを無視して、長すぎる結果を受け入れていました。注意深く作成された無効なUTF-8は、NUL、スラッシュ、引用符などのASCII文字をスキップまたは作成する可能性があります。無効なUTF-8は、MicrosoftのIISWebサーバー[25]やApacheのTomcatサーブレットコンテナなどの注目を集める製品のセキュリティ検証をバイパスするために使用されています。[26] RFC 3629は、「デコードアルゴリズムの実装は、無効なシーケンスのデコードから保護しなければならない」と述べています。[7] Unicode標準では、デコーダーが「...不正な形式のコードユニットシーケンスをエラー状態として扱う必要があります。これにより、不正な形式のコードユニットシーケンスを解釈したり発行したりしないことが保証されます」。

RFC 3629(2003年11月)以降、UTF-16(U + D800からU + DFFF)で使用される上位および下位のサロゲートハーフとUTF-16でエンコードできないコードポイント(U + 10FFFF以降)は、正規のUnicode値ではありません。また、UTF-8エンコーディングは無効なバイトシーケンスとして扱われる必要があります。対になっていないサロゲートの半分をデコードしないと、無効なUTF-16(Windowsファイル名やサロゲート間で分割されたUTF-16など)をUTF-8として保存できなくなります[27]が、 WTF-8では可​​能です。

デコーダーの一部の実装では、エラー時に例外がスローされます。[28]これには、他の方法では無害なエラー(「そのようなファイルがない」エラーなど)がサービス拒否に変わる可能性があるという欠点がありますたとえば、Python 3.0の初期バージョンは、コマンドラインまたは環境変数に無効なUTF-8が含まれている場合、すぐに終了します。[29]別の方法は、エラーを置換文字に置き換えることです。Unicode 6 [30](2010年10月)以降、標準(第3章)では、許可されていないバイトが検出されるとすぐにエラーが終了する「ベストプラクティス」が推奨されています。これらのデコーダーではE1、A0、C02つのエラーです(最初のエラーは2バイト)。これは、エラーの長さが3バイト以下であり、有効な文字の先頭が含まれることはなく、21,952の異なるエラーが発生する可能性があることを意味します。[31]規格では、各エラーを置換文字「�」(U + FFFD)に置き換えることも推奨されています。

バイト順マーク

UTF-16 Unicodeバイト順マーク(BOM、U + FEFF)文字がUTF-8ファイルの先頭にある場合、最初の3バイトは0xEF0xBB0xBFになります。

Unicode標準は、UTF-8にBOMを使用することを要求も推奨もしていませんが、別のエンコーディングからトランスコーディングされたファイルの開始時に発生する可能性があることを警告しています。[32] UTF-8を使用してエンコードされたASCIIテキストはASCIIと下位互換性がありますが、Unicode標準の推奨事項が無視され、BOMが追加された場合、これは当てはまりません。BOMは、準備されていないソフトウェアを混乱させる可能性がありますが、UTF-8を受け入れる可能性があります。たとえば、文字列リテラルで非ASCIIバイトを許可するが、ファイルの先頭では許可しないプログラミング言語です。それにもかかわらず、UTF-8を書き込むときに常にBOMを挿入し、最初の文字がBOMでない限り(またはファイルにASCIIのみが含まれている場合)、UTF-8を正しく解釈することを拒否するソフトウェアがありました。[要出典]

一部のファイル形式とプログラミング言語には、ソースコードでのUTF-8などのエンコーディングの使用をマークする独自の方法があります。例には、HTML <meta charset="UTF-8"/>Python2.7が含まれます # coding: utf-8

採用

 2010年以降に最も人気のある1,000万のWebサイトの文字セットを宣言
Googleによって記録された2001年から2012年までのWebでのメインエンコーディングの使用[33]、UTF-8(「Unicode」とラベル付け)は2008年に他のすべてを追い越し、2012年にはWebの60%以上(その後100%に近づいています) )。ASCIIのみの図には、宣言されたヘッダーに関係なく、ASCII文字のみを含むすべてのWebページが含まれます。GB2312などのUnicodeの他のエンコーディングが「その他」に追加されます。

多くの標準はUTF-8のみをサポートします。たとえば、オープンJSON交換ではUTF-8が必要です(バイト順マーク(BOM)なし)。[34] UTF-8は、HTMLおよびDOM仕様に関するWHATWGからの推奨事項でもあり[35]インターネットメールコンソーシアムは、すべての電子メールプログラムがUTF-8を使用してメールを表示および作成できることを推奨しています。[36] [37] World Wide Web Consortiumは、「すべての文字がASCII範囲にある場合でも、UTF-8をXMLおよびHTMLのデフォルトのエンコーディングとして推奨しています(UTF-8を使用するだけでなく、メタデータでも宣言しています) 。 。UTF-8以外のエンコーディングを使用すると、予期しない結果が生じる可能性があります。」[38]

多くのソフトウェアにはUTF-8の読み取り/書き込み機能がありますが、これにはユーザーが通常の設定からオプションを変更する必要があり、ファイルを読み取る最初の文字としてBOM(バイト順マーク)が必要になる場合があります。例としては、Microsoft Word [39] [40] [41]MicrosoftExcelなどがあります。[42] [43] SQL Server 2019以降のMicrosoftを含め、ほとんどのデータベースはUTF-8(一部のファイル形式の場合は唯一のオプション)をサポートしているため、速度が35%向上し、「ストレージ要件がほぼ50%削減」されます。[44]

UTF-8は、2008年以来ワールドワイドウェブの最も一般的なエンコーディングです。 [45] 2022年2月の時点で、UTF-8はすべてのWebページの平均97.7%を占めています(上位1,000のWebページのうち987)。 。[4] UTF-8にはサブセットとしてASCIIが含まれています。ASCIIのみが使用されていると宣言しているWebサイトはほとんどありません。[46]追跡された言語の3分の1以上で、100.0%のUTF-8が使用されています。

ローカルテキストファイルの場合、UTF-8の使用量は少なく、多くのレガシーシングルバイト(およびCJKマルチバイト)エンコーディングが引き続き使用されます。主な原因は、ファイルの最初の文字がバイト順マーク(BOM)でない限り、UTF-8を表示または書き込まないエディターであり、他のソフトウェアがバイト順マークを無視するように書き直さずにUTF-8を使用することは不可能です。入力時に追加し、出力に追加します。[47] [48]いくつかの改善があり、Windows 10のメモ帳はデフォルトでBOMなしでUTF-8を書き込みます[49]、Windows 11の一部のシステムファイルはUTF-8、[50]およびmacOSのほとんどすべてのファイルを必要としますおよびLinuxはUTF-8(BOMなし)である必要があります。[要出典] JavaNIOAPIのデフォルトはUTF-8ファイルの読み取りと書き込みであり、Java18リリースで他のすべてのファイルAPIを更新する予定です。[51]他の多くのプログラミング言語は、デフォルトでI / OにUTF-8を使用します。 または、プログラマーが「UTF-8への変更が事実上の標準テキストエンコーディングになった」ための準備を支援するためにすでに変更を加えたPythonなどのUTF-8への移行を計画します。[52]

内部的にはソフトウェアの使用量が少なく、特にWindowsではUTF-16またはUCS-2が使用されていますが、 JavaScript、Python、[53] Qt、およびその他の多くのクロスプラットフォームソフトウェアライブラリでも使用されています。Windows APIとの互換性がこの主な理由ですが、BMPの直接インデックス作成によって速度が向上するという信念も要因でした。最近のソフトウェアはUTF-8の使用を開始しました。Go[54] JuliaRustSwift 5[55]およびPyPy [56]で使用されるデフォルトの文字列プリミティブはUTF-8であり、Pythonの将来のバージョンは保存する予定です。 UTF-8としての文字列、[57]最新バージョンのMicrosoftVisual Studioは内部でUTF-8を使用します[58](ただし、UTF-8の読み取りまたは書き込みにはコマンドラインスイッチが必要です[59])。UTF-8は、 C ++ 20の時点で、「C ++標準でサポートすることが義務付けられている唯一のテキストエンコーディング」です。[60] 2019年5月の時点で、MicrosoftはWindows APIでUTF-16のみをサポートするという方針を覆し、UTF-8をマルチバイトAPIの「コードページ」として設定する機能を提供しました(以前はこれは不可能でした)。そして今、マイクロソフトは(プログラマーが)UTF-8を使用することを推奨しています。[61]

歴史

国際標準化機構(ISO)は、1989年にユニバーサルマルチバイト文字セットの作成に着手しました。ISO10646標準のドラフトには、 32ビットコードポイントのバイトストリームエンコーディングを提供するUTF-1と呼ばれる不要な付属書が含まれていました。 。このエンコーディングは、他の問題の中でも特にパフォーマンス上の理由で満足のいくものではありませんでした。最大の問題は、ASCIIと非ASCIIが明確に区別されていないことでした。新しいUTF-1ツールはASCIIエンコードされたテキストと下位互換性がありますが、 UTF-1でエンコードされたテキストは、ASCII(または拡張ASCII)を期待する既存のコードを混乱させる可能性があります。これは、0x21〜0x7Eの範囲の継続バイトが含まれている可能性があるためです。Unix パスディレクトリ区切り文字。この例は、その置換の名前と紹介テキストに反映されています。以下の表は、付録のテキストによる説明から派生したものです。

UTF-1

バイト
最初
のコードポイント
最後の
コードポイント
バイト1 バイト2 バイト3 バイト4 バイト5
1 U + 0000 U + 009F 00–9F
2 U + 00A0 U + 00FF A0 A0–FF
2 U + 0100 U + 4015 A1〜F5 21–7E、A0–FF
3 U + 4016 U + 38E2D F6–FB 21–7E、A0–FF 21–7E、A0–FF
5 U + 38E2E U + 7FFFFFFF FC–FF 21–7E、A0–FF 21–7E、A0–FF 21–7E、A0–FF 21–7E、A0–FF

1992年7月、X / Open委員会XoJIGはより良いエンコーディングを探していました。Unix SystemLaboratoriesのDaveProsserは、より高速な実装特性を備えた提案を提出し、7ビットASCII文字はそれ自体を表すだけであるという改善を導入しました。すべてのマルチバイトシーケンスには、上位ビットが設定されたバイトのみが含まれます。ファイルシステムセーフUCSトランスフォーメーションフォーマット(FSS-UTF)という名前と、この提案のほとんどのテキストは、後で最終仕様に保存されました。[62] [63] [64] [65]

FSS-UTF

FSS-UTF提案(1992)

バイト
最初
のコードポイント
最後の
コードポイント
バイト1 バイト2 バイト3 バイト4 バイト5
1 U + 0000 U + 007F 0xxxxxxx
2 U + 0080 U + 207F 10xxxxxx 1xxxxxxx
3 U + 2080 U + 8207F 110xxxxx 1xxxxxxx 1xxxxxxx
4 U + 82080 U + 208207F 1110xxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx
5 U + 2082080 U + 7FFFFFFF 11110xxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx

1992年8月、この提案はIBM X / Openの担当者によって利害関係者に回覧されました。BellLabsPlan9 オペレーティングシステムグループのKenThompsonによる変更により、以前の提案よりもビット効率がやや低下しましたが、自己同期が可能になりました。、リーダーがどこからでも開始し、バイトシーケンスの境界をすぐに検出できるようにします。また、バイアスの使用を放棄し、代わりに可能な限り短いエンコーディングのみが許可されるというルールを追加しました。コンパクトさの追加の損失は比較的重要ではありませんが、信頼性、特にセキュリティの問題を回避するために、読者は無効なエンコーディングに注意する必要があります。トンプソンのデザインは、1992年9月2日に、ロブパイクと一緒ニュージャージーのダイナーのプレースマットで概説されました翌日、PikeとThompsonはそれを実装し、Plan 9を更新して全体で使用し、成功をX / Openに伝え、FSS-UTFの仕様として受け入れました。[64]

FSS-UTF(1992)/ UTF-8(1993)[2]

バイト
最初
のコードポイント
最後の
コードポイント
バイト1 バイト2 バイト3 バイト4 バイト5 バイト6
1 U + 0000 U + 007F 0xxxxxxx
2 U + 0080 U + 07FF 110xxxxx 10xxxxxx
3 U + 0800 U + FFFF 1110xxxx 10xxxxxx 10xxxxxx
4 U + 10000 U + 1FFFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
5 U + 200000 U + 3FFFFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
6 U + 4000000 U + 7FFFFFFF 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

UTF-8は、1993年1月25日から29日にサンディエゴで開催されたUSENIX会議で最初に正式に発表されました。インターネットエンジニアリングタスクフォースは、将来のインターネットのためにRFC 2277(BCP 18)の文字セットと言語に関するポリシーでUTF-8を採用しました。標準は機能し、古いRFCのLatin-1などのシングルバイト文字セットを置き換えます。[66]

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

標準

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

  • RFC  3629 / STD 63(2003)、これはUTF-8を標準のインターネットプロトコル要素として確立します
  • RFC  5198は、ネットワーク交換用のUTF-8 NFCを定義しています(2008)
  • ISO / IEC 10646:2014§9.1(2014)[67]
  • Unicode標準、バージョン11.0(2018)[68]

それらは、以下の廃止された作品で与えられた定義に取って代わります。

  • 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)
  • Unicode Standard Annex#27:Unicode 3.1(2001)[69]
  • Unicode標準、バージョン5.0(2006)[70]
  • Unicode標準、バージョン6.0(2010)[71]

それらはすべて一般的な仕組みで同じですが、主な違いは、コードポイント値の許容範囲や無効な入力の安全な処理などの問題です。

他のエンコーディングとの比較

このエンコーディングの重要な機能のいくつかは次のとおりです。

  • 下位互換性:ASCIIとの下位互換性と、ASCIIでエンコードされたテキストを処理するために設計された膨大な量のソフトウェアが、UTF-8の設計の背後にある主な推進力でした。UTF-8では、0〜127の範囲の値を持つ1バイトは、ASCII範囲のUnicodeコードポイントに直接マップされます。この範囲の1バイトは、ASCIIの場合と同様に、文字を表します。さらに、7ビットバイト(最上位ビットが0のバイト)がマルチバイトシーケンスに現れることはなく、有効なマルチバイトシーケンスがASCIIコードポイントにデコードされることはありません。7ビットバイトのシーケンスは、有効なASCIIと有効なUTF-8の両方であり、どちらの解釈でも同じ文字シーケンスを表します。したがって、UTF-8ストリームの7ビットバイトは、ストリーム内のすべてのASCII文字のみを表します。したがって、多くのテキストプロセッサ、パーサー、プロトコル、ファイル形式、テキスト表示プログラムなど、フォーマットと制御の目的でASCII文字を使用するものは、マルチバイトシーケンスをデコードせずに、UTF-8バイトストリームをシングルバイト文字のシーケンスとして処理することにより、意図したとおりに機能し続けます。句読点、空白、制御文字などの処理が行われるASCII文字は、マルチバイトシーケンスとしてエンコードされることはありません。したがって、そのようなプロセッサは、マルチバイトシーケンスをデコードせずに、単に無視またはパススルーすることが安全です。たとえば、ASCII空白は次の目的で使用できます。制御文字がマルチバイトシーケンスとしてエンコードされることはありません。したがって、そのようなプロセッサは、マルチバイトシーケンスをデコードせずに、単に無視またはパススルーすることが安全です。たとえば、ASCII空白は次の目的で使用できます。制御文字がマルチバイトシーケンスとしてエンコードされることはありません。したがって、そのようなプロセッサは、マルチバイトシーケンスをデコードせずに、単に無視またはパススルーすることが安全です。たとえば、ASCII空白は次の目的で使用できます。UTF-8ストリームを単語にトークン化します。ASCII改行を使用して、UTF-8ストリームを行に分割できます。また、ASCII NUL文字を使用して、UTF-8でエンコードされたデータをヌル文字で終了する文字列に分割できます。同様に、「printf」などのライブラリ関数で使用される多くのフォーマット文字列は、UTF-8でエンコードされた入力引数を正しく処理します。
  • フォールバックと自動検出:有効なUTF-8文字列は可能なバイト文字列のごく一部のみです。バイトC0、C1、およびF5からFFは表示できず、上位ビットが設定されたバイトはペアである必要があります。その他の要件。拡張ASCIIで読み取り可能なテキストが有効なUTF-8である可能性はほとんどありません。UTF-8の人気の一部は、これらにも下位互換性の形式を提供することによるものです。したがって、拡張ASCIIを入力として誤って受信するUTF-8プロセッサは、これを非常に高い信頼性で「自動検出」できます。フォールバックエラーはフォールスネガティブになり、これらはまれになります。さらに、テキストディスプレイなどの多くのアプリケーションでは、誤ったフォールバックの結果は通常わずかです。独自の研究?]UTF-8ストリームには単にエラーが含まれている可能性があり、その結果、自動検出スキームが誤検知を生成します。ただし、自動検出はほとんどの場合、特に長いテキストで成功し、広く使用されています。また、UTF-8のエラーが検出された場合にのみ、レガシーエンコーディングの適切なコードポイントを使用して8ビットバイトを「フォールバック」または置換するように機能し、UTF-8とレガシーエンコーディングが同じものに連結されている場合でもリカバリできます。ファイル。
  • プレフィックスコード最初のバイトは、シーケンスのバイト数を示します。ストリームからの読み取りは、最初に次のシーケンスの最初のバイトまたはストリームの終わりの表示のいずれかを待つ必要なしに、完全に受信された個々のシーケンスを瞬時にデコードできます。マルチバイトシーケンスの長さは、先頭のバイトの上位1の数であるため、人間が簡単に決定できます。ストリームがシーケンスの途中で終了した場合、誤った文字はデコードされません。
  • 自己同期先行バイトと継続バイトは値を共有しません(継続バイトはビット10で始まり、単一バイトは0で始まり、長い先行バイトは11で始まります)。これは、検索によって、ある文字のシーケンスが別の文字の途中から始まることを誤って見つけないことを意味します。また、最大3バイトをバックアップして先頭のバイトを見つけることにより、ランダムな位置から文字の先頭を見つけることができることも意味します。ストリームがシーケンスの途中で開始された場合、誤った文字はデコードされず、短いシーケンスが長いシーケンスの中に表示されることはありません。
  • 並べ替え順序:先頭のバイトの選択された値は、対応するバイトシーケンスを並べ替えることにより、UTF-8文字列のリストをコードポイントの順序で並べ替えることができることを意味します。

シングルバイト

  • UTF-8は、任意のUnicode文字をエンコードできるため、「コードページ」を見つけて設定したり、使用中の文字セットを示したりする必要がなく、同時に複数のスクリプトで出力できます。多くのスクリプトでは、複数のシングルバイトエンコーディングが使用されているため、スクリプトを知っていても、正しく表示するには情報が不十分でした。
  • バイト0xFEおよび0xFFは表示されないため、有効なUTF-8ストリームがUTF-16バイトオーダーマークと一致することはなく、それと混同することはできません。0xFF(0377)がないため、 Telnet(およびFTP制御接続)でこのバイトをエスケープする必要もありません。
  • UTF-8でエンコードされたテキストは、プレーンASCII文字を除いて、特殊なシングルバイトエンコーディングよりも大きくなります。上半分に非ラテン文字がエンコードされた8ビット文字セットを使用したスクリプト(ほとんどのキリル文字ギリシャ文字のアルファベットコードページなど)の場合、UTF-8の文字は2倍のサイズになります。タイ語デーバナーガリー語(さまざまな南アジア言語で使用されている)などの一部のスクリプトでは、文字のサイズが3倍になります。Unicodeでは1バイトが複合文字になり、UTF-8では6倍になる例もあります。これは、インドや他の国々で異議を唱えています。
  • UTF-8(またはその他の可変長エンコーディング)では、文字の途中で文字列を分割または切り捨てることができます。2つの部分が文字として解釈される前に後で再追加されない場合、前のセクションの終わりと次のセクションの始まりの両方で無効なシーケンスが導入される可能性があり、一部のデコーダーはこれらのバイトを保持せず、データが失われます。UTF-8は自己同期しているため、これによって別の有効な文字が導入されることはありません。また、切り捨てポイントを文字の先頭に戻すのもかなり簡単です。
  • コードポイントがすべて同じサイズであれば、それらの固定数の測定は簡単です。「文字」が「バイト」の同義語として使用されているASCII時代のドキュメントのため、これはしばしば重要であると考えられています。ただし、「文字」の代わりにバイトを使用して文字列の位置を測定することにより、ほとんどのアルゴリズムをUTF-8に簡単かつ効率的に適合させることができます。長い文字列内の文字列の検索は、たとえばバイトごとに実行できます。自己同期プロパティは誤検知を防ぎます。

その他のマルチバイト

  • UTF-8は、任意のUnicode文字をエンコードできます。正しいコードページやフォントを選択しなくても、さまざまなスクリプトのファイルを正しく表示できます。たとえば、中国語とアラビア語は、エンコーディングを指定する特別なマークアップや手動設定なしで同じファイルに書き込むことができます。
  • UTF-8は自己同期型です。文字の境界は、どちらの方向でも明確に定義されたビットパターンをスキャンすることで簡単に識別できます。エラーまたは破損のためにバイトが失われた場合、いつでも次の有効な文字を見つけて処理を再開できます。指定されたフィールドに合うように文字列を短縮する必要がある場合は、前の有効な文字を簡単に見つけることができます。Shift JISなどの多くのマルチバイトエンコーディングは、再同期がはるかに困難です。これは、バイト指向の 文字列検索アルゴリズムも意味しますUTF-8で使用でき(文字はその数のバイトで構成される「単語」と同じであるため)、ハードウェアサポートと256エントリしかないルックアップテーブルにより、バイト検索の最適化バージョンをはるかに高速化できます。ただし、自己同期では、バイトごとにこれらのマーカー用にビットを予約する必要があり、サイズが大きくなります。
  • 単純なビット演算を使用してエンコードするのに効率的です。UTF-8は、乗算や除算などの低速の数学演算を必要としません(Shift JISGB 2312およびその他のエンコーディングとは異なります)。
  • UTF-8は、特定のスクリプト用に設計されたマルチバイトエンコーディングよりも多くのスペースを必要とします。東アジアのレガシーエンコーディングは、一般的に1文字あたり2バイトを使用していましたが、UTF-8では1文字あたり3バイトを使用していました。

UTF-16

  • バイトエンコーディングとUTF-8は、プログラムではバイト配列で表され、ソースコードをバイトエンコーディングからUTF-8に変換するときに、関数に対して何もする必要がないことがよくあります。UTF-16は16ビットワード配列で表され、既存のASCIIベースのプログラム(Windowsで行われたものなど)との互換性を維持しながらUTF-16に変換するには、文字列を複製するためのすべてのAPIとデータ構造が必要です。バイト文字列を受け入れるバージョンとUTF-16を受け入れる別のバージョン。下位互換性が必要ない場合でも、すべての文字列処理を変更する必要があります。
  • U + 0080の下にU + 0800..U + FFFFの範囲よりも多くのコードポイントがある場合、UTF-8でエンコードされたテキストはUTF-16でエンコードされた同じテキストよりも小さくなります。これは、現代のすべてのヨーロッパ言語に当てはまります。一般的なファイルにはスペース、改行、数字、HTMLマークアップが多数含まれているため、中国語などの言語でも当てはまることがよくあります。
  • ほとんどの通信(HTMLやIPなど)とストレージ(Unixなど)は、バイトストリーム用に設計されています。UTF-16文字列は、コード単位ごとに1組のバイトを使用する必要があります。
    • これらの2バイトの順序が問題になるため、バイト順序マークなどを使用してUTF-16プロトコルで指定する必要があります
    • UTF-16から奇数バイトが欠落している場合、文字列の残りの部分全体が無意味なテキストになります。UTF-8から欠落しているバイトがある場合でも、欠落しているバイトの次の文字からテキストを正確に復元できます。

派生物

次の実装は、UTF-8仕様とのわずかな違いを示しています。これらはUTF-8仕様と互換性がなく、UTF-8アプリケーションに準拠することで拒否される可能性があります。

CESU-8

Unicodeテクニカルレポート#26 [72]は、CESU-8という名前をUTF-8の非標準バリアントに割り当てます。このバリアントでは、補足プレーンのUnicode文字は、UTF-8で必要な4バイトではなく、6バイトを使用してエンコードされます。CESU-8エンコーディングは、4バイトのUTF-16サロゲートペアの各半分を2バイトのUCS-2文字として扱い、元の補助文字を一緒に表す2つの3バイトのUTF-8文字を生成します。基本多言語面内のUnicode文字は、UTF-8で通常表示されるように表示されます。このレポートは、ユニコードコンソーシアムにもかかわらず、CESU-8としてエンコードされたデータの存在を認めて形式化するために作成されました。その使用を思いとどまらせ、CESU-8エンコーディングの考えられる意図的な理由はUTF-16バイナリ照合の保存であることに注意してください。

CESU-8エンコーディングは、UCS-2データを想定する変換方法を使用して、補足文字を含むUTF-16データをUTF-8に変換することで発生する可能性があります。つまり、4バイトのUTF-16補足文字を認識しません。これは主に、 MicrosoftWindowsなどの内部でUTF-16を広範囲に使用するオペレーティングシステムの問題です。[要出典]

Oracle DatabaseではUTF8文字セットはCESU-8エンコーディングを使用するため、非推奨になりました。AL32UTF8文字セットは標準に準拠したUTF-8エンコーディングを使用しており、推奨されます[73] [74]

CESU-8は、HTML5ドキュメントでの使用が禁止されています。[75] [76] [77]

MySQL utf8mb3

MySQLではutf8mb3文字セットは、文字あたり最大3バイトのUTF-8エンコードデータとして定義されています。つまり、基本多言語面(つまり、UCS-2から)のUnicode文字のみがサポートされます。補助平面のUnicode文字は明示的にサポートされていません。標準に準拠したUTF-8エンコーディングを使用utf8mb3する文字セットを優先して非推奨になりました。はのエイリアスですが、MySQLの将来のリリースでのエイリアスになることを目的としています。[78]サポートされていませんが、 UCS-2であるかのように補足文字を含むUTF-16データを処理することにより、 CESU-8でエンコードされたデータをに格納することができます。utf8mb4utf8utf8mb3utf8mb4utf8mb3

変更されたUTF-8

変更されたUTF-8(MUTF-8)は、Javaプログラミング言語で作成されました。変更されたUTF-8では、ヌル文字(U + 0000)は、 00000000(16進数の00 )ではなく、2バイトの長すぎるエンコード110 00000 10 000000(16進数のC0 80 )を使用します。[79]変更されたUTF-8文字列には、実際のnullバイトは含まれませんが、U + 0000を含むすべてのUnicodeコードポイントを含めることができます[80]。これにより、このような文字列(nullバイトが追加された)を従来のnullで終了する文字列で処理できます 関数。既知のすべてのModifiedUTF-8実装も、CESU-8のようにサロゲートペアを扱います。

InputStreamReader通常の使用法では、言語は、およびを介して文字列を読み書きするときに標準のUTF-8をサポートしますOutputStreamWriter(プラットフォームのデフォルトの文字セットである場合、またはプログラムの要求に応じて)。ただし、オブジェクトのシリアル化[ 81]DataInputJava Native Interface [82]、およびクラスファイルへの定数文字列の埋め込みにはModifiedUTF-8を使用しDataOutputます[83]

Dalvikによって定義されたdex形式も、同じ変更されたUTF-8を使用して文字列値を表します。[84] Tclも、Unicodeデータの内部表現にJavaと同じ変更されたUTF-8 [85]を使用しますが、外部データには厳密なCESU-8を使用します。

WTF-8

WTF-8(Wobbly Transformation Format、8ビット)では、になっていない代理の半分(U + D800からU + DFFF)が許可されます。[86]これは、Windowsファイル名などの無効な可能性のあるUTF-16を格納するために必要です。UTF-8を処理する多くのシステムは、より単純であるため、別のエンコーディングとは見なさずにこのように機能します。[87]

(「WTF-8」という用語は、誤って二重にエンコードされたUTF-8 [88] [89]を指すためにもユーモラスに使用されており、 CP1252バイトだけがエンコードされていることを意味する場合があります。) [90]

PEP 383

Pythonプログラミング言語のバージョン3は、無効なUTF-8バイトストリームの各バイトをエラーとして扱います(Python 3.7 [91]の新しいUTF-8モードでの変更も参照してください)。これにより、128の異なるエラーが発生する可能性があります。128の可能なエラーバイトを予約済みのコードポイントに変換し、それらのコードポイントをエラーに戻すことにより、UTF-8と見なされるバイトシーケンスを損失なくUTF-16またはUTF-32に変換できるようにする拡張機能が作成されました。 UTF-8を出力するバイト。最も一般的なアプローチは、コードをU + DC80 ... U + DCFFに変換することです。これは、PythonのPEP 383(または「surrogateescape」)で使用されるように、低い(末尾の)代理値であり、したがって「無効な」UTF-16です。アプローチ。[92] MirBSDと呼ばれる別のエンコーディングOPTU-8 / 16は、私用面でそれらをU + EF80 ... U + EFFFに変換します[93]どちらのアプローチでも、バイト値は出力コードポイントの下位8ビットにエンコードされます。

これらのエンコーディングは、「無効な」バイト文字列を処理する必要がないため、非常に便利です。また、「テキスト」と「データ」のバイト配列を同じオブジェクトにすることができます。プログラムがUTF-16を内部で使用する場合、無効なUTF-8を使用できるファイル名を保持および使用するためにこれらが必要です。[94] WindowsファイルシステムAPIはUTF-16を使用するため、無効なUTF-8をサポートする必要性は少なくなります。[92]

エンコーディングをリバーシブルにするには、誤ったバイトに使用されるコードポイントの標準UTF-8エンコーディングを無効と見なす必要があります。これにより、エンコーディングはWTF-8またはCESU-8と互換性がなくなります(ただし、128コードポイントの場合のみ)。再エンコードするときは、有効なUTF-8に変換されるエラーコードポイントのシーケンスに注意する必要があります。これは、ASCII文字を生成できないため、悪意のあるソフトウェアによって出力に予期しない文字を取得するために使用される可能性があります。悪意のあるシーケンス(クロスサイトスクリプトなど)は通常ASCII文字に依存しているため、比較的安全です。[94]

も参照してください

メモ

  1. ^ 17プレーン×プレーンあたり2 16コードポイント、マイナス211技術的に無効なサロゲート
  2. ^ 以前のRFC2279では、コードポイントU + 7FFFFFFを介したUTF-8エンコードが許可されていました。ただし、現在のRFC3629§3では、UTF-16の制限に一致するように、コードポイントU + 10FFFFを介したUTF-8エンコーディングが制限されています。
  3. ^ 一部の複雑な絵文字は、これよりも多くかかる場合があります。5つのコードポイントシーケンスU + 1F3F3 U + FE0F U + 200D U + 26A7 U + FE0Fで構成されるトランスジェンダーフラッグ絵文字(🏳️‍⚧️)は、エンコードに16バイトを必要としますが、スコットランドのフラグ(🏴ꠁ ②)は、7つのコードポイントシーケンスU + 1F3F4 U + E0067 U + E0062 U + E0073 U + E0063 U + E0074 U + E007Fに対して合計28バイトを必要とします。
  4. ^ たとえば、セル9Dは+ 1Dを示します。2進数の16進数9Dは10011101であり、上位2ビット( 10)はこれを継続バイトとしてマークするために予約されているため、残りの6ビット( 011101)の16進値は1Dになります。

参考文献

  1. ^ 「第2章一般的な構造」Unicode標準(6.0版)。米国カリフォルニア州マウンテンビュー:ユニコードコンソーシアムISBN 978-1-936213-01-6
  2. ^ a b パイク、ロブ(2003年4月30日)。「UTF-8の歴史」
  3. ^ パイク、ロブ; トンプソン、ケン(1993)。「HelloWorldまたはΚαλημέρακόσμεまたはこんにちは世界」(PDF)1993年冬のUSENIX会議の議事録
  4. ^ ab 「ランキング別に分類された文字エンコードの使用状況調査w3techs.com 2022-02-20を取得
  5. ^ a b "文字セット"Internet Assigned NumbersAuthority2013-01-23 2013年2月8日取得
  6. ^ デュルスト、マーティン。「HTTP文字セットパラメータの設定」W3C 2013年2月8日取得
  7. ^ a b Yergeau、F。(2003)。UTF-8、ISO10646の変換形式インターネットエンジニアリングタスクフォース土井10.17487 / RFC3629RFC3629 _ 2015年2月3日取得
  8. ^ 「エンコーディング標準§4.2。名前とラベル」WHATWG 2018年4月29日取得
  9. ^ 「BOM」suikawik​​i(日本語)2013年4月26日取得
  10. ^ デイビス、マーク「Unicodeの形式」IBM2005年5月6日にオリジナルからアーカイブされまし2013年9月18日取得
  11. ^ Liviu(2014-02-07)。「Windows7のUTF-8コードページ65001-パートI」2018年1月30日取得以前はXP(および未確認ですがおそらくVistaも)では、コードページ65001がアクティブな間はforループが機能しませんでした
  12. ^ Srinivasan、Ramesh(2021年5月23日)。「メモ帳でデフォルトの文字エンコードを変更する方法」Winhelponlineブログ2021-10-20を取得
  13. ^ キム・ドアン(2020年12月2日)。「ファイルを保存するときに新しいメモ帳ドキュメントのデフォルトのUTF-8エンコーディングを設定する方法」KimConnect.com 2021-10-20を取得
  14. ^ 「HPPCLシンボルセット|プリンター制御言語(PCL&PXL)サポートブログ」2015-02-19。2015-02-19にオリジナルからアーカイブされました2018年1月30日取得
  15. ^ アレン、ジュリーD。; アンダーソン、デボラ; ベッカー、ジョー; クック、リチャード、編。(2012)。「Unicode標準、バージョン6.1」。カリフォルニア州マウンテンビュー:ユニコードコンソーシアム。 {{cite journal}}引用ジャーナルには|journal=ヘルプ)が必要です
  16. ^ 「AppleDeveloperDocumentation」developer.apple.com 2021-03-15を取得
  17. ^ "BinaryString(flink 1.9-SNAPSHOT API)"ci.apache.org 2021-03-24を取得
  18. ^ 「第3章」(PDF)Unicode標準、p。54
  19. ^ 「第3章」(PDF)Unicode標準、p。55
  20. ^ 「第3章」(PDF)Unicode標準、p。55
  21. ^ Yergeau、F。(2003年11月)。UTF-8、ISO10646の変換形式IETF土井10.17487 / RFC3629STD63。RFC3629 _ _ 2020年8月20日取得
  22. ^ 「第3章」(PDF)Unicode標準、p。54
  23. ^ Yergeau、F。(2003年11月)。UTF-8、ISO10646の変換形式IETF土井10.17487 / RFC3629STD63。RFC3629 _ _ 2020年8月20日取得
  24. ^ 「第3章」(PDF)Unicode標準、p。55
  25. ^ マリン、マーヴィン(2000-10-17)。「WebサーバーフォルダトラバーサルMS00-078」
  26. ^ 「CVE-2008-2938の概要」National VulnerabilityDatabase
  27. ^ "PEP529-WindowsファイルシステムのエンコーディングをUTF-8に変更"Python.org 2021年8月27日取得このPEPは、Windowsのデフォルトのファイルシステムエンコーディングをutf-8に変更し、ファイルシステムパスにUnicodeAPIを使用するようにすべてのファイルシステム関数を変更することを提案しています。[..]は、パスで使用されるすべての文字を正しくラウンドトリップできます(POSIXではsurrogateescapeを処理します。Windowsでは、strはネイティブ表現にマップされるため)。Windowsでは、バイトはパスで使用されるすべての文字をラウンドトリップできません
  28. ^ "DataInput(Java Platform SE 8)"docs.oracle.com 2021-03-24を取得
  29. ^ 「システム文字インターフェースのデコード不可能なバイト」python.org2009-04-22 2014年8月13日取得
  30. ^ 「Unicode6.0.0」
  31. ^ 128 1バイト、(16 + 5)×64 2バイト、および5×64×643バイト。継続バイトごとに、より正確なテストを実行すると、多少少なくなる可能性があります。
  32. ^ 「第2章」(PDF)Unicode標準、p。30
  33. ^ デイビス、マーク(2012-02-03)。「Webの60%以上をUnicode」公式Googleブログ2018-08-09にオリジナルからアーカイブされました2020年7月24日取得
  34. ^ ブレイ、ティム(2017年12月)。「JavaScriptオブジェクト表記(JSON)データ交換フォーマット」IETF 2018年2月16日取得 {{cite journal}}引用ジャーナルには|journal=ヘルプ)が必要です
  35. ^ 「エンコーディング標準」encoding.spec.whatwg.org 2020年4月15日取得
  36. ^ 「世界のキャラクターのインターネットメールの使用」Washingtonindependent.com。1998-08-01 2007年11月8日取得
  37. ^ 「エンコーディング標準」encoding.spec.whatwg.org 2018年11月15日取得
  38. ^ 「ドキュメントの文字エンコードの指定」HTML5.2World WideWebコンソーシアム2017年12月14日2018年6月3日取得
  39. ^ 「ファイルを開いて保存するときにテキストエンコーディングを選択してください」support.microsoft.com 2021-11-01を取得
  40. ^ 「utf8-MicrosoftWord DOCおよびDOCXファイルの文字エンコード?」スタックオーバーフロー2021-11-01を取得
  41. ^ 「WordからのUTF-8.txtファイルのエクスポート」{{cite web}}:CS1 maint:url-status(link
  42. ^ 「Excel-XLSXファイルは定義によってUTF-8でエンコードされていますか?」スタックオーバーフロー2021-11-01を取得
  43. ^ 「MacとWindowsの両方で日本語と中国語の文字を誤って変換せずにExcelでUTF-8CSVファイルを開く方法は?」Answers.microsoft.com 2021-11-01を取得
  44. ^ 「SQLServerのUTF-8サポートの紹介」techcommunity.microsoft.com2019-07-02 2021年8月24日取得たとえば、UTF-8対応の照合を使用して既存の列データ型をNCHAR(10)からCHAR(10)に変更すると、ストレージ要件がほぼ50%削減されます。[..] ASCII範囲では、UTF-8で集中的な読み取り/書き込みI / Oを実行すると、文字列列に非クラスター化インデックスを持つクラスター化テーブルを使用して、UTF-16と比較して平均35%のパフォーマンス向上が測定されました。ヒープを使用したUTF-16と比較して平均11%のパフォーマンスの向上。
  45. ^ デイビス、マーク(2008-05-05)。「Unicode5.1への移行」2021-02-19を取得
  46. ^ 「ウェブサイトのためのUS-ASCIIの使用統計および市場占有率、2021年10月」w3techs.com 2020年11月1日取得
  47. ^ 「メモ帳を作成してBOMなしでUTF-8にテキストを保存するにはどうすればよいですか?」スタックオーバーフロー2021-03-24を取得
  48. ^ ギャロウェー、マット。「iOS開発者向けの文字エンコード。それともUTF-8は今何?」www.galloway.me.uk 2021-01-02を取得実際には、UTF-8が最も一般的なエンコーディングであるため、通常はUTF-8を想定しています。
  49. ^ 「Windows10のメモ帳はより良いUTF-8エンコーディングサポートを取得しています」BleepingComputer 2021-03-24を取得Microsoftは現在、以下に示すように、デフォルトで新しいテキストファイルをBOMなしのUTF-8として保存しています。
  50. ^ 「Windows11のスタートメニューをカスタマイズする」docs.microsoft.com 2021-06-29を取得LayoutModification.jsonがUTF-8エンコーディングを使用していることを確認してください。
  51. ^ 「JEP400:デフォルトではUTF-8」openjdk.java.net 2021年8月24日取得
  52. ^ "PEP597-オプションのEncodingWarningを追加"Python.org 2021年8月24日取得
  53. ^ WindowsではPython2および初期の3バージョン、UnixではUTF-32を使用していました。新しいPython3実装では、必要な最大コードポイントに応じて、 ISO-8859-1、UCS-2、およびUTF-32の3つすべてを使用します。
  54. ^ 「Goプログラミング言語仕様」2021-02-10を取得
  55. ^ Tsai、MichaelJ。「MichaelTsai-ブログ-Swift5のUTF-8文字列」2021-03-15を取得UTF-8に切り替えることで、高性能処理を可能にするというStringの長期目標の1つが達成されます。また、[..]は、将来さらに高性能なAPIを提供するための基礎を築きます。
  56. ^ Mattip(2019-03-24)。「PyPyステータスブログ:PyPyv7.1がリリースされました。Unicode文字列に内部的にutf-8を使用するようになりました」PyPyステータスブログ2020年11月21日取得
  57. ^ "PEP623--Unicodeからwstrを削除"Python.org 2020年11月21日取得従来のUnicodeオブジェクトを削除するまで、PyPyでのUTF-8ベースの実装のような他のUnicode実装を試すことは非常に困難です。
  58. ^ "/ validate-charset(互換性のある文字を検証します)"docs.microsoft.com 2021年7月19日取得Visual Studioは、ソース文字セットと実行文字セットの間の変換中に、内部文字エンコードとしてUTF-8を使用します。
  59. ^ "/ utf-8(ソースおよび実行可能文字セットをUTF-8に設定)"docs.microsoft.com 2021年7月18日取得
  60. ^ "C ++ 11にstd :: u8stringがありません"NewbeDEV 2021-11-01を取得
  61. ^ 「WindowsUTF-8コードページを使用する-UWPアプリケーション」docs.microsoft.com 2020年6月6日取得Windowsバージョン1903(2019年5月の更新)以降、パッケージ化されたアプリの場合はappxmanifestのActiveCodePageプロパティを使用し、パッケージ化されていないアプリの場合はフュージョンマニフェストを使用して、プロセスにUTF-8をプロセスコードページとして使用するように強制できます。[..]は、Windowsバージョン1903(2019年5月の更新)以降で実行されており、上記のActiveCodePageプロパティがUTF-8に設定されている場合にのみ相当します。それ以外の場合は、レガシーシステムコードページを尊重します。明示的に使用することをお勧めします。CP_ACPCP_UTF8CP_UTF8
  62. ^ 「付録F.FSS-UTF /ファイルシステムセーフUCS変換フォーマット」(PDF)Unicode標準1.12016年6月7日のオリジナルからアーカイブ(PDF)2016年6月7日取得
  63. ^ ウィスラー、ケネス(2001-06-12)。「FSS-UTF、UTF-2、UTF-8、およびUTF-16」2016年6月7日にオリジナルからアーカイブされました2006年6月7日取得
  64. ^ a b パイク、ロブ(2003-04-30)。「UTF-8の歴史」2012年9月7日取得
  65. ^ パイク、ロブ(2012-09-06)。「UTF-8は昨日20歳になりました」2012年9月7日取得
  66. ^ Alvestrand、Harald(1998年1月)。文字セットと言語に関するIETFポリシー土井10.17487 / RFC2277BCP18。
  67. ^ ISO / IEC 10646:2014§9.1、2014
  68. ^ Unicode標準、バージョン 11.0§3.9D92、§3.10D95、2018
  69. ^ Unicode標準付属書#27:Unicode 3.1、2001
  70. ^ Unicode標準、バージョン 5.0§3.9–§3.10ch。3、2006
  71. ^ Unicode標準、バージョン 6.0§3.9D92、§3.10D95、2010
  72. ^ McGowan、Rick(2011-12-19)。「UTF-16の互換性エンコーディングスキーム:8ビット(CESU-8)」ユニコードコンソーシアムUnicodeテクニカルレポート#26。
  73. ^ 「文字セットのサポート」Oracle Database 19cのドキュメント、SQL言語リファレンスOracleCorporation
  74. ^ 「Unicodeによる多言語データベースのサポート§OracleデータベースでのUnicode標準のサポート」データベースグローバリゼーションサポートガイドOracleCorporation
  75. ^ 「8.2.2.3。文字エンコード」HTML5.1標準W3C
  76. ^ 「8.2.2.3。文字エンコード」HTML5標準W3C
  77. ^ 「12.2.3.3文字エンコーディング」HTML生活水準WHATWG
  78. ^ 「utf8mb3文字セット(3バイトUTF-8 Unicodeエンコーディング)」MySQL8.0リファレンスマニュアルOracleCorporation
  79. ^ 「インタフェースjava.io.DataInputのJavaSEドキュメント、変更されたUTF-8のサブセクション」OracleCorporation2015 2015年10月16日取得
  80. ^ 「Java仮想マシン仕様、セクション4.4.7:「CONSTANT_Utf8_info構造」" 。OracleCorporation。20152015年10月16日取得
  81. ^ 「Javaオブジェクトシリアル化仕様、第6章:オブジェクトシリアル化ストリームプロトコル、セクション2:ストリーム要素」OracleCorporation2010 2015年10月16日取得
  82. ^ 「JavaNativeInterface仕様、第3章:JNIタイプとデータ構造、セクション:変更されたUTF-8文字列」OracleCorporation2015 2015年10月16日取得
  83. ^ 「Java仮想マシン仕様、セクション4.4.7:「CONSTANT_Utf8_info構造」" 。OracleCorporation。20152015年10月16日取得
  84. ^ 「ARTとDalvik」Android Open SourceProject2013年4月26日にオリジナルからアーカイブされました2013年4月9日取得
  85. ^ 「TclerのWiki:UTF-8ビットごと(リビジョン6)」2009-04-25 2009年5月22日取得
  86. ^ Sapin、Simon(2016-03-11)[2014-09-25]。「WTF-8エンコーディング」2016年5月24日にオリジナルからアーカイブされました2016年5月24日取得
  87. ^ Sapin、Simon(2015-03-25)[2014-09-25]。「WTF-8エンコーディング§モチベーション」2016年5月24日にオリジナルからアーカイブされました2020年8月26日取得
  88. ^ 「WTF-8.com」2006-05-18 2016年6月21日取得
  89. ^ Speer、Robyn(2015-05-21)。"ftfy(テキストを修正します)4.0:変更を減らして修正を増やします"2015年5月30日にオリジナルからアーカイブされました2016年6月21日取得
  90. ^ 「WTF-8、コードページ1252の変換形式」2016-10-13にオリジナルからアーカイブされました2016年10月12日取得
  91. ^ 「PEP540-新しいUTF-8モードを追加」Python.org 2021-03-24を取得
  92. ^ abvonLöwis Martin(2009-04-22)。「システム文字インターフェイスのデコード不可能なバイト」Python SoftwareFoundationPEP383。
  93. ^ 「RTFMoptu8to16(3)、optu8to16vis(3)」www.mirbsd.org
  94. ^ a b デイビス、マーク; Suignard、Michel(2014)。「3.7ロスレス変換の有効化」Unicodeのセキュリティに関する考慮事項Unicodeテクニカルレポート#36。

外部リンク