关于UTF-8编码致使网页解析出现空白的问题

今天在作Magento模板的时候，由于涉及到中文，因而在notepad++下面将文件转换成了，utf-8编码格式。可是刷新网页以后就发现解析出来的源码多了几个空格。如图

四处查看模板文件，也没发现什么端倪。只有耐着头皮继续作咯。。。

还好改编码的不止一个，再修改完另一个跟搜索相关的文件以后，发现出现了一样的问题，因而意识到问题可能出如今编码上。去群里面问了一下，高手提示直接转换成无BOM的编码格式就能够了，因而转换保存，果真ok

这里面有什么玄机呢，上网搜寻了一番，截取部分感受比较实用的贴一下吧：

UTF-8编码的文件中，BOM占三个字节。若是用记事本把一个文本文件另存为UTF-8编码方式的话，
用UE打开这个文件，切换到十六进制编辑状态就能够看到开头的FFFE了。这是个标识UTF-8编码文件的好办法，
软件经过BOM来识别这个文件是不是UTF-8编码，不少软件还要求读入的文件必须带BOM。但是，仍是有不少软件不能识别BOM。

在Firefox早期的版本里，扩展是不能有BOM的，不过Firefox 1.5之后的版本已经开始支持BOM了。
如今又发现，PHP也不支持BOM。PHP在设计时就没有考虑BOM的问题，也就是说他不会忽略UTF-8编码的文件开头BOM的那三个字符。

因为必须在在Bo-Blog的wiki看到，一样使用PHP的Bo-Blog也同样受到BOM的困扰。
其中有提到另外一个麻烦：“受COOKIE送出机制的限制，在这些文件开头已经有BOM的文件中，
COOKIE没法送出（由于在COOKIE送出前PHP已经送出了文件头），因此登入和登出功能失效。
一切依赖COOKIE、SESSION实现的功能所有无效。”这个应该就是Wordpress后台出现空白页面的缘由了，
由于任何一个被执行的文件包含了BOM，这三个字符都将被送出，致使依赖cookies和session的功能失效。

解决的办法嘛，若是只包含英文字符(或者说ASCII编码内的字符)，就把文件存成ASCII码方式吧。
用UE等编辑器的话，点文件->转换->UTF-8转ASCII，或者在另存为里选择ASCII编码。
若是是DOS格式的行尾符，能够用记事本打开，点另存为，选ASCII编码。若是包含中文字符的话，能够用UE的另存为功能，
选择“UTF-8 无 BOM”便可。

相信看了上面 就会明白，为何多冒出来3个空格了吧。还有记得在编辑网页文件的时候，若是选择utf-8编码，尽可能选择 无BOM的编码方式吧 :-)

好了，问题解决了  思惟又转移到其余东西上面了，费了很多时间，这样可不太好.继续模板吧 :(