ブラウザ別EUC-JP補助漢字のサポート状況（1）

EUC-JP補助漢字（JIS X 212）の処理をPHPやPerlなどにてどのように処理すべきかを考えるために、ここで、補助漢字や補助漢字でも表すことのできない外国語や記号について、各種ブラウザ別対応状況を詳しく調べてみたいと思います。その前に、前提となる知識として、以下の３つのサイトをご紹介したいと思います。

● IEがEUCのJIS X 212をサポートしていないのは規格違反なのか
http://mkosaki.blog46.fc2.com/blog-category-10.html

● Extended Unix Code - Wikipedia
http://ja.wikipedia.org/wiki/Extended_Unix_Code

● Bug 4873 –EUC-JPエンコーダは補助漢字を変換すべきではない
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=4873
（bugzillaの投稿。かなり活発に意見が交わされています。）を読んでみてください。

ここから分かるのは、IEの仕様もFirefoxの仕様もどちらが規格違反とかバグであるとかいうことは、ないようです。ただ、私は、IEの仕様に合わせるほうがいろいろ都合がよいと考えています。（誰がどのように・どんな名目や理由で合わせる作業をするのかという議論とかかわっていますが、その考えを述べるに当たっても、下記のようなテストは重要だと考えます。

こんなややこしいことを考えないためにも、EUC-JPではなくUTF-8でサイトを構築すべきであるという結論ももちろんありでしょうが、必ずしもそうできない場合もありますから、その結論はとりあえず「抜き」にして、別の対処案を考えてみたいです。）

実験１：各種ブラウザは「鷗外」をどのようにエンコードするか？（EUC-JPのページで）
（※ このテストには、HTMLページにメタタグによる文字コード指定（<meta http-equiv="Content-Type" content="text/html; charset=EUC-JP">）がブラウザによっては必須のようです。）

ブラウザ名	URLエンコード	デコードしたもの （ピンク部分は私が注目したところで、特別な意味はありません。）
IE7（Vista）	%26%2340407%3B %B3%B0	鷗 0xB3 0xB0
IE6（XP SP2）
IE5.5（Windows 2000）
Firefox 2.0.0.11 （Vista）	%8F%EC%BF %B3%B0	0x8F 0xEC 0xBF 0xB3 0xB0
Firefox 3.0β2 （Vista）
Firefox 1.0.8 （XP SP2）
Netscape 7.1 （Vista）
Opera 9.25（Vista）	%26%2340407%3B%B3%B0	鷗0xB30xB0 （Windows版IEと同じ挙動）
Opera 9.5β1 （Vista）	%8F%EC%BF%B3%B0	0x8F 0xEC 0xBF 0xB3 0xB0 （β版の挙動だからこうなのか、Operaは9.5以降、この方向性になるのでしょうかね・・・）
Safari 3.0.5 （Vista）	%B2%AA%B3%B0	0xB2 0xAA 0xB3 0xB0 「0xB2 0xAA」は「鴎」です。字自体を置き換えています。
Safari 3.0.5 （Tiger 10.4.11）
IE 5.2.3 （Tiger 10.4.11）	入力不能。コピー＆ペーストの時点で「?」に。
Firefox 2.0.0.11 （Tiger 10.4.11）	%8F%EC%BF %B3%B0	0x8F 0xEC 0xBF 0xB3 0xB0
Safari 2.0.4 （Tiger 10.4.8）	%3FB3%B0	? 0xB3 0xB0 コピー&ペースト時に入力した文字の表示はOKですが、POSTすると「?」になります。

Opera 9.5β版の結果が意外でした。9.5の正式版でどうなるかですね。


実験２：各種ブラウザは「髙﨑」をどのようにエンコードするか？（EUC-JPのページで）

