テキストファイルを扱っていて、UTF-8のBOM無しとBOM付きのどちらにすればよいか分からなくなる場面は、多くの方が一度は経験します。結論から言えば、HTML・CSS・JavaScript・PHP・JSON・シェルスクリプトといったWeb系やプログラム系のファイルはBOM無しを基本にし、WindowsのExcelでそのまま開く日本語入りのCSVだけBOM付きにする、という使い分けで実務のほとんどはうまくいきます。迷ったときはBOM無しを選んでおけば、後から困る可能性は小さくなります。

とはいえ「どちらか分からなくなる」「自分で確かめたい」という悩みの本質は、判別と切り替えの手順がはっきりしないことにあります。そこでこの記事では、BOMの正体から、先頭3バイトを自分の目で確認する具体的なコマンドやエディタ操作、付け外しの手順、つまずきやすい誤解までを、Web制作の現場で実際に遭遇したケースとあわせて整理していきます。読み終えるころには、手元のファイルがBOM付きかどうかを自分で判定できるようになっているはずです。

なお、この記事は文字コード(エンコーディング)という言葉に初めて触れる方でも読み進められるように書いています。文字コードとは、画面に見える文字を、コンピュータが扱うバイト(数値の並び)へ対応づける取り決めのことです。UTF-8はその取り決めの一つで、世界中の文字をほぼ網羅できるため、現在のWebの標準として広く使われています。

結論：BOM無しを基本にし、ExcelのCSVだけBOM付きにする

はじめに、状況別の早見表として判断の目安を示します。理由や仕組みは後の章で順番に説明しますので、まずは全体像をつかんでください。

• HTML・CSS・JavaScript・PHP：BOM無し。BOMがあると表示崩れやサーバーエラーの原因になりやすいためです。
• JSON・YAMLなどの設定ファイル：BOM無し。仕様上BOMを認めていないため、読み込みエラーにつながることがあるのです。
• シェルスクリプト・各種プログラムのソース：BOM無し。先頭のBOMが命令の解釈を妨げる場合があります。
• WindowsのExcelでダブルクリックして開く日本語入りCSV：BOM付き。BOMがないと日本語が文字化けしやすいためです。
• 判断に迷う場合：BOM無し。現在の標準であり、互換性のトラブルが起きにくい選択です。

この早見表は「中身は同じUTF-8でも、先頭にBOMという3バイトの目印を付けるかどうかだけが違う」という前提に立っています。次の章で、その目印が何者なのかを掘り下げていきましょう。

そもそもBOMとは何か(前提知識の整理)

BOMはByte Order Mark(バイトオーダーマーク)の略で、日本語では「バイト順マーク」と訳されます。ファイルの先頭に置かれる特別な目印で、その実体はUnicodeのU+FEFFという1つの文字です。この文字は本来「ゼロ幅ノーブレークスペース」と呼ばれ、幅を持たない、画面には見えない文字として定義されています。

BOMの正体はU+FEFFという1文字

「マーク」と聞くと特殊な記号を思い浮かべるかもしれませんが、BOMの中身はあくまで1文字です。見えない文字なので、対応しているエディタで開けば何も表示されません。一方で、BOMを認識できないソフトで開くと、後述するように先頭に文字化けのような並びが現れます。ここがBOMの分かりにくさの入口になっています。

UTF-8では「バイト順」ではなく「署名」の役割

名前に「バイト順」と付いている点が、混乱を招きやすいところです。もともとBOMは、文字を2バイトや4バイトのまとまりで表すUTF-16やUTF-32のために生まれました。これらの形式では、複数バイトをどちらの順番で並べるか(バイト順、エンディアン)が機種によって異なるため、先頭のBOMでどちらの順番かを示す必要があったのです。

これに対してUTF-8は、文字を1バイト単位で組み立てるバイト指向のエンコードであり、バイト順という概念がそもそも存在しません。そのためUTF-8におけるBOMは、バイト順を示すという本来の役目を持ちません。残された役割は「このファイルはUTF-8です」と知らせる署名(シグネチャ)としての働きだけです。Unicodeの規格でも、UTF-8でのBOMは「認めるが、必須でも推奨でもない」という位置づけになっています。

UTF-8のBOMは必ず EF BB BF の3バイト

