JISAutoDetectの使いどころ

以前のエントリで、「1.4.2_10のJISAutoDetectがClassCastExceptionを投げる」というJavaのバグについて良く耳にすると書きましたが、実際、「JISAutoDetect」って業務などで使われているのかが気になりました。

JISAutoDetectって?

「JISAutoDetect」は、「Windows-31J」「EUC-JP」などの文字エンコーディング名と異なり、対象の文字の内容から、使用する文字エンコーディング自動判別して変換してくれます。
選択される文字エンコーディングは、下記の3つとなります。(Sun J2SE 1.4.2 Windows上で確認)

Sunが公開している、サポートしているエンコーディング一覧を見ると、「Windows-31J」ではなく「Shift_JIS」のように書いてありますが、実際動かしてみたら上記の通りでした。(Windows上だから?)

日本語扱う時は、全部このエンコーディング使えばいいのでは?と錯覚してしまうような優れものですが、下記のような問題(とういか注意点)があります。

最終的に使用された文字エンコーディングが何であったのか検出できない。

Windows-31J」は、「EUC-JP」「ISO-2022-JP」にて下記の文字のUnicodeマッピングが異なります。

¢£¬‖−〜―

そのため、使用された文字エンコーディングがわからないと、これらの文字がどちらのUnicodeになっているのかが判別出来ません。

3種類以外の文字エンコーディングを判別してくれない。

先に述べた3種類のエンコーディング以外は判別してくれないため、「UTF-8」「UTF-16」が読めなかったり、また日本語EUC機種依存文字(カッコ株など)が入っていた場合、文字化けします。(「EUCJP-OPEN」ではなく「EUC-JP」が選択されるので)

判別が完璧では無い。(=誤識別の可能性がある)

対象の文字が少ない場合、文字エンコーディングを特定することが出来ない場合があります。
この場合、Windows-31Jが優先されることが多く、EUC-JPの文字列が化けてしまったりします。
どのような場合に発生するかというと、、
たとえば、EUC-JPで「小」という文字は、バイトでは「0xBEAE」となりますが、この「0xBEAE」をWindows-31Jでエンコーディングすると、「0xBE」が「セ」(半角カナの"セ")、「0xAE」が「ョ」(半角カナの"ョ")となってしまいます。
文字エンコーディングが特定出来ない場合、Windows-31Jが優先されるので、上記の例だと「小」ではなく「セョ」としてUnicodeに変換されてしまうようです。(これは、Javaに特化した話では無く、文字コードの自動判別を行う場合は必ず付いてくる問題です。)

まとめ

「JISAutoDetect」の使用は出来るだけ避けるべきではと思います。(当然、やもえず使わなければならない場合もあるかもしれませんが…)
今のところ、「JISAutoDetect」を使用したプロジェクトに参加した事は無いです。もっぱら見かけるのは、技術書やサンプルプログラムの中ぐらいでしょうか。

半角カナと、Windows-31Jとその他のエンコーディングで異なる『¢£¬‖−〜―』について気をつければ、使えそうな気もしますが…