UTF-16
UTF-16
UTF-16によるUnicode文字エンコードの例
MIME / IANA• text/plain; 文字セット=UTF-16 • text/plain; 文字セット=utf-16le • text/plain; 文字セット=utf-16be
言語国際的
標準ユニコード標準
分類Unicode変換形式、可変幅エンコーディング
拡張UCS-2
変換/エンコードISO/IEC 10646 (ユニコード)

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

UTF-16はWindows APIや、 Java、Qtなどの多くのプログラミング環境で使用されています。UTF-16の可変長文字と、ほとんどの文字が可変長ではない（そのため可変長はほとんどテストされていない）という事実が相まって、Windows自体を含むソフトウェアに多くのバグを引き起こしています。[ 6 ]

UTF-16は、ウェブ上で（現在も）許可されている8ビットASCIIと互換性のない唯一のエンコーディングです。[ 7 ] [ b ] UTF-16はウェブ上では普及したことがなく、公開されているウェブページの0.004%未満でUTF-16が宣言されています（そして、その場合でも、そのウェブページはUTF-8も使用している可能性が高いです）。[ 9 ]一方、UTF-8は数年前に主流となり、2025年までにすべてのウェブページの99%を占めるようになりました。[ 10 ]ウェブハイパーテキストアプリケーション技術ワーキンググループ（WHATWG）は、UTF-8を「すべての[テキスト]の必須エンコーディング」と見なし、セキュリティ上の理由からブラウザアプリケーションはUTF-16を使用すべきではないと考えています。[ 11 ]

GNU Unifont 16.0.01 Plane 0マップ。下部近くの白い帯はサロゲートコードポイントの範囲です。

歴史

1980年代後半、従来の言語固有のエンコーディングを単一の統一されたシステムに置き換える「ユニバーサル文字セット」（UCS）のための統一エンコーディングの開発作業が開始されました。その目標は、世界のほとんどの言語で必要なすべての文字に加え、科学、数学、音楽といった技術分野の記号も網羅することでした。当初のアイデアは、1文字あたり1バイトを必要とする典型的な256文字エンコーディングを、1文字あたり2バイト（16ビット）を必要とする65,536（2の16乗）値を使用するエンコーディングに置き換えることでした。

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

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

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

説明

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

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

UTF-16とUCS-2はどちらも、この範囲のコードポイントを、対応するコードポイントと数値的に等しい単一の16ビットコード単位としてエンコードします。UCS -2で表現できるのは、基本多言語面（BMP）にあるこれらのコードポイントのみです。Unicode 9.0以降、一部の現代非ラテンアジア、中東、アフリカの文字体系は、ほとんどの絵文字と同様に、この範囲外となります。

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

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

UTF-16デコーダー
低い
高い
DC00DC01   ...   DFFF
D800010000010001...0103FF
D801010400010401...0107FF
⋮⋮⋮⋱⋮
DBFF10FC0010FC01...10FFFF
  • コード ポイント(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）。

U+D800からU+DFFF（サロゲート）

公式の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 UTF-16 16進コード単位 UTF-16BE 16進バイト UTF-16LE 16進バイト
$U+00240000 0000 0010 01000000 0000 0010 0100002400 2424 00
€U+20AC0010 0000 1010 11000010 0000 1010 110020AC20 ACAC 20
𐐷U+104370001 0000 0100 0011 01111101 1000 0000 0001 1101 1100 0011 0111D801DC37D8 01DC 3701 D837 DC
𤭢U+24B620010 0100 1011 0110 00101101 1000 0101 0010 1101 1111 0110 0010D852DF62D8 52DF 6252 D862 DF

バイト順エンコード方式

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

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

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

この規格では、エンコードタイプとして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 ]を使用できますが、UTF-16ではコードポイントは1つまたは2つの16ビット値を使用できます。つまり、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 と同じかそれより小さいサイズのファイルを生成します (これは自己同期を犠牲にすることで実現しています)。

使用法

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

オペレーティングシステム

UTF-16は、現在サポートされているすべてのバージョンのMicrosoft Windows [ 22 ]（少なくともWindows CE 5.0以降のWindows CE [ 23 ] とWindows 2000以降のWindows NT [ 24 ] を含む）のOS APIのテキストに使用されています。Windows 2000 より前のWindows NTはUCS-2のみをサポートしていました。[ 25 ] [ 26 ] Windows 9xはUCS-2のみをサポートし、UnicodeのサポートはVFATやWDMなどの内部的なものに限定されていました。Windows 10バージョン1903（またはインサイダービルド17035）以降では、APIでUTF-8を使用できるようになりましたが[ 27 ] Windowsファイルエクスプローラーなどのほとんどのソフトウェアは、依然としてUTF-16 APIを使用しています。Microsoftは、「UTF-16は、複数のプラットフォームを対象とするコードにWindowsが課す独特の負担である」と述べています[ 28 ]

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

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