UTF-8で表したBOM(U+FEFF)は、16進数でEF BB BFという3バイトに必ずなります。値が変わることはありませんので、この3バイトを覚えておくと判別がぐっと楽になります。たとえば、内容が「Hello」というファイルの場合、バイトの並びは次のように変わります。

• BOM無し：48 65 6C 6C 6F(そのまま H e l l o)
• BOM付き：EF BB BF 48 65 6C 6C 6F(先頭にBOMの3バイトが付く)

このように、違いは先頭の3バイトだけです。BOMより後ろの本文は、どちらもまったく同じバイトで表されます。「BOM付きは別のエンコードなのではないか」と感じる方もいますが、そうではありません。どちらも同じUTF-8であり、先頭3バイトの有無だけが異なるのです。

BOM無しとBOM付きは「同じUTF-8」── 違いは先頭3バイトだけ

前章のとおり、BOM無しとBOM付きは中身の文字エンコードが同一です。だからこそ、対応したソフトで開けば、どちらも同じ内容として正しく表示されます。問題が起きるのは、BOMを想定していないソフトがその3バイトを本文の一部だと誤解したときに限られます。

BOM付きが文字化け「」として現れる仕組み

BOMを認識できない環境でBOM付きファイルを開くと、先頭にのような並びが現れることがあります。これは、EF BB BFという3バイトを、UTF-8ではなく古い1バイト系のエンコード(Latin-1など)として読んでしまったときに、その3バイトがそれぞれ別々の文字として表示された姿です。文字化けに見えますが、ファイルが壊れているわけではなく、読み手側のエンコードの解釈がずれているだけなのです。先頭にこの並びを見つけたら「BOM付きを誤って解釈しているサイン」と考えると、原因にたどり着きやすくなります。

ファイルサイズやチェックサムが3バイト分変わる

BOMは3バイトの実体を持つため、同じ本文でもBOM付きのファイルはBOM無しより3バイト大きくなります。普段は気にならない差ですが、ファイルのバイト数を厳密に比較したり、内容が同一かどうかをチェックサムで突き合わせたりする場面では、この3バイトの違いが「別物」と判定される原因になります。自動処理でファイルを比較するときは、BOMの有無をそろえておくと余計な差異を避けられます。

BOM付きが役立つ場面(メリット)

ここまで読むと「BOMは無いほうがよいのでは」と感じるかもしれませんが、BOMがしっかり役に立つ場面もあります。代表例がWindows環境でのExcelとの相性です。

WindowsのExcelでCSVを正しく開ける

WindowsのExcelで日本語入りのCSVファイルをダブルクリックで開くと、BOMが無い場合は日本語が文字化けしてしまうことがよくあります。これは、Excelが「明示的な目印が無いCSVは、その環境の従来の文字コード(日本語WindowsではシフトJIS系)だろう」と推測してしまうためです。ここにBOM付きのUTF-8であれば、Excelが先頭の署名を見て「これはUTF-8だ」と判断し、日本語を正しく表示できます。

私たち株式会社ドラマでも、ECサイトの構築や運用支援で商品データのCSVを扱う機会が数多くあります。たとえば、システムからUTF-8で書き出した商品一覧のCSVをお客様へお渡しした際、お客様がそれをダブルクリックでExcelに読み込むと商品名が化けてしまう、というご相談を受けることがあります。こうしたケースでは、書き出し時にBOM付きのUTF-8(ExcelのいわゆるCSV UTF-8形式)にそろえることで、ダブルクリックでも文字化けせずに開けるようになり、現場の手間を大きく減らせます。表計算ソフトからの書き出しでも同じ考え方が当てはまり、相手がWindowsのExcelで直接開く前提なら、BOM付きを選んでおくと安心です。2000年の創業以来、4,800件を超えるWeb制作に携わってきた経験からも、CSVとExcelの組み合わせはBOMの恩恵が分かりやすい代表例だと感じています。

従来のWindowsソフトがUTF-8と認識しやすくなる

