BOMとは何か？UTF-8のBOMあり/なしの違いと注意点

2025年9月4日2025年9月12日

その他

テキストファイルの先頭に現れるBOM(Byte Order Mark)は、ファイルがどの文字コードで書かれ、場合によってはどちら向きのバイト順序で並んでいるかを示す特別なマークです。

特にUTF-8ではBOMありとなしの違いが挙動に影響し、Webやスクリプトで思わぬ不具合を招くことがあります。

ここでは初心者の方にも分かりやすく、仕組みと使い分けの実践的な目安を解説します。

目次 [ close ]

BOM (Byte Order Mark) とは

何を示すマークか

BOMは、テキストファイルの先頭に挿入される数バイトの目印で、主にUnicode系の文字コードでエンコードの種類とバイト順序を示します。

UTF-16やUTF-32のように同じ文字コードでもビッグエンディアンとリトルエンディアンがあり得る形式では、BOMが実際のバイト順序を明示する役割を持ちます。

一方、UTF-8はバイト順序の概念を持たないため、BOMは文字コードの“署名”(このファイルはUTF-8である)として使われることがあります。

どの文字コードで使われるか

BOMはUnicodeの各エンコーディングで下記のようなバイト列になります。

先頭3～4バイトがこの並びで始まると「BOMあり」と判断できます。

文字コード	BOMのバイト列	役割の意味
UTF-8	`EF BB BF`	署名(UTF-8であることの目印)。バイト順序の意味はない
UTF-16 BE	`FE FF`	ビッグエンディアンの目印
UTF-16 LE	`FF FE`	リトルエンディアンの目印
UTF-32 BE	`00 00 FE FF`	ビッグエンディアンの目印
UTF-32 LE	`FF FE 00 00`	リトルエンディアンの目印

UTF-8に限って言えば、BOMは必須ではありません。

多くのツールやプログラミング言語は、BOMなしのUTF-8を標準として扱います。

UTF-8を使う前に知っておくこと

UTF-8は現在もっとも広く使われる文字コードであり、原則としてBOMなしのUTF-8が最も互換性が高いです。

BOMありのUTF-8は、一部のアプリケーション(特にWindowsの旧来ツールやExcel)で文字コードの自動判別に役立つ一方、スクリプトの実行やWeb配信で不具合を起こすリスクがあります。

用途に応じて使い分けることが重要です。

UTF-8のBOMあり/なしの違い

BOMありのメリット(自動判別しやすい)

BOMありのUTF-8は、エディタや表計算ソフトが自動的にUTF-8と認識しやすいという利点があります。

特にWindows環境では、BOMがないUTF-8をShift_JISなどと誤判定して表示が乱れるケースがあり、BOMがあると回避できることがあります。

ExcelでCSVを開く場合はUTF-8のBOM付きが最も安全です。

BOMありのデメリット(互換性の問題)

一方で、BOMありのUTF-8は次のような問題を引き起こすことがあります。

どれも実運用でよく遭遇します。

