BOM（バイトオーダーマーク）完全ガイド：UTF-8の文字化け・ヘッダーエラーの原因と実務で使える対処法

2025年11月19日 最終更新日時 : 2025年11月19日 エバープレイ編集部

バイトオーダーマーク（BOM）とは何か

バイトオーダーマーク（Byte Order Mark、略してBOM）は、テキストファイルの先頭に置かれる特別なバイト列で、主に文字エンコーディングの情報（特にバイト順＝エンディアン）を示すために使われます。Unicodeの符号位置U+FEFF（ZERO WIDTH NO-BREAK SPACE）の符号化表現がファイル先頭に置かれることで実現されます。BOMの役割は、ファイルがどのUnicodeエンコーディング（UTF-8／UTF-16／UTF-32など）で書かれているか、またUTF-16／UTF-32のような符号単位のバイト順がリトルエンディアンかビッグエンディアンかを判別することです。

主なBOMのバイト列（代表例）

代表的なBOMのバイト列は以下の通りです。ここで示す16進表記はファイル先頭に現れる生のバイト列です。

  • UTF-8: EF BB BF
  • UTF-16（Little Endian）: FF FE
  • UTF-16（Big Endian）: FE FF
  • UTF-32（Little Endian）: FF FE 00 00
  • UTF-32（Big Endian）: 00 00 FE FF

注意：UTF-8はバイト順の問題がないため、EF BB BFは「エンコーディングのシグネチャ（UTF-8署名）」として使われることが多く、エンディアン情報を担うわけではありません。

技術的背景と歴史

Unicodeの初期段階では、UTF-16やUTF-32のように16ビット／32ビット単位で符号化する方式でバイト順（エンディアン）による解釈の違いが生じました。たとえば、UTF-16でU+0041（'A'）が0x0041として表されると、ビッグエンディアンではバイト列 00 41、リトルエンディアンでは 41 00 となります。ファイルがどちらの並びで保存されているかを示すため、ファイル先頭にU+FEFF（0xFE 0xFF または 0xFF 0xFE に符号化される）を置く運用が採られました。これがBOMの起源です。

その後、UTF-8が広く普及するにつれて、UTF-8でもBOM（EF BB BF）が「エンコーディングを示す署名」として使われるようになりましたが、UTF-8自体はバイト順の影響を受けないため、本来は不要です。

U+FEFFの意味の変化と注意点

U+FEFFには二つの役割がありました。1つはBOM（ファイル先頭の符号化署名）としての機能、もう1つは「ゼロ幅非改行スペース（Zero Width No-Break Space）」として可視化しない空白の文字としての利用です。しかし、Unicodeの仕様ではU+FEFFを文中で空白文字として使う運用は非推奨とされ（代わりにU+2060 WORD JOINERの使用が推奨されます）、U+FEFFは主にBOMとして扱うべきである旨が示されています（歴史的理由による機能分離）。

実務上よく発生する問題と原因

  • スクリプト言語やWebのヘッダー処理での不具合：PHPなどでは、PHPファイルの先頭にBOM（UTF-8のEF BB BF）が存在すると、BOMが先に出力されてしまい「ヘッダーを送信できない（headers already sent）」エラーの原因になります。これはBOMが実際に出力バイトとして扱われるためです。
  • シェバン（#!）やバッチ起動に影響：シェルスクリプトの先頭に不可視のバイトがあると、シェバン行が正しく解釈されないことがあります。
  • JSONやCSV解析の失敗や文字化け：BOMがあると解析ツールが先頭の非表示文字をそのままデータとして扱う場合があり、不正なデータ扱いになったり「」のように表示されることがあります（これはUTF-8のEF BB BFをWindows-1252などで誤解釈すると現れる文字列）。
  • JavaScript/CSSの結合時の問題：複数ファイルを単純に連結するような処理で、ファイルごとにBOMが含まれていると途中に不可視のバイトが入り、パーサのエラーや意図しない出力を引き起こすことがあります。

Webブラウザや規格での扱い

HTML5（WHATWGのEncoding Standard）や多くの実装では、受信したドキュメントの先頭でBOMを検出した場合は適切にエンコーディングを判別し、BOM自体を可視文字として表示しないように扱います。つまり、ブラウザはBOMをエンコーディングのヒントとして使用することが多いです。

ただし、サーバー送信時のContent-Typeヘッダとメタ要素、またHTTPヘッダで指定される文字セットとの組み合わせで挙動は影響を受けるため、BOMにだけ頼らず明示的なエンコーディング指定が望ましいです。

BOMによる文字化けのメカニズム（簡潔な説明）

