文字コードとUnicodeの内部（符号化と正規化）

文字・コードポイント・バイト列の三層

文字コードの混乱は、「文字」を一枚岩で捉えることから生まれます。Unicodeは概念を3層に分けます。第一に抽象文字（人間が認識する「あ」「A」「é」）。第二にコードポイント——各文字に振られた一意の整数で、U+0041（A）のように書きます。範囲は U+0000 から U+10FFFF までで、約111万個分の空間があります。第三に符号化形式（encoding）——コードポイントを実際のバイト列に落とす規則で、ここがUTF-8/16/32の役割です。

つまり「文字 → 番号 → バイト」という写像が二段あり、文字コードの不具合はたいていこの境界で起きます。番号を割り当てるのがUnicode規格、番号をバイトにするのが符号化方式、と切り分けるのが理解の起点です。文字列が結局はバイト列であることは「変数とデータ型」の参照とコピーの話とも地続きです。

UTF-8／16／32の符号化原理

同じコードポイントでも、バイトへの詰め方が異なります。三方式の設計思想を区別するのが要点です。

UTF-8はコードポイントの大きさで1〜4バイトを使い分けます。先頭バイトのビットパターンが長さを示し、後続バイトはすべて 10xxxxxx で始まります。

U+0041 'A'  → 0xxxxxxx                            : 41                (1バイト)
U+00E9 'é'  → 110xxxxx 10xxxxxx                   : C3 A9             (2バイト)
U+3042 'あ' → 1110xxxx 10xxxxxx 10xxxxxx          : E3 81 82          (3バイト)
U+1F600 '😀'→ 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx : F0 9F 98 80       (4バイト)

この設計には2つの利点があります。ひとつはASCII互換——U+0000〜U+007F は1バイトでそのままASCIIと一致するため、既存のASCIIテキストはすべて妥当なUTF-8です。もうひとつは自己同期性——後続バイトが必ず 10 で始まるので、バイト列の途中から読み始めても文字境界を即座に見つけられます。壊れたバイトが混ざっても、その1文字だけ捨てて復帰できます。

UTF-16はBMPを2バイトで表し、BMP外を後述のサロゲートペアで4バイトにします。JavaScriptの文字列、Java/C#のchar、Windows APIの内部表現はUTF-16です。UTF-32は全コードポイントを4バイト固定で表し、i 番目のコードポイントへ定数時間でアクセスできますが、英数字中心のテキストではUTF-8の4倍の容量を食います。

サロゲートペア——UTF-16がBMP外を表す仕掛け

UTF-16の符号単位は16ビット＝65536通りしかなく、BMP外（U+10000 以上）を直接は表せません。そこでUnicodeは U+D800〜U+DFFF の2048個をサロゲート専用領域として予約し、ここには文字を割り当てません。BMP外の1文字は、上位サロゲート（U+D800〜U+DBFF）と下位サロゲート（U+DC00〜U+DFFF）の2個1組で表します。

U+1F600 '😀' を UTF-16 にする手順
1. 0x10000 を引く           : 1F600 - 10000 = 0F600
2. 20ビットを上位10/下位10に: 0000111101 1000000000
3. 上位 + 0xD800            : D83D
4. 下位 + 0xDC00            : DE00
結果（サロゲートペア）       : D83D DE00

この仕組みのため、UTF-16ベースの言語では**「1文字」が符号単位1個とは限りません**。JavaScriptの "😀".length が 2 を返すのはこのためで、charAt や添字 [i] はサロゲートの片割れを返してしまいます。正しくはコードポイント単位の反復（for...of や Array.from）を使います。

"😀".length            // 2（UTF-16符号単位の数）
[..."😀"].length        // 1（コードポイント単位）
"😀".codePointAt(0)     // 128512（= 0x1F600）

書記素クラスタ——人間が数える「1文字」

コードポイント単位でも、まだ人間の「1文字」とはずれます。é は2通りで表せます。単一の U+00E9（合成済み）か、U+0065（e）＋ U+0301（結合アクサンテギュ）の2コードポイントです。後者のように、基底文字と結合文字をまとめて1つの見える単位にしたものを**書記素クラスタ（grapheme cluster）**と呼びます。

