最近、UTF‑8 の BOM（Byte Order Mark）について考え直す機会がありました。 昔は「Excel で文字化けしないように付けておくもの」という感覚が強かったのですが、Web やプログラミングの世界では BOM を付けない UTF‑8 が正しいという話をよく見かけるようになりました。実際、自分でも「もう BOM は付けないほうがいいのでは？」と感じ始めています。
ただ調べてみると、どうやら 一部の例外では BOM を付けたほうが良いケースも残っているようです。 そこで、UTF‑8 の BOM がどのように生まれ、なぜ問題になり、今はどう扱われているのかを整理してみました。
広告（PR）｜自分の投資スタイルを見つける。※タップで開閉
DMM FXは、「最初の一歩を踏み出す場」として選ばれることがある
口座を開いてみた。取引してみた。思ったよりも難しかった。──そんな経験が、投資との距離感を知るきっかけになることもあります。
サービスを通じて、自分の投資スタイルを見つける。それは、確信ではなくても構いません。「試してみた」という実感が、次の選択の材料になることもあるからです。
DMM FXに関する詳細は、以下の広告（PR）リンクをご覧いただけます。
※FXは元本保証のない金融商品です。相場変動により損失が生じる可能性がありますので、ご理解のうえでご覧ください。
👇こちらは広告（PR）リンクバナーです
※本リンクは広告収益が発生する可能性のある広告（PR）リンクです
UTF‑8 に BOM が存在する理由（歴史の出発点）
Unicode が登場した当初、主流は UTF‑16 でした。 UTF‑16 は エンディアン（LE/BE）問題があるため、ファイルの先頭に
FE FF→ UTF‑16BEFF FE→ UTF‑16LE
という BOM が必須でした。
この BOM の概念を Unicode 全体で統一するため、UTF‑8 にも形式上の BOM（EF BB BF）が定義されました。
しかし UTF‑8 は エンディアンを持たないため、本来 BOM は不要でした。 つまり、UTF‑8 の BOM は「仕様上は存在するが、実用上は不要」という位置づけで誕生しました。
UTF‑8 BOM が“事故”として広まった理由
本来不要だった UTF‑8 BOM が世界に広まったのは、Windows のメモ帳（旧バージョン）が原因です。
Windows メモ帳の問題
- メモ帳は長年「ANSI（実質 Shift_JIS）」をデフォルトとしていた
- UTF‑8 を判別する手段がなかった
- そこで UTF‑8 のときだけ BOM を付けるという仕様を採用した
結果として、Windows で保存された UTF‑8 ファイルには BOM が付くようになり、 これが世界中に拡散しました。
UTF‑8 BOM が引き起こしたトラブル
UTF‑8 の BOM は、Web やプログラミングの世界で数え切れない問題を生みました。
Web・サーバー系のトラブル
- PHP の
header()より前に BOM が出力されてエラー - JSON の先頭に BOM があるとパーサーが壊れる
- HTML の先頭に BOM があると IE が誤判定する
- API レスポンスに BOM が混入してクライアントが壊れる
プログラミング系のトラブル
- Python が BOM を文字として読み取り、先頭に
\ufeffが混入 - Git の diff が汚れる
- シェルスクリプトの先頭に BOM があると実行できない
- C/C++ のプリプロセッサが BOM を嫌う
データ処理のトラブル
- CSV に BOM があると Excel は正しく読むが、他のツールが壊れる
- BOM 付き JSON を読み込めないライブラリが多数存在
UTF‑8 BOM は「付いていても問題ない」どころか、 付いていると壊れるシステムが多い危険な存在でした。
2020年代の現在：UTF‑8 BOM の扱いはどうなったか
Web の世界
- HTML / CSS / JS / JSON → UTF‑8（BOMなし）が標準
- W3C も BOM なしを推奨
- ブラウザは BOM を無視するが、サーバーや API は無視しないため危険
プログラミング言語
- Python → BOM を文字として扱うため危険
- Go → BOM を嫌う
- Rust → BOM を嫌う
- Node.js → JSON に BOM があると壊れる
- Java → BOM を嫌う
ほぼすべての言語で BOM なし UTF‑8 が推奨。
エディタ
- VSCode → UTF‑8（BOMなし）がデフォルト
- GitHub → UTF‑8（BOMなし）が標準
- Sublime → UTF‑8（BOMなし）
- 秀丸など一部の日本製エディタ → BOM 付き設定が残っている
Windows の変化
Windows 10（2018年以降）でメモ帳がついに UTF‑8（BOMなし）をデフォルトに変更 したことで、BOM 問題は大幅に減少しました。
実務での結論：UTF‑8 BOM は使うべきか？
使うべき場面
- Excel で開く CSV（日本語） → Excel が UTF‑8 を正しく認識するために BOM が必要な場合がある
- Windows の一部のレガシー環境 → UTF‑8 を判別できないツールが存在する
使ってはいけない場面（重要）
- Web（HTML / CSS / JS / JSON / API）
- シェルスクリプト
- プログラムのソースコード
- 設定ファイル（YAML / TOML / INI / env）
- Git 管理するファイル
- Python の入力ファイル
- サーバー間通信のデータ
基本方針
基本方針：UTF‑8 は BOM なしが正解。 例外は Excel だけ。
まとめ
- UTF‑8 の BOM は、UTF‑16 の BOM 文化を引き継いだ「仕様上の存在」
- 本来 UTF‑8 に BOM は不要
- Windows メモ帳が UTF‑8 判別のために BOM を付けたことで世界に広まった
- Web・プログラミング・API で大量のトラブルを生んだ
- 現代では UTF‑8（BOMなし）が標準
- 例外的に Excel の CSV だけは BOM が必要な場合がある