BOM (Byte Order Mark) は、テキストファイルの先頭に付与される特殊なバイト列で、エンコーディングの種類やバイト順 (エンディアン) を示す目印です。Unicode の文字 U+FEFF (ZERO WIDTH NO-BREAK SPACE) をエンコードしたもので、ファイルを開くアプリケーションがエンコーディングを自動判定するための手がかりとして機能します。BOM はファイルの内容そのものではなく、メタ情報としての役割を担っています。

BOM の具体的なバイト列はエンコーディングごとに異なります。UTF-8 では EF BB BF の 3 バイト、UTF-16 ビッグエンディアン (BE) では FE FF の 2 バイト、UTF-16 リトルエンディアン (LE) では FF FE の 2 バイト、UTF-32 BE では 00 00 FE FF の 4 バイトです。UTF-16 や UTF-32 ではマルチバイトの数値をどちらのバイト順で格納するかが問題になるため、BOM によるエンディアン判別が不可欠です。一方、UTF-8 はバイト順の概念を持たないため、BOM は純粋にエンコーディング識別の目的で使われます。ファイルエンコーディングの書籍で BOM の詳細を学べます。

実務で最も頻繁に問題になるのが UTF-8 BOM の扱いです。UTF-8 BOM (EF BB BF) はファイル先頭の 3 バイトとして存在しますが、多くのプログラムやツールがこれを不要なバイトとして扱います。たとえば、シェルスクリプトの先頭に BOM があると shebang 行 (#!/bin/bash) が正しく認識されず実行に失敗します。PHP ファイルでは BOM が HTML 出力の前に送信され、headers already sent エラーの原因になります。CSV ファイルでは、BOM の有無によって Excel での文字化けが発生するかどうかが変わります。Web 開発では BOM なし UTF-8 が事実上の標準であり、HTML5 仕様でも BOM なしが推奨されています。

Windows のメモ帳は長年にわたり UTF-8 保存時に BOM を自動付与していましたが、Windows 10 のバージョン 1903 以降では BOM なし UTF-8 がデフォルトに変更されました。この変更は、Web 開発者やプログラマーにとって歓迎すべき改善です。一方、Excel で UTF-8 CSV を正しく開くには BOM が必要な場合があり、用途に応じた使い分けが求められます。Visual Studio Code や Sublime Text などのモダンなエディタでは、ステータスバーでエンコーディングと BOM の有無を確認・変更できます。テキストエディタ活用の書籍でもエンコーディング設定は重要なトピックです。

文字数カウントにおいて、BOM は見落としやすい落とし穴です。BOM はゼロ幅の不可視文字であるため画面上には表示されませんが、ファイルサイズには影響します。UTF-8 BOM 付きファイルは BOM なしファイルより 3 バイト大きくなります。また、テキストを文字列として読み込んだ際に BOM が文字列の先頭に残ると、文字数が 1 文字多くカウントされたり、文字列比較で不一致が生じたりする原因になります。プログラムでファイルを読み込む際は、BOM の有無を検出して適切に除去する処理を組み込むことが重要です。