Excel以外にも、UTF-8とANSI(従来のコードページ)を見分ける手がかりとしてBOMを利用する古いWindowsソフトがあります。こうしたソフトでは、BOMが無いとUTF-8を従来の文字コードと取り違えて文字化けすることがあり、BOMを付けておくことで正しく開けるようになります。ただし、これはあくまで特定の環境に向けた対処であり、すべての場面で推奨されるわけではありません。次章の注意点とあわせて、用途を見極めて選ぶことが大切です。

BOM付きが問題を起こす場面(注意点)

BOMが思わぬトラブルを生む場面も具体的に押さえておきましょう。とくにWeb制作やプログラムの現場では、BOM無しが基本になる理由がここにあります。

PHPで「headers already sent」が出る

WordPressをはじめとするPHPのファイルでよく起きるのが、ファイル先頭のBOMが原因でheaders already sentという警告が出るケースです。PHPでは、ヘッダー送信より前に少しでも出力があるとこの警告が発生しますが、ファイル冒頭のBOM(EF BB BFの3バイト)が「最初の出力」として扱われ、ヘッダー処理が阻害されてしまうのです。

株式会社ドラマでのWordPress開発でも、テーマやプラグインのPHPファイルを複数人で編集する際に、保存時のエンコード設定の違いから一部のファイルだけBOM付きで保存され、リダイレクトやCookieの処理が動かなくなる、といった状況に出会うことがあります。原因がBOMだと分かれば対処は単純で、該当ファイルをBOM無しのUTF-8で保存し直すだけで解決します。だからこそ、PHPファイルは最初からBOM無しにそろえておくことが、有効な予防策になります。

シェルスクリプトのshebangが壊れる

Linuxやmacのシェルスクリプトでは、先頭行に書く#!/bin/bashのような行(シバン)で、どのプログラムで実行するかを指定します。ところがファイル先頭にBOMが付いていると、システムは「EF BB BF 23 21」という並びを読み込むことになり、本来の「23 21(#!)」を先頭として認識できません。その結果、シバンが効かずにスクリプトが正しく起動しないことがあります。シェルスクリプトもBOM無しが前提だと覚えておきましょう。

JSONや設定ファイルが読み込みエラーになる

JSONは、規格上、先頭にBOMを付けないことになっています。そのため、厳密に実装されたJSONの読み込み処理では、先頭にBOMがあるだけでエラーになることがあります。設定ファイルとしてJSONを使う場面は多いので、BOM付きで保存してしまうと、原因の分かりにくい読み込み失敗につながりかねません。JSONはBOM無しで扱うのが安全です。

CSVの1列目のヘッダーにBOMが紛れ込む

BOM付きのCSVを、BOMを取り除かずにプログラムで読み込むと、1列目の見出しの先頭にBOMがくっついてしまうことがあります。たとえば見出しが「id」のつもりでも、実際には先頭にBOMが付いた状態として読まれ、列名の照合に失敗する、という不具合です。各種のインポート機能で「1列目だけ列名が一致しない」という症状が出たときは、BOMが紛れ込んでいないかを疑うと早く解決できます。ExcelでBOM付きにしておきたい場面と、プログラムで読み込みたい場面が混在するときは、とくに注意が必要です。

ファイル結合やGitの差分で予期せぬ挙動が出る

複数のUTF-8ファイルを単純に連結すると、それぞれのファイルが持つBOMが、結合後のファイルの途中に挟まってしまいます。途中に現れたBOMは見えない文字として残り、意図しない空白のように振る舞うことがあります。また、ソースコードのBOMの有無は、バージョン管理(Gitなど)で実質的な変更が無いのに差分として検出され、不要な差分やコンフリクトのもとになることもあります。チームでの開発では、BOMの有無をそろえておくと、こうした無用な混乱を避けられます。

HTML・CSS・JavaScriptとBOMの関係(Web制作での勘所)

Webサイトを作る現場では、BOMの有無がブラウザでの解釈や表示に関わってくるため、もう一段ふみ込んで押さえておくと役立ちます。結論としては、文字コードはmetaタグやサーバーの設定で明示的に宣言し、ファイル自体はBOM無しにそろえるのが扱いやすい形です。

HTML5では、ファイルの先頭にBOMがあると、それがページの文字エンコードの判定で、metaタグの宣言やサーバーのContent-Typeヘッダーよりも優先される、という決まりがあります。サーバー側の文字コード設定を変えられない状況では、BOMでUTF-8を強制できる利点になる場面もあるでしょう。一方で、これは裏を返せば、意図せず付いたBOMが宣言を上書きしてしまうということでもあり、扱いには注意が要ります。

