JREの違いによる文字化けの可能性

今日のアハ体験。

winXP上にて、SunJavaとIBMJavaでは、異なるコードポイントになる文字を発見した。

この実験で、文字は、intからbyteを作り、シフトJIS系を表せる2つのbyteを組み合わせ、エンコーディングをStringのコンストラクタに渡しながら生成している。

PCKを渡した場合に、JREによってコードポイントが違う文字がいた。
0x815Cのダッシュがそれだ。
ダッシュは、Windows-31JとShift_JISでの文字化けでは代表的な部類に入る文字だが、同じエンコーディングでコードポイントが変わるなんて迷惑極まっちゃったね。

他にもPCKでは、SunJavaでは文字になるが、IBMJavaでは文字化けするものもあった。
㍉(ミリ)などである。

僕の実験の仕方が悪いのだろうか？

PCKでも、他の文字は普通に出来ている。
この違いはなんだろう。

PCKはSolarisで使われることが多いだろうから、きっとSunの挙動が正しいと思う。

SolarisのページにはPCKの16進の表がある。
残念ながら、Unicodeへのマッピングは載ってないが、Unicodeコンソーシアムに行けばきっと置いてあるんだろう。

この表に㍉(ミリ)は確かに載っている。

となると、IBMの実装ミスの可能性がまず考えられる。
他に、IBM PCKが存在する可能性も考えないといけない。
とは考えても、実装ミスな気がする。またはJPを表すようなものをPCKにくっつけないとダメだとか？
それはCharSetあたりをグリグリやればどんなエイリアスがあるか等を調べられたはずだから、今度また調べるとしよう。

実験は、WAS6.1fixpack19でのJREを使っていて、ASTからの実行ではなく、ASTでコンパイル済みのクラスを適当な場所に配置して、エンコーディングやら出力先ファイルを引数として渡して実行している。

出力ファイルに関するエンコーディングは関係ない。なぜならば、コードポイントやバイトを16進で表してるだけなので、英数字しか出力してない。
ダブルクォーテーションによる文字も使ってないため、コンパイルに纏わる文字化けでもない。

javaでたたくとhotspotが動いていた。
だからIBMのをためすときは、明示的にフルパスでWebSpere/AppServer/java/bin/java.exeを叩いた。

あまり実験方法に大きな落ち度を感じない。

byteとcharのマッピングは、sunパッケージの方が担当しているんだが、こいつの実装が間違ってるんじゃないかと思う。
リフレクション使って、保持してるcharやbyteをダンプして、SunとIBMでなにが違うか
試した方が良いのだろうか？
EuropeでJDK6.0を見ると、sun.nio.cs.ext.JIS_X_0208_Solaris_Decoderが㍉(ミリ)を保持してるようだ。
仮に、sun.io.ByteToCharPCKの実装が、sun.io.ByteToCharJIS0208_Solarisなどの_Solarisありのクラスを呼んでないとかだったら嫌だな。そうだとしても、コードポイントがずれる件は納得出来ない。来週確かめてみよう。

IBMの人に疑問符をぶつけてみよう。

前にもあったけど、きっとまたこの手の質問は海を渡るんじゃなかろうか。

WAS7.0が手に入ったら、そっちでも試しみようか。

各社が自社のJVMとJavaAPIをもつのは構わないが、勝手に文字を乱さないで欲しいと願う。ただでさえシフトJISは扱いにくいんだ。詳しい人間も多いとは思わない。

風間さんという方はお会いしたことはないが、かなり尊敬してますぜ。あと、どこぞの図書館の人もすごいよね。