BOM 付き UTF-8のトラブル

| コメント(0) | トラックバック(0)

入力としてUTF-8のテキストファイルをとるJavaプログラムでうまくいかないことがありました。

テキスト形式で入力されたデータを処理するプログラムなのですが、ファイル中に存在するはずのデータがないといってエラーになる。

テキストエディタで開いても、ExcelやLibreOffice Calcで開いてみても、ファイルに異常は見当たらないし、問題のデータもきちんと記述されているようにしか見えない。

実はこのエラーの原因は、入力のテキストファイルにBOMが付いていることでした。BOMがどういうものかは『プログラマのための文字コード技術入門』をご覧ください。

Javaで書かれた処理プログラムがUTF-8のテキストを読み込む際に、BOMを消費せずに単なるUnicode文字のように扱うため、1行目のデータの先頭にゴミが付いた状態になっていたのです。それで、見えないゴミ付きのデータになってしまい、意図どおりに動作しないし、テキストエディタで開いてみても異常に気付かなかったわけです。

JavaのライブラリでUTF-8のテキストを読み込むとき、先頭にBOMがあると、それを単なるU+FEFFという符号位置の文字データとして読み込んでしまいます。本来のBOMは、Byte Order Markという名前のとおり、バイト順を示す役割のものであって、文字を符号化したデータの一部ではありません。UTF-16/32と違ってバイト順の問題のないUTF-8にBOMを付けるべきかという問題は議論が分かれるところかもしれません。しかし現実にはBOM付きUTF-8は生成されることがあります。

ウェブ検索で「java utf-8 bom」などとしてみると、BOM付きUTF-8をJavaで読み込んでトラブルになった話が複数出てきたり、また互換性のためにJavaではUTF-8読み込み時の挙動を変える予定はなさそうだという話が出てきたりします。

自分で対策をするしかないようです。

ちなみに、iconvのUTF-8も同じようにデータ先頭のBOMを単なる文字として扱うということを、以前当ブログの記事に書きました。

トラックバック(0)

トラックバックURL: http://yanok.net/yanok/mt-tb.cgi/454

コメントする

最近のブログ記事

Jアラート訓練メールで文字化けとのニュース
一昨日のことですが、中国・四国地方から文…
任俠の第3水準漢字
ユーモラス、と言っていいのか分かりません…
ふるさと納税で奥尻島のワインを頂きました
奥尻島は北海道の南西の方に浮かぶ島です。…
電子マネーの優先順位を考える
このブログを電子マネーとクレジットカード…
電子マネーiDの隠れたお得
iDというのはSuicaやEdyのような…

広告