表示面では、HTMLの先頭にBOMが入ることで、古い環境やレンダリングの状況によっては、ページの先頭に余分な空白のようなものが生じたり、レイアウトに影響したりすることがあります。CSSでも、文字コードを指定する@charsetの記述は本来ファイルの先頭に置く必要があるため、その手前にBOMが割り込むと指定がうまく働かないことがあります。JavaScriptを含め、Web系のファイルはBOM無しでそろえ、文字コードはHTMLのmetaタグ(charsetの指定)やサーバーのレスポンスヘッダーで明示する、という運用にしておくと、こうした細かなトラブルを避けやすくなります。

株式会社ドラマでも、ホームページ制作やLP制作、オウンドメディアの運用で多数のHTML・CSS・JavaScriptを扱いますが、これらはBOM無しを基本とし、文字コードはmetaタグで明示する方針にそろえています。こうしておくことで、複数人で制作・編集する際にも、エンコード起因の表示崩れを未然に防ぎやすくなります。

自分で確認する方法(判別の手順)

ここからがこの記事の中心です。「どちらか分からなくなる」を解消する一番の近道は、先頭3バイトがEF BB BFかどうかを自分の目で確かめられるようになることです。手軽な方法から確実な方法まで、順番に紹介します。自分の環境に合うものを一つ身につけておけば、迷ったときにすぐ判定できるようになります。

高機能エディタのステータスバーで見る(最も手軽)

普段づかいのエディタが対応していれば、これが一番手早い方法です。多くの高機能エディタは、現在のファイルがBOM付きかどうかを画面の端に表示してくれます。

• VS Code：画面右下のステータスバーに、BOM無しなら「UTF-8」、BOM付きなら「UTF-8 with BOM」と表示されます。表示部分をクリックすると、エンコードを変えて保存し直すこともできます。
• Notepad++：上部のエンコードのメニューを開くと、現在の状態として「UTF-8」か「UTF-8(BOM付き)」のどちらが選ばれているかを確認できます。

ステータスバーの表示は直感的で分かりやすい一方、エディタごとに表記が少しずつ異なります。表記に迷ったら、後述するバイトを直接見る方法で裏取りすると確実です。

Windowsのメモ帳で見る・切り替える(1903以降)

Windows標準のメモ帳でも、近年のバージョンであればBOMの有無を扱えます。Windows 10のバージョン1903以降のメモ帳では、保存時のエンコードにUTF-8(BOM無し)とUTF-8(BOM付き)が別々に用意され、画面右下のステータスバーに現在のエンコードが表示されるようになりました。新規ファイルの保存は、標準でBOM無しのUTF-8になっています。

ここで一点、注意したい歴史的な事情があります。バージョン1903より前の古いメモ帳では、UTF-8として保存すると自動的にBOMが付く仕様でした。「メモ帳でUTF-8保存したのにBOMが付いている」という食い違いは、たいていこの古い挙動が背景にあります。現在のメモ帳では「UTF-8」を選べばBOM無しになりますので、用途に応じて選び分けてください。

コマンドでバイトを直接見る(確実な方法)

表示の表記に頼らず、先頭のバイトをそのまま見れば、解釈の余地なく判定できます。ここが「自分で細かく確認したい」という目的に、もっとも合う方法です。

• Mac・Linux(xxd)：xxd file.txt | head -1 を実行し、行の先頭に ef bb bf と並んでいればBOM付き、いきなり本文のバイトが始まっていればBOM無しです。
• Mac・Linux(hexdump)：hexdump -C file.txt | head -1 でも同様に、先頭の ef bb bf の有無で判別できます。
• Mac・Linux(fileコマンド)：file file.txt を実行すると、BOM付きの場合は「with BOM」を含む説明が表示されることがあり、ざっくり確認したいときに便利です。
• Windows(PowerShell 5.1)：Get-Content file.txt -Encoding Byte -TotalCount 3 を実行し、先頭3バイトが 239 187 191(EF BB BFを10進数で表したもの)であればBOM付きです。
• Windows(PowerShell 7)：Format-Hex file.txt の先頭行を見て、EF BB BF で始まっていればBOM付きと分かります。

