1. はじめに
UTF-8 は、Web アプリケーションでよく使用される Unicode 文字エンコード方式であり、ANSII コードのエンコード長が 1 バイトであるという利点があります。 ASCII 文字セットを使用して多数の Web ページを送信するときに、ネットワーク帯域幅を大幅に節約できます。
UTF-8 署名は、BOM (バイト オーダー マーク) とも呼ばれ、UTF エンコーディング スキームでエンコーディングを識別するために使用される標準マークです。 BOM は UTF エンコード方式でエンコードを識別するために使用される標準マークです。UTF-16 では元々 FF FE でしたが、UTF-8 になると EF BB BF になります。 UTF8 バイトは順序付けされていないため、このフラグはオプションであり、バイト ストリームが UTF-8 でエンコードされているかどうかを検出するために使用できます。 Microsoft はこの検出を行いますが、一部のソフトウェアはこの検出を行わず、通常の文字として扱います。 Microsoft は、独自の UTF-8 形式のテキスト ファイルの前に 3 バイト (EF BB BF) を追加します。Windows 上の他のプログラムは、これらの 3 バイトを使用してテキスト ファイルが ASCII か UTF-8 かを判断します。 Microsoft によって秘密裏にマークされており、他のプラットフォームではこの方法で UTF-8 テキスト ファイルにマークが付けられていません。つまり、UTF-8 ファイルには BOM がある場合とない場合があります。
BOM が 1 つだけあれば問題ありません。複数のファイルに署名が設定されている場合、バイナリ ストリームには複数の UTF-8 署名が含まれることになります。これが、XML 変換が失敗する原因となる「ルート要素は整形式である必要がある」という理由です。
2. 表示と変換
UTF-8 ファイルには BOM がある場合とない場合がありますが、それを区別するにはどうすればよいでしょうか?
16 進数編集モードのソフトウェアを使用するだけです。たとえば、UltraEdit-32 を使用してファイルを開き、16 進数編集モードに切り替えて、ファイルのヘッダーに EF BB BF があるかどうかを確認します。 「はい」の場合は、BOM を使用する方法です。
Windows に付属のメモ帳は、UTF-8 として保存すると、デフォルトで BOM を持ちます。
一般的な UltraEdit-32 や NotePad++ など、多くの変換方法があります。例として UltraEdit-32 を取り上げます。ファイルを開いた後、「名前を付けて保存」を選択します。「形式」列には次のオプションがあります:
さらに、Unicode (UTF) を選択した場合、DreamWeaver CS3 にも同様のオプションがあります。 -8) デフォルトのエンコーディングとして、「Unicode 署名 (BOM) を含める」オプションを選択して、ドキュメントにバイト オーダー マーク (BOM) を含めることができます。それ以外の場合、BOM なし:
3. その他の知識 http://blog.csdn.net/thimin/archive/2007/08/03/1724393.aspx の記事から学びました:
そのため、 unicode と呼ばれる 保存されたファイルは実際には UTF-16 であり、これはたまたま Unicode と同じコードであるだけですが、概念的には Unicode と UTF はメモリのエンコーディング表現スキームであり、UTF は保存方法とそのスキームです。 Unicodeを送信します。 UTF-16 は、ハイ エンディアン (LE) とハイ エンディアン (BE) の 2 つのタイプにも分類されます。公式の UTF エンコーディングも UTF-32 ですが、これも LE と BE に分かれています。公式の非 Unicode UTF エンコーディングも UTF-7 であり、主に電子メール送信に使用されます。 utf-8 のシングルバイト部分は iso-8859-1 と互換性があります。これは主に、一部の古いシステムおよびライブラリ関数が utf-16 を正しく処理できないためであり、ファイル領域の節約にもなります。 (英語以外の文字のための無駄なスペースが犠牲になります)。 iso-8859-1 の場合、utf8 と iso-8859-1 は両方とも 1 バイトで表されます。他の文字を表す場合、utf-8 は 2 バイトまたは 3 バイトを使用します。
BOM についてのより詳しい説明はここからです:
UCS エンコードには「ZERO WIDTH NO-BREAK SPACE」と呼ばれる文字があり、そのエンコードは FEFF です。 FFFE は UCS には存在しない文字ですので、実際の送信では出現しないはずです。 UCS 仕様では、バイト ストリームを送信する前に文字「ZERO WIDTH NO-BREAK SPACE」を送信することを推奨しています。このように、受信機が FEFF を受信した場合は、バイト ストリームがビッグ エンディアンであることを示し、FFFE を受信した場合は、バイト ストリームがリトル エンディアンであることを示します。したがって、「ZERO WIDTH NO-BREAK SPACE」という文字は BOM とも呼ばれます。
UTF-8 はバイト順序を示すために BOM を必要としませんが、BOM を使用してエンコード方式を示すことができます。文字「ZERO WIDTH NO-BREAK SPACE」の UTF-8 エンコーディングは EF BB BF です。したがって、受信側が EF BB BF で始まるバイト ストリームを受信すると、それが UTF-8 でエンコードされていることを認識します。
Windows は BOM を使用してテキスト ファイルのエンコード方法をマークします。
PHP も BOM をサポートしていません。 PHP は設計時に BOM の問題を考慮しませんでした。つまり、UTF-8 でエンコードされたファイルの先頭にある BOM の 3 文字は無視されません。 または ※ もう一つ: 特に php を使用してテンプレートをインポートする場合、これら 3 つの文字が原因で閲覧異常が発生する可能性が高くなります。