BOM
Claude Code.icon
BOM（Byte Order Mark、バイトオーダーマーク）は、テキストファイルの先頭に置かれる特殊なバイト列で、そのファイルの文字エンコーディングやバイトの並び順（エンディアン）を示すための「目印」です。
Unicode のコードポイント U+FEFF（ZERO WIDTH NO-BREAK SPACE）がこの目印として使われます。 そもそも何のためにあるのか
主な役割は2つあります。
1. エンディアン（バイト順）の判別
UTF-16 や UTF-32 では、1文字を複数バイトで表します
このとき「上位バイトを先に置くか（ビッグエンディアン）／下位バイトを先に置くか（リトルエンディアン）」の2通りがあり、どちらか判別する必要があります。BOM はこれを示します。
2. エンコーディングの判別
ファイルが UTF-8 なのか UTF-16 なのか、といった種類の推定に使われます。
エンコーディング別のバイト列
U+FEFF は、各エンコーディングで次のようなバイト列になります。
table:_
エンコーディング 先頭バイト列（16進）
UTF-8 EF BB BF
UTF-16 BE（ビッグエンディアン） FE FF
UTF-16 LE（リトルエンディアン） FF FE
UTF-32 BE 00 00 FE FF
UTF-32 LE FF FE 00 00
BE を読み込むと FE FF、LE では逆に FF FE になる点がポイントです。この差でバイト順を見分けます。
UTF-8 の BOM は「厄介者」になりがち
UTF-8 はもともとバイト順の概念がない（1バイト単位で並ぶ）ので、UTF-8 に BOM は本来不要です。にもかかわらず、Windows のメモ帳などが「これは UTF-8 ですよ」という印として付けることがあり、これがトラブルの元になります。
よくある問題：
プログラムのソースコード：ファイル先頭の EF BB BF が余計な文字として扱われ、シェルスクリプトの #!/bin/bash が効かない、PHP で意図しない空白が出力される、などの不具合。
CSV / JSON：先頭に見えない文字が混入し、パースエラーや、最初の列名がずれる。
文字列比較・diff：見た目は同じなのに一致しない。
実務での扱い方
テキストエディタで「UTF-8」と「UTF-8 with BOM（BOM付き）」を選べる場合、特別な理由がなければ BOM なしの UTF-8 を選ぶのが無難です。
Unix/Linux 系のツールや多くのプログラミング言語は BOM なし UTF-8 を前提にしています。
逆に一部の Windows アプリ（古い Excel など）は、BOM がないと UTF-8 CSV を正しく認識しないことがあり、あえて BOM を付ける場面もあります。
見えないけど存在する、という点に注意
BOM は画面上には表示されないため、「なぜかエラーになる」「原因不明の1バイトのズレ」といった形で気づきにくいバグを生みます。hexdump や xxd などでファイル先頭のバイトを確認すると、ef bb bf があるかどうかを直接チェックできます。
code:bash
xxd file.txt | head -1
# 先頭に ef bb bf があれば UTF-8 BOM 付き
要するに BOM は「エンコーディングとバイト順を伝えるための先頭マーカー」で、UTF-16/32 では有用、UTF-8 では基本つけない方が安全、と覚えておくとよいです。