次の方法で共有

バイトオーダーマークの使用

  • [アーティクル]

Unicode プレーン テキスト ファイルの先頭に必ずバイト順マークを付けます。これにより、ファイルがバイト順であることをアプリケーションが受け取ります。 使用可能なバイト順マークを次の表に示します。 Unicode プレーン テキストは 16 ビットコード値のシーケンスであるため、テキストの書き込み時に使用されるバイト順序に依存します。

Note

バイトオーダーマークは、テキストのバイトオーダーを選択する制御文字ではありません。

 

バイト順マーク (BOM: Byte Order Mark) 説明
EF BB BF UTF-8
FF FE UTF-16、リトル エンディアン
FE FF UTF-16、ビッグ エンディアン
FF FE 00 00 UTF-32、リトル エンディアン
00 00 FE FF UTF-32、ビッグ エンディアン

 

Note

Microsoft は UTF-16 のリトル エンディアン バイト順を使用します。

 

理想的には、すべての Unicode テキストは、バイト順序付け規則の 1 つのセットにのみ従います。 ただし、マイクロプロセッサーは最下位バイトの配置が異なるため、これは不可能です。 Intel および MIPS プロセッサは最下位バイトを最初に配置しますが、Motorola プロセッサ (およびすべてのバイト反転 Unicode ファイル) は最後に位置します。 1 つのバイト順序付け規則のセットだけで、1 種類のマイクロプロセッサのユーザーは、ファイルが別のマイクロプロセッサに基づいて別のオペレーティング システムに転送されていなくても、プレーン テキスト ファイルの読み取りまたは書き込みが行われるたびに、バイト順を強制的に入れ替える必要があります。

バイト順を指定する推奨される場所はファイル ヘッダーにありますが、テキスト ファイルにはヘッダーがありません。 したがって、Unicode では文字 (U+FEFF) と非文字 (U+FFFE) がバイト順マークとして定義されています。 これらはミラー互いのバイト 画像です。

シーケンス U+FEFF は通常の Unicode 以外のテキスト ファイルの先頭では非常にまれであるため、ファイルを Unicode ファイルとして識別するための暗黙的なマーカーまたはシグネチャとして機能できます。 Unicode テキスト ファイルと Unicode 以外のテキスト ファイルの両方を読み取るアプリケーションでは、ファイルが Unicode ファイルである可能性が最も高いインジケーターとして、このシーケンスの存在を使用する必要があります。 この手法を MS-DOS EOF マーカーを使用してテキスト ファイルを終了する方法と比較します。

アプリケーションは、テキスト ファイルの先頭で U+FEFF を検出すると、通常は Unicode ファイルとしてファイルを処理しますが、検証のためにさらにヒューリスティック チェックを実行できます。 このようなチェックは、下位バイトの変動が高次バイトの変動よりもはるかに大きいかどうかを調べるテストと同じくらい簡単です。 たとえば、ASCII テキストが Unicode テキストに変換される場合、2 番目のバイトは 0 になります。 また、ラインフィード文字と復帰文字 (U+000A および U+000D) と偶数または奇数のファイル サイズの両方をチェックすると、ファイルの性質を強く示すことができます。

アプリケーションがテキスト ファイルの先頭で U+FFFE を検出すると、ファイルがバイト反転 Unicode ファイルであることを意味すると解釈されます。 アプリケーションは、バイトの順序を入れ替えるか、エラーが発生したことをユーザーに警告することができます。

Unicode バイト順マーク文字はどのコード ページにも見つからないため、データが ANSI に変換されると消えます。 他の Unicode 文字とは異なり、変換時に既定の文字に置き換えられるわけではありません。 ファイルの途中でバイトオーダーマークが見つかった場合、Unicode 文字として解釈されず、テキスト出力には影響しません。

Note

Unicode 値 U+FFFF はプレーン テキスト ファイルでは無効であり、アプリケーション間で渡すことはできません。 これは、アプリケーションのプライベート使用のために予約されています。

 

Unicode での特殊文字の使用