top / index / prev / next / target / source
日記形式でつづる いがぴょんコラム ウェブページです。
x-windows-iso2022jp を使うと、極めて Outlook風の JISコードを利用することができるようになります。
Javaによるソフトウェア開発において、JavaMail APIを使った Outlook風の JISコード (ISO-2022-JP) を利用したメール送信をどうしても実現したいという局面があります。
本来は UTF-8を用いて 文字化けのリスクの少ないメール送信方式を選択したい。
しかし古いメールソフトなどでは UTF-8 は対応されていない。(もしかしたら携帯メールも同様にUTF-8は扱うことができない?)
UTF-8に対応していないメールソフトを救うために、やむを得ず 古くから日本国内で使われてきた JISコード (ISO-2022-JP) を利用することを検討する。
しかし 純粋な JISコード (ISO-2022-JP) では 「○1 (まるいち)」 や「ローマ数字」のような文字を扱うことができない。 ※Javaで ISO-2022-JP によってエンコード仕様とすると 「?」という文字に化けてしまう。(文字化け)
Outlook風の JISコード (ISO-2022-JP) を 何とか メール本文やメールSubjectで使いたい。 ※注意: この方式を選択すると、MacやLinuxなどでは表示できない (文字化けしてしまう) メールを送信することになります。
こういう やむを得ない状況を打開したいという局面にぴったりのエンコーディングが x-windows-iso2022jp として Javaでは提供されています。今日初めて知りました。 x-windows-iso2022jp を使うと、極めて Outlook風の JISコードを利用することができるようになります。(細部についての妥当性については未試験)
また更に便利なことに、x-windows-iso2022jp では 重複符号化領域のコードについても、適切に Outlook風のUnicodeマッピングを行ってくれます。重複符号化領域のコードは Oracleにデータを格納して取り出すと、良く問題として顕在化しやすいものとして知られていることのひとつです。
Javaでは プログラミングのなかで気にせず x-windows-iso2022jp を利用する方法も提供されています。JavaVMの実行オプションに「-Dsun.nio.cs.map=x-windows-iso2022jp/ISO-2022-JP」というスイッチを利用すると、JISコード (ISO-2022-JP) の挙動を x-windows-iso2022jp に強制的に上書きするという方法が存在するのです。JavaMailにおいて、メールのSubjectを実際のエンコーディングとメール電文に乗せるエンコーディングとを変更して調整するメソッドが提供されていないので、このスイッチの存在は とても便利です。
Shift_JIS と MS932 (あるいは Windows-31J)とのマッピング同様の関係が、ISO-2022-JP と x-windows-iso2022jpとの間にあるのですね。とても勉強になりました。
ただし、、、妥協の産物であることは しっかりと理解しておく必要があります。
本来あるべき姿としては、JISコード (ISO-2022-JP) の場合には メール本文やSubjectに 「○1 (まるいち)」 や「ローマ数字」のような文字を扱わせないように誘導すべきなのでしょう。あるいは世のメールソフトが UTF-8 を適切に扱うことができるようになれば良いのでしょうけれどもね…。
MacやLinuxなどで文字化けすることを覚悟のうえ 利用する技術となります。
「x-」といえば、「x-sjis」という過去の苦い経験を連想します。「x-」 ではなく IANAに登録されているエンコーディングを利用すべきなのです。 しかし 「x-windows-iso2022jp」こそが Outlook風 ISO-2022-JP を実現する手段なので、悩ましいところです。
関連リソース
関連する日記
仕事で Flash / Flex 2 を扱う必要性が ほんのりと あがってきたので、ごくごく簡単に Flex 2 を調査しはじめました。
Flex 2 SDK などが無償で提供されていることを、今日 初めて知りました。