原因：这是由于IE解析网页编码时以HTML内的标签优先，而后才是HTTP header内的讯息；而mozilla系列的浏览器则刚刚相反。由于UTF-8为3个字节表示一个汉子，而普通的GB2312或BIG5是两个。页面输出时，由于上述原因，使浏览器解析、输出<title></title>的内容时，如果在</title>前有奇数个全角字符时，IE把UTF-8当作两个字节解析时出现半个汉字的情况，这时该半个汉字会和</title>的<结合成一个乱码字，导致IE无法读完<title>部分，使整个页面为空百输出。而这个时候如果察看源文件的话，会发现实际上整个叶面全部已经输出了。
解决办法：<meta charset="UTF-8">放在<title></title>之前
做了一个小测试，使用Windows 2000 SP4操作系统，IE6 SP1和Firefox 1.5.0.5浏览器。所有文件使用DOS格式换行符。测试代码如下：
<?php header(”Content-Type: text/html; charset=utf-8″); ?><html> <head> <meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ /> <title>你好啊</title> </head> <body> 你好啊。 </body>
先不要前面的PHP语句，直接使用html文件，分无meta、meta在title前、meta在title后3种方式，分别做成GBK、UTF-8(no BOM)、UTF-8(BOM)三种编码方式的文件，再分别用IE和Firefox测试。我的Blog所在的服务器上，访问html文件时HTTP Header里Content-Type是Content-Type: text/html。第二遍测试加上PHP语句，用Header函数给HTTP Header中加上Content-Type: text/html; charset=utf-8，再把第一遍做的重新做一遍。
IE6 SP1
Firefox 1.5.0.5
字节
地址
无meta
GBK
正常
正常
73
t11.html
UTF-8(no BOM)
空白页
使用GBK解码形成乱码
80
t12.html
UTF-8(BOM)
正常
正常
83
t13.html
meta在前
GBK
使用UTF-8解码形成乱码
使用UTF-8解码形成乱码
144
t21.html
UTF-8(no BOM)
正常
正常
151
t22.html
UTF-8(BOM)
正常
正常
154
t23.html
meta在后
GBK
使用UTF-8解码形成乱码
使用UTF-8解码形成乱码
144
t31.html
UTF-8(no BOM)
空白页
正常
151
t32.html
UTF-8(BOM)
正常
正常
154
t33.html
—加了Header语句后—
无meta
GBK
使用UTF-8解码形成乱码
使用UTF-8解码形成乱码
133
t11.php
UTF-8(no BOM)
正常
正常
140
t12.php
UTF-8(BOM)
正常
正常
143
t13.php
meta在前
GBK
使用UTF-8解码形成乱码
使用UTF-8解码形成乱码
204
t21.php
UTF-8(no BOM)
正常
正常
211
t22.php
UTF-8(BOM)
正常
正常
214
t23.php
meta在后
GBK
使用UTF-8解码形成乱码
使用UTF-8解码形成乱码
204
t31.php
UTF-8(no BOM)
正常
正常
211
t32.php
UTF-8(BOM)
正常
正常
214
t33.php
文件中有6个汉字和一个汉字句号，所以UTF-8(no BOM)格式比GBK格式多出7个字节。UTF-8的BOM占用3个字节，所以UTF-8(BOM)比UTF-8(no BOM)多出3个字节。经验证，所有数据都符合这个规则，所以各文件格式没有错误。
PHP不支持BOM，又因为BOM的3个字符在最前面，显示不包含在<?php…?>标签里，所以PHP引擎会3个字符输出，于是输出的html文件也有了BOM。所以这次测试中，为了修改http header而加入的PHP语句不影响最终输出的html文件的BOM。
浏览器解析页面首先取HTTP header中的 content-type项，如果有charset就认定页面的编码方式是charset指定的值，如果没有指明，则认定为默认值。IE中文版默认值是gb2312，FF中文版默认的是GBK,然后，浏览器会看有没有BOM，一旦饭才能够有UTF-8的3字节BOM，则重新认定页面的编码方式UTF-8。然后是解码阶段，解码完成后是解析html的阶段。解析html的过程中，当解析到head部分的meta标签时，浏览器会根据<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ />这个语句中的说明，重新认定编码方式为charset后面的方式，中断html解析过程，返回到解码步骤重新解码。
知道了这个步骤，再来看这个表：在加了Header语句设置了HTTP Header后，两个浏览器解析所有页面都是用的UTF-8方式，包括GBK编码的页面。(当然要正常解析GBK编码的文件，可以在title前加上个meta标签标明编码方式。)在上表的下半部分可以清楚的看到这一点。再来看上半部分，在没有加Header语句的页面里，首先浏览器认定页面编码方式为默认值GBK。检测有无UTF-8的3字节BOM，检测到的，认定页面编码方式为UTF-8，解码再解析html，一切正常。如上表所示，上半部分带BOM的页面都能正常显示。如果没有BOM，页面可能是GBK或者UTF-8(no BOM)格式，浏览器会先按照默认的GBK方式开始解码。页面为GBK格式时，无meta时正常，有meta时浏览器解析到meta标签会回头重现按UTF-8方式解码，所以GBK,meta在前或后，无论IE还是FF都是乱码。再看UTF-8(no BOM)的页面，无meta时FF用GBK方式解码下去，最终显示乱码，IE则解码出错，形成空白页。有meta时，Firefox找到meta后回头重新按UTF-8方式解码，所以无论meta在前或在后都是正常；IE则是在meta在前时能够和Firefox一样回头重新解码，当meta在后时，又是解析到title出错，返回空白页。
所以，IE显示空白页的问题，很明显是因为IE的解码程序兼容性差。