BOM（Byte Order Mark）

マルチバイト文字を扱うときの問題のひとつに，エンディアンの違いがある． 送信者と受信者でエンディアンが一致しているかどうかを調べる方法として， ファイルの先頭にU+FEFF ZERO WIDTH NO-BREAK SPACEを書き込んでおく方法がある． ZERO WIDTH NO-BREAK SPACEは，幅がゼロで改行されない空白文字なので，このコードを挿入しても見た目上は変化がなく， かつ，送信者と受信者でエンディアンが違っていた場合，受信者は0xFFFEというコードを読み込むことになり， このコードがUnicodeでは文字ではないため［参考］，エンディアンが一致していないことがすぐわかるという仕掛けになっている． この使い方のU+FEFFをバイトオーダーマーク（Byte Order Mark；BOM）と呼ぶ．

BOMの具体的な使い方（どんなときに使うべきで どんなときに使わないべきか）については次の資料が詳しい．

• FAQ - UTF-8, UTF-16, UTF-32 & BOM
  • Byte Order Mark (BOM) FAQ

簡単に内容を書いておくと…

• BOMはUTF-8のようにエンディアンが関係ないファイルでも使われる．
• UNIXのスクリプトファイルのように先頭数バイトに特定の文字（UNIXのスクリプトの場合“#!”） がきていることを想定しているファイルの場合はBOMをつけるべきではない．
• U+FEFFがファイルの先頭以外にでてきた場合には，それはBOMではないので，そのまま幅がゼロで改行しない空白文字と解釈すべき．
• U+FEFFを通すとまずいプロトコルを使っている場合は，代替としてU+2060 WORD JOINERが使える．
• データベースのように型づけされたデータの場合，BOMは不要． データベースの各フィールドにBOMをつけたりはするべきではない． また，UTF-16BEやUTF-16LEとマークされているテキストストリームにデータを流す場合， BOMは必要でもないし・許容されるものでもない［うっかりエンディアンが逆のBOMを流すとU+FFFEが不正なコードのためエラーになったりしても文句は言えないという意味だろう］． この場合，すべてのU+FEFFは幅0で改行しない空白文字と解釈される．