BOMとは？UTF-8ファイルの先頭に付く目印をどう考えるべきか

先に要点

BOM は Byte Order Mark の略で、テキストファイル先頭に付く目印 です。
UTF-16 や UTF-32 ではバイト順の判断に関係しますが、UTF-8 では byte order のためではなく、UTF-8 だと分かりやすくする署名 として使われます。
UTF-8 では BOM は必須ではなく、むしろ一般的には不要なことも多い です。
ただし、Excel で UTF-8 CSV をそのまま開かせたい場面では BOM が効くことがある ので、実務では `常に付ける` でも `絶対付けない` でもなく、利用先で判断します。

BOM って何？ UTF-8 with BOM と UTF-8 の違いは？ 付けた方がいいの？邪魔なの？ というのは、CSV や文字化けの話をするとすぐ出てきます。
しかも BOM は、場面によって 助かるもの にも 邪魔になるもの にもなるので、単純に覚えにくいです。

この記事では、BOM とは何かを、Byte Order Mark の意味、UTF-8 での役割、付けるべき場面、付けない方がよい場面 の順で整理します。
前に公開した UTF-8とは？文字コードを初心者向けにどう理解すればいいのかや CSVをExcelで開くと文字化けするのはなぜかの補強として読める形です。

BOMとは何か

BOM は Byte Order Mark の略です。
Unicode 公式 FAQ でも、BOM は Unicode テキストの先頭に付けられる目印として説明されています。

UTF-8 での BOM は、バイト列で書くと次です。

EF BB BF

これは Unicode 文字 U+FEFF が UTF-8 で表現されたものです。

ただし大事なのは、UTF-8 の BOM は「文字データそのもの」より、ファイル先頭にある署名のような役割で使われる ことです。

なぜ BOM という名前なのか

Byte Order Mark という名前だけ見ると、UTF-8 でもバイト順があるの？ と混乱しやすいです。
ここは分けると分かりやすいです。

UTF-16 / UTF-32 の場合

UTF-16 や UTF-32 では、複数バイトの並び順、つまり ビッグエンディアン / リトルエンディアン の区別が問題になります。
そのため BOM が、どちらの順番なのかを示す役割を持ちます。

UTF-8 の場合

UTF-8 には、その意味での byte order の問題はありません。
Unicode FAQ でも、UTF-8 で BOM が使われる場合、それは byte order のためではなく、UTF-8 を他のエンコーディングと区別するための signature だと説明されています。

つまり UTF-8 では、BOM は Byte Order Mark という名前のままですが、実質的には UTF-8 ですよという先頭マーク と考える方が実務では分かりやすいです。

UTF-8 で BOM は必要なのか

結論から言うと、必須ではありません。
むしろ Unicode 公式でも、UTF-8 に BOM は required でも recommended でもない という整理に近い扱いです。

今の Web や API、一般的なテキスト処理では、UTF-8 は BOM なしで問題なく使われることが多いです。

なので、まず基本理解としては、

UTF-8 は BOM なしでも普通に使える
BOM がないから壊れているわけではない

で OK です。

じゃあ何のために付けるのか

それでも BOM が出てくるのは、一部のソフトが UTF-8 と認識しやすくなるから です。

実務で一番分かりやすいのは Excel です。
Microsoft 公式でも、UTF-8 でエンコードされた CSV は BOM が付いていれば通常どおり開ける と案内されています。

つまり BOM は、

いろいろな文字コードが混ざる環境で
相手に UTF-8 と気づいてもらう

ための助けになることがあります。

BOM が役立つ場面

1. Excel で UTF-8 CSV を直接開かせたいとき

これはかなり代表的です。
CSV をダブルクリックで開く 運用だと、UTF-8 BOM 付きの方が文字化けを避けやすいことがあります。

前に公開した CSVをExcelで開くと文字化けするのはなぜかでも触れた通り、ここは Microsoft 公式に根拠があります。

2. 古いツールや曖昧な文字コード判定をするツール相手

