バイトオーダーマーク

バイトオーダーマーク（BOM ）は、特殊なUnicode文字コードU+FEFF ZERO WIDTH NO-BREAK SPACEの特殊な用法であり、テキストストリームの先頭にマジックナンバーとして現れることで、テキストを読み取るプログラムにいくつかのことを知らせることができます。^[1]

• 16ビットおよび 32 ビット エンコーディングの場合のテキスト ストリームのバイト順序、またはエンディアン。
• テキスト ストリームのエンコーディングが Unicode であることの信頼性が高いこと。
• 使用される Unicode 文字エンコーディング。

BOM の使用はオプションです。BOM が存在すると、ファイルの先頭に 非ASCIIバイトを想定していないが、テキスト ストリームを処理できるソフトウェアによるUTF-8の使用が妨げられます。

Unicode は、8 ビット、16 ビット、または 32 ビットの整数単位でエンコードできます。16 ビットおよび 32 ビットの表現の場合、任意のソースからテキストを受信するコンピューターは、整数がどのバイト順序でエンコードされているかを知る必要があります。BOM は、ドキュメントの残りの部分と同じスキームでエンコードされ、バイトがスワップされると非文字Unicode コード ポイントになります。したがって、テキストにアクセスするプロセスは、テキスト ストリーム自体の外部の契約やメタデータを必要とせずに、これらの最初の数バイトを調べてエンディアンを判断できます。通常、受信側のコンピューターは、必要に応じてバイトを独自のエンディアンにスワップし、処理に BOM は不要になります。

BOM のバイトシーケンスは Unicode エンコードごとに異なり ( UTF-7などの Unicode 標準外のものも含む、下の表を参照)、他のエンコードで保存されたテキストストリームの先頭には、どのシーケンスも出現しない可能性が高い。したがって、エンコードされた BOM をテキストストリームの先頭に配置すると、テキストが Unicode であることを示し、使用されているエンコード方式を識別できる。この BOM の使用は「Unicode 署名」と呼ばれる。^[2]

BOM は、単純に、U+FEFF ZERO WIDTH NO-BREAK SPACE現在のエンコードでエンコードされた Unicode コードポイントです。 バイトで始まるテキスト ファイルは、FE FFビッグ エンディアン UTF-16 でエンコードされていることを示します。

BOMがデータストリームの途中に現れる場合は、ZWNBSPという名前を使用する必要があります。Unicodeでは、BOMではなく、通常のコードポイント（つまり、単語結合子）として解釈する必要があるとされています。Unicode 3.2以降、この使用法は廃止され、代わりにが使用されています。^[1]U+2060 WORD JOINER

このコードポイントのUnicode 1.0名もBYTE ORDER MARK^{[3]である。}

BOM の UTF-8 表現は ( 16進数の) バイト シーケンスですEF BB BF。

Unicode 標準では、UTF-8での BOM の使用が許可されていますが^[4]、その使用は必須でも推奨でもありません。^[5] UTF-8 は常に同じバイト順序であるため^[6] 、 UTF-8 での BOM の使用は、テキスト ストリームが UTF-8 でエンコードされているか、オプションの BOM を含むストリームから UTF-8 に変換されたことを最初に通知する場合のみです。 また、標準では、エンコード間のラウンドトリップで情報が失われないように、また、BOM に依存するコードが引き続き機能するように、BOM が存在する場合は削除しないことも推奨しています。^{[7] [8]} IETF は、プロトコルが (a) 常に UTF-8 を使用するか、(b) 使用されているエンコードを示す他の方法がある場合、「署名として U+FEFF の使用を禁止するべき」と推奨しています。^[9]この推奨に従わない例としては、テキストが UTF-8 で、BOM も必要なIETF Syslogプロトコルがあります。 ^[10]

BOM を使用しないと、テキストは拡張 ASCII用に設計されたソフトウェアと下位互換性を保つことができます。たとえば、多くのプログラミング言語では、文字列リテラル内では非ASCIIバイトが許可されますが、ファイルの先頭では許可されません。

