UTF-16

UTF-16

UTF-16 による Unicode 文字エンコードの例
言語	国際的
標準	ユニコード標準
分類	Unicode 変換形式、可変幅エンコーディング
拡張	UCS-2
変換/エンコード	ISO/IEC 10646 (ユニコード)
ヴ t e

UTF-16 ( 16ビット Unicode変換形式) は、Unicodeの有効な1,112,064コードポイントすべてをエンコードできる文字エンコード方式です。 ^[a]コードポイントは1つまたは2つの16ビットコード単位でエンコードされるため、エンコードは可変長です。UTF-16は、現在UCS-2 (2バイトユニバーサル文字セット)として知られている以前の廃止された固定幅16ビットエンコードから生まれました。^{[1] [2] 2 16} (65,536)を超えるコードポイントが必要であることが明らかになったため、ほとんどの絵文字と人名や地名などの重要なCJK文字が含まれます。 ^{[4 ]}

UTF-16は、 Microsoft Windows API、Javaプログラミング言語、JavaScript /ECMAScriptなどのシステムで使用されています。また、 Microsoft Windowsのプレーンテキストやワードプロセッサのデータファイルにも使用されることがあります。SMSのより新しい実装でも使用されています。 [ ^5]

UTF-16 は、ウェブ上で（今でも）許可されている 8 ビットASCIIと互換性のない唯一のエンコーディングです。^{[6] [b]}しかし、ウェブ上では UTF-16 が普及したことはなく、公開されているウェブページの 0.003% 未満で使用されています。^[8] これに対して、UTF-8はすべてのウェブページの 98% 以上を占めています。 ^[9] Web Hypertext Application Technology Working Group (WHATWG) は、 UTF-8 を「すべての [テキスト] の必須エンコーディング」と見なし、セキュリティ上の理由からブラウザ アプリケーションは UTF-16 を使用すべきではないとしています。^[10]

UTF-16の可変長文字は、ほとんどの文字が可変長ではない（そのため可変長がテストされることはほとんどない）という事実と相まって、Windows自体を含むソフトウェアに多くのバグをもたらしました。^[11]解決策としては通常、UTF-8を採用することが挙げられますが、ほとんどのソフトウェア（部分的にWindows自体、Java、JavaScriptなど）がそうしています。

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

この作業には、ISO/IEC JTC 1/SC 2とUnicodeコンソーシアムの2つのグループが並行して取り組んでいた。後者は主にコンピュータ機器メーカーを代表する。2つのグループは、開発中のエンコーディングが相互に互換性を持つように、文字の割り当てを同期させようとした。初期の2バイトエンコーディングはもともと「Unicode」と呼ばれていたが、現在は「UCS-2」と呼ばれている。^{[1] [2] [12]}

^{2 16}文字では不十分であることが次第に明らかになったため、 ^[13] IEEE は、より大きな 31 ビット空間と、 1 文字あたり 4 バイトを必要とするエンコード ( UCS-4 ) を導入しました。これは、1 文字あたり 4 バイトでは大量のメモリとディスク領域が浪費されることと、一部のメーカーが 1 文字あたり 2 バイトの技術にすでに多額の投資を行っていたことから、Unicode コンソーシアムによって抵抗されました。UTF-16 エンコード方式は妥協案として開発され、1996 年 7 月に Unicode 標準のバージョン 2.0 で導入されました。[ ^{14]これは、2000 年に}IETFによって公開された RFC 2781 で完全に指定されています。^{[15] [16]}

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

各 Unicodeコード ポイントは、1 つまたは 2 つの 16 ビットコード単位としてエンコードされます。2 ¹⁶未満のコード ポイント(「BMP 内」) は、古い UCS-2 と同様に、コード ポイントの数値に等しい単一の 16 ビット コード単位でエンコードされます。2 16 以上 ( ^{「 BMP より上」) のコード ポイントは、} 2 つの16 ビット コード単位を使用してエンコードされます。これらの 2 つの 16 ビット コード単位は、以前は文字に割り当てられていなかったUTF-16 サロゲート範囲 0xD800～0xDFFFから選択されます。この範囲の値は文字として使用されず、UTF-16 では、それらを個別のコード ポイントとしてコード化する正当な方法はありません。したがって、UTF-16 ストリームは、サロゲート範囲外の単一の 16 ビット コードと、サロゲート範囲内の 16 ビット値のペアで構成されます。

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