10進数の239 187 191と16進数のEF BB BFは、同じ3バイトを別の表記で表しているだけです。どちらの表記で出会っても「同じBOMを指している」と分かれば、戸惑わずに済みます。出力の先頭3バイトだけを見れば判定できるので、慣れればほんの数秒で確認できます。

Pythonで確認する(プログラムで判定)

判定を自動化したい場合や、たくさんのファイルをまとめて調べたい場合は、Pythonでバイナリとして先頭3バイトを読むのが確実です。ファイルをバイナリモード(rb)で開き、先頭3バイトが b’\xef\xbb\xbf’ と一致するかを調べれば、BOMの有無を機械的に判定できます。標準ライブラリのcodecsには、このBOMを表すcodecs.BOM_UTF8(中身は b’\xef\xbb\xbf’)が用意されているので、自分でバイトを書かずに比較に使うこともできます。

判定の考え方はシンプルで、「先頭3バイトがBOMと等しいならBOM付き、そうでなければBOM無し」と分岐するだけです。これを使えば、納品前に対象フォルダのファイルを一括で点検し、想定と違うBOMの状態を見つけ出すといった運用も組み立てられます。手作業で一つずつ開く手間がなくなるため、扱うファイル数が多い現場ほど効果を実感しやすいでしょう。

ブラウザやCMS上で見えない文字として気づくケース

専用のツールを使わなくても、表示の異変からBOMの存在に気づけることがあります。たとえば、ブラウザでページを開いたときに本文の先頭に不自然な空白が見える、WordPressなどの編集画面でテキストの冒頭に見覚えのない記号が混じる、テンプレートに差し込んだ覚えのない空白が先頭に入る、といった症状です。こうしたときは、該当ファイルや貼り付け元のテキストにBOMが紛れていないかを、ここまでに紹介した方法で確かめてみてください。原因がBOMだと分かれば、保存し直すだけで解決することがほとんどです。

BOMを付ける・外す手順(切り替え)

判別ができたら、次は目的に合わせて付けたり外したりできるようにしておきましょう。代表的な手段をまとめます。

BOMを付ける手順

• VS Code：右下のエンコード表示をクリックし、「エンコード付きで保存」から「UTF-8 with BOM」を選んで保存します。
• Excel：保存形式として「CSV UTF-8」を選ぶと、BOM付きのUTF-8として書き出されます。Windowsのダブルクリックで文字化けさせたくないCSVに向いています。
• Python：書き込み時に encoding=’utf-8-sig’ を指定すると、先頭にBOMを付けて保存できます。

BOMを外す手順

• VS Code：右下のエンコード表示をクリックし、「エンコード付きで保存」から「UTF-8」(BOM無し)を選んで保存します。
• Notepad++：エンコードのメニューから「UTF-8(BOM なし)」へ変換して保存します。
• Python：読み込み時に encoding=’utf-8-sig’ を指定するとBOMを取り除いて読み込めるので、その内容を encoding=’utf-8′ で書き出せばBOM無しのファイルになります。
• Mac・Linux(sed)：sed -i ‘1s/^\xEF\xBB\xBF//’ file.txt のように、1行目の先頭にあるBOMだけを削除する方法もあります。

Pythonのutf-8-sigは、覚えておくと便利な仕組みです。読み込み時にはBOMがあれば自動で取り除き、書き込み時にはBOMを付ける、という役割分担になっています。BOM付きで届いたファイルを読み、BOM無しで書き出す、という変換にちょうど向いています。逆に、ふだんBOM無しのファイルを作りたいだけなら、書き込みには標準のutf-8を使うのが安全です。utf-8-sigは書き込みのたびにBOMを足す点だけ、取り違えないようにしましょう。

よくある誤解

BOMにまつわる代表的な勘違いを整理します。どれも「分からなくなる」原因になりやすいポイントです。

