WindowsのEUC-JP、「CP 51932」について
WindowsのEUC-JPは、正式には「CP51932」といいます。
CPはコードページといい、つまるところ符号を識別するための16ビットの数値です。
今回は、この件について記述します。
Windowsの標準EUC-JPデコーダは、JIS X 0208の範囲内しか対応していません。
つまり、CP51932はG3にあるJIS X 0212は対応していません。
G2にある、いわゆる半角カナには対応しています。
多国語対応のWindowsは、内部はUnicode(UTF-16)で動作します。
従って、入力されたEUC-JP符号列は、Unicodeに変換して使われます。
但し、その変換過程は先人たちの調査により、EUC-JP→SJIS→Unicodeの順になされることが、明らかとなりました。
全体的な変換処理は、次の通りです。
① アルゴリズム的に、EUC-JP(CP51932)→SJIS(CP932)
② 但し、JIS X 0208の範囲外となるものは、そのまま符号を残す
③ 変換表で、SJIS(CP932)→Unicode
例えば「森鷗外」の「鷗」はJIS X 0208にはなく、JIS X 0212またはJIS X 0213に存在します。
EUC-JPでJIS X 0212を使用する場合、文字はG3にあるためSS3(0x8f)を冠して「0x8f 0xec 0xbf」という3バイトの符号列になります。
さて、CP51932デコーダはSS3に対応していないため、これは変換せずそのまま残します。次に、0xec 0xbfをSJISに変換し、0xe6 0xbdとします。都合「0x8f 0xec 0xbf」という、異常な符号列が完成します。
次に、この文字列をSJIS(CP932)として解釈し、Unicodeへと変換します。
0x8f 0xec → U+4E57 (乗)
0xbf → U+FF7D (ｽ)
結果として、「森鷗外」は「森乗ｽ外」に文字化けすることになります。
理解に苦しむ挙動ですが、日本語Windowsは元々SJISで動作していたこと、SJISにある94区を超える位置にあるシステム外字への対応を維持すること等から、変換表はSJIS←→Unicodeが維持されているのだろうと推測されます。
従って、他の符号は、一旦SJISを介することになるのでしょう。
それは良いとしても、EUCの解釈と変換の過程は、明らかにおかしい。
未対応の文字が化けるのは仕方がないとしても、その化け方が美しくない結果となっています。
gTefは、この異常なEUC-JPの入力に対応しました。
gTefの場合は、変換表はJISを基本としているなど内部動作は根本的に違っていますが、同様の結果が得られるよう、変換関数を幾重にも挟んで符号を弄ってみました。
もし万が一利用する必要がある場合は、入力の符号名を「CP51932」とします。
1文字の入力から、内部的に2文字に増えるため、入力処理(外部からMIXTUREへのEncode)の大きな改造が必要となりました。
出力処理(MIXTUREから外部へのDecode)はまだ書いていませんが、どうやら、次のようになるようです。
① UnicodeからCP932に変換
② IBM拡張文字(115区〜119区)は、NEC選定IBM拡張文字(89区〜92区)の文字に置換
③ アルゴリズム的変換により、SJISからEUCに変換
④ ③の過程で、94区を超えるものはSJISのまま残す
つまり、SJISでは扱えるU+E000〜U+E757の外字文字は、EUC-JPでは扱えないため、これがSJISのまま残って出力される。
つまり、0xF040〜0xF9FCとして残ります。
これはG1にあるJIS X 0208の文字と重なることもあれば、EUCとして不正な符号になることもあります。
どう考えてもバグとしか思えない動作です。
そして、この0xf0 0x40という符号をEUC-JPとして読ませて見ましたが、当然のようにEUC-JPの符号列としては認識しませんでした。Windowsとしては、この符号は出力専用のようです。
後日、CP51932の出力を書くとして、この間抜けな動作をそのまま再現するべきなのだろうか。外字は出力不可にした方が良さそうではあるが…
以下は、全てSS3によりJIS X 0212を処理することができます。
Forefox 3.0.5
Opera 9.63
Google Chrome 1.0.154.36
つまるところ、IE7だけダメ。
今回、この符号を実装しようと思ったきっかけは、「「[區鳥]」が「乗ｽ」に化けるメカニズム コードページ932-ウェブリブログ」を偶然に参照したことによります。
IE7のEUC-JPがSS3に対応していないことは実際の検証により分かっていましたが、SJISを介していたとは、そういえば考えたことがありませんでした。
EUC-JP系で、外字や98文字等を扱える符号には幾つかありますが、eucJP-openを21年1月9日に書いています。
CPはコードページといい、つまるところ符号を識別するための16ビットの数値です。
今回は、この件について記述します。
CP51932の概要
Windowsの標準EUC-JPデコーダは、JIS X 0208の範囲内しか対応していません。
つまり、CP51932はG3にあるJIS X 0212は対応していません。
G2にある、いわゆる半角カナには対応しています。
多国語対応のWindowsは、内部はUnicode(UTF-16)で動作します。
従って、入力されたEUC-JP符号列は、Unicodeに変換して使われます。
但し、その変換過程は先人たちの調査により、EUC-JP→SJIS→Unicodeの順になされることが、明らかとなりました。
CP51932→SJIS変換
全体的な変換処理は、次の通りです。
① アルゴリズム的に、EUC-JP(CP51932)→SJIS(CP932)
② 但し、JIS X 0208の範囲外となるものは、そのまま符号を残す
③ 変換表で、SJIS(CP932)→Unicode
例えば「森鷗外」の「鷗」はJIS X 0208にはなく、JIS X 0212またはJIS X 0213に存在します。
EUC-JPでJIS X 0212を使用する場合、文字はG3にあるためSS3(0x8f)を冠して「0x8f 0xec 0xbf」という3バイトの符号列になります。
さて、CP51932デコーダはSS3に対応していないため、これは変換せずそのまま残します。次に、0xec 0xbfをSJISに変換し、0xe6 0xbdとします。都合「0x8f 0xec 0xbf」という、異常な符号列が完成します。
SJIS→Unicode変換
次に、この文字列をSJIS(CP932)として解釈し、Unicodeへと変換します。
0x8f 0xec → U+4E57 (乗)
0xbf → U+FF7D (ｽ)
結果として、「森鷗外」は「森乗ｽ外」に文字化けすることになります。
理解に苦しむ挙動ですが、日本語Windowsは元々SJISで動作していたこと、SJISにある94区を超える位置にあるシステム外字への対応を維持すること等から、変換表はSJIS←→Unicodeが維持されているのだろうと推測されます。
従って、他の符号は、一旦SJISを介することになるのでしょう。
それは良いとしても、EUCの解釈と変換の過程は、明らかにおかしい。
未対応の文字が化けるのは仕方がないとしても、その化け方が美しくない結果となっています。
実装
gTefは、この異常なEUC-JPの入力に対応しました。
gTefの場合は、変換表はJISを基本としているなど内部動作は根本的に違っていますが、同様の結果が得られるよう、変換関数を幾重にも挟んで符号を弄ってみました。
もし万が一利用する必要がある場合は、入力の符号名を「CP51932」とします。
1文字の入力から、内部的に2文字に増えるため、入力処理(外部からMIXTUREへのEncode)の大きな改造が必要となりました。
出力処理(MIXTUREから外部へのDecode)はまだ書いていませんが、どうやら、次のようになるようです。
① UnicodeからCP932に変換
② IBM拡張文字(115区〜119区)は、NEC選定IBM拡張文字(89区〜92区)の文字に置換
③ アルゴリズム的変換により、SJISからEUCに変換
④ ③の過程で、94区を超えるものはSJISのまま残す
つまり、SJISでは扱えるU+E000〜U+E757の外字文字は、EUC-JPでは扱えないため、これがSJISのまま残って出力される。
つまり、0xF040〜0xF9FCとして残ります。
これはG1にあるJIS X 0208の文字と重なることもあれば、EUCとして不正な符号になることもあります。
どう考えてもバグとしか思えない動作です。
そして、この0xf0 0x40という符号をEUC-JPとして読ませて見ましたが、当然のようにEUC-JPの符号列としては認識しませんでした。Windowsとしては、この符号は出力専用のようです。
後日、CP51932の出力を書くとして、この間抜けな動作をそのまま再現するべきなのだろうか。外字は出力不可にした方が良さそうではあるが…
他のブラウザでの動作
以下は、全てSS3によりJIS X 0212を処理することができます。
Forefox 3.0.5
Opera 9.63
Google Chrome 1.0.154.36
つまるところ、IE7だけダメ。
参考文献
今回、この符号を実装しようと思ったきっかけは、「「[區鳥]」が「乗ｽ」に化けるメカニズム コードページ932-ウェブリブログ」を偶然に参照したことによります。
IE7のEUC-JPがSS3に対応していないことは実際の検証により分かっていましたが、SJISを介していたとは、そういえば考えたことがありませんでした。
補足
EUC-JP系で、外字や98文字等を扱える符号には幾つかありますが、eucJP-openを21年1月9日に書いています。
2008/12/26(金)02:01 |Comments(0) |Trackback(0) |製造開発 | [編集]
