1 UTF-16の概要
UTF-16（Unicode Transformation Format, 16-bit）は、Unicodeの文字を符号化するための文字コード方式の一つである。文字符号を直接「ビット列として表す」方式であり、通常は16ビット（2バイト）単位の符号化要素を用いて文字を表す。基本多言語面（BMP）に属する文字は1要素で表現し、補助平面に属する文字は2要素を組み合わせて表現する点が特徴である。
UTF-16は、OSやプログラミング言語、テキスト処理ライブラリなどで長年採用されてきた。一方で、エンディアン（バイト順）やサロゲート対の扱い、文字長とバイト長の混同など、実務上の注意点も多い。これらを理解したうえで、入出力・検証・移植性に配慮しながら利用することが重要となる。
1.1 Unicodeとの関係
1.1.1 Unicode符号位置と符号化方式
Unicodeは、文字に対応する番号体系（符号位置）を定めている。符号化方式（エンコーディング）は、その符号位置を、実際に保存・転送できる形（バイト列）へ変換する手順と定義の総称である。UTF-16はUnicodeの符号位置を、16ビット単位の要素列として表す変換方式に該当する。
このため、同じ文字でも「符号位置」（Unicodeの側）と「符号化表現」（UTF-16などの側）は別概念として扱う必要がある。変換方式が変わればバイト列は変化するが、符号位置に対応する文字自体は同一である。
1.1.2 コードポイントと文字の違い
Unicodeでは、一般に「コードポイント」という語が符号位置の意味で用いられることが多い。コードポイントは特定の文字に対応する番号であり、表示上の「文字」とは常に一致しない場合がある。たとえば、見た目上1文字に見える組合せが、複数のコードポイントから構成されることがある。
UTF-16の扱いでは、符号位置の単位で変換・検証を行う一方、ユーザーが感じる「1文字」の境界は別の規則に基づく。したがって、文字数で数える処理と符号化要素数（あるいはコードポイント数）で数える処理を混同しないことが実務の要点となる。
1.2 UTF-16の基本構造
1.2.1 16ビット単位での表現
UTF-16では、符号化要素として16ビット（一般に2バイト）を使う。UTF-16の「固定長」性はこの要素単位に限られる。つまり、1文字が常に同じ個数の要素で表されるわけではない。BMP内の文字は1要素で完結し、補助平面の文字は2要素にまたがる。
符号化要素列として見ると、UTF-16は可変長の符号化方式である。最小単位は16ビットであり、必要に応じて隣接する要素と対をなして文字を構成する。
1.2.2 BMPと補助平面の扱い
BMP（Basic Multilingual Plane）はUnicodeの符号位置のうち0から始まる広い範囲で、一般に多くの主要文字が含まれる。UTF-16では、このBMP内に収まる符号位置の文字は、対応する値をそのまま16ビット要素として格納することで表せる。
一方、補助平面に属する文字はBMP外にあるため、単独の16ビット要素では表現できない。その結果、UTF-16ではサロゲート対と呼ばれる2要素の組を用いて表現する。
1.2.3 サロゲート対の仕組み
補助平面の文字を表すには、16ビット要素のうち特定の範囲に割り当てられた値を使う。これがサロゲートであり、通常は「上位サロゲート」と「下位サロゲート」を組として並べる。
上位サロゲートと下位サロゲートは、符号位置の情報をそれぞれ一部ずつに分割して表す。デコーダは、入力要素列を順に読みながら上位サロゲートらしさを確認し、続く要素が適切な下位サロゲートである場合に限って1文字として復元する。不整合がある場合は、後述する置換方針やエラー処理に従う。
1.3 エンディアンと符号化表現
1.3.1 ビッグエンディアン
エンディアンは、マルチバイト数値を構成する際のバイト順の規則である。UTF-16では16ビット要素が基本単位となるため、その要素を2バイトに分けて扱う際にバイト順が問題となる。
ビッグエンディアンでは、上位のバイトが先に配置される。したがって、16ビット要素の値を受け取る側は、そのバイト順を前提に復元しないと誤った要素列として解釈してしまう。
1.3.2 リトルエンディアン
リトルエンディアンでは、下位のバイトが先に配置される。ビッグエンディアンと異なるため、同じUTF-16要素でもバイト列の見え方は逆になる。
通信やファイル交換でエンディアン情報が曖昧なまま処理すると、文字化けの原因になりやすい。特に単純なバイト列コピーで運ぶ場面では、受信側が期待する順序と一致しているかの確認が必要になる。
1.3.3 BOMの役割
BOM（Byte Order Mark）は、バイト順を示すためにデータ先頭に配置されることがある目印である。UTF-16では、BOMがあるとバイト順の判定が容易になる場合がある。
ただし、BOMの有無は運用に依存し、BOMが省略されるケースもある。そのため、実装ではBOMに頼り切らず、プロトコル仕様やコンテキスト（たとえばファイル形式やHTTPヘッダ）によりエンディアンを確定する設計が望ましい。
2 文字表現の実例
2.1 BMP内の文字
2.1.1 1単位で表せるケース
BMP内の文字は、対応する符号位置がBMP範囲にあるため、UTF-16では1つの16ビット要素に収まる。したがって、BMP文字はデコーダから見て「要素を1つ読むことで1文字が確定する」傾向を持つ。
この性質により、BMP中心のデータでは文字ごとの扱いが比較的単純になることがある。ただし、見た目の「文字」の数とコードポイント列の数が一致するとは限らない点には注意が必要である。
2.2 補助平面の文字
2.2.1 サロゲート対による表現
補助平面の文字は、上位サロゲートと下位サロゲートの2要素として表現される。実装では、上位サロゲートに遭遇したら次の要素が下位サロゲートとして妥当かを確認し、セットとして復元する。
この仕組みのため、補助平面文字を含むデータでは、要素数と文字数が一致しない。たとえば文字数を数える処理は、サロゲート対を1文字として数えるロジックを必要とすることがある。
2.2.2 よくある取り扱いミス
よくある誤りとして、サロゲート対の境界を無視して16ビット要素を単純に文字扱いすることが挙げられる。これにより、補助平面文字が分割された別々の「文字」として誤って扱われる。
また、デコーダが不正な並び（上位サロゲートの単独出現、下位サロゲートの単独出現、対応しない組の並びなど）を検出した際の振る舞いを、明確に定めないことも問題になる。結果として、文字化けや長さ計算の破綻、検索・比較の不整合が起こりうる。
2.3 文字長とバイト長の考え方
2.3.1 文字数とユニット数
UTF-16では、長さを測る対象が複数存在しうる。最も低レベルでは16ビット要素の数（ユニット数）であり、次にコードポイント数、さらにユーザーから見た表示単位（書記素クラスタ）の数がある。
コードポイント数はサロゲート対を1つにまとめる必要があるため、ユニット数と一致しない。加えて、コードポイントが組合せで表示単位を形成する場合、表示上の「1文字」をコードポイント数に対応づけるのも適切でないことがある。
2.3.2 バイト数の計算
UTF-16のバイト数は、基本的に16ビット要素の数に2を掛けた値になる。ただし、ファイル形式によってはBOMが追加されることがあり、その分だけ先頭が増える。
この計算は符号化要素単位で行うため、文字数が欲しい場面では注意が必要である。補助平面文字が含まれる場合、同じ「文字数」でもバイト数は増減する。設計としては、目的（保存容量、通信量、切り出し単位）に応じて、長さ指標を明確化することが望ましい。
3 実装と利用上の注意
3.1 入出力での課題
3.1.1 テキストファイルの読み書き
ファイル入出力では、エンディアン、BOMの有無、改行コード、文字列の終端（たとえば長さ付きかヌル終端か）といった周辺条件が揃って初めて正しく動作する。UTF-16で保存されたファイルを別環境で読む際は、エンディアンの期待値とBOM情報の扱いが一致しているかを確認する必要がある。
また、編集ツールや既存のデータとの互換性のために、エンコード名指定（UTF-16LE/UTF-16BEなど）を明示する運用が有効になる場合がある。省略された場合に推測で動く実装では、環境差による事故が起きやすい。
3.1.2 ソケット通信などストリーミング
ストリーミングでは、データが途中で区切られて到着するため、UTF-16の要素境界やサロゲート対の分割が問題になる。上位サロゲートの途中までしか受信できていない状態で切れてしまうと、復元ができない。
このため、受信側は「直前に不完全な状態がないか」を管理し、必要に応じてバッファリングしてからデコードする設計が求められる。送信側も、切り出し単位が要素や文字境界を跨いでいないかを意識することが、結果の安定性につながる。
3.2 妥当性検証
3.2.1 不正なサロゲートの検出
デコーダは入力要素列を検査し、サロゲート対として成立しない組を見つけた場合に不正として扱うのが基本である。具体的には、上位サロゲートの後に不適切な下位サロゲートが来た場合、またはサロゲートが想定外の場所に単独で現れた場合などが対象となる。
検出の実装では、エンディアンによる復元後の16ビット要素を基に判定する。バイト順が誤っていると、検査条件を満たしてしまう可能性があるため、まずはエンディアン推定や指定を適切に行うことが前提となる。
3.2.2 置換文字（リプレース）の方針
不正入力に対しては、処理を継続するための方針が必要になることが多い。一般的には、問題の箇所を置換文字（replacement character）に置き換えることで、デコード結果の型（文字列）を維持しつつ破損位置を表す。
他方で、厳密モードでは例外を投げる、あるいはエラーコードを返すなど、破損の検出を強く扱う場合もある。どの方針を採るかは、アプリケーションの要件（ログ優先、入力品質の厳格性、データ破損時の許容範囲）に依存する。
3.3 移植性と互換性
3.3.1 エンディアン差の吸収
移植性の観点では、UTF-16LEとUTF-16BEのどちらが使われているか、またBOMで示されるかを整理する必要がある。内部表現としては、ホスト環境に合わせた16ビット要素の順序で扱い、外部入出力時だけエンディアン変換を行う設計が採られることが多い。
この方針により、アプリケーション内部の比較や長さ計算が安定し、外部仕様への適合が明確になる。変換の責務を境界層に寄せることが、保守性にも寄与する。
3.3.2 APIごとの文字列モデルの差
同じUTF-16でも、言語やOSが提供する文字列型は必ずしも同一の意味を持たない。あるAPIでは16ビット要素をそのまま文字列長として返し、別のAPIではコードポイント数に相当する長さを返す場合がある。
また、スライスや添字アクセスが要素単位かコードポイント単位かで挙動が変わりうる。移植の際は、APIドキュメントで「添字の基準」「長さの定義」「サロゲートを跨ぐ操作の扱い」を確認し、必要なら変換関数を介して整合性を確保することが実務上の要点になる。
4 UTF-16の比較と選択指針
4.1 UTF-8との比較
4.1.1 表現長の傾向
UTF-8は符号位置に応じて1バイトから最大4バイトまで可変長で表す。一般にASCII範囲（ごく基本的な英数字など）が多いデータでは、UTF-8は短くなりやすい。これに対しUTF-16は、BMPの多くの文字が2バイト相当で表れるため、対象文字の分布によって優劣が入れ替わる。
補助平面の文字については、UTF-16では2要素（4バイト相当）になり、UTF-8では長さが3または4バイトになる。したがってデータの実態に即した比較が必要になる。
4.1.2 性能と互換性の考慮
性能は単純なバイト数だけで決まらない。デコード器の実装品質、メモリアクセスの形、文字境界の走査頻度などが効いてくる。UTF-8は多くのWeb系基盤で標準的に使われ、ツールチェーンも充実している一方、UTF-16は一部のOSや言語で文字列型との親和性が高いとされる。
互換性の観点では、入出力先がどのエンコーディングを前提としているかが最重要になることが多い。交換フォーマットや外部APIがUTF-16を期待する場合は合理性がある。
4.2 UTF-32との比較
4.2.1 固定長の利点と欠点
UTF-32は、各符号位置を固定長で表す方式である。固定長であるため、理論上は位置からの参照が簡単になり、長さ計算や乱アクセスがしやすい利点がある。
一方で、メモリ使用量が増えやすく、転送量も増える傾向がある。特にBMP中心のテキストではUTF-16やUTF-8より不利になりやすい。そのため、UTF-32は内部処理の一部で使われることはあっても、外部交換の標準としては状況が限定される場合がある。
4.3 用途別の選び方
4.3.1 エディタ・OS・アプリ開発
エディタやOS、特定のアプリ環境では、既存の文字列型やAPIがUTF-16を前提としていることがある。この場合、内部表現をUTF-16に合わせると、変換コストや不整合の発生を抑えられる。
ただし、UIでのカーソル移動や選択範囲の計算は、文字境界（書記素クラスタ）に基づく必要がある。UTF-16であっても、表示単位の計算ロジックは別途整えるべきである。
4.3.2 ログ、データ交換、ウェブ連携
ログでは、後から解析するために損失の少ないデコードと、破損入力への方針（置換か停止か）が重要になる。UTF-16を採用する場合は、BOMの扱いとエンディアン統一を強く意識する必要がある。
データ交換やウェブ連携では、受け手がUTF-8を前提にしている場合が多い。互換性を重視するなら、外部向けはUTF-8へ寄せ、内部ではUTF-16で扱う折衷案も検討される。要件に応じて変換の位置と回数を最小化する設計が実務上の指針となる。