なんとなくJavaMail - かずめもラジカル - AndroidとDebianのある生活 -

昔プロジェクトで使ってたJavaMailのhackが出てきたので、今のJavaMailはどうなっているのか確認。
現在はオープンソースとしてBSDとかGPLライセンスになっていたりして、やっぱり時代が進んでいるんだなぁとか。

Mercurialに寄り道

で、JavaMailのソースをリポジトリから引っ張ってこようと思ったらSubversionではなくてMercurialとかいうもの。調べたら分散リポジトリとか。Gitとかと同じ考え方かな。ネットワークに接続していなくてもチェックインできたりするから、ノートPCで太平洋の上でも開発ができる、と。
というわけでTortoiseHGというやつをインストール。よくわからん。リモートのリポジトリを元にローカルにリポジトリを作ってしまうわけだな。ふむふむ。ディスク容量が潤沢となった今でこそのソリューションという感じ。

JavaMail1.4.2

で、JavaMailに話は戻るわけで、当時のhackというのは、ISO-2022-JPでも「?」とか「〜」とかちゃんと使えるようにといったもの。
hack箇所はcom.sun.mail.handlers.text_plainを修正(性格には修正コピー)して、OutputStreamWriterを独自のものにすりかえるといったもの。独自のOutputStreamWriterではISO-2022-JPのときだけ別処理。文字列をUnicode→MS932にしたうえで、ビット操作でEUC化してた。
じゃ、JavaMail1.4.2とかになってどうなってたかといえば(今考えてみれば当たり前だが)そのまんま。

x-windows-iso2022jp

で、みんなはどうしてるのかと探したら、いがぴょんの日記ウェブページv2の2007/04/27で「x-windows-iso2022jp」なるエンコーディングに出会う。
なるほどね〜、と思ってみたが、メールヘッダにそんな変なエンコーディングが書いてあるわけもなく、さてどうするかと思って読み進むと、

JavaVMの実行オプションに「-Dsun.nio.cs.map=x-windows-iso2022jp/ISO-2022-JP」というスイッチを利用すると、JISコード (ISO-2022-JP) の挙動を x-windows-iso2022jp に強制的に上書きするという方法が存在する

なるほろ〜。これで何も考えずにJavaMailが使えると。
じゃ、もしかすると、Shift_JIS/windows-31j(MS932)問題*1もこれで一発解決？とか思ってたら、やっぱり似たような話が。(http://d.hatena.ne.jp/cazzie/20080312/1205329765)
とはいえ、結局JavaMailで日本語のメールを扱おうとすると、細かい問題がたくさんあるんだよなぁ。

「JavaMail完全解説」サポートページ

ということで、古きよき時代を思い出して「JavaMail完全解説」サポートページにアクセス…ってサーバ落ちとるやんけ。
最近コンテンツの入れ替わりが多い気がする。復活するかもしれなけど、念のためhttp://www.archive.orgのお世話になって最低限必要なところを確保。googleのキャッシュにもあるということは一時的なダウンなのかも。
見てて思ったけど、これのJDK1.6/JavaMail1.4版とかつくったらどうなるかな。需要は結構あったりして。

ということで

今日はフレームワークの速習はお休み。そろそろworkflowも再開しないと…。

*1:Java1.3から1.4に移行した頃に出てきたかなり深刻な問題