UTF-16

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ
UTF-16
Unifont Full Map.png
最初の216のUnicodeコードポイント。下部にある灰色のストライプは、UTF-16で使用される代理の半分です(ストライプの下の白い領域は私用領域です
言語国際的
標準Unicode標準
分類Unicode変換形式可変幅エンコーディング
延長UCS-2
変換/エンコードISO 10646Unicode

UTF-1616ビット Unicode変換形式)は、 Unicodeの1,112,064個の有効な文字コードポイントすべてをエンコードできる文字エンコードです(実際、このコードポイントの数はUTF-16の設計によって決定されます)。コードポイントは1つまたは2つの16ビットコードユニットでエンコードされるため、エンコードは可変長ですUTF-16は、2 16(65,536)を超えるコードポイントが必要であることが明らかになった後、現在はUCS-2 (2バイトのユニバーサル文字セット用)として知られている、以前の廃止された固定幅16ビットエンコーディングから生まれました。[1]

UTF-16は、Microsoft Windows API、Javaプログラミング言語JavaScript / ECMAScriptなどのシステムで使用されます。また、MicrosoftWindowsのプレーンテキストおよびワードプロセッシングデータファイルにも使用されることがあります。Unixライクなシステムのファイルに使用されることはめったにありません2019年5月以降、MicrosoftはUTF-8(およびUTF-16)のサポートを開始し、その使用を奨励しています。[2]

UTF-16は、 ASCII [3]と互換性のない唯一のWebエンコーディングであり、Webページで0.002%未満(1%の1000分の1強)で使用されているWebで人気を博したことはありません。[4] 比較すると、 UTF-8はすべてのWebページの98%を占めています。[5] Webハイパーテキストアプリケーションテクノロジーワーキンググループ(WHATWG)は、UTF-8を「すべての[テキスト]の必須エンコーディング」と見なしており、セキュリティ上の理由から、ブラウザアプリケーションはUTF-16を使用しないでください。[6]

絵文字がサポートされている場合にSMSで使用されます。[要出典]

歴史

1980年代後半に、以前の言語固有のエンコーディングを1つの調整されたシステムに置き換える「ユニバーサル文字セット」( UCS )の統一エンコーディングの開発に着手しました。目標は、世界のほとんどの言語から必要なすべての文字と、科学、数学、音楽などの技術分野からの記号を含めることでした。元々のアイデアは、1文字あたり1バイトを必要とする一般的な256文字のエンコーディングを、1文字あたり2バイト(16ビット)を必要とする65,536(2 16)値を使用するエンコーディングに置き換えることでした。

ISO / IEC JTC 1 / SC 2ユニコードコンソーシアムの2つのグループが並行してこれに取り組みました。後者は、主にコンピューティング機器のメーカーを代表しています。2つのグループは、開発中のエンコーディングが相互に互換性を持つように、文字割り当てを同期しようとしました。初期の2バイトエンコーディングは元々「Unicode」と呼ばれていましたが、現在は「UCS-2」と呼ばれています。[7]

2つの16文字では不十分であることがますます明らかになると、 [1] IEEEは、より大きな31ビットスペースと、1文字あたり4バイトを必要とするエンコーディング( UCS-4 )を導入しました。これは、ユニコードコンソーシアムによって抵抗されました。これは、1文字あたり4バイトが大量のメモリとディスク領域を浪費し、一部のメーカーがすでに1文字あたり2バイトのテクノロジに多額の投資を行っているためです。UTF-16エンコーディングスキームは妥協案として開発され、1996年7月にUnicode標準のバージョン2.0で導入されました。[8]これは、2000年にIETFによって公開されたRFC2781で完全に指定されています[9] [10]

UTF-16エンコーディングでは、2 16未満のコードポイントは、古いUCS-2と同様に、コードポイントの数値に等しい単一の16ビットコードユニットでエンコードされます。2 16以上の新しいコードポイントは、 2つの16ビットコードユニットを使用する複合値によってエンコードされます。これらの2つの16ビットコードユニットは、以前は文字に割り当てられていなかったUTF-16サロゲート範囲 0xD800–0xDFFFから選択されます。この範囲の値は文字として使用されず、UTF-16はそれらを個々のコードポイントとしてコード化する合法的な方法を提供しません。したがって、UTF-16ストリームは、基本多言語面のコードポイントの代理範囲外にある単一の16ビットコードポイントで構成されます。(BMP)、およびBMPより上のコードポイントの代理範囲内の16ビット値のペア。

