UTF-8 BOMの有無で何が変わるか
Excelで開いたら文字化けする、CSVをアップロードしたら1行目だけ妙な文字が…その犯人はだいたいBOMです。Unicode公式の見解と実務の落としどころを整理します。
1. BOMとは何か
BOM（Byte Order Mark）はテキストの先頭に付与する U+FEFF（ゼロ幅ノーブレークスペース）の特殊文字です。本来はUTF-16/UTF-32でバイト順（ビッグエンディアン／リトルエンディアン）を識別するために使われました。UTF-8はバイト順の概念がないため、本来BOMは不要です。それでも UTF-8 BOM（EF BB BF）が現実に流通しているのは、「これはUTF-8です」という識別マーカーとして使われているからです。
2. Unicode公式の見解
Unicode Consortium公式FAQ「UTF-8, UTF-16, UTF-32 & BOM」では、UTF-8ファイルにBOMを付けるかどうかは「文脈次第」で、必ずしも推奨しないという立場です。IETF RFC 3629 §6でも「BOMは UTF-8 では原則として不要だが、識別マーカーとして付けることはある」と明記。つまり「規格的にどっちでもよい」のですが、ソフトウェア側の対応はバラバラで、これが文字化けの温床になっています。
3. BOMを付けた方がいい場面
代表は「Excelで日本語CSVを開きたい時」。Microsoft ExcelはBOMなしUTF-8をShift_JISと誤判定して文字化けすることがあり、BOM付きUTF-8で保存すると正しく開けます。Windowsのメモ帳も同様。一方、Apple Numbers・LibreOffice・Googleスプレッドシートは大抵BOMなしでもUTF-8を自動判別します。「相手がWindowsのExcelで開くCSV」を作るなら BOM 付与が安全策です。
4. BOMを付けない方がいい場面
Web・プログラムに渡す時はBOM無しが基本。HTML/CSS/JSONの先頭にBOMが残るとパーサが拒否したり、想定外の空白扱いになることがあります。シェルスクリプト（#!/bin/bash の前にBOMが入ると起動失敗）、PHPの「Headers already sent」、JSONの先頭に余計な文字が入って JSON.parse が落ちる、などが典型的トラブル。「APIに送るCSV」や「コードファイル」はBOMなしで作成・保存してください。
5. 既存ファイルのBOM有無を確認・除去する
確認は「VS Codeの右下に UTF-8 with BOM と表示されるか」で一目瞭然。秀丸・サクラエディタなら「文字コード変更→BOMなしUTF-8」で除去できます。本ツールにBOM付きテキストを貼ると、最初の行の先頭にゼロ幅文字（U+FEFF）が残ります。これも1文字としてカウントされる点に注意。重複判定では「BOM付きの行」と「BOM無しの行」が別物と扱われます。
6. 実務での判断フロー
①最終的に誰が開くかを考える。②Windows Excel/メモ帳で開くなら BOM 付与。③Web/プログラム/API に渡すなら BOM なし。④分からない時は BOM なしで作って、文字化けしたら BOM 付きに切替。出典はUnicode公式FAQとRFC 3629 §6。BOMで悩むくらいなら本ツールで先に重複・空行を整理してから、用途に応じてBOM有無を切り替えるのが楽です。