網頁UTF8編碼開發中空白的問題

　　頁面采用UTF8編碼，頭部和尾部用了模闆包含檔案的方法，結果頭部和尾部無端端各多出一個約10px的空行，什麼也沒有。 　　原因是全部采用utf8編碼，包含檔案的時候，最後的二進制流中包含了多次UTF8 BOM标記，IE不能正常解析包含多個UTF8 BOM 标記的頁面，直接替換成實際顯示的回車，這樣導緻一個空行，而firefox卻沒有這個問題。 　　故如果模闆采用包含的方法包含多個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，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，就表明這個位元組流是Big-Endian的；如果收到FFFE，就表明這個位元組流是Little- Endian的。是以字元”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） notepad ： 可以自動識别出沒有帶 bom 的 utf-8 編碼格式檔案，但不可以控制儲存檔案時是否添加 bom ， 如果儲存檔案，那麼會統一添加 bom 。     2）editplus ： 不能自動識别出沒有 bom 的 utf-8 編碼格式檔案，檔案儲存時，選擇UTF-8 格式，不會在檔案頭寫上 BOM header.     3） UltraEdit ： 對于字元編碼的功能最為強大，可以自動識别帶 bom 和不帶 bom 的 utf-8 檔案 （可以配置） ； 儲存的時候可以通過配置選擇是否添加 bom.     （特别需要注意的是，儲存一個建立立的檔案時，需要選擇另存為 utf-8 no bom 格式）     後來發現 Notepad ++ 也對于 utf-8 bom 支援比較好，推薦大家使用。