JavaMail特殊文字付本文が文字化けで困ってい

現在JavaMail（Ver1.4）+JAVA 7を使用して、あるメール配信システムを
構築しています。仕様上特殊文字を使用しなければならないので、
受信メールに特殊文字付本文が文字化けで困っています


JavaMailのバッチがIBMのUNIX系AIXサーバ（文字コードがCP943C）
に置いて、起動する

メール本文データがIBMのDB2（文字コードがCP943C）から取得し、
Stringのhonbun_DB変数にいれる。

メール送信の本文が

String honbun = new String(honbun_DB.getBytes("ISO-2022-JP"),"ISO-2022-JP")
msg.setText(honbun,"ISO-2022-JP");
メールのヘッダーが
msg.setHeader("Content-Type", "text/plain; charset="+"ISO-2022-JP");
msg.setHeader("Content-Transfer-Encoding", "7bit");


問題点：
getBytesでISO-2022-JP範囲外文字（いわゆる機種依存文字）すべて？に
置き返されます。

送信メールに、(1)(株)といった機種依存文字、NEC拡張外字が入っている
場合、文字が化けます。

ネットで得た対策方法について、以下方法が試しました。

対策１：
Javaの起動オプション-Dsun.nio.cs.map=x-windows-iso2022jp/ISO-2022-JP付ける
こちらのオプションがoracle者のJVMの有効で、現在のシステムがIBMのJVMを使用して
いるので、効かないです。

対策２：
本文がshift-jisにする手もありますが、APPLE社のMAC、iphone端末で、同様に
機種依存文字が化けます。

対策３：
String honbun = new String(honbun_DB.getBytes("ISO-2022-JP"),"ISO-2022-JP")
の代わりに、getBytes()使用せずに、独自のCP943Cの文字コードからISO-2022-JP
の文字コードに変換するロジックを組むという提案（機種依存文字でも、getBytes()みたいの
？に置き換えではなく、JIS範囲コードに変換）もあった。品質の懸念があるため、採用難しいところ。

上記対策１，２、３以外の方法があれば、教えていただけると助かります。
例えば対策３の機種依存文字か、ISO-2022-JP範囲内文字か、すべてJISコードに変換できる
ライブラリなど

長文となって申し訳ありません。

No.1 回答者： hue2011 回答日時： 2014/07/27 09:04

この話は高級な話でもなくシンプルなことで、インターネットの話ではありません。

文字化けということをよく理解していない人が多いと思います。

文字をどう人に伝えるか、で、文字コードというものがあるわけです。
半角文字で知られる８ビット文字で、16進41とすれば、みんなでAという文字だと思おうという提案がありました。
これがASCIIコードという話です。漢字も何もない時代の話です。
保存するほう、読む方が同じルールで読み書きすれば問題ないはずです。
さらに、データのはじまりや終わりを示すマーク、これ以降別のルールでコードを処理するよという特殊記号を用意しました。
全然問題なくなるはずです。

しかしながらそうはいかなかった。ABC,abc,数字、!#などの記号を全部合わせても８ビット256の枠には余地があります。
さらに、英語ばかりというわけにいかないので、ある領域を半角カナにつかうことにしました。
ここが半角カナであるということが合意できている機械同士では間に合います。
しかし、ここをアキ領域だと思う日本語以外の文化のひとたちはウムラウト文字やティルド文字を割り付けます。
もしかれらが半角ドイツ語文としてデータを送信したとして、受け取り側がカナ文化圏なら異常に化けまくった文に見えます。

本来別のコードでやり取りしてる場合は「文字化け」という概念はなかったのです。
別の世界のコード同士ですから。
それが、一部でも共通したコードを使うから「文字化け」となるのです。

話をすこしはやめにします。
16ビットを使う全角コードというものがでてきて、日本語文字を統一するためにJISコードが現れます。
これはコンピュータの機種によって全員が共有できなかった。
半角のときに話しました、「別のルールでコードを処理する」というのはエスケープコードです。
これを使って漢字と半角を切り替えるとそのコードを読みそこなうとそれ以後の文が全部化けます。
そこで、それが不要な、最上位ビットをONにしたコードShift-JISというものがでてきたりします。
JISとShift-JISは相互変換可能ですから、相手がどちらのコードを読むかと意識すれば問題はないはずです。

しかしながら、ここでも「文字化け」が起きます。
機種依存文字です。○で囲んだ数字だとか括弧つきの株マークがそうなります。
また、パソコン通信ワープロ通信というものがさかんになり、アキ領域に自分らだけに通じる文字をいれる使い方をする人間が出ます。
猫マークだとか、禿おじさんとかを使いました。
さすがにこれは別の人にはつたわらないだろうと意識しているといいのですが、パソコン通信初心者は、まねき猫で記事を囲んで発信し、読めないのはなぜだという騒ぎになったことｂがあります。

いいでしょうか。話はたったひとつのことです。
自分の使っている文字がどの範囲まで同じ意味で伝わるかです。
これはルールで決めているのですが、意識しなくなる人、最初から知らない人がでてきます。

また話を早めます。コードのサイズはさらに倍になります
UNICODEという、国際的に安全だということを目指して使う文字がでてきました。
日本語であれ中国語であれドイツ語であれ表現できる理想に向かいたいということです。
うまくいくか。かならずしもそうではない。
なぜか。そこに用意されていない文字があるからです。

漢字でいいますと、たとえば山崎の「崎」の文字だとか渡辺の「辺」の文字の、形が違うものがそもそもいくつもあります。
自分の名前の場合点がひとつないだけでもこだわって直させますから、ほんのちょっと違う異字を必要とするからです。

では、たとえば戸籍課がその字を作って処理したら、戸籍簿や住民票では大丈夫になりますが、別の市区町村に引っ越ししたらそれきりです。
もちろんそれをもとに社員名簿をつくろうとしたら会社でつくらなければなりません。
だから、非常に珍しい文字を使う名前の人は「あきらめる」しかないのです。
運用で対応する、という言葉になります。

こういう事情ですから、HTMLで文字コードを変更したりしても完璧になることはあり得ません。

SEは、特殊文字を使わないで済む運用提案をするべきなのです。

どうしても使いたければ、画像にして、文章のなかに<img>でいれるしかありません。
src=をサーバー内に登録しておけば、そのページを見る分については問題はなくなります。

この回答へのお礼

hue2011さん
早速な回答ありがとうございました。
既存の同様機能の旧メール配信システムがあって、特殊文字が使用できて、
新旧比較でレベルダウンにならないように、いろな案を探しています。

お礼日時：2014/07/28 23:33