UTF-16は、国際規格ISO / IEC10646とUnicode規格の両方の最新バージョンで指定されています。「UCS-2は廃止されたと見なされるはずです。10646またはUnicode標準のエンコード形式を参照しなくなりました。」[11] UTF-16は、より多くのコードポイントをサポートしたり、サロゲートに置き換えられたコードポイントをサポートしたりするために拡張されることはありません。これは、一般的なカテゴリまたはサロゲートコードポイントに関するUnicode安定性ポリシーに違反するためです。[12] (自己同期コードのままのスキームでは、シーケンスを開始するために少なくとも1つのBMPコードポイントを割り当てる必要があります。コードポイントの目的を変更することは許可されていません。)

説明

各Unicodeコードポイントは、1つまたは2つの16ビットコードユニットとしてエンコードされます。これらの16ビットコードがバイトとしてどのように格納されるかは、テキストファイルまたは通信プロトコルの 「エンディアン」によって異なります。

「文字」は、記録するために2バイトから14 [13]またはそれ以上のバイトを必要とする場合があります。たとえば、絵文字フラグ文字は「Unicodeスカラー値のペアから構築される」[14]ため、8バイトかかります(これらの値はBMPの外部にあり、それぞれ4バイトが必要です)。

U +0000からU + D7FFおよびU + E000からU + FFFF

UTF-16とUCS-2はどちらも、この範囲のコードポイントを、対応するコードポイントと数値的に等しい単一の16ビットコードユニットとしてエンコードします。基本多言語面(BMP)のこれらのコードポイントは、UCS-2で表すことができる唯一のコードポイントです。[要出典] Unicode 9.0の時点で、ほとんどの絵文字と同様に、一部の現代の非ラテンアジア、中東、およびアフリカのスクリプトはこの範囲外です。

U +010000からU + 10FFFFまでのコードポイント

他のプレーン(補足プレーンと呼ばれる)からのコードポイントは、次のスキームによって、 サロゲートペアと呼ばれる2つの16ビットコードユニットとしてエンコードされます。