他のプレーンのコードポイントは、サロゲートペアと呼ばれる2つの16ビットコード単位としてエンコードされます。最初のコード単位は高サロゲートで、2番目は低サロゲートです（これらは、UTF-8の先頭バイトと末尾バイトに類似して、それぞれ「先頭」サロゲートと「末尾」サロゲートとも呼ばれます。^[18]）。

• コードポイント(U)から 0x10000 が減算され、 16 進数範囲 0x00000～0xFFFFF の20 ビットの数値(U')が残ります。
• 上位 10 ビット (範囲 0x000～0x3FF) が 0xD800 に追加され、最初の 16 ビットコード ユニットまたは上位サロゲート (W1)が生成されます。これは0xD800～0xDBFF の範囲になります。
• 下位 10 ビット (0x000～0x3FF の範囲) が 0xDC00 に追加され、2 番目の 16 ビットコード ユニットまたは下位サロゲート (W2)が生成されます。これは0xDC00～0xDFFF の範囲になります。

視覚的に表すと、 W1とW2間のU' の分布は次のようになります。^[19]

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

上位サロゲート( 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)。

公式の Unicode 標準では、UTF-16 を含む UTF 形式ではサロゲート コード ポイントをエンコードできないとされています。これらには文字が割り当てられることはないため、エンコードする理由はありません。ただし、Windows ではファイル名^[20]やその他の場所でペアになっていないサロゲートが許可されているため、Unicode 標準から除外されているにもかかわらず、ソフトウェアでサポートする必要があります。

UCS-2、UTF-8、およびUTF-32では、これらのコード ポイントを単純かつ明白な方法でエンコードすることができ、標準ではこのような配置はエンコード エラーとして扱う必要があると規定されているにもかかわらず、多くのソフトウェアがそうしています。

コード ポイントに等しいコード ユニットを使用することで、ペアになっていないサロゲート(上位のサロゲート コード ポイントの後に下位のサロゲート コード ポイントが続かない、または下位のサロゲート コード ポイントの前に上位のサロゲート コード ポイントが続かない) を UTF-16 形式で明確にエンコードできます。結果は有効な UTF-16 ではありませんが、UTF-16 エンコーダーとデコーダーの実装の大部分は、エンコード間の変換時にこれを行います。^{[引用が必要]}

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 を加算して、最終的なコード ポイント 0x10437 を取得します。

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

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

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

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

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

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

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

「文字」は、任意の数のUnicodeコードポイントを使用できます。^[21]たとえば、絵文字のフラグ文字は、「一対のUnicodeスカラー値から構築される」ため、8バイトかかります^[22]（そして、それらの値はBMPの外側にあり、それぞれ4バイト必要です）。UTF-16は、「文字を数える」ことや「文字列の幅を測定する」ことにはまったく役立ちません。

UTF-16 は、 UTF-8 では 3 バイトかかる文字を 2 バイトで処理するため、東アジアの言語ではUTF-8よりもスペース効率が良いとよく言われます。実際のテキストには、UTF-8 では 1 バイトしかかからないスペース、数字、句読点、マークアップ (Web ページなど)、制御文字が多数含まれるため、これは人工的に構築された高密度のテキスト ブロックにのみ当てはまります。^{[要出典]複数文字の単語を使用する}デーヴァナーガリー語とベンガル語では、文字すべてが UTF-8 では 3 バイト、UTF-16 では 2 バイトしかかかりません。

さらに、中国語 Unicode エンコード標準GB 18030 は、中国語だけでなくすべての言語で常に UTF-16 と同じサイズかそれより小さいファイルを生成します (これは自己同期を犠牲にすることによって行われます)。

UTF-16は、  Windows 10を含む、現在サポートされているすべてのバージョンのMicrosoft Windows（少なくともWindows CE / 2000 / XP / 2003 / Vista / 7 ^[23]以降のすべてを含む）のOS APIのテキストに使用されます。Windows XPでは、ヨーロッパ言語用にWindowsに付属するフォントには、U+FFFFを超えるコードポイントは含まれていません。^{[24] [25]}古いWindows NTシステム（Windows 2000より前）は、UCS-2のみをサポートしています。^[26]ファイルとネットワークデータは、UTF-16、UTF-8、および従来のバイトエンコーディングが混在する傾向があります。

Windows XPでもUTF-8のサポートは一部ありましたが^{[27] 、Windows 10} Insider Build 17035と2019年5月のアップデートで改善されました（特にUTF-8を使用してファイルに名前を付ける機能） 。2019年5月現在、MicrosoftはWindowsとXboxでソフトウェアが他の8ビットエンコーディングではなくUTF-8を使用することを推奨しています。^[28] UTF-16よりもUTF-8の使用を推奨しているかどうかは不明ですが、「UTF-16は、複数のプラットフォームを対象とするコードにWindowsが課す独特の負担です」と述べています。^[29]

IBM iオペレーティングシステムでは、 UCS-2エンコードにはCCSID（コードページ）13488、UTF-16エンコードにはCCSID 1200が指定されていますが、システムは両方ともUTF-16として扱います。^[30]

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

Nokia S60端末やSony Ericsson UIQ端末で使用されているSymbian OSはUCS-2を使用しています。iPhone端末は、 3GPP TS 23.038（GSM）およびIS-637（CDMA ）標準で説明されているUCS-2ではなく、ショートメッセージサービスにUTF-16を使用しています。^[31]

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

Pythonバージョン2.0は公式には内部的にUCS-2のみを使用していましたが、UTF-8デコーダーから「Unicode」への変換では正しいUTF-16が生成されました。また、Pythonをコンパイルして内部的にUTF-32を使用する機能もあり、これはUnixで時々行われていました。Python 3.3では、文字列の最大コードポイントに応じて、内部ストレージをISO-8859-1 、UCS-2、またはUTF-32のいずれかを使用するように切り替えました。 ^{[32] Python 3.12では、すべての文字列を}UTF-8に移行しやすくするために、いくつかの機能（CPython拡張機能用）が削除されました。^[33]

JavaはもともとUCS-2を使用していましたが、J2SE 5.0でUTF-16補助文字のサポートを追加しました。最近ではUTF-8以外の8ビットエンコーディングのサポートを廃止することが推奨されていますが^[34]、内部的にはUTF-16がまだ使用されています。

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

UEFI はデフォルトで UTF-16 を使用して文字列をエンコードします。

Appleの推奨アプリケーション言語であるSwiftは、バージョン5でUTF-8に切り替わるまで、文字列の保存にUTF-16を使用していました。^[36]

多くの言語では、エンコーディングを文字列オブジェクトの一部にし、UTF-16を含む多数のエンコーディングを保存およびサポートしています。ほとんどの言語では、UTF-16とUCS-2は異なるエンコーディングであると考えられています。例としては、PHP言語^[37]やMySQL ^[38]が挙げられます。

システムが内部的に使用しているエンコーディングを判別する方法は、単一の非 BMP 文字を含む文字列の「長さ」を尋ねることです。長さが 2 の場合、UTF-16 が使用されています。4 は UTF-8 を示します。3 または 6 はCESU-8を示します。1 はUTF -32 を示しますが、おそらく言語が「長さ」を測定する前に文字列をコード ポイントにデコードすることを示します。

多くの言語では、C スタイルの"\uXXXX"構文が明示的に 16 進数 4 桁に制限されているため、引用符で囲まれた文字列には非 BMP 文字を引用するための新しい構文が必要です。次の例は、非 BMP 文字U+1D11E 𝄞 MUSICAL SYMBOL G CLEFの構文を示しています。

• 最も一般的なのは（C++、C#、D、その他いくつかの言語）、大文字の「U」と8桁の16進数の組み合わせです"\U0001D11E"。^[39]
• Java 7 正規表現、ICU、および Perl では、 を使用します"\x{1D11E}"。
• ECMAScript 2015 (JavaScript) では が使用されます"\u{1D11E}"。
• 他の多くの場合（正規表現以外のJavaなど）では、^[40]非BMP文字を取得する唯一の方法は、サロゲート半分を個別に入力することです"\uD834\uDD1E"。

• Unicode エンコーディングの比較
• 飛行機 (Unicode)
• UTF-8
• CESU-8
• UTF-32

• 任意のコードポイントのサロゲートペアを決定するための非常に短いアルゴリズム
• Unicode テクニカル ノート #12: 処理のための UTF-16
• Unicode FAQ: UCS-2 と UTF-16 の違いは何ですか?
• Unicode 文字名インデックス
• RFC 2781: UTF-16、ISO 10646 のエンコード
• java.lang.String ドキュメント、サロゲート処理についての説明