ブラウザ名	URL エンコード	--
IE7（Vista）	%FC%E2 %F9%F5	0xFC 0xE2 0xF9 0xF5
IE6（XP SP2）
IE5.5（Windows 2000）
Firefox 2.0.0.11 （Vista）	%FC%E2 %F9%F5	0xFC 0xE2 0xF9 0xF5 つまり、この事例では、FirefoxはIEと同じ挙動を取ります。これが、先述のBugzillaにおける森山先生のコメント: 問題となっているのは、Firefox が POST の際のコードポイントではないでしょうか? 具体的には、JIS X 0212 補助漢字と CP51932 の 機種依存文字 (NEC特殊文字、NEC選定IBM拡張文字) の両方で同じ文字が定義されている場合に、Firefox では CP51932 のコードポイントが用いられて、CP51932 で定義されていないが JIS X 0212 で定義されている文字に関しては、JIS X 0212 のコードポイントが用いられているという点です。 に通じるのだと思います。
Firefox 3.0β2 （Vista）
Firefox 1.0.8 （XP SP2）
Netscape 7.1 （Vista）
Opera 9.25（Vista）	%FC%E2 %F9%F5	0xFC 0xE2 0xF9 0xF5 （Windows版IEと同じ挙動）
Opera 9.5β1 （Vista）	%FC%E2 %F9%F5	0xFC 0xE2 0xF9 0xF5 （結局、Firefoxとここも挙動は同じであり、結果的に、Opera 9.25とも同じであり、Windows版IEとも同じです。）
Safari 3.0.5 （Vista）	%8F%F4%F5 %8F%F4%B1	0x8f 0xF4 0xF5 0x8F xF4 0xB1 （原則どおり、補助漢字として処理）→ （2008年1月4日午前10時ごろ追記） Safariのエンコード方法は、eucJP-msに近いと言えるのかもしれません。
Safari 3.0.5 （Tiger 10.4.11）
IE 5.2.3 （Tiger 10.4.11）	入力不能。コピー＆ペーストの時点で「?」に。
Firefox 2.0.0.11 （Tiger 10.4.11）	%FC%E2 %F9%F5	0xFC 0xE2 0xF9 0xF5
Safari 2.0.4 （Tiger 10.4.8）	%3F%3F	? ? コピー&ペースト時に入力した文字の表示はOKですが、POSTすると「?」になります。或る意味、潔いです。

Safari 3のこの挙動には注意した方が良いですね。Firefoxとも違う処理になっています。

次に、補助漢字ではありませんが、参考までに、補助漢字に含まれない韓国語の場合、どうなるかを考えてみたいと思います。

実験３（番外編）：各種ブラウザは韓国語の「안녕하세요?」をどのようにエンコードするか？（EUC-JPのページで）
或る意味、当然の結果が出ました。

ブラウザ名	URL エンコード	--
IE7（Vista）	%26%2350504%3B %26%2345397%3B %26%2354616%3B %26%2349464%3B %26%2350836%3B %3F	数値参照文字 안녕하 세요?
IE6（XP SP2）
IE5.5（Windows 2000）
Firefox 2.0.0.11 （Vista）
Firefox 3.0β2 （Vista）
Firefox 1,0.8 （XP SP2）
Netscape 7.1 （Vista）
Opera 9.25（Vista）
Opera 9.5β1 （Vista）
Safari 3.0.5 （Vista）
Safari 3.0.5 （Tiger 10.4.11）
IE 5.2.3 （Tiger 10.4.11）	コピー＆ペーストの時点で文字化けするので、送信してもやはり文字化け。
Firefox 2.0.0.11 （Tiger 10.4.11）	%26%2350504%3B %26%2345397%3B %26%2354616%3B %26%2349464%3B %26%2350836%3B %3F	数値参照文字 안녕하 세요?
Safari 2.0.4 （Tiger 10.4.8）	%3F%3F%3F%3F%3F%3F	?????? 最後の「?」だけ意味合いが違いますが、EUC-JPのページではハングルの処理はできないようです。

韓国語に関しては、何とか対応しようとしているブラウザは全て数値文字参照方式を取っています。或る意味、当然の処理かもしれませんが、ここで「&」が登場するため、EUC-JPで構築されたブログや掲示板などシステムでは、エスケープされたまま、元に戻されないため、結局韓国語を表示させることは不可能であり、「UTF-8で構築されたブログや掲示板で投稿してください」ということになるのかもしれません。

韓国語はこうなりましたが、ではドイツ語の場合はどうでしょうか？

実験４：各種ブラウザはドイツ語の「möchte」をどのようにエンコードするか？（EUC-JPのページで）

ブラウザ名	URL エンコード	--
IE7（Vista）	m %26ouml%3B chte	文字実体参照 m ö chte
IE6（XP SP2）
IE5.5（Windows 2000）
Firefox 2.0.0.11 （Vista）	m%8F%AB%D3chte	m 0x8F 0xAB 0xD3 chte 「補助漢字」には、漢字だけでなく、ドイツ語のウムラウトやフランス語のアクサン記号が含まれているため、このような処理になっています。
Firefox 3.0β2 （Vista）
Firefox 1.0.8 （XP SP2）
Netscape 7.1 （Vista）
Opera 9.25（Vista）	m%26ouml%3Bchte	文字実体参照 m ö chte （Windows版IEと同じ挙動）
Opera 9.5β1 （Vista）	m%8F%AB%D3chte	m 0x8F 0xAB 0xD3 chte （β版の挙動だからこうなのか、Operaは9.5以降、この方向性になるのでしょうかね・・・。Firefoxと同じ処理です。Firefoxに追随？）
Safari 3.0.5 （Vista）	m%26%23246%3Bchte	数値文字参照 m ö chte （これは意外な結果。補助漢字に相応する文字は何でも0x8F～で処理するのかと思いきや、違いました。しかも、Windows版IEでは文字実体参照ですが、Safari 3は数値文字参照です。） eucJP-msとは違うということのようです。
Safari 3.0.5 （Tiger 10.4.11）
IE 5.2.3 （Tiger 10.4.11）	入力不能。コピー＆ペーストの時点で「?」に。
Firefox 2.0.0.11 （Tiger 10.4.11）	m%8F%AB%D3chte	m 0x8F 0xAB 0xD3 chte
Safari 2.0.4 （Tiger 10.4.8）	m%3Fchte	m?chte コピー&ペースト時に入力した文字の表示はOKですが、POSTすると「?」になります。とても分かりやすい仕様です。