ファイルシステム

CD-ROMメディアで使用されるジョリエットファイルシステムは、UCS-2BE（ファイル名あたり最大64文字のUnicode文字）を使用してファイル名をエンコードします。NTFSとReFSは文字列の保存にUTF-16を使用します。[ 30 ]

メッセージング

SMSテキストメッセージは実質的にUTF-16を使用しています。3GPP TS 23.038（GSM）およびIS-637（CDMA）規格ではUCS-2が規定されていますが、絵文字を使用するにはUTF-16が必要です。[ 31 ] Nokia S60端末およびSony Ericsson UIQ端末で使用されているSymbian OSはUCS-2を使用しています。iPhone端末はUTF-16を使用しています。

プログラミング言語

Pythonバージョン2.0は公式には内部的にUCS-2のみを使用していましたが、「Unicode」へのUTF-8デコーダーは正しい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-16です（Java 9以降、ISO-8859-1文字のみを含む文字列はバイトに「圧縮」できるようになりました[ 34 ] [ 35 ]）。Java I/OはUTF-8 [ 36 ]または修正UTF-8を使用します[ 37 ]。

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

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

多くの言語では、エンコーディングを文字列オブジェクトの一部として扱い、UTF-16を含む広範なエンコーディングを格納・サポートしています。多くの言語では、UTF-16とUCS-2は異なるエンコーディングとみなされています。例としては、PHP言語[ 40 ]やMySQL [ 41 ]が挙げられます。

ファームウェア

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

参照

注記

  1. ^この数字は実はUTF-16の帰結です。UTF -16でエンコード可能なコードポイントは2 16 − 2048 + 1024 · 1024 = 1,112,064個あります。UTF-16が標準に追加された時点で、Unicodeはこれらのコードポイントに制限されました。それ以前のUnicodeには、 2 31 = 2,147,483,648個の有効なコードポイントがありました。
  2. ^ UTF-32もASCIIと互換性がありませんが、ウェブエンコーディングとしてはリストされていません。 [ 8 ]
  3. ^ UTF-8 エンコーディングでは、0xFE 未満のバイト値が生成されるため、BOM シーケンス内のいずれかのバイトでもエンコーディングが UTF-16 であると識別されます (UTF-32 が想定されていないと仮定)。
  4. ^ U+FEFF を BOM ではなく ZWNBSP 文字として使用することは非推奨となり、U+2060 (WORD JOINER) が推奨されます。Unicode.orgのバイトオーダーマーク (BOM) に関する FAQ を参照してください。ただし、アプリケーションが先頭の BOM を文字として解釈する場合、ZWNBSP 文字は表示されないため、影響は最小限に抑えられます。
  5. ^ RFC 2781セクション4.3では、BOMがない場合、「テキストはビッグエンディアンとして解釈されるべきである（SHOULD）」と規定されています。セクション1.2によると、「べきである（SHOULD）」という用語の意味はRFC 2119によって規定されています。同文書のセクション3では、「…特定の状況下では特定の項目を無視する正当な理由が存在する可能性がありますが、異なる方針を選択する前に、その影響を完全に理解し、慎重に検討する必要があります」と規定されています。  

