BOM つき UTF-8 へのその場しのぎの対処

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

UTF-8のCSVファイルを扱うプログラムが理由のわからないエラーを出したとき、原因が入力ファイルのBOMだったことがあります。

1行目の先頭にU+FEFFがついていて、ファイルを読み込む処理でそれを落とさなかったために、U+FEFFもデータの一部として扱われてしまったためです。つまり最初のレコードの最初のフィールドにゴミがついてしまったわけです。

この問題が厄介なのは、データの中身をテキストエディタやコンソールで見てもよくわからないことです。U+FEFFは "ZERO WIDTH NO-BREAK SPACE" であって目に見えない存在であるので、ソフトウェアがきちんと対応しているほど、存在が隠れてしまうわけです。いっそ豆腐にでもなってくれれば異常に気付きやすいのですが。

(余談ながら、ネットのジョークに「お前のコードに全角スペースを入れたぞ」「なにー」みたいなのがありますが、和字間隔(全角スペース)は可視化するエディタも多く、昔からよく知られているだけに対処も容易であって、U+FEFFやその他Unicodeの制御文字の類いの方がずっと面倒です)

ここで、もし、CSVファイルの1行目がヘッダ行であって、なおかつそのヘッダ行を(あるいは少なくともヘッダの先頭の項目を)単に読み飛ばすようになっていると、BOMがあろうがなかろうが同じことになります。

つまり、たいして必要でなくても(というかむしろ必要でない方が好都合)、ヘッダ行を設けておくと、BOMよけとして働いてくれるわけです。

もっとも、本当は、UTF-8のファイル先頭のBOM (バイト列 EF BB BF) をプログラムが読み飛ばすようになっている方がいいわけで、これはあまりちゃんとした対処ではありません。

参考:

トラックバック(0)

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

コメント(2)

BOMではなくZERO WIDTH NO-BREAK SPACEかもしれないので、ファイルの先頭のU+FEFFを削っていいかどうかは自明ではありませんよ。

本記事のユースケースでは一律に削ってしまって問題ないはずです。また、もともとZWNBSPが担っていたセマンティクスについては、Unicode 3.2で追加された WORD JOINER U+2060 の使用が現在では推奨されています。

コメントする

最近のブログ記事

仮名合字・合略仮名の文字コード
合字とは 合字というものがあります。複数…
なぜ『プログラマのための文字コード技術入門』の改訂新版にはSKKと Emacsの話が入っていないのか
拙著『[改訂新版] プログラマのための文…
朝鮮半島の訃報の第3水準漢字
朝鮮戦争で韓国軍として活躍した白善燁氏が…
テレワークの環境改善〜CO2濃度をチェックする
テレワークの問題点 新型コロナウイルスの…
エンジニアHubにて「文字コード再入門─ Unicodeでのサロゲートペア、結合文字、正規化、書記素クラスタを理解しよう!」公開
「エンジニアHub」にて記事を執筆しまし…

広告