ドイツ語のウムラウトは、EUC-JP補助漢字（JIS X 212）に入っていますので、Firefoxなどでは原則どおりの対応をしようとしているのが分かります。

実験5：各種ブラウザは「©♦」をどのようにエンコードするか？（EUC-JPのページで）
（♦は補助漢字には入っていません。）

ブラウザ名	URL エンコード	--
IE7（Vista）	%26copy%3B %26%239830%3B	文字実体参照+数値文字参照 ©♦
IE6（XP SP2）
IE5.5（Windows 2000）
Firefox 2.0.0.11 （Vista）	%8F%A2%ED %26%239830%3B	0x8F 0xA2 0xED ♦ 「©」だけ補助漢字扱いで、「♦」は数値文字参照処理です。
Firefox 3.0β2 （Vista）
Firefox 1.0.8 （XP SP2）
Netscape 7.1 （Vista）
Opera 9.25（Vista）	%26copy%3B%26%239830%3B	文字実体参照+数値文字参照 ©♦ 結局、Opera 9.25は全てにわたって、IE7やIE6と同じ挙動です。
Opera 9.5β1 （Vista）	%8F%A2%ED %26%239830%3B	0x8F 0xA2 0xED ♦ 「©」だけ補助漢字扱いで、「♦」は数値文字参照処理です。 （β版の挙動だからこうなのか、Operaは9.5以降、この方向性になるのでしょうかね・・・）
Safari 3.0.5 （Vista）	%26%23169%3B %26%239830%3B	数値文字参照+数値文字参照 ©♦ （これは意外な結果。両方を数値文字参照にするとは、IEともFirefoxとも違う第三の処理体系です。）
Safari 3.0.5 （Tiger 10.4.11）
IE 5.2.3 （Tiger 10.4.11）	入力不能。コピー＆ペーストの時点で「?」に。
Firefox 2.0.0.11 （Tiger 10.4.11）	%8F%A2%ED%26%239830%3B	0x8F 0xA2 0xED ♦ 「©」だけ補助漢字扱いで、「♦」は数値文字参照処理です。 （話がそれますが、Mac版Firefoxではフォントの設定の問題なのか、「♦」は期待通りには表示されませんでしたが、POST後のURLエンコードは予想していた通りになりました。）
Safari 2.0.4 （Tiger 10.4.8）	%3F%AC%A8	?0xAC 0xA8 コピー&ペースト時に入力した文字の表示はOKですが、POSTすると「©」は「?」になります。ところがダイヤマークは、別の2バイトの「?」（黒いダイヤマークの中に白抜きの？マーク）に変わりました。

今までの内容をまとめますと、次のようになると思います（順不同。順番に意味はありません）。

• Windows版IEの処理は、IE5.5・IE6・IE7で全て同じです。バージョンアップによって挙動が変わった事実はありません。
  
  
• Firefoxは、Windows版とMac版で挙動が異なることはありませんでした。
  
  
• Netscape 7.1はFirefoxと挙動が異なることはありませんでした。つまり、Mozilla系ブラウザの挙動も変化がありません。（Netscape 6は調べていません。）
  
  
• Mac版IEはUnicodeのサポートが中途半端なまま、開発が終了し、配布も中止になったため、テストからはずしたほうが良さそうです。
  
  
• Mac版Safariは、2.0.xまでは、補助漢字を処理できず、処理できない文字は全て「?」にしていた。
  
  
• Safariは3.0xに進化する中で（Mac版だけでなくWindows版も）、補助漢字に対する処理を大幅に進化させました。しかしながら、Windows版IEともFirefoxとも異なる仕様を採用しました。
  
  
• Opera 9.25まではWindows版IEと全く同じ挙動を示していたOperaがなぜか、Opera 9.5β版では、Firefoxと同じ挙動を取るようになりました。9.5 正式版では、Windows版IEの挙動に戻るのか、ベータ版と同じ仕様に落ち着くのかは分かりません。
  
  

これらのブラウザの挙動の違いを元に、PHPやPerl+MySQLなどのデータベースで構築されたサイトを運営するに当たり、どのように処理するのが望ましいのかまで考察したかったのですが、時間などの関係で本稿はここまでにしたいと思います。



XOOPSも簡単インストーラで、すぐに利用可能です。