なぜUTF-8が世界標準になったか

結論 — なぜUTF-8が勝ったか

横にスクロール

一言で言えば、既存のASCII資産を1バイトも書き換えずに動かせたからです。UTF-8はASCII文字（0x00〜0x7F）をASCIIと完全に同じ1バイトで表現します。つまり既存のASCIIテキストは、そのまま何も変換せずに有効なUTF-8です。ファイルシステム、C言語の文字列関数、/ や NUL を区切りに使うプロトコル——これらを一切改修せずに多言語対応へ橋渡しできたことが、固定幅の美しさを掲げたUTF-16に対する決定的な優位でした。標準化の勝敗は理論的な優雅さではなく、移行コストの低さと既存基盤との互換性で決まったのです。

当時の状況と競合 — 固定幅か、可変幅か

1980年代末、世界の文字を1つの体系に収める試みとしてUnicodeとISO/IEC 10646（UCS）が並行して進み、後に統合されます。初期のUnicodeは「世界の全文字は16ビット（65,536通り）に収まる」という前提に立ち、各文字を固定16ビットで表すUCS-2を採り、これが「Unicode＝2バイト固定」という発想を広めました。

固定幅UCS-2の弱点は明白でした。第一に、ASCIIの A（0x41）が 00 41 になり、既存のCの文字列やUNIXのファイルパスとバイト単位で非互換です。文字列中に NUL（0x00）バイトが頻出するため、NUL 終端を前提にしたC標準ライブラリが軒並み破綻します。第二に、2バイトをどちらの順で並べるか（ビッグ/リトルエンディアン）でバイト列が変わり、先頭にBOM（Byte Order Mark、0xFEFF）を付けて区別する運用が必要でした。移行にはOS・ライブラリ・プロトコルの全面改修が要り、その負担は膨大だったのです。

決定打・経緯 — 一晩で生まれた設計

転機は1992年でした。当時のUTF-8の原案（X/Openが検討したFSS-UTF）は、自己同期性——バイト列の途中から見ても、それが文字の先頭バイトか後続バイトかを判別できる性質——を欠いていました。ベル研究所でPlan 9を開発していたKen ThompsonとRob Pikeはこの案に満足せず、1992年9月2日、ニュージャージー州のダイナーで食事中にThompsonがランチョンマット（紙ナプキン）の裏に新しい符号化を設計したと、後にPike自身が回想しています。その晩のうちにThompsonが実装し、Plan 9のシステム全体を数日で書き換えて実運用に載せました。この設計こそ現在のUTF-8です。

その設計の要点は、バイトの上位ビットに役割を持たせた点にあります。

コードポイント範囲        バイト列（2進表記のパターン）
U+0000  - U+007F   0xxxxxxx                             （ASCIIと完全一致）
U+0080  - U+07FF   110xxxxx 10xxxxxx
U+0800  - U+FFFF   1110xxxx 10xxxxxx 10xxxxxx
U+10000 - U+10FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

この規則から3つの性質が同時に導かれます。(1) 後方互換：先頭ビットが0のバイトはASCIIそのもの。(2) 自己同期：後続バイトは必ず 10 で始まるので、任意の位置から前後に走査して文字境界を復元できる。1バイト欠落しても次の文字先頭で同期が回復し、破損が局所化します。(3) エンディアン非依存：バイト列として順序が確定しているため、BOMもバイト順の取り決めも不要です。加えて、ASCIIの区切り文字（/、NUL 等）は多バイト文字の途中には決して出現しないため、既存のパーサやパス処理をそのまま使えました。

標準化も速やかに進みました。UTF-8は1993年にThompsonとPikeによりUSENIXで発表され、1998年にRFC 2279、2003年には現在の決定版であるRFC 3629として定義されます。RFC 3629はコードポイント上限をUTF-16と揃えて 0x10FFFF に制限し、最大4バイトに確定させました。

今への影響と教訓 — 後方互換性という原則

Webの世界がUTF-8を後押ししました。HTML5（2010年代前半に策定）はUTF-8を推奨エンコーディングと明記し、ブラウザのデフォルト解釈もUTF-8へ収束します。IETFはRFC 2277で新規プロトコルのUTF-8対応を要件化し、JSON（RFC 8259）はUTF-8を既定としました。結果として、Webページの文字エンコーディングに占めるUTF-8の割合は現在98%超に達しています。ASCII互換ゆえに「まずASCIIで書いておけば自動的にUTF-8」という緩やかな移行が効いたのです。

一方、早期にUCS-2/UTF-16を採用した陣営は代償を払い続けました。Windows（NTのワイド文字APIはUTF-16）、Java（char は16ビット）、JavaScript（内部文字列はUTF-16）は、BMP外文字（絵文字など）でサロゲートペアを扱う必要があり、「文字数」と「コード単位数」がずれる、上位/下位サロゲート単独の不正シーケンスが混入するといった落とし穴を長く抱えました。JavaScriptで絵文字の length が2になるのはこの名残です。固定幅を狙って可変長に転じたUTF-16は、UTF-8の利点（ASCII互換）を持たないまま、複雑さだけを引き継ぐ結果になりました。

ここから引き出せる原則は明快です。新しい標準の成否は理論的完成度より、既存資産との後方互換性と移行コストで決まる。UTF-8は最も美しい設計だったから勝ったのではなく、世界中に存在した膨大なASCIIコード・ファイル・プロトコルを「壊さなかった」から勝ちました。技術選定でも、優れた新方式が普及しない最大の理由はしばしば互換性の断絶にあります。

文字列をバイト列として正しく扱う実装の勘所はプログラミング、エンコーディングがHTTPヘッダやコンテンツネゴシエーションでどう宣言されるかはWeb、ファイルシステムやパスがバイト列をどう解釈するかはOSの基礎知識が土台になります。

一段で言うと

UTF-8が勝った理由は、設計の優雅さではなく後方互換性です。ASCIIをそのまま1バイトで表し、既存のC言語・ファイルシステム・プロトコルを一切壊さずに世界の文字へ橋を架けた——だから移行が安く、Webの98%超を占めるに至りました。固定幅の美しさを掲げたUTF-16が結局サロゲートで可変長化し複雑さを抱えたのと対照的です。標準の勝敗は「壊さないこと」で決まる、という普遍の教訓がここにあります。