「[區鳥]」が「乗ｽ」に化けるメカニズムコードページ932/ウェブリブログ

「[區鳥]」が「乗ｽ」に化けるメカニズム

<< 作成日時： 2006/11/11 17:29 >>

<<補助漢字をサポートしているアプリケーションは、実際のところ少ない。>>
この補助漢字（JIS X 0212-1990）は、天下の秀丸エディタがver. 6.0になってやっとサポートするようになったことからも分かりますように、サポートしているアプリケーションは、現在のところ少ないです。

例えば、Firefoxではサポートしていますが、IEではIE7になってもサポートされていません。せっかく秀丸エディタでEUC-JPの補助漢字をサポートするようになっても、IEでは文字化けします。「繫がる」が「恕ﾘがる」にIEでは文字化けします。明治の文豪・「森鷗外」は「森乗ｽ外」に文字化けします。

IE で EUC-JP ページの「森鷗外」を表示させると「鷗」が「乗ｽ」に化けるメカニズムを考えてみましょう。

前提知識

IE のように、国際化されたソフトウェアでは、内部処理を Unicode でして、各種エンコーディングと Unicode の変換を行うことで、多種多様なエンコーディングに対応しています。その際、Windows では、エンコーディング変換を API で、あらかじめ用意しています。個々のエンコーディングは、コードページで指定し、シフトJIS、日本語EUC、7ビットJISコードの、それぞれのコードページは、932、51932、50220(50221,50222) となっています。

IE に限らず、Windows 用の国際化されているソフトウェアは、Windows が用意している API を使うようにする事により、自前でエンコーディング変換を用意せずにすみます。しかし、Windows の変換 API で指定するコードページでサポートされていない文字、今回の場合であれば、コードページ51932 (以後、CP51932 とします) でサポートされていない JIS X 0212-1990 補助漢字は、正しく変換できないという事になります。

CP51932 と Unicode との変換の実現方法

各種の実験により、Windows では、次のような変換を行っていると推測されます。(Windows2000 Professional で確認)

CP51932 → Unicode

文字列をアルゴリズム的変換で EUC から SJIS に変換
CP932 から Unicode に変換

Unicode → CP51932

Unicode から CP932 に変換
IBM拡張文字(115区～119区) の文字を NEC選定IBM拡張文字 (89区～92区) の文字に置換
アルゴリズム的変換により、SJIS から EUC に変換

「鷗」が「乗ｽ」に化けるメカニズム

問題となっているのは、EUC-JP のページで、「鷗」を JIS X 0212 補助漢字を使って、\x8F\xEC\xBF で表現し、それを IE で表示すると、「乗ｽ」に化けて表示されるというケースです。

IE は内部処理を Unicode で行っているため、EUC を CP51932 → Unicode 変換しています。「CP51932 と Unicode との変換の実現方法」で示した方法を実際に適用してみます。

\x8F\xEC\xBF をアルゴリズム的変換で EUC から SJIS に変換します。
- この際、Windows では、JIS X 0208 の94(区)×94(点)の範囲外のコードポイントは、変換されずに SJIS 文字列の中に残るような変換をします。
- その事を踏まえると、\x8F はそのまま残し、次のように変換されます。
- \x8F → \x8F
- \xEC\xBF → \xE6\xBD
\x8F\xE6\xBD を CP932 から Unicode に変換
- \x8F\xE6 → U+4E57 (乗)
- \xBD → U+FF7D (ｽ)

「鷗」が「乗ｽ」に化けました!

ポイントは、アルゴリズム的変換で EUC から SJIS に変換する際に、変換できないコードポイントを他の文字に置換するなどの処理をせずに、SJIS 文字列の中に残してしまっている事です。

Unicode → CP51932 の変換でも同様の処理をしているため、U+E000～U+E757 のユーザー定義文字を変換すると、EUC 文字列中に SJIS のコードポイントでユーザー定義文字が紛れてしまうという問題がありますのでご注意ください。