参考文献

  1. ^ 「適合性」 . Unicode標準（第6.0版）. マウンテンビュー、カリフォルニア州、米国: Unicodeコンソーシアム. 3.9 Unicodeエンコーディング形式. ISBN 978-1-936213-01-6各エンコード形式は、UnicodeコードポイントU+0000..U+D7FFとU+E000..U+10FFFFをマッピングします。
  2. ^ a b c「C.2 ISO/IEC 10646の符号化形式」（PDF） . Unicode標準バージョン6.0 . マウンテンビュー、カリフォルニア州：Unicodeコンソーシアム. 2011年2月. 573ページ. ISBN 978-1-936213-01-6…… UCS-2という用語は現在では廃止されているとみなされるべきです。UCS-2はもはや10646やUnicode標準のエンコード形式を指すものではありません。
  3. ^ a b c「FAQ: UCS-2とUTF-16の違いは何ですか？」unicode.org . 2003年8月18日時点のオリジナルからアーカイブ。 2024年3月19日閲覧。UCS -2は、Unicode 1.1までのUnicode実装を指す古い用語です [...]
  4. ^ 「UTF-16とは？」 . Unicodeコンソーシアム. Unicode, Inc. 2023年1月7日閲覧。UTF -16は、16ビットのコード単位を1つ使用して、Unicodeで最も一般的な6万文字以上をエンコードします。
  5. ^ Lunde, Ken (2022-01-09). 「2022年トップ10リスト：BMP以外のコードポイントをサポートする理由とは？」 . Medium . 2024-01-07閲覧。このトップ10リストのアイデアを思いついたのは10年以上前で、まだBMPコードポイントしかサポートしていない環境がいくつかあったことがきっかけでした。もちろん、その目的は、そのような環境の開発者に、BMP以外のコードポイントをサポートする理由を列挙することで、サポートを促すことでした。実際、VivaDesignerアプリのように、BMPコードポイントしかサポートしていない環境もまだ存在します。
  6. ^ 「UTF-16は有害と考えられるべきか？」 . Software Engineering Stack Exchange . 2024年11月20日閲覧。ウィンドウダイアログでのファイル名編集が機能しない（削除にはバックスペースキーを2回押す必要がある）
  7. ^ "HTML Living Standard" . w3.org . 2020年6月10日. 2020年9月8日時点のオリジナルよりアーカイブ。2020年6月15日閲覧。UTF -16エンコーディングは、この仕様においてASCII互換エンコーディングではないものとして扱う必要がある唯一のエンコーディングです。
  8. ^ 「エンコーディング標準」 . encoding.spec.whatwg.org . 2023年4月22日閲覧。
  9. ^ 「ウェブサイトにおけるUTF-16の使用統計と市場シェア、2025年11月」w3techs.com . 2025年11月20日閲覧。
  10. ^ 「ウェブサイトにおけるUTF-8の使用統計と市場シェア、2025年11月」w3techs.com . 2025年11月20日閲覧。
  11. ^ 「エンコーディング標準」 . encoding.spec.whatwg.org . 2018年10月22日閲覧。UTF -8エンコーディングは、ユニバーサルコード化文字セットであるUnicodeの交換に最も適したエンコーディングです。したがって、新しいプロトコルやフォーマット、そして新しいコンテキストで展開される既存のフォーマットにおいて、この仕様はUTF-8エンコーディングを必須とし、定義します。[..] ここで概説した問題は、UTF-8のみを使用することで解消されます。これが、UTF-8が現在Web上のすべてのテキストに必須のエンコーディングとなっている多くの理由の1つです。
  12. ^ 「MySQL :: MySQL 5.7 リファレンスマニュアル :: 10.9.4 ucs2文字セット（UCS-2 Unicodeエンコーディング） 」dev.mysql.com。2025年11月20日閲覧。
  13. ^ 「UTF-16とは何か？」 UnicodeコンソーシアムUnicode, Inc. 2018年3月29日閲覧。
  14. ^ 「FAQ - UTF-8、UTF-16、UTF-32 & BOM」 . www.unicode.org . 2025年11月20日閲覧。
  15. ^ ISO/IEC 10646:2014「情報技術 - 汎用コード化文字セット（UCS）」セクション9および10。
  16. ^ 「第2章 全体構造」（PDF） . Unicode標準バージョン7.0 . 2014. 2.5 エンコーディング形式.
  17. ^ 「文字エンコーディングの安定性」 . unicode.org . 2025年11月20日閲覧。
  18. ^ Allen, Julie D.; Anderson, Deborah; Becker, Joe ; Cook, Richard, 編 (2014). 「3.8 Surrogates」(PDF) . Unicode標準バージョン7.0—コア仕様. マウンテンビュー: Unicodeコンソーシアム. p. 118. 2022年10月9日時点のオリジナルよりアーカイブ(PDF) . 2014年11月3日閲覧。
  19. ^ Yergeau, Francois; Hoffman, Paul (2000年2月). 「UTF-16, an encoding of ISO 10646」 . tools.ietf.org . 2019年6月18日閲覧。
  20. ^ 「パスの最大長制限」 . Microsoft . 2022年7月18日. 2022年10月10日閲覧. […] ファイルシステムは、パスとファイル名をWCHARの不透明なシーケンスとして扱います。
  21. ^ 「"🤦🏼‍♂️".length == 7 というのは間違いではない」hsivonen.fi . 2025年11月20日閲覧。
  22. ^ "Unicode" . Microsoft Learn . 2011年3月8日閲覧。これらの関数は、WindowsオペレーティングシステムのネイティブUnicodeエンコードで使用されるUTF-16（ワイド文字）エンコード（…）を使用します。
  23. ^アーカイブドキュメント。「Unicodeサロゲートの操作（Windows CE 5.0）」。learn.microsoft.com 。 2025年11月20日閲覧。
  24. ^ 「サロゲートと補助文字」 . Microsoft Learn . 2022年5月24日. Windows 2000では、補助文字の基本的な入力、出力、および単純な並べ替えのサポートが導入されました。ただし、すべてのシステムコンポーネントが補助文字と互換性があるわけではありません。
  25. ^ Karl-Bridge-Microsoft. 「Unicode - Win32 アプリ」 . learn.microsoft.com . 2025年11月20日閲覧。
  26. ^ Karl-Bridge-Microsoft. 「サロゲートと補助文字 - Win32 アプリ」 . learn.microsoft.com . 2025年11月20日閲覧。
  27. ^ 「Windows アプリで UTF-8 コード ページを使用する」 . learn.microsoft.com . 2020年6月6日取得. Windows バージョン 1903（2019 年 5 月更新）以降、パッケージ アプリの場合は appxmanifest の ActiveCodePage プロパティ、パッケージ化されていないアプリの場合は fusion マニフェストの ActiveCodePage プロパティを使用して、プロセスでプロセス コード ページとして UTF-8 を使用するように強制できます。[...] は、 Windows バージョン 1903（2019 年 5 月更新）以降で実行され、上記の ActiveCodePage プロパティが UTF-8 に設定されている場合にのみに相当します。それ以外の場合は、従来のシステム コード ページが適用されます。明示的に を使用することをお勧めします。CP_ACPCP_UTF8CP_UTF8
  28. ^ 「Microsoft ゲーム開発キット (GDK) での UTF-8 サポート - Microsoft ゲーム開発キット」。learn.microsoft.com。2023年3 月 5 日閲覧。UTF -8 で動作させることで、最大限の互換性を確保できます。[..] Windows はネイティブで UTF-16 (または WCHAR) で動作するため、MultiByteToWideChar および WideCharToMultiByte を使用してコード ページを変換する必要があります。これは、複数のプラットフォームを対象とするコードに Windows が課す独特の負担です。[..] Microsoft ゲーム開発キット (GDK) と Windows 全般は、複数のプラットフォームや Web を対象とするコードやそれらとのやり取りに Windows が課すこの独特の負担を取り除くために、UTF-8 のサポートに向けて取り組んでいます。また、これによりアプリやゲームにおける国際化の問題が減り、正しく動作させるために必要なテスト マトリックスも削減されます。
  29. ^ 「UCS-2とUnicode（UTF-16）との関係」 www.ibm.com . 2025年11月20日閲覧。
  30. ^ Karl-Bridge-Microsoft. 「ファイル名で使用される文字セット - Win32 アプリ」 . learn.microsoft.com . 2025年10月11日閲覧。
  31. ^ Chad Selph (2012年11月8日). 「Unicode SMSの冒険」 . Twilio. 2015年9月8日時点のオリジナルよりアーカイブ。 2015年8月28日閲覧。
  32. ^ "PEP 393 – Flexible String Representation | peps.python.org" . Python Enhancement Proposals (PEPs) . 2025年11月20日閲覧。
  33. ^ "PEP 623 – Unicodeからwstrを削除 | peps.python.org" . Python拡張提案（PEP） . 2025年11月20日閲覧。
  34. ^ 「JDK 9 リリースノート - 新機能」。
  35. ^ "kí tự đặc biệt" .キトゥ ベトナム。 2025-07-23 。2025 年 11 月 20 日に取得。
  36. ^ 「Java Development Kitバージョン24 API仕様」 . docs.oracle.com . 2025年11月20日閲覧。
  37. ^ 「Java SEドキュメント java.io.DataInputインタフェースの修正UTF-8に関するサブセクション」 Oracle Corporation 2015年 2015年10月16日閲覧。
  38. ^ 「JavaScriptの内部文字エンコーディング：UCS-2かUTF-16か？ · Mathias Bynens」 . mathiasbynens.be . 2025年11月20日閲覧。
  39. ^ 「UTF-8文字列」 . Swift.org . 2019年3月20日. 2020年8月20日閲覧。
  40. ^ 「PHP: サポートされている文字エンコーディング - マニュアル」 . php.net .
  41. ^ 「MySQL :: MySQL 8.0 リファレンスマニュアル :: 10.9.2 utf8mb3 文字セット（3バイト UTF-8 Unicode エンコーディング） 」 dev.mysql.com 。2023年2月24日閲覧。
「 https://en.wikipedia.org/w/index.php?title=UTF-16&oldid=1323352403」より取得