開發中一直沒辦法解決的一個問題頁面採用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頭：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，就表示這個位元組流是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 支援比較好，推薦大家使用。