UTF-8页面在IE什么都不显示打开是空白页的解决方法

作者：佚名来源: JZ5U整理日期：2019/08/26 00:23:04

今天就遇到了这个问题，真是挺郁闷的，还好在网上找到了解决方法。

起因
　　这个问题要从浏览器解析html的方式讲起。浏览器读取了页面的html代码后开始进行解析。解析前浏览器要先知道页面的编码方式，然后根据编码方式进行解码，然后才能开始解析。我大概想了一下，浏览器可以从下面3个方面得到页面编码方式：HTTP Header中的"Content-Type"项、返回的html代码开头是否有BOM、html代码中的meta标签。

　　浏览器(无论是IE还是Firefox)在解析页面时，首先取HTTP Header中的Content-Type项，如果有写明charset的话就认定页面的编码方式为charset指定的值。如果没有指明，则认定为默认值。根据上表，IE中文版的默认值是GB2312，Firefox中文版的默认值是GBK，不过IE的GB2312好像和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出错，返回空白页。

解决方案：
将 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> 写在title前面。

页面采用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页面应该使用标准顺序