最近弄個小網站，發現windows下的文件上傳到linux服務器上后，出現了標簽錯亂的問題。

比如，我的代碼是：

print '

testtest';

但是，瀏覽器的解析格式缺成了下面的樣子:

test

test

進過不停地搜索，發現了問題所在：

由于為了在linux服務器上正常顯示中文，將一些包含中文字符串的頁面文件編碼轉成了utf8格式(貌似其實不用轉，也可以顯示的)，導致了下面的問題：

頁面采用UTF8編碼，頭部和尾部用了模板包含文檔的method，結果頭部和尾部無端端各多出一個約10px的空行，什么也沒有。

原因是全部采用utf8編碼，包含文檔的時候，最后的二進制流中包含了多次UTF8 BOM標記，IE不能正常解析包含多個UTF8 BOM 標記的頁面，直接替換成實際顯示的回車，這樣導致一個空行，而firefox卻沒有這個問題。

故如果模板采用包含的method包含多個utf8文檔需要用ultraedit保存時另存為功能 選擇utf8 無bom格式保存即可。

另外，如果中文頁面在html head標記中將title標記放在前面會導致頁面空白。

所以utf8頁面應該使用標準順序：

BOM頭：\xEF\xBB\xBF，PHP腳本4、5尚對BOM無視，所以在解析前直接輸出。

對此 w3.org 標準 FAQ 中對此問題有一個專門的描述：

具體如下:

在UCS 編碼中有一個叫做”ZERO WIDTH NO-BREAK SPACE”的char，它的編碼是FEFF。而FFFE在UCS中是不存在的char，所以不應該出現在實際傳輸中。UCS規范建議我們在傳輸字節流 前，先傳輸 char”ZERO WIDTH NO-BREAK SPACE”。這樣如果接收者收到FEFF，就表明這個字節流是Big-Endian的；如果收到FFFE，就表明這個字節流是Little- Endian的。因此char”ZERO WIDTH NO-BREAK SPACE”又被稱作BOM。

UTF-8不需要BOM來表明字節順序，但可以用BOM來表明編碼方式。char”ZERO WIDTH NO-BREAK SPACE”的UTF-8編碼是EF BB BF。所以如果接收者收到以EF BB BF開頭的字節流，就知道這是UTF-8編碼了。

Windows就是使用BOM來標記文本文檔的編碼方式的操作Systam: WindowsXP Professional , 缺省char集：中文

1) notepad ： 可以自動識別出沒有帶 bom 的 utf-8 編碼格式文檔，但不可以控制保存文檔時是否添加 bom ， 如果保存文檔，那么會統一添加 bom 。

2)editplus ： 不能自動識別出沒有 bom 的 utf-8 編碼格式文檔，文檔保存時，選擇UTF-8 格式，不會在文檔頭寫上 BOM header.

3) UltraEdit ： 對于char編碼的功能最為強大， 可以自動識別帶 bom 和不帶 bom 的 utf-8 文檔 (可以配置) ； 保存的時候可以通過配置選擇是否添加 bom.

(特別需要注意的是，保存一個新建立的文檔時，需要選擇另存為 utf-8 no bom 格式)

后來發現 Notepad++ 也對于 utf-8 bom 支持比較好，推薦大家使用。

總結

以上是生活随笔為你收集整理的php文件怎么制定编码格式,php文件编码格式对结果有影响的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。