WHATWG vs Unicode.org: Why Browsers and Standards Disagree on EncodingWHATWG vs Unicode.org: ブラウザと規格がエンコーディングで食い違う理由

When converting legacy encodings to Unicode, multiple organizations created their own mapping tables independently. The official Unicode.org tables followed national standards strictly, while Microsoft and later WHATWG followed what browsers actually implemented.

WHATWG’s fundamental principle: “Don’t break existing web content.” This means ratifying browser behavior even when it contradicts official standards.

The most well-known mapping conflict. The same JIS byte position maps to different Unicode code points:

This tool lets you toggle between both mappings in Settings to see the difference.

Big5 (Traditional Chinese): WHATWG merges CP950 and HKSCS into a hybrid table. 6 characters have duplicate byte positions where the encoding order differs between WHATWG and other implementations.

GB18030 (Simplified Chinese): Byte 0xA3 0xA0 maps to U+3000 (ideographic space) in WHATWG, but the official GB18030 standard maps it to U+E5E5 (a PUA character). This was a deliberate web-compatibility fix from 2002.

WHATWG’s “EUC-KR” is actually Windows CP949/UHC, covering all 11,172 Hangul syllables — far more than the original KS X 1001 standard’s ~2,350.

Notably, the Unicode.org KSX1001.TXT was created from Microsoft’s UHC mapping (stated in the file header), so there is no WHATWG vs Unicode.org discrepancy for Korean — unlike JIS.

WHATWG’s most sweeping decision: all labels including iso-8859-1, latin1, and ascii resolve to Windows-1252. This means 27 bytes in the 0x80-0x9F range decode as typographic characters instead of C1 controls.

Across all encodings, the pattern is the same:

WHATWG standardized what browsers had been doing for decades. The result is pragmatic but means “the standard” and “browser behavior” now agree — at the cost of diverging from the original national standards.

レガシーエンコーディングを Unicode に変換する際、複数の組織が独自にマッピングテーブルを作成しました。Unicode.org は各国規格に忠実に、Microsoft と WHATWG はブラウザの実装に従いました。

WHATWG の基本原則: 「既存の Web コンテンツを壊さない」。これはブラウザの動作を公式規格より優先することを意味します。

最も有名なマッピング問題。同じ JIS バイト位置が異なる Unicode コードポイントにマップされます:

このツールでは設定から両マッピングを切り替えて違いを確認できます。

Big5（繁体字）: WHATWG は CP950 と HKSCS を統合したハイブリッドテーブルを使用。6文字でバイト列の順序が他の実装と異なります。

GB18030（簡体字）: バイト 0xA3 0xA0 は WHATWG では U+3000（全角スペース）にマップされますが、公式 GB18030 規格では U+E5E5（PUA 文字）です。2002年の Web 互換性修正に基づく決定です。

WHATWG の「EUC-KR」は実際には Windows CP949/UHC で、全 11,172 ハングル音節をカバー — 本来の KS X 1001 の約 2,350 字をはるかに超えます。

注目すべき点: Unicode.org の KSX1001.TXT は Microsoft の UHC マッピングに基づいて作成されている（ファイルヘッダーに明記）ため、韓国語では JIS のような WHATWG vs Unicode.org の相違はありません。

WHATWG の最も影響範囲の広い決定: iso-8859-1、latin1、ascii 等のラベルは全て Windows-1252 として解釈。0x80-0x9F の27バイトが C1 制御文字ではなくタイポグラフィ文字に。

全てのエンコーディングに共通する構造:

WHATWG はブラウザが数十年間行ってきた動作を標準化しました。「規格」と「ブラウザの動作」が一致する代わりに、元の各国規格とは乖離する結果になっています。