開発中に一度も解決できなかった問題
ページはUTF8でエンコードされており、先頭と末尾にテンプレートインクルードファイル方式を採用しているため、先頭と末尾に10px程度の余分な空白行が発生してしまいます。理由もなく尾を引く、そして何もありません。
その理由は、ファイルがインクルードされると、最終的なバイナリ ストリームに複数の UTF8 BOM タグが含まれるため、複数の UTF8 BOM タグを含むページを正常に解析できず、実際に表示される改行に直接置き換えられるためです。空白行が発生しますが、Firefox ではこの問題は発生しません。
そのため、テンプレートが包含メソッドを使用して複数の utf8 ファイルを含み、ultraedit で保存する必要がある場合は、utf8 を選択して BOM 形式なしで保存するだけです。
さらに、中国語ページが html head タグの したがって、utf8 ページは標準順序を使用する必要があります
BOM ヘッダー: xEFxBBxBF、PHP4 および 5 は依然として BOM を無視するため、解析する前に直接出力されます。
この問題については、w3.org の標準 FAQ に専用の説明があります:
http://www.w3.org/International/questions/qa-utf8-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 を使用してテキスト ファイルのエンコード方法をマークするオペレーティング システムです: WindowsXP Professional、デフォルトの文字セット: 中国語
1) メモ帳: BOM のない UTF-8 エンコード形式のファイルを自動的に識別できますが、ファイルを保存するときに BOM を追加するかどうかを制御することはできません。
2) editplus: BOM のない UTF-8 エンコード形式のファイルは自動的に認識できません。ファイルを保存するときに UTF-8 形式を選択すると、ファイル ヘッダーに BOM ヘッダーが書き込まれません。
3) UltraEdit: 文字エンコーディングの最も強力な機能で、保存時に BOM ありと BOM なしの utf-8 ファイルを自動的に識別できます。設定を通じて BOM を追加するかどうかを選択できます。(新しく作成したファイルを保存するときは、utf-8 no bom 形式で保存することを選択する必要があることに注意することが重要です)
後で、Notepad ++ も utf-8 BOM をより適切にサポートしていることを発見したので、皆さんにもそれを使用することをお勧めします。
http://www.bkjia.com/PHPjc/364154.html