原理は非常に単純です。gb2312/gbk は中国語の 2 バイトであり、これらの 2 バイトには値の範囲がありますが、utf-8 の中国語の文字は 3 バイトであり、各バイトにも値の範囲があります。エンコードの状況に関係なく、英語は 128 未満であり、占有するのは 1 バイトのみです (全角を除く)。
ファイル形式でのエンコードチェックであれば、utf-8のBOM情報を直接確認することもできます。この関数は文字列のチェックとトランスコードに使用されます。
リーリーバイト オーダー マーク (BOM) は、コード ポイント U+FEFF にある Unicode 文字 (「ゼロ幅の非改行空白」) です。この文字は、UCS/Unicode 文字の文字列を UTF-16 または UTF-32 としてエンコードするときにバイト順序を示すために使用されます。ファイルが UTF-8、UTF-16、または UTF-32 でエンコードされていることを示すマーカーとしてよく使用されます。
ほとんどの文字エンコーディングでは、バイト オーダー マークは他のファイルには現れにくいパターンです (通常、難読化された一連の制御コードのように見えます)。バイト オーダー マークが Unicode ファイル内の実際の文字として誤って解釈された場合、バイト オーダー マークは幅ゼロの非改行空白であるため表示されません。 Unicode 3.2 では、非バイト オーダー トークンに対する U+FEFF の使用が削除され (代わりに、この使用を表すために U+2060 が使用されます)、バイト オーダー トークンのセマンティクスにのみ U+FEFF を使用できるようになりました。
UTF-16 では、バイト オーダー マークは、ファイルまたは文字列ストリーム内のすべての 16 ビット文字のエンディアン性 (バイト オーダー) を示すために、ファイルまたは文字列ストリームの最初の文字として配置されます。
Unicode では、U+FFFE の値を持つコード ポイントは Unicode 文字として指定されないことが保証されています。これは、0xFF と 0xFE は、リトル エンディアン順序では U+FEFF としてのみ解釈されることを意味します (ビッグ エンディアン順序では U+FFFE になることができないため)。
UTF-8 にはバイト順序の問題はありません。 UTF-8 でエンコードされたバイト オーダー マークは、UTF-8 ファイルであることを示すために使用されます。これは UTF-8 ファイルをマークするためにのみ使用され、バイト順序を指定するためには使用されません。 [1] 多くの Windows プログラム (メモ帳を含む) は、UTF-8 ファイルにバイト オーダー マークを追加します。ただし、Unix 系システム (ファイル形式やプロセス間通信に en:text ファイルを多用するシステム) では、この方法はお勧めできません。インタプリタ スクリプトの先頭にある en:Shebang などの一部の重要なコードが正しく処理されなくなるためです。認識しないプログラミング言語にも影響します。たとえば、gcc は、ソース ファイルの先頭に認識できない文字があることを報告します。 PHP では、出力バッファリングが有効になっていない場合、ページ コンテンツがブラウザに送信され始める (つまり、ユーザー ヘッダー ファイルが送信された) ため、PHP スクリプトでユーザー ヘッダー ファイル (HTTP ヘッダー) を指定できなくなります。 )。バイト オーダー マークは、UTF-8 ではシーケンス EF BB BF として表され、UTF-8 を処理する準備ができていないほとんどのテキスト エディターおよび Web ブラウザでは、ISO-8859-1 環境では ??? が表示されます。
バイト オーダー表記は UTF-32 にも使用できますが、このエンコーディングは送信に使用されることはほとんどなく、そのルールは UTF-16 と同じです。 IANA 登録文字セット UTF-16BE、UTF-16LE、UTF-32BE、および UTF-32LE では、バイト オーダー表記は使用できません。これらの文字セットの名前によってバイト順序が決定されるため、文書の先頭にある U+FEFF は (破棄された) 「幅ゼロの非改行空白」として解釈されます。登録された文字セット UTF-16 および UTF-32 の場合、バイト順序を示すために先頭の U+FEFF が使用されます。