UTF-16デコーダー
低い
高い
DC00 DC01    ..。    DFFF
D800 010000 010001 ..。 0103FF
D801 010400 010401 ..。 0107FF
DBFF 10FC00 10FC01 ..。 10FFFF
  • 0x10000がコードポイント(U)から減算され、16進数の範囲0x00000–0xFFFFFに20ビットの数値(U ')が残ります。これらの目的のために、Uは0x10FFFF以下であると定義されていることに注意してください。
  • 上位10ビット(0x000〜0x3FFの範囲)が0xD800に追加され、最初の16ビットコードユニットまたは上位サロゲート (W1)が提供されます。これは、 0xD800〜0xDBFFの範囲になります。
  • 下位10ビット(これも0x000〜0x3FFの範囲)が0xDC00に追加され、2番目の16ビットコードユニットまたは下位サロゲート (W2)が提供されます。これは、 0xDC00〜0xDFFFの範囲になります。

視覚的に説明すると、W1W2の間のU 'の分布は次のようになります。[15]

U '= yyyyyyyyyyxxxxxxxxxx // U-0x10000
W1 = 110110yyyyyyyyyy // 0xD800 + yyyyyyyyyy
W2 = 110111xxxxxxxxxx // 0xDC00 + xxxxxxxxxx

高サロゲート低サロゲートは、それぞれ「先頭」と「末尾」のサロゲートとも呼ばれ、UTF-8の先頭バイトと末尾バイトに類似しています。[16]

高サロゲート0xD800–0xDBFF)、低サロゲート0xDC00–0xDFFF)、および有効なBMP文字(0x0000–0xD7FF、0xE000–0xFFFF)の範囲は互いに素あるため、サロゲートがBMP文字と一致することはできません。または、隣接する2つのコードユニットが正当な代理ペアのように見えるようにしますこれにより、検索が大幅に簡素化されます。また、UTF-16が16ビットワードで自己同期していることも意味します。コードユニットが文字を開始するかどうかは、以前のコードユニット(つまり、コードユニットのタイプ)を調べることなく判断できます。それが該当する値の範囲によって決定できます)。UTF-8はこれらの利点を共有しますが、以前の多くのマルチバイトエンコーディングスキーム(Shift JISやその他のアジアのマルチバイトエンコーディングなど)では、明確な検索ができず、文字列の先頭から再解析することによってのみ同期できました(UTF -16は、1バイトが失われた場合、またはトラバーサルがランダムなバイトで開始された場合、自己同期しません。

最も一般的に使用される文字はすべてBMPに含まれているため、サロゲートペアの処理は十分にテストされていないことがよくあります。これは、人気があり十分にレビューされたアプリケーションソフトウェア( CVE - 2008-2938、 CVE- 2012-2135など)でも、永続的なバグと潜在的なセキュリティホールにつながります。

補助平面には、絵文字歴史的スクリプトあまり使用されていない記号、あまり使用されていない中国の表意文字などが含まれます。エンコードされ、それぞれ216コードポイントの16平面に分割されます。個別に処理される基本多言語面を含めて、合計17面があります。

U + D800からU + DFFF

Unicode標準では、これらのコードポイント値が高サロゲートと低サロゲートのUTF-16エンコード用に永続的に予約されており、文字が割り当てられることはないため、エンコードする理由はありません。公式のUnicode標準では、UTF-16を含むUTFフォームはこれらのコードポイントをエンコードできないとされています。[要出典]

ただし、UCS-2、UTF-8、およびUTF-32は、これらのコードポイントを簡単で明白な方法でエンコードでき、大量のソフトウェアがエンコードますエンコーディングエラー。[要出典]

コードポイントと等しいコードユニットを使用することにより、UTF-16の形式で、対になっていないサロゲート(高いサロゲートコードポイントの後に低いサロゲートがない、または低いサロゲートコードポイントの前に高いサロゲートがない)を明確にエンコードできます。 結果は有効なUTF-16ではありませんが、UTF-16エンコーダーおよびデコーダーの実装の大部分は、エンコード間で変換するときにこれを実行します。[要出典] Windowsでは、ファイル名やその他の場所で対になっていないサロゲートを使用できます。[要出典]は、Unicode標準から除外されているにもかかわらず、ソフトウェアでサポートする必要があることを意味します。

U + 10437(𐐷)をUTF-16にエンコードするには:

  • コードポイントから0x10000を引き、0x0437を残します。
  • 高いサロゲートの場合は、右に10シフト(0x400で除算)してから0xD800を追加すると、0x0001 + 0xD800 = 0xD801になります。
  • 下位サロゲートの場合、下位10ビット(0x400で除算した余り)を取得し、0xDC00を追加すると、0x0037 + 0xDC00 = 0xDC37になります。

UTF-16からU + 10437(𐐷)をデコードするには:

  • 高いサロゲート(0xD801)を取り、0xD800を減算してから、0x400を乗算すると、0x0001×0x400 = 0x0400になります。
  • 低いサロゲート(0xDC37)を取り、0xDC00を引くと、0x37になります。
  • これらの2つの結果(0x0437)を合計し、最後に0x10000を追加して、最終的にデコードされたUTF-32コードポイント0x10437を取得します。

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

キャラクター バイナリコードポイント バイナリUTF-16 UTF-1616進
コード単位
UTF-16BEの
16進バイト
UTF-16LEの
16進バイト
$ U+0024 0000 0000 0010 0100 0000 0000 0010 0100 0024 00 24 24 00
€€ U+20AC 0010 0000 1010 1100 0010 0000 1010 1100 20AC 20 AC AC 20
𐐷 U+10437 0001 0000 0100 0011 0111 1101 1000 0000 0001 1101 1100 0011 0111 D801 DC37 D8 01 DC 37 01 D8 37 DC
𤭢 U+24B62 0010 0100 1011 0110 0010 1101 1000 0101 0010 1101 1111 0110 0010 D852 DF62 D8 52 DF 62 52 D8 62 DF

バイトオーダーエンコーディングスキーム

UTF-16およびUCS-2は、16ビットコードユニットのシーケンスを生成します。ほとんどの通信およびストレージプロトコルはバイトに対して定義されており、各ユニットは2つの8ビットバイトを使用するため、バイトの順序はコンピュータアーキテクチャのエンディアン(バイト順序)に 依存する場合があります。

コード単位のバイト順序の認識を支援するために、UTF-16では、値U + FEFFのコードポイントであるバイト順序マーク(BOM)を、最初の実際のコード値の前に置くことができます。[nb 1](U + FEFFは非表示のゼロ幅の改行なしスペース/ ZWNBSP文字です。)[nb 2]デコーダーのエンディアンアーキテクチャーがエンコーダーのエンディアンアーキテクチャーと一致する場合、デコーダーは0xFEFF値を検出しますが、その逆です。 -エンディアンデコーダーは、BOMをこの目的のために予約された文字以外の値U + FFFEとして解釈します。この誤った結果は、残りの値に対してバイトスワッピングを実行するためのヒントを提供します。

BOMが欠落している場合、RFC2781はビッグエンディアンエンコーディングを想定することを[nb3]推奨しています。実際には、Windowsはデフォルトでリトルエンディアンの順序を使用しているため、多くのアプリケーションはリトルエンディアンのエンコーディングを想定しています。U + 0100未満の文字が非常に一般的であると仮定して、ヌルバイトを探すことによってエンディアンを検出することも信頼できます。より多くの偶数バイト(0から始まる)がnullの場合、それはビッグエンディアンです。

この標準では、エンコードタイプとしてUTF -16BEまたはUTF-16LEを指定することにより、バイト順序を明示的に指定することもできます。このようにバイト順序が明示的に指定されている場合、BOMは特にテキストの前に付加されることは想定されておらず、先頭のU + FEFFはZWNBSP文字として処理される必要があります。このルールにもかかわらず、ほとんどのアプリケーションはすべての場合にBOMを無視します。

インターネットプロトコルの場合、IANAこれらのエンコーディングの名前として「UTF-16」、「UTF-16BE」、および「UTF-16LE」を承認しています(名前は大文字と小文字を区別しません)。エイリアスUTF_16またはUTF16は、一部のプログラミング言語またはソフトウェアアプリケーションでは意味がある場合がありますが、インターネットプロトコルの標準名ではありません。

同様の指定、UCS-2BEおよびUCS-2LEは、 UCS-2のバージョンを示すために使用されます

使用法

UTF-16は、Windows10を含む現在サポートされているすべてのバージョンのMicrosoftWindows(および少なくともWindows CE / 2000 / XP / 2003 / Vista / 7 [17]以降のすべてを含む)のOSAPIのテキストに使用されますWindows XPでは、ヨーロッパ言語用のWindowsで提供されるフォントには、U + FFFFを超えるコードポイントは含まれていません。[18] [19]古いWindowsNTシステム(Windows 2000より前)はUCS-2のみをサポートします。[20]ファイルとネットワークデータは、UTF-16、UTF-8、およびレガシーバイトエンコーディングが混在する傾向があります。

Windows XPでもUTF-8がサポートされていますが、[21] Windows 10 Insider Build 17035および2018年4月の更新改善されました(特にUTF-8を使用してファイルに名前を付ける機能) 。2019年5月の時点で、マイクロソフトはソフトウェアでUTF-16ではなくUTF-8を使用することを推奨しています。[2]

IBM iオペレーティング・システムは、UCS-2エンコード用にCCSID(コード・ページ)13488を指定 UTF - 16エンコード用にCCSID 1200を指定しますが、システムは両方をUTF-16として扱います。[22]

UTF-16は、QualcommBREWオペレーティングシステムで使用されます。.NET環境およびQtクロスプラットフォームのグラフィカルウィジェットツールキット

NokiaS60ハンドセットおよびSonyEricssonUIQハンドセットで使用されるSymbianOSは、 UCS-2を使用します。iPhoneハンドセットは、 3GPP TS 23.038GSM)およびIS-637(CDMA)規格で説明されているUCS-2ではなく、ショートメッセージサービスにUTF-16を使用します。[23]

