6. Byte order mark (BOM) (バイトオーダーマーク)
定義 (Definition)
UCS文字U+FEFF "ZERO WIDTH NO-BREAK SPACE"は、非公式に"BYTE ORDER MARK"（略して"BOM"）としても知られています。この文字は、テキスト内で本物の"ZERO WIDTH NO-BREAK SPACE"として使用できますが、BOMという名前は、文字の2番目の使用法を示唆しています：UCS文字のストリームに"シグネチャ"としてU+FEFF文字を前置することです。
シグネチャとしての使用 (Usage as Signature)
このようなシリアル化されたストリームの受信者は、最初の文字を以下のヒントとして使用できます：
- ストリームがUCS文字で構成されていること
- どのUCSエンコーディングが関与しているかを認識すること
- マルチオクテットエンコーディング単位を持つエンコーディングでは、オクテットのシリアル化順序を認識する方法として
UTF-8とBOM (UTF-8 and BOM)
UTF-8は単一オクテットエンコーディング単位を持っているため、この最後の機能は不要であり、BOMは常にオクテットシーケンスEF BB BFとして現れます。
解釈規則 (Interpretation Rules)
位置が重要 (Position Matters)
ストリームの先頭以外の位置に現れる文字U+FEFFは、ゼロ幅非改行スペースのセマンティクスで解釈されなければならず (MUST)、シグネチャとして解釈してはなりません (MUST NOT)。
ストリッピングの考慮事項 (Stripping Considerations)
シグネチャとして解釈される場合、Unicode標準は、最初のU+FEFF文字がテキストを処理する前に削除される可能性があることを示唆しています。このようなストリッピングは、場合によっては必要です（例えば、2つの文字列を連結する場合、そうしないと結果の文字列が接続点で意図しない"ZERO WIDTH NO-BREAK SPACE"を含む可能性があります）が、ストリーム内のすべての文字の存在に依存している異なるレイヤーの外部プロセス（デジタル署名や文字のカウントなど）に影響を与える可能性があります。
推奨事項 (Recommendation)
したがって、以下のことが推奨されます (RECOMMENDED)：
- 正当な理由なしに、シグネチャとして解釈される最初のU+FEFFのストリッピングを避けること
- 適切な場合（表示など）、ストリッピングではなく無視すること
- 本当に必要な場合にのみストリッピングすること
曖昧性の問題 (Ambiguity Issues)
ストリームの最初の位置のU+FEFFは、ゼロ幅非改行スペースとして解釈される可能性があり (MAY)、常にシグネチャであるとは限りません。
Unicode 3.2の追加 (Unicode 3.2 Addition)
この不確実性を減らす試みとして、Unicode 3.2は、シグネチャ機能を除いて、U+FEFFと全く同じセマンティクスと使用法を持つ新しい文字、U+2060 "WORD JOINER"を追加し、単語結合セマンティクスを表現するためにこれを独占的に使用することを強く推奨しています。
将来の明確性 (Future Clarity)
最終的に、この推奨に従うことで、最初のU+FEFFはシグネチャであり、意図された"ZERO WIDTH NO-BREAK SPACE"ではないことがほぼ確実になります。
プロトコルガイドライン (Protocol Guidelines)
それまでの間、不確実性は残念ながら残り、インターネットプロトコルに影響を与える可能性があります。プロトコル仕様は、この不確実性の潜在的な悪影響を減らすまたは排除するために、シグネチャとしてのU+FEFFの使用を制限してもよい (MAY) です。
このような制限の利点（不確実性の削減）と欠点（シグネチャ機能の喪失）のバランスを取ることを目的として、いくつかのケースを区別することが有用です：
ケース1: UTF-8が義務付けられている場合
プロトコルは、プロトコルが常にUTF-8であることを義務付けているテキストプロトコル要素に対して、シグネチャとしてのU+FEFFの使用を禁止すべきです (SHOULD)。これらのケースでは、シグネチャ機能は完全に無用です。
ケース2: 信頼できる識別メカニズム
プロトコルはまた、プロトコルが文字エンコーディング識別メカニズムを提供しているテキストプロトコル要素に対して、実装がメカニズムを適切に使用できる立場にあることが期待される場合、シグネチャとしてのU+FEFFの使用を禁止すべきです (SHOULD)。
これは、プロトコル要素が作成時から（適切にラベル付けされた）送信時まで、実装の制御下で厳密に維持される場合に該当します。
ケース3: 識別メカニズムなし
プロトコルは、以下の場合、プロトコルが文字エンコーディング識別メカニズムを提供していないテキストプロトコル要素に対して、シグネチャとしてのU+FEFFの使用を禁止すべきではありません (SHOULD NOT)：
- 禁止が強制不可能である場合、または
- プロトコルの実装がメカニズムを適切に使用できる立場にないことが期待される場合
後者の2つのケースは、特にプロトコルの実装が以下からそのようなエンティティを取得する場合、MIMEエンティティなどの大きなプロトコル要素で発生する可能性が高いです：
- ファイルシステム
- ペイロードのエンコーディング識別メカニズムを持たないプロトコル（FTPなど）
- 文字エンコーディングの適切な識別を保証しない他のプロトコル（HTTPなど）
実装ガイダンス (Implementation Guidance)
禁止されている場合
プロトコルが特定のプロトコル要素に対してシグネチャとしてのU+FEFFの使用を禁止している場合、そのプロトコル要素内の最初のU+FEFFは、"ZERO WIDTH NO-BREAK SPACE"として解釈されなければなりません (MUST)。
禁止されていない場合
プロトコルが特定のプロトコル要素に対してシグネチャとしてのU+FEFFの使用を禁止していない場合、実装は以下を行う準備をすべきです (SHOULD)：
- その要素内のシグネチャを処理すること
- 適切に反応すること：必要に応じてシグネチャを使用して文字エンコーディングを識別すること
- 適切にシグネチャをストリッピングまたは無視すること