一部のエディタ、取り込み処理、業務ツールでは、先頭に BOM があることで これは UTF-8 だな と判断しやすくなることがあります。

3. 文字コードの自己主張が欲しいとき

たとえば単体のテキストファイルを人に渡すだけで、HTTP ヘッダーや別の文字コード情報がない場合、BOM がヒントになることがあります。

BOM が邪魔になる場面

ここが大事です。
BOM は便利なこともありますが、付いていることで問題になる場面もあります。

1. プログラムやツールが先頭文字として拾ってしまう

ツールによっては、BOM を透明に無視してくれず、先頭の見えない文字として扱うことがあります。
その結果、

先頭列名だけおかしい
JSON パースでこける
スクリプトの先頭で謎の文字扱いになる

といったことが起きます。

2. 識別子や厳密なテキスト比較で問題になる

ファイルの最初にあるべき文字列が、実際には BOM 付きになっていて、比較や判定がズレることがあります。

たとえば、

1行目の先頭キーが一致しない
ヘッダー名だけ別物になる
数値パースで最初の列だけ失敗する

という事故です。

3. Web や API では不要なことが多い

Web の HTML や API レスポンスでは、HTTP ヘッダーや <meta charset="utf-8"> などで文字コードを伝えられます。
そういう場面では、BOM に頼らなくても正しく伝えられることが多いです。

特にプロトコルやフォーマットが明確に UTF-8 を前提にしている 場合は、BOM はなくても困らないことが多いです。

実務ではどう考えるべきか

ここは 付けるべき / 付けないべき の二択ではなく、利用先で判断する のが実務的です。

付ける寄りの判断

受け手が Excel で直接開く
古い業務ツールに渡す
UTF-8 だと認識させるヒントが必要

付けない寄りの判断

Web や API のレスポンス
JSON やプログラム入力
厳密な先頭一致やパースが必要
ツール側が BOM を嫌う

つまり、

人が Office で開く世界 では BOM が助かることがある
プログラム同士で扱う世界 では BOM が邪魔になることがある

と覚えるとかなり分かりやすいです。

UTF-8 with BOM と UTF-8 は別物なのか

実務では UTF-8 と UTF-8 with BOM を別の選択肢として見ることがあります。
でも本質的には、どちらも UTF-8 です。

違うのは、先頭に BOM が付いているかどうか だけです。

なので、

エンコーディングそのものは UTF-8
追加で先頭に署名があるかないか

という理解で十分です。

どう見分けるのか

エディタやツールによっては、

UTF-8
UTF-8 with BOM

のように明示されます。

また、バイナリや16進表示で見ると、先頭が EF BB BF なら UTF-8 BOM 付きです。

文字化けして ï»¿ のような見え方になることがありますが、これは BOM を文字として誤って見てしまっている典型例です。

文字化けとの関係

BOM 自体が文字化けの原因になるというより、BOM の扱いを相手が理解できないとトラブルになる と考える方が近いです。

たとえば、

BOM があるから Excel で助かる
BOM があるせいで別のツールが先頭文字として拾う

の両方が起きます。

つまり BOM は、良い / 悪い の属性ではなく、相手がどう扱うかで評価が変わる目印 です。

まとめ

BOM は Byte Order Mark の略で、テキストファイル先頭に付く目印です。
UTF-16 や UTF-32 では byte order の判断に関係し、UTF-8 では UTF-8 ですよ と分かりやすくする signature のように使われます。

UTF-8 では、

BOM は必須ではない
付ければ助かる場面がある
逆に邪魔になる場面もある

というのが実務的な結論です。

一番大事なのは、常に付ける 絶対付けない と決め打ちせず、Excel や人向け配布なのか、プログラム処理なのか で判断することです。

この記事と一緒に読みたい

参考リンク

Unicode FAQ: UTF-8, UTF-16, UTF-32 & BOM
WHATWG: Encoding Standard
Microsoft Support: Opening CSV UTF-8 files correctly in Excel