バイト順マーク (バイトじゅんマーク、) 、バイトオーダーマークあるいはBOM(ボム)は、Unicodeの符号化形式で符号化したテキストの先頭につける数バイトのデータ。元にUnicodeで符号化されていることおよび符号化の種類の判別に使用する。
概要 プログラムがテキストデータを読み込む時、その先頭の数バイトからそのデータがUnicodeで表現されていること、また符号化形式(エンコーディング)としてどれを使用しているかを判別できるようにしたものである。
経緯 Unicodeが開発された当初は、アメリカではASCII、ヨーロッパなどではISO-8859、日本ではShift_JISやEUC-JPといった他の文字コードが主流であり、使用されている符号化方式がUnicodeのものであることを明示する必要があった。また、Unicodeの符号化方式は複数あり、特にUTF-16やUTF-32にはそれぞれエンディアンが異なる2種類があるため、符号化方式同士を区別する必要があった。その方法として、先頭のデータにテキスト以外のデータを入れることが発案された。
使用するべきか否か 実際にBOMを使用すべきか、あるいは使用すべきでないかは、Unicodeを利用したより上位の仕様によって定められることがある。"XML Media Types" () では、XMLをUTF-16で符号化する場合は先頭のBOMを必須とし、またXMLを解釈するソフトウェアでは、先頭にBOMがあった場合はxml宣言における<?xml encoding="..."?>の指定よりも優先してエンコーディングを判別すべきとしている XML Media Types(2001年1月)。JSONの場合は、ネットワークで送信する場合はBOMを付けてはならないとしている8.1. Character Encoding - STD 90 - The JavaScript Object Notation (JSON) Data Interchange Format。
UTF-8は文字コードとしてASCIIを前提としたプログラムでもおよそ支障なく動作するように設計されているが、BOMによって正常に処理できなくなる場合がある。Unicodeの規格において、UTF-8においてBOMは容認されるが、必須でも勧められるものでもないとされている。また、データベースやメモリにロードするデータなど、内部的なデータ形式では、プログラムの性能や効率の観点から普通BOMは用いられない。
BOMによってUnicodeのテキストデータが他のUnicode符号化形式や、BOMのバイト表現(UTF-7を除く)に符号位置に該当する文字のない日本語の文字コードから正確に区別をすることができる一方で、0xFEに"þ"、0xFFに"ÿ"が割り当てられているISO/IEC 8859-1に対しては、この2文字が先頭にくる文章を誤ってUnicodeと判断してしまう問題がある。
Windowsのメモ帳は、長らくUTF-8で保存する際にBOM付きしかなかったが、2019年以降BOMなしのUTF-8で保存できるようになった上にBOMなしのUTF-8がデフォルトとなった「メモ帳」に多数の改善、BOMなしUTF-8がデフォルト保存形式に ~「Windows 10 19H1」 - 窓の杜 (2018年12月11日) - 2025年7月19日閲覧。
各符号化形式(符号化スキーム)ごとのバイト順マーク 符号化形式(符号化スキーム)エンディアンの区別バイト順マーク (BOM)UTF-8 0xEF 0xBB 0xBFUTF-16BE0xFE 0xFF||LE||0xFF 0xFEUTF-16BE (付加は認められない)UTF-16LE (付加は認められない)UTF-32BE0x00 0x00 0xFE 0xFF||LE||0xFF 0xFE 0x00 0x00UTF-32BE (付加は認められない)UTF-32LE (付加は認められない)UTF-7 0x2B 0x2F 0x76 ※ (※は次のバイトの値によって異なり、0x38、0x39、0x2B、0x2Fのいずれかがくる)
関連項目 ゼロ幅ノーブレークスペース - U+FEFF の文字
脚注