• UTF-8にもBOMでバイト順を示す必要がある、という誤解：UTF-8はバイト指向のため、そもそもバイト順の問題がありません。UTF-8のBOMは署名としての役割だけで、バイト順を示すものではないのです。
• BOMは目に見える記号だ、という誤解：BOMの正体は幅を持たない不可視のU+FEFFです。見えないからこそ、混入しても気づきにくいという難しさがあります。
• BOM無しは壊れている、不完全だ、という誤解：むしろBOM無しのUTF-8が現在の標準であり、Webやプログラムの多くの場面で推奨される形です。BOMが無いことは異常ではありません。
• メモ帳でUTF-8保存すれば必ずBOM無しになる、という誤解：これはバージョン次第です。1903より前の古いメモ帳では、UTF-8保存でBOMが付きました。現在は「UTF-8」を選べばBOM無しになります。
• BOMと文字コード(エンコード)は同じものだ、という誤解：BOMは「このファイルはUTF-8です」という目印で、文字コードは文字をバイトに対応づける仕組みそのものです。BOMの有無にかかわらず、ファイルはUTF-8です。
• JSONはBOM付きでも必ず読める、という誤解：規格上、JSONはBOMを付けない決まりです。厳密な読み込み処理では、先頭のBOMでエラーになることがあります。

補足：文字化けの原因はBOMだけではない

最後に、トラブル対応で混同しやすい点を補足します。文字化けが起きると「BOMのせいでは」と考えがちですが、原因がBOMとは限りません。多いのは、UTF-8で保存されたファイルを別の文字コードとして読んでしまう(あるいはその逆)という、エンコードそのものの取り違えです。この場合、éや’のような並びが本文のあちこちに現れます。一方、BOMが直接関わる症状は、ファイルの先頭にのような並びが出る、先頭に見えない空白が入る、1列目の列名が一致しない、といった「先頭」に集中する点が見分けの手がかりです。症状が本文全体に散らばっているならエンコードの取り違え、先頭に限られているならBOM、という切り分けを覚えておくと、原因にたどり着きやすくなります。

失敗しないためのチェック項目

迷ったときに見返せるチェックリストをまとめます。納品前やトラブル発生時の確認に役立ててください。

• 用途を確認したか：Web系・プログラム系ならBOM無し、WindowsのExcelで開く日本語CSVならBOM付き、という方針に沿っているか。
• 先頭3バイトを確認したか：EF BB BF(10進数なら239 187 191)が先頭にあるかどうかを、バイト単位で確かめたか。
• エディタの表示を確認したか：VS CodeやNotepad++のステータスバー・メニューで、BOMの有無の表示を見たか。
• 実際に開いて確かめたか：納品予定のCSVを、想定される環境(WindowsのExcelなど)でダブルクリックして開き、日本語が化けないか。
• プログラム系はBOM無しか：PHP・シェルスクリプト・JSONなど、BOMで不具合が出やすいファイルがBOM無しになっているか。
• 結合時にBOMが混ざっていないか：複数ファイルを連結した場合に、途中へBOMが挟まっていないか。
• チームで設定をそろえたか：共同で編集するファイルについて、保存時のエンコード(BOMの有無)をメンバー間で統一したか。

まとめ

BOM無しとBOM付きの違いは、中身のUTF-8は同じで、先頭にEF BB BFの3バイトを付けるかどうかだけです。Web系やプログラム系のファイルはBOM無しを基本にし、WindowsのExcelでそのまま開く日本語入りCSVだけBOM付きにすれば、実務の大半はうまく回ります。そして「どちらか分からなくなる」を根本から解消する鍵は、先頭3バイトを自分で確認できるようになることにあります。エディタのステータスバー、コマンドでのバイト確認、Pythonでの判定のいずれか一つを身につけておけば、迷ったその場で判定でき、付け外しも落ち着いて対応できます。

Web制作・EC・WordPressの文字コードでお困りなら

株式会社ドラマは、京都を拠点に2000年の創業以来、4,800件を超えるホームページ制作・ECサイト構築・WordPress開発に携わってきたWeb制作会社です。文字コードやBOMにまつわる文字化け、CSVの取り回し、WordPressの不具合の切り分けなど、現場で積み重ねた知見をもとに、原因の特定から運用の改善まで一緒に進めます。お困りごとがありましたら、サイトのお問い合わせフォーム、LINEでのご相談、お見積もりのご依頼、またはお電話(075-585-5352)からお気軽にご連絡ください。詳しくは https://drama.co.jp/ をご覧ください。