スクリプトの先頭にBOMがあると、UNIX系OSでシェバン行(例#!/usr/bin/env python3)が先頭ではなくなり、実行エラーになることがあります。
PHPなどでheaderやセッション開始前にBOMが「すでに出力されたデータ」とみなされて、Cannot modify header informationエラーが出ることがあります。
JSONは仕様上BOMを要求せず、BOM付きJSONを受け付けないパーサがあります。APIの相互運用で失敗の原因になります。
CSSやJSなどの静的ファイルにBOMが入ると、一部のミニファイや連結処理でゴミ文字(画面上ではï»¿など)が紛れ込むことがあります。
単純なテキスト比較や連結処理で、先頭以外にBOMが混入すると想定外の文字として扱われ、検索や解析の精度が落ちます。

コードや設定ファイルではBOMなしが基本と覚えておくと安全です。

BOMなしのメリット(シンプルで広く動く)

BOMなしのUTF-8は、ほぼすべての現代的なツール・ランタイム・ブラウザにおいて既定の前提です。

余計な先頭バイトがないため、スクリプト実行やプロトコル処理との相性が良く、JSONやYAMLなどのデータ交換でも問題になりにくいという利点があります。

文字化けとの関係

BOMは文字コードを示すヒントであり、文字化けを直接「修正」する魔法ではありません。

ツールがUTF-8かどうかを誤判定する場合には有効ですが、サーバ側ヘッダのcharset宣言が誤っている、アプリが内部で別のエンコードを想定しているといった根本原因があると、BOMの有無だけでは解決しません。

画面にï»¿と表示されるのは、UTF-8のBOMEF BB BFが文字として誤解釈された典型例です。

使い分けの目安と注意点

Web(HTML/CSS/JS)はUTF-8(BOMなし)が無難

Web配信では、UTF-8(BOMなし)が最も互換性が高い選択です。

HTMLは<meta charset="utf-8">を先頭近くに書き、サーバのHTTPレスポンスヘッダContent-Type: text/html; charset=utf-8を正しく設定します。

BOMを入れる必要はありません。

CSSやJSでも同様で、BOMなしのUTF-8の方がツールチェーンやCDN最適化でトラブルが少ないです。

スクリプトや設定ファイルはUTF-8(BOMなし)

シェルスクリプト、Python、Ruby、Node.js、PowerShell、Dockerfile、.envやYAMLなどの設定ファイルは、UTF-8(BOMなし)が原則です。

スクリプトは先頭のシェバン行が命であり、BOMがこれを妨げます。

設定ファイルでも先頭のBOMがキー名の一部とみなされ、意図しないキーが生まれる事故があります。

ExcelのCSVはUTF-8(BOMあり)が安全

WindowsのExcelは、BOMなしUTF-8のCSVをShift_JISと誤認して日本語が崩れることがよくあります。

Excelに読み込ませるCSVはUTF-8のBOM付きが安全です。

最近のExcelには「CSV UTF-8」で保存する機能があり、これを使うとBOM付きUTF-8になります。

ツール間連携でCSVを受け渡す際は、相手側の仕様も確認しましょう。

日本語テキストはツールに合わせて選ぶ

メモやドキュメントのテキストは、利用するツールの特性に合わせて選びます。

現行のエディタやビューワはUTF-8(BOMなし)を問題なく扱えますが、古いWindowsアプリではBOMありの方が安全な場合があります。

配布先の環境に不安があるなら、事前にBOMあり/なし両方でテストしておくと安心です。

用途・文脈	推奨
HTML/CSS/JSなどのWeb資産	UTF-8(BOMなし)
シェル/言語スクリプト、設定ファイル	UTF-8(BOMなし)
Excelで開くことを想定したCSV	UTF-8(BOMあり)
一般的な日本語テキスト	可能ならUTF-8(BOMなし)。古いツール相手は要検証

エディタ設定とチェック方法

エンコード設定でUTF-8とBOMあり/なしを選ぶ

主要なエディタでは、保存時の文字コードとBOMの有無を選べます。

Visual Studio Code: ステータスバーの「UTF-8」をクリック→「エンコード付きで保存」→「UTF-8」(BOMなし)または「UTF-8 with BOM」を選びます。既定値はsettings.jsonのfiles.encodingとfiles.insertFinalNewline、files.autoGuessEncodingで調整できます。
Notepad++: メニュー「エンコーディング」→「UTF-8」(BOMなし)または「UTF-8 BOM付き」を選択してから保存します。
Vim/Neovim: :set fileencoding=utf-8でUTF-8を指定し、BOMを付けないなら:set nobomb、付けるなら:set bomb→:wで保存します。
JetBrains系IDE: ステータスバーのエンコーディング表示から「UTF-8」または「UTF-8 BOM」を選び保存します。

既存ファイルのBOMを確認する

BOMの有無は、エディタのステータス表示か、先頭バイトを確認すれば分かります。

目視確認(16進表示):
- macOS/Linux: xxd -g 1 -l 3 ファイル名 または hexdump -C ファイル名 | head -n 1
  先頭がef bb bfならUTF-8のBOMありです。
- Windows PowerShell: Format-Hex -Path .\ファイル名 | Select-Object -First 4 で先頭バイトを確認します。
VS Code: ステータスバーに「UTF-8」か「UTF-8 with BOM」と表示されます。

UTF-8のBOMはEF BB BFです。

FE FFやFF FEの場合はUTF-16の可能性があるため、誤ってUTF-16で保存していないかも併せて確認しましょう。