今日の文字化け

今回のはまだ解決してない。

Oracle11gのchar項目に入ってる2バイト文字が
Javaでファイルに書き出した場合に文字化けしている。

特殊な2バイト文字ではなく、簡単な漢字だ。
2バイト文字が全滅。

JavaではOutputStreamWriterにエンコーディングに渡し忘れているようだが、それを直したとしても恐らく解決しないだろう。

HP-UX上のWebSphere6.1 fixpack19なんだが、file.encodingはPCKのようだ。-D指定もしてない。

簡単な漢字の例。
Oracle側はdump関数で確認。
1バイト目、144。
2バイト目、70。
これは、「信」という字だ。

Javaはこのバイトの組み合わせを元にPCKで文字を作れる。

僕の知識からはJavaで化けたわけではないという予感が走る。

不安な点はいくつもある。
varchar2でもncharでもなくcharであること。
11gではサポート外のojdbc14.jarの使用。
誤用と思われるnls_charset12.jarの使用。

僕が昔調べた感じでは、10g以降に最後のjarは要らないはず。仮に加えるとしてもorai18n.jarか何かを自分で固めるのが正しかった気がする。
いったい誰が始めた風習なんだろう。。。
9iの時代の話なんじゃないの？

こいつはsetArrayを使うのにいるらしいのだが、根拠となる技術資料は教えてもらえてない。出展は大事だよ。jdk1.4をサポートしない11gがなぜ1.2をサポート出来んだいって話もあるな。とりあえず動かしたいもんが動いたからそのままやってるけど、誰もnls_charset12.jarの必要な理屈を知らない。Type4ドライバの場合はドライバ側で文字コード変換するんだっけ？

JDBC開発者ガイドは読もうよって、前から言ってるつもりなんだけどなぁ。

JA16SJISTILDEは本当にcharにも効いてるのかな。Javaに渡す時にAL16UTF16が使用されてないだろうか。
だってncharじゃないし。。。

全ての2バイト文字が化けるのなんてそんなにないよな。

WASが馬鹿だから、暫定的にojdbc14.jarを使うことにしている。ojdbc5.jarを使おうとすると、設定した覚えのない10gのヘルパークラスを呼んで例外出しやがる。マジ勘弁してください。11gのヘルバークラスを設定してるのに、なんでそいつが動くねん。クラスパスにojdbc14.jarが居なくても起こる。早く直して欲しい。

ふぅ、明日あたりデバッグコードを埋め込んでみるかー。いや、まずはjava.sqlをDEBUGにして、iBATISにselect結果を出力させようかな。
うん、そいつがベターに違いない。
きっと化けてるはずだ。それが分かると、JDBCドライバ周辺の問題と見做して次の確認に移るかな。

早いところ暇が欲しい。シフトJIS系以外の文字コードも試したい。ホストから移行するとき、エビシディックをそのまま持ってくることもあるみたいだね。僕も昔使ってたことあるし、最近2人から質問されたことあるし、IBMも日立もひっくるめて、Javaの見地から実験しときたい。日立の文字コードなんてJavaで使えるだっけ、とかね。