CD-ROMメディアで使用されるJolietファイルシステムは、 UCS-2BEを使用してファイル名をエンコードします(ファイル名ごとに最大64のUnicode文字)。

Python言語環境は、バージョン2.0以降、公式には内部でのみUCS-2を使用しますが、「Unicode」へのUTF-8デコーダーは正しいUTF-16を生成します。Python 2.2以降、代わりにUTF-32を使用するUnicodeの「ワイド」ビルドがサポートされています。[24]これらは主にLinuxで使用されます。Python 3.3はUTF-16を使用しなくなりました。代わりに、指定された文字列に対して最もコンパクトな表現を提供するエンコーディングが、ASCII / Latin-1、UCS-2、およびUTF-32から選択されます。[25]

Javaは元々UCS-2を使用し、 J2SE5.0でUTF-16補足文字サポートを追加しました。

JavaScriptはUCS-2またはUTF-16を使用する場合があります。[26] ES2015の時点で、文字列メソッドと正規表現フラグが言語に追加され、エンコードに依存しない観点から文字列を処理できるようになりました。

多くの言語では、引用符で囲まれた文字列は、非BMP文字を引用符で囲むための新しい構文を必要とします。これは、Cスタイルの"\uXXXX"構文が明示的に4桁の16進数に制限されているためです。次の例は、非BMP文字「𝄞」(U + 1D11E、MUSICAL SYMBOL G CLEF)の構文を示しています。最も一般的な(C ++C#D、およびその他のいくつかの言語で使用される)のは、。などの8桁の16進数を含む大文字の「U」を使用すること"\U0001D11E"です。[27] Java 7正規表現、ICU、およびPerlでは、構文"\x{1D11E}"を使用する必要があります。同様に、ECMAScript 2015(JavaScript)では、エスケープ形式は"\u{1D11E}"です。他の多くの場合(正規表現以外のJavaなど)、[28]非BMP文字を取得する唯一の方法は、サロゲートの半分を個別に入力することです。たとえば"\uD834\uDD1E"、U + 1D11Eの場合です。

UTF-16に基づく文字列の実装では、通常、文字列の長さを定義し、コードポイントではなく、これらの16ビットコード単位でインデックスを作成できます。コードポイントもコードユニットも、エンドユーザーが「文字」として認識する可能性のあるものには対応していません。ユーザーが文字として識別するものは、一般に、ベースコードポイントと結合文字のシーケンスで構成されます(または、他の種類のコードポイントのシーケンス、たとえば、Hangul結合jamos)– Unicodeは、この構造を書記素と呼びます。 cluster [29]  –したがって、Unicode文字列を処理するアプリケーションは、エンコードに関係なく、文字列を任意に分割および結合する機能が制限されるという事実に対処する必要があります。

UCS-2は、 PHP言語[30]およびMySQLでもサポートされています[7]

Swift、バージョン5、Appleの優先アプリケーション言語は、優先エンコーディングとしてUTF-16からUTF-8に切り替えられました。[31]

も参照してください

メモ

  1. ^ UTF-8エンコーディングは、厳密に0xFE未満のバイト値を生成するため、BOMシーケンスのいずれかのバイトもエンコーディングをUTF-16として識別します(UTF-32が予期されていないことを前提としています)。
  2. ^ BOMとしてではなく文字ZWNBSPとしてのU + FEFFの使用は廃止され、U + 2060(WORD JOINER)が採用されました。unicode.orgのバイトオーダーマーク(BOM)FAQを参照してください。ただし、アプリケーションが最初のBOMを文字として解釈する場合、ZWNBSP文字は表示されないため、影響は最小限に抑えられます。
  3. ^ RFC 2781セクション4.3は、BOMがない場合、「テキストはビッグエンディアンであると解釈されるべきである」と述べています。セクション1.2によると、「SHOULD」という用語の意味はRFC2119に準拠してますその文書のセクション3には、「...特定の状況で特定の項目を無視する正当な理由が存在する可能性がありますが、別のコースを選択する前に、完全な影響を理解し、慎重に検討する必要があります」と記載されています。  

参考文献

  1. ^ a b 「UTF-16とは何ですか?」ユニコードコンソーシアムUnicode、Inc 2018年3月29日取得
  2. ^ a b "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
  3. ^ 「HTML生活水準」w3.org2020-06-10 2020年6月15日取得UTF-16エンコーディングは、この仕様がASCII互換のエンコーディングではないものとして扱う必要がある唯一のエンコーディングです。
  4. ^ 「ウェブサイトのためのUTF-16の使用統計、2021年6月」w3techs.com 2021-06-17を取得
  5. ^ 「ウェブサイトのためのUTF-8の使用統計、2021年11月」w3techs.com 2021-11-10を取得
  6. ^ 「エンコーディング標準」encoding.spec.whatwg.org 2018年10月22日取得UTF-8エンコーディングは、ユニバーサルコード化文字セットであるUnicodeの交換に最も適したエンコーディングです。したがって、新しいプロトコルとフォーマット、および新しいコンテキストでデプロイされた既存のフォーマットの場合、この仕様ではUTF-8エンコーディングが必要(および定義)されます。[..]ここで概説した問題は、UTF-8を排他的に使用すると解消されます。これは、UTF-8がWeb上のすべてのテキストに必須のエンコーディングである多くの理由の1つです。
  7. ^ a b "MySQL :: MySQL5.7リファレンスマニュアル:: 10.1.9.4 ucs2文字セット(UCS-2 Unicodeエンコーディング)"dev.mysql.com
  8. ^ 「フォームのエンコードに関する質問」2010年11月12日取得
  9. ^ ISO / IEC 10646:2014「情報技術–ユニバーサルコード化文字集合(UCS)」セクション9および10。
  10. ^ Unicode標準バージョン7.0(2014)セクション2.5。
  11. ^ 「Unicode®標準バージョン10.0–コア仕様。付録C ISO / IEC 10646との関係」(PDF)ユニコードコンソーシアム。 セクションC.2ページ913(pdfページ10)
  12. ^ 「Unicode文字エンコーディングの安定性ポリシー」unicode.org
  13. ^ 「 "🤦🏼‍♂️" .length == 7 "であることは間違いではありませんhsivonen.fi 2021-03-15を取得
  14. ^ 「AppleDeveloperDocumentation」developer.apple.com 2021-03-15を取得
  15. ^ Yergeau、Francois; ホフマン、ポール(2000年2月)。「UTF-16、ISO10646のエンコーディング」tools.ietf.org 2019年6月18日取得
  16. ^ アレン、ジュリーD。; アンダーソン、デボラ; ベッカー、ジョー; クック、リチャード、編。(2014)。「3.8代理人」(PDF)Unicode標準バージョン7.0-コア仕様マウンテンビュー:ユニコードコンソーシアムp。118 2014年11月3日取得
  17. ^ Unicode(Windows)取得2011-03-08「これらの関数は、WindowsオペレーティングシステムのネイティブUnicodeエンコーディングに使用されるUTF-16(ワイド文字)エンコーディング(…)を使用します。」
  18. ^ 「Unicode」microsoft.com 2009年7月20日取得
  19. ^ 「サロゲートと補足文字」microsoft.com 2009年7月20日取得
  20. ^ 「SQLServerへのUTF-8データの保存の説明」microsoft.com。2005年12月7日2008年2月1日取得
  21. ^ "[更新] cp65001用のWindowsXP用のcmd.exeのパッチ-ページ2-DosTips.com"www.dostips.com 2021-06-17を取得
  22. ^ 「UCS-2とそのUnicodeとの関係(UTF-16)」IBM 2019年4月26日取得
  23. ^ セルフ、チャド(2012-11-08)。「UnicodeSMSの冒険」Twilio。2012-11-09にオリジナルからアーカイブされました2015年8月28日取得
  24. ^ 「PEP261–「ワイド」Unicode文字のサポート」Python.org 2015年5月29日取得
  25. ^ 「PEP0393–柔軟な文字列表現」Python.org 2015年5月29日取得
  26. ^ 「JavaScriptの内部文字エンコード:UCS-2またはUTF-16?・MathiasBynens」
  27. ^ 「ECMA-334:9.4.1Unicodeエスケープシーケンス」en.csharp-online.net2013年5月1日にオリジナルからアーカイブされまし
  28. ^ 字句構造:「Java言語仕様、第3版」のUnicodeエスケープ。Sun Microsystems、Inc2005 2019-10-11を取得
  29. ^ 「Unicode用語集」2016年6月21日取得
  30. ^ 「PHP:サポートされている文字エンコード-手動」php.net
  31. ^ 「UTF-8文字列」Swift.org2019-03-20 2020年8月20日取得

外部リンク