たとえば、UTF-8でエンコードされたテキストの先頭にEF BB BFがある場合、UTF-8を正しく解釈するソフトウェアではBOMは取り除かれて見えません。しかし、ファイルをISO-8859-1やWindows-1252などの単一バイト文字セットで読み込むと、EFは「ï」に、BBは「»」に、BFは「¿」のように解釈され、画面に「」として現れることがあります。これが典型的なBOM由来の文字化けです。

実務上の対処法・チェック方法

  • ファイルの先頭バイトを確認する（コマンド例）：
    # UTF-8 BOMを検出（Linux/macOS）
xxd -g 1 -l 3 filename | head -n 1
# または
hexdump -C filename | head -n 1

    先頭が EF BB BF ならUTF-8のBOMです。

  • BOMを削除する（コマンド例）：
    # UTF-8 BOM（3バイト）を削除して新しいファイルを作る
tail -c +4 input.txt > output.txt

# iconvで変換しつつBOMを除去（場合による）
iconv -f UTF-8 -t UTF-8 input.txt -o output.txt

# Pythonで読み込み時にBOMを自動除去（utf-8-sigを利用）
with open('input.txt', 'r', encoding='utf-8-sig') as f:
    s = f.read()
with open('output.txt', 'w', encoding='utf-8') as f:
    f.write(s)

    注意：ツールや環境によっては期待通りに動かないことがあるため、バックアップを取ってから操作してください。

  • エディタの「保存時のエンコーディング」設定を確認する：Visual Studio Code、Notepad++、Sublime Text、EmEditorなど多くのエディタは「UTF-8（BOM付き）」と「UTF-8（BOMなし）」を選べます。Web開発やスクリプトファイルでは「BOMなし（UTF-8 without BOM）」が推奨されることが多いです。
  • プログラムで処理する場合はBOM対応を行う：パーサ側で先頭にBOMがあるかをチェックして除去する（言語やライブラリに「UTF-8-SIG」「utf_8_sig」等のBOM対応エンコーディングがある場合はそれを利用すると簡便）。

BOMを付けるべきか、付けないべきか（実務的な結論）

「付けるべき/付けないべき」は用途によりますが、一般的なWeb開発やスクリプト作成では「UTF-8（BOMなし）」が推奨される場面が多いです。その理由は、BOMが不意に出力バイトとして扱われることでヘッダ処理やスクリプト実行に支障を来すケースがあるためです。一方で、クロスプラットフォームでバイナリに近い処理を行う環境や、受信側の文字コード判別が不確かな場合にはBOMが有用になることもあります。

各種フォーマットや規格の扱い

  • HTMLやXML：XML宣言（）がある場合でもBOMは検出されることがあり、XMLパーサはBOMに対応しているべきとされています。HTMLでは、HTTPヘッダやが優先されるが、BOMは実装でエンコーディング判定の手がかりとして使われます。
  • JSON：多くの実装は先頭のBOMを無視する（取り除く）実装が多いですが、常に保証されるわけではないため、JSONを生成する側はBOMを付けない方が互換性が高いです。
  • スクリプト（PHP、Perl、Pythonなど）：BOMが先頭にあると意図しない出力や実行エラーの原因になることがあるので注意が必要です。特にPHPではBOMのせいでヘッダー操作が失敗するケースがよく知られています。

具体的な「よくある現場のケース」と対処例

  • ケース：PHPでファイルインクルードしたら「ヘッダーを送信できない」エラーが出る。

    対処：インクルードするファイルの先頭にBOMがないかバイナリチェックし、存在すれば削除する。エディタで「UTF-8（BOMなし）」で保存する習慣をつける。

  • ケース：複数のJavaScriptファイルを結合したら文法エラーが発生する。

    対処：各ファイルの先頭にBOMが含まれていないかチェックし、BOMを削除した上で結合ツールを使う。ビルドパイプラインにBOM除去ステップを入れるのも有効。

  • ケース：外部から受け取ったCSVに不可視文字が含まれ、列がずれる。

    対処：受け取ったファイルの先頭バイトを確認し、BOMがあれば除去してからパースする。あるいは、パーサにBOM除去のオプションがあるか確認する。

まとめ（実務的な推奨）

バイトオーダーマークは、歴史的事情と実装の都合から今でも重要な役割を果たしますが、使用には注意が必要です。特にWeb開発・スクリプト開発では「UTF-8（BOMなし）」を標準にすることが互換性の面で安全です。外部データを扱う場合はBOMの有無をチェックして適切に処理するルールを開発プロセスに入れておくとトラブルを未然に防げます。

参考文献

カテゴリー
IT
前の記事
コードポイント完全ガイド：Unicodeの基礎、UTF-8/16の違い、実務上の注意点とセキュリティ対策New!!
2025年11月19日
次の記事
サロゲートペアとは — UTF-16の仕組み、絵文字や文字列処理で起きる問題と実務的な対処法New!!
2025年11月19日