絵文字はさらに複雑です。国旗 🇯🇵 は2個の地域指示子の組、肌色付き絵文字は絵文字＋肌色修飾子、家族絵文字は複数の人物絵文字を U+200D（ZWJ, ゼロ幅接合子）で連結したZWJシーケンスで、コードポイント数個が1書記素になります。

「文字数を数える」「N文字で切る」といった処理が国際化で壊れるのは、この4つの「数」を混同するからです。表示・カーソル移動・切り詰めは書記素クラスタ単位で行う必要があり、UAX #29（テキスト境界）が境界判定規則を定めます。実装にはICUや各言語のセグメンテーションAPI（JavaScriptの Intl.Segmenter 等）を使います。「正規表現」の .（任意の1文字）も多くのエンジンでは書記素ではなくコードポイント単位で動くため、絵文字1個に複数回マッチしうる点に注意が要ります。

正規化（NFC/NFD）——表現の一意化

é の2表現は見た目もコードポイント列も意味も等価ですが、バイト列としては別物です。そのまま == で比較すると不一致になります。これを揃えるのが**正規化（normalization）**で、Unicodeは4形式を定めます。

軸は2つです。正準（canonical）か互換（compatibility, K付き）か——正準は「真に同じ文字」だけを等価とし、互換は「全角①と半角1」「合字fiとfi」のような見た目違いも同一視します（情報が落ちるので不可逆）。もう一方は分解（D）か合成（C）か。一般的な保存・比較にはNFCが推奨され、Webやファイル名で広く使われます。検索インデックスのキー化など見た目差を無視したい場面でNFKCを使います。

正準分解では、結合文字の並びを正準結合クラスに基づいて一意な順序へ並べ替えます（例えば下に付く点と上に付くアクセントの順序を固定）。これにより、同じ見た目を生む結合文字の順列がすべて同一のバイト列へ収束します。

正規化はハッシュキーの安定性にも直結します。文字列をキーにする際、同じ見た目で異なるバイト列があるとハッシュ値が割れる——この問題意識は「ハッシュ関数の設計と均一性」の入力前処理と同じ発想です。

照合（collation）——「等しいか」と「どの順か」は別問題

正規化が「等価判定」を扱うのに対し、**照合（collation）**は「並び順」を扱う別レイヤです。コードポイントの数値順（バイナリ順）に並べると、Z（U+005A）が a（U+0061）より前に来る、ひらがなより漢字が散らばる、といった人間の直感に反する順序になります。

Unicode照合アルゴリズム（UCA, UTS #10）は、各文字に多段の照合重みを与えます。第1レベルが文字の素性（a/b/c…）、第2レベルがアクセント差、第3レベルが大文字小文字差、という具合に段階比較し、まず第1レベルで比べ、同じなら次のレベルへ進みます。これにより「大文字小文字を無視」「アクセントを無視」といった強さ（strength）の調整が可能になります。

さらに照合はロケール依存です。ドイツ語では ä を a の近くに、スウェーデン語では ä をアルファベット末尾に置きます。同じUnicode文字列でも言語によって正しい順序が違うため、ソートには必ずロケールを指定します。文字列照合のアルゴリズム自体（部分一致探索）は「文字列照合アルゴリズム」で扱う別の問題で、ここでの照合は「順序づけ」を指します。

バイナリ順（コードポイント値）:  apple, Banana, cherry, Äpfel
ドイツ語ロケールのUCA順:        Äpfel, apple, Banana, cherry

まとめ

文字コードは「抽象文字 → コードポイント → バイト列」の三層で捉えるのが要です。コードポイント（U+0000〜U+10FFFF）を符号化するのがUTF-8/16/32で、UTF-8は1〜4バイトの可変長・ASCII互換・自己同期、UTF-16はサロゲートペアでBMP外を表します。「1文字」はバイト・符号単位・コードポイント・書記素クラスタで数が食い違い、表示や切り詰めは書記素単位で行います。等価判定の前にはNFC（見た目差まで無視するならNFKC）で正規化を揃え、並び順はロケール依存のUnicode照合アルゴリズムで決めます。文字化けと比較バグは気のせいではなく、どの層を扱っているかの取り違えなのです。