I love software!

« アンテナハウスPDF電子書名モジュールV1.3MR1を公開しました | メイン | アンテナハウスPDF Driver API V5.0を発売しました »

2011年05月19日

UTF-8のBOM（Byte Order Mark)は想定外でした

この前の日記は、結局、日本語の混じったCSSをUTF-8で符号化した際にBOMをつけたためAdobe Digital Editionsが誤動作したらしい、という話になりました。お騒がせしました。

実はこのCSSはいまお勉強中のスタッフにいろいろ試してもらったものなのですが、彼女が使っているテキストエディタにはUTF-8をBOM付きで保存するメニューがあって、日本語テキストを保存するにはBOMが必要だろうと考えた彼女がBOM付きで保存してしまったようなんです。そんなこととはつゆしらず。大騒ぎしてしまいました。ゴメンナサイ。

でも、UTF-8にはBOMは本来必要ないんです。

BOMはByte Order Markの略で、UnicodeではU+FEFFのコードポイントが与えられています。次はUnicodeのコード表の一部。

http://www.unicode.org/charts/PDF/UFE70.pdf

※BOMのコードポイントが誤っていましたので訂正しました。

BOMのもとはByte Order（バイトオーダー）ということですが、これは例えば16ビット（2バイト）単位でデータを扱うとき、２つのバイトをどういう順序で扱うか（CPUのレジスタに取り込むか）ということを表すマークとして用意されています。UnicodeをUTF-16、UTF-32で表すときは意味がありますが、UTF-8は2バイト固定長ではなく1バイトずつの可変長でデータを扱うのでバイトオーダーは意味がありません。

私は10数年前、シフトJISとかISO-2022-JP全盛の時代で、XMLが出てきてUnicodeが使われ始めた時代にテキスト判別モジュールを設計した経験があります。これからはUnicodeの時代になるので、XML Editorのテキスト文字コード自動判別でも、シフトJISやISO-2022-JPだけではなく、UTF-8、UTF-16、UTF-32を自動判別できないとまずいだろうということで調べました。で、その当時はUTF-8にBOMをつけると言う発想は無かったと記憶しています。

でもいつの間にか、UTF-8にBOMをつけるテキストエディタが普及していたのですね。

最近は、UTF-8にBOMをつけて、これがUTF-8であることを示したり、UTF-8にASCII文字以外が入っていることを示すために使うとしているようです。しかし、これはBOM本来の意味ではありませんし、UTF-8はもともとASCIIコードだけのときにはASCIIコードと同じになるように設計されているわけだからBOMをつけるのはUTF-8の精神に反するような気もします。

それはともかく、古くからのソフトの中にはUTF-8にBOMがついていると、"想定外"ということで破綻するものがいろいろあります。Adobe Digital Editionsだけではないんです。

実はCAS-UBの中核になっているデータ処理系もUTF-8にBOMがついていると破綻します。このことは、ユーザーガイドに書いてないので早速追加しなくっちゃ。

「CAS-UBで扱うテキストや各種スタイルシートやテキストはUTF-8固定です。しかし、BOMはつけないでください。」

http://d.hatena.ne.jp/cassupport/20110518/1305751974　から転載。

投稿者 koba : 2011年05月19日 06:50

トラックバック

このエントリーのトラックバックURL:
http://blog.antenna.co.jp/PDFTool/mt-tbng2.cgi/1623

コメント

コメントしてください