UTF-8 エンコーディングの検出には BOM は不要です。^[要出典] UTF-8 はスパース エンコーディングです。つまり、可能なバイトの組み合わせの大部分は、有効な UTF-8 テキストにはなりません。バイナリ データと他のエンコーディングのテキストには、UTF-8 としては無効なバイト シーケンスが含まれている可能性が高いため、このような無効なシーケンスが存在する場合はファイルが UTF-8 ではないことを示し、無効なシーケンスがない場合はテキストがUTF-8 であることを非常に強く示しています。実質的に唯一の例外は、ASCII 範囲のバイトのみを含むテキストです。これは非 ASCII 7 ビット エンコーディングである可能性がありますが、これは最近のデータでは考えにくく、ASCII との違いはわずかです ('\' を '¥' に変更するなど)。

Microsoftのコンパイラ^[11]とインタープリタ、およびメモ帳（Windows 10 Build 1903 ^[12]より前）などのMicrosoft Windows上の多くのソフトウェアは、ヒューリスティックを使用するのではなく、BOMを必須のマジックナンバーとして扱います。これらのツールは、テキストをUTF-8として保存するときにBOMを追加しますが、BOMが存在するかファイルにASCIIのみが含まれていない限り、UTF-8を解釈できません。Windows PowerShell（5.1まで）は、UTF-8 XMLドキュメントを保存するときにBOMを追加します。ただし、PowerShell Core 6では、一部のコマンドレットにutf8NoBOMというスイッチが追加され、ドキュメントをBOMなしで保存できるようになりました。Google Docsも、ドキュメントをダウンロード用に プレーンテキストファイルに変換するときにBOMを追加します。-Encoding

UTF-16では、U+FEFFファイルまたは文字ストリームの最初のバイトとしてBOM ( ) を配置して、ファイルまたはストリームのすべての 16 ビットコード ユニットのエンディアン (バイト順序) を示すことができます。このストリームを間違ったエンディアンで読み取ろうとすると、バイトが入れ替わり、Unicode によってテキストに出現してはならない「非文字」として定義されている文字 がU+FFFE生成されます。

• 16ビット単位がビッグエンディアンバイト順（「UTF-16BE」）で表現される場合、BOMは（16進）バイトシーケンスである。FE FF
• 16ビットユニットがリトルエンディアン順序（「UTF-16LE」）を使用する場合、BOMは（16進）バイトシーケンスです。FF FE

IANAに登録されている文字セット UTF-16BE および UTF-16LEの場合、これらの文字セットの名前によってバイト順序がすでに決定されているため、バイト順序マークは使用しないでください。

BOM がない場合、ASCII 文字 (つまり、0x20-0x7E の範囲のバイトに隣接する 0 バイト、CR と LF の場合は 0x0A と 0x0D) を検索することで、テキストが UTF-16 であるかどうか、およびそのバイト順序を推測できます。同じ順序で大きな数字 (つまり、ランダムな確率よりもはるかに高い) がある場合は、UTF-16 である可能性が非常に高く、0 が偶数バイトにあるか奇数バイトにあるかによってバイト順序がわかります。ただし、これにより誤検知と誤検知の両方が発生する可能性があります。

Unicode 標準の適合性条項 D98 (セクション 3.10) には、「UTF-16 エンコード方式は BOM で始まる場合と始まらない場合があります。ただし、BOM がなく、上位レベルのプロトコルがない場合、UTF-16 エンコード方式のバイト順序はビッグ エンディアンです。」と記載されています。上位レベルのプロトコルが有効かどうかは、解釈の余地があります。たとえば、ネイティブ バイト順序がリトルエンディアンであるコンピューターのローカル ファイルは、暗黙的に UTF-16LE としてエンコードされていると主張される可能性があります。したがって、ビッグ エンディアンの推定は広く無視されています。HTML5で使用されるW3C /WHATWG エンコード標準では、「utf-16」または「utf-16le」のいずれかのラベルが付けられたコンテンツは、「展開されたコンテンツを処理するため」リトルエンディアンとして解釈されることが規定されています。^[13]ただし、バイト順序マークが存在する場合、その BOM は「他の何よりも信頼できる」ものとして扱われます。^[14]

UTF-32でも BOM を使用できますが、このエンコードが送信に使用されることはほとんどありません。それ以外は、 UTF-16と同じルールが適用されます。

リトルエンディアン UTF-32 の BOM は、リトルエンディアン UTF-16 BOM の後に UTF-16 NUL 文字が続くパターンと同じであり、2 つの異なるエンコードで BOM が同じパターンになる珍しい例です。BOM を使用してエンコードを識別するプログラマーは、UTF-32 と、先頭文字が NUL である UTF-16 のどちらがより適切であるかを判断する必要があります。

この表は、BOM がさまざまなエンコーディングでバイト シーケンスとしてどのように表現されるか、および各バイトをレガシー エンコーディング( Windows-1252およびC0 コントロールのキャレット表記) として解釈するテキスト エディターでそれらのシーケンスがどのように表示されるかを示しています。

• 左から右へのマーク
• アラビア語表示形式BU+FEFF 、コードポイントが属するブロック

• Unicode に関するよくある質問: UTF-8、UTF-16、UTF-32、BOM
• Unicode 標準、第 2.6 章 エンコード スキーム
• Unicode 標準、第 2.13 章「特殊文字と非文字」、セクション「バイト オーダー マーク (BOM)」
• Unicode 標準、第 16.8 章「特殊文字」、セクション「バイト オーダー マーク (BOM): U+FEFF」