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

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

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

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

 
  
  1. UTF-8编码的文件中，BOM占三个字节。如果用记事本把一个文本文件另存为UTF-8编码方式的话，
  2. 用UE打开这个文件，切换到十六进制编辑状态就可以看到开头的FFFE了。这是个标识UTF-8编码文件的好办法，
  3. 软件通过BOM来识别这个文件是否是UTF-8编码，很多软件还要求读入的文件必须带BOM。可是，还是有很多软件不能识别BOM。 
  4.  
  5. 在Firefox早期的版本里，扩展是不能有BOM的，不过Firefox 1.5以后的版本已经开始支持BOM了。
  6. 现在又发现，PHP也不支持BOM。PHP在设计时就没有考虑BOM的问题，也就是说他不会忽略UTF-8编码的文件开头BOM的那三个字符。 
  7.  
  8. 由于必须在在Bo-Blog的wiki看到，同样使用PHP的Bo-Blog也一样受到BOM的困扰。
  9. 其中有提到另一个麻烦：“受COOKIE送出机制的限制，在这些文件开头已经有BOM的文件中，
  10. COOKIE无法送出（因为在COOKIE送出前PHP已经送出了文件头），所以登入和登出功能失效。
  11. 一切依赖COOKIE、SESSION实现的功能全部无效。”这个应该就是Wordpress后台出现空白页面的原因了，
  12. 因为任何一个被执行的文件包含了BOM，这三个字符都将被送出，导致依赖cookies和session的功能失效。 
  13.  
  14. 解决的办法嘛，如果只包含英文字符(或者说ASCII编码内的字符)，就把文件存成ASCII码方式吧。
  15. 用UE等编辑器的话，点文件->转换->UTF-8转ASCII，或者在另存为里选择ASCII编码。
  16. 如果是DOS格式的行尾符，可以用记事本打开，点另存为，选ASCII编码。如果包含中文字符的话，可以用UE的另存为功能，
  17. 选择“UTF-8 无 BOM”即可。 
 
  
相信看了上面 就会明白，为什么多冒出来3个空格了吧。还有记得在编辑网页文件的时候，如果选择utf-8编码，尽量选择 无BOM的编码方式吧 :-)
 
  
好了，问题解决了  思维又转移到其他东西上面了，费了不少时间，这样可不太好.继续模板吧 :(