スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ISO-2022-JP 丸数字等の文字化け

ベンダーからjavaの質問を受け、答えることに。バージョンは1.4系。
POPサーバからメールを読み取り、Unicodeに変換する際に一部文字化けすると。
通常、メールはJISでエンコーディングされているので、ISO-2022-JPを指定して変換する。

その前にもShift_JISについて質問を受けたときは、すぐにShijt_JISとWindows-31Jの混同の問題だとすぐにわかり、SJISではなく、MS932を使えと回答し、簡単に問題は解決した。

ところが今回はそうは行かない。機種依存文字はもちろんのこと、
―~∥-
これらの文字も文字化けする。new String(bytes, "ISO-2022-JP");でファイルから読み込んだバイト配列をJISコードとして読み取り、Unicodeへ変換するのであるが、Unicodeへのマッピングがおかしい。Unicodeの見地からすれば、これらの文字はJISとShift_JISでは別物のようだ。これは次のような、修正メソッドをかませれば修復できる。


public static String JIStoUnicode(String s) {
char[] c = s.toCharArray() ;
for (int i = 0 ; i < c.length ; i++) {
switch (c[i]) {
case '\u2014': // '―'
c[i] = '\u2015' ;
break ;
case '\u301c': // '~'
c[i] = '\uff5e' ;
break ;
case '\u2016': // '∥'
c[i] = '\u2225' ;
break ;
case '\u2212': // '-'
c[i] = '\uff0d' ;
break ;
default:
break ;
}
}
return new String(c) ;


ところが、丸数字等の機種依存文字については、同じようには行かない。Unicodeへの変換の際に対応する文字がなく、すべてfffdに変換されてしまっているので、コンバータに手を加えるほかない。コンバータがどこにあるかソースに当たってみた。
sun.nio.cs.ext.ISO2022_JP
というクラスだったが、さすがにこれには手を加えられない。

ネットで同様の問題にどう対応しているのか探してみたが情報はほとんどない。@itの会議室で対応のために自作でコンバータを作った旨書いてあったが、一般にこのように回避するというのはなかった。自作で作らせるのは大変なことだろうという気がする。

そもそも、丸数字を含むNECやIBMの拡張コードは、ISO-2022-JPに規定されていないのだから、javaのコンバータが変換しなくてもいいのは正論だ。ただ現状ではそうも行かない。

丸数字や半角カタカナをメールで使ってはならないというのはもはや過去の話だ。いまだに、「ネチケット」と称して、それを振り回しているのも多いが、現実上、丸数字は、メールで当たり前のように飛び交っている。もっとも半角カタカナは全角にメーラで変換されてしまうことが多いが。(メールマガジンのように不特定多数への送信にはいまでも気をつけた方がいいとは思う)。

JISコードでは、丸数字は2D21から割り当てられ、Shift_JISでは8740から割り当てられている。nkfコマンドを使うと、相互の変換は正しく行われる。IEでもJISの丸数字は正しく表示される。Outlook Express、Wzエディタ、BeckyでもOK。しかし秀丸だと駄目だった。

また、HotmailやYahooメールなどのWebメールも、JISで送ったメールの丸数字はきちんと表示される。それぞれShift_JIS、UTF-8に変換されているが。

ユーザにとっては、普通にメールで使えているのに、Javaのアプリケーションにしたとたんに使えなくなるというのは、おかしい、ということになる。Webメールやメーラーでjavaで作られたものはないのだろうか。あまりにも情報がなさ過ぎる。まあ、他言語でも同じようなものだったが。

nkfにしろ、対応エディタにしろ、JISとShift_JISの変換は計算式を当ててやっているだけだと思うが、Javaのコンバータでも同じようにしてくれればいいと思う。おそらくUnicodeへのマッピングは規定していないのだろう。1.5だとどうなのだろうか。

自前で作るか、nkfをjavaから呼び出して、Shift_JISに変換して取り組むか。
文字コードは厄介だ。

スポンサーサイト

struts、CSVParser

久しぶりに投稿する。
自分で、半分趣味で始めたプロジェクトを暇を見ては進めている。多くは通勤時間にやっている。そうしてチビチビとは進歩するのだが、今日はまとまった時間をとってやった。
基本的に、ソフト開発とは時間のかかるものだ。どんな効率的な方法をとったとしても、やはり量が多いと時間がかかる。
今回struts + MySQLだったが、時間をとられるのは、その調査だ。細かい部分まで理解していないと、あるいは適切なマニュアルがない限り、フレームワークを使った開発は、かえって時間がかかる。今回の場合、自分の慣れた方法で作ったのなら、倍以上早く進んだと思う。単にロジックを駆使すればいいだけだからだ。

今日はつまらないことでかなり長い間時間をつぶした。
<logic:iterate id="item" name="HogeForm" property="list" indexId="idx">
としたとき、ActionFormのsetterで、
public List getList() {
return list;
}
とすると、listに対するゲッターメソッドがありません。と出てきてしまう。getterはあるのになぜだ、とあれこれ手順を変えて、見当違いのところを変えて時間を費やしてしまった。
public Object[] getList() {
return list.toArray();
}
とする必要があったのだが、こんなことはstrutsの実装を詳細にわかっていないと気づかない。チームで開発するなら、チーム内に一人精通した人がいればいい。というか絶対に必要だ。そして問題があったときにその人に聞くようにする。
一人で開発をするとしたら、その一人が精通する必要がある。そのためには多くの学習時間が必要になる。
フレームワークの学習時間+効率化された開発時間×そのフレームワークで行うプロジェクト数
を計算してみて、どっちが効果的か検討する必要があるだろう。フレームワークはバージョンアップするし、別の効率的なものも出てくるし、次のプロジェクトでは別のものを使うかもしれない。

それと、今日、便利なものを探した。
javaのCSVのパーサーだ。
http://ostermiller.org/utils/CSV.html
最初,jakartaのcommonsあたりになかっただろうかと思って再度目を通したが、そんなものはなかった。Commonsは結構便利そうなものがあるかのように見えて、実際大したことないものが多い。jakartaのDbUtilもそのままでは使えないので改良する必要があった。
CSVのパースなどは頻繁に使われるものだから、こういうのを共通化部品として取り上げてもいいと思うのだが。StringTokenizerでは全く不十分で、今までも自作してきたが、今回はなるべく共通のもので行きたいと思った。
上記のリンク先のものは、Freewareだし、そのほかにも使えそうなものが結構ある。


プロフィール

dayan

Author:dayan
小職は、SE(システムエンジニア)を専門としておりますが、技術的な情報を中心に、それ以外に経済関連の日記、たわいもない日記も載せていきます。
[公式HPもよろしく!]

天気予報

-天気予報コム- -FC2-
リンク
ブロとも申請フォーム

この人とブロともになる

カテゴリー
最近の記事
ブログ内検索
最近のコメント
最近のトラックバック
RSSフィード
月別アーカイブ


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。