1.php中用smarty模板產生的html在瀏覽器中頂部有一空行.
2.用firedebug發現 meta和link標記在body標籤裡.
本機上wmap運行沒事, 送到遠程伺服器上是IASP的服務, 會出現上述bug.
看了下源檔案, 文本一樣的. 但儲存時提示編碼問題.估計是utf-8問題了.
在網上找了下, 是utf-8 BOM問題.
解決方案: 用UltraEdit32把smarty模板檔案即引用的模板檔案(如include的header,footer等檔案)全另存新檔無BOM的utf-8檔案.
其它補充說明:
頁面採用UTF8編碼,頭部和尾部用了模板包含文檔的method,結果頭部和尾部無端端各多出一個約10px的空行,什麼也沒有。
原因是全部採用utf8編碼,包含文檔的時候,最後的二進位流中包含了多次UTF8 BOM標記,IE不能正常解析包含多個UTF8 BOM 標記的頁面,直接替換成實際顯示的斷行符號,這樣導致一個空行,而firefox卻沒有這個問題。
故如果模板採用包含的method包含多個utf8文檔需要用ultraedit儲存時另存新檔功能 選擇utf8 無bom格式儲存即可。
另外,如果中文頁面在html head標記中將title標記放在<meta http-equiv=”Content-type” Content=”text/html; Charset=UTF-8″ />前面會導致頁面空白。
所以utf8頁面應該使用標準順序 複製代碼 代碼如下:<meta http-equiv=”Content-type” Content=”text/html; Charset=UTF-8″ />
<meta http-equiv=”Content-language” Content=”zh-CN” />
<meta name=”robots” Content=”index,follow” />
<meta name=”keywords” Content=”" />
<meta name=”desCription” Content=”" />
<meta name=”rating” Content=”general” />
<meta name=”author” Content=”" />
<meta name=”Copyright” Content=”" />
<meta name=”generator” Content=”" />
<title></title>
BOM頭:\xEF\xBB\xBF,PHP指令碼4、5尚對BOM無視,所以在解析前直接輸出。
對此 w3.org 標準 FAQ 中對此問題有一個專門的描述:
www.w3.org/International/questions/qa-utf8-bom
具體如下:
在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 支援比較好,推薦大家使用。