最近在调试PHP/Asp验证码的问题时，发现验证码总是不能正确显示，经过很多次测试，发现唯一的解决之道是用CMS的安装程序重新安装才能解决。如果总是这样找不到原因的话，那不会害苦了人，在网上一搜同类型的问题，发现都是菜鸟级的回答，什么GD库支持啊什么的~ 但是能够解决问题的非常少！
     出了什么问题了？不管怎么样，那一定是有问题的，一定不是服务器的问题！ 
     再查了半天，发现如下解决方法，经调试，结果正常，问题得到彻底解决！最终发现问题是由于Utf-8编码格式的文件所导致，如果Utf-8的文件被记事本、DreamWeaver工具编辑过，但没有注意处理的方式，那么会自动在Utf-8文件中添加BOM格式，以表示文件是Utf-8编码的文件。 
     补充说一下，我也是从查找文件空格查起，因空格也会影响图片的输出，才顺着这条线找到的问题根源和解决方法。 
具体原理如下： 

    BOM——Byte order Mark，就是字节序标记。在这里找到一段关于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来标记文本文件的编码方式的。 
    现在几乎所有的文本编辑软件都可以显示并编辑UTF-8编码的文件。但是很遗憾，其中很多软件的表现并不理想。 

    类似WINDOWS自带的记事本等软件，在保存一个以UTF-8编码的文件时，会在文件开始的地方插入三个不可见的字符（0xEF 0xBB 0xBF，即BOM）。它是一串隐藏的字符，用于让记事本等编辑器识别这个文件是否以UTF-8编码。对于一般的文件，这样并不会产生什么麻烦。但对于 PHP/Asp来说，BOM是个大麻烦。 

     PHP/Asp并不会忽略BOM，所以在读取、包含或者引用这些文件时，会把BOM作为该文件开头正文的一部分。根据嵌入式语言的特点，这串字符 将被直接执行（显示）出来。由此造成即使页面的 top padding 设置为0，也无法让整个网页紧贴浏览器顶部，因为在html一开头有这3个字符呢！ 

     最大的麻烦还不是这个。受COOKIE送出机制的限制，在这些文件开头已经有BOM的文件中，COOKIE无法送出（因为在COOKIE送出前PHP/Asp已经送出了文件头），所以登入和登出功能失效。一切依赖COOKIE、SESSION实现的功能全部无效。 

     因此，在编辑、更改任何文本文件时，请务必使用不会乱加BOM的编辑器。Linux下的编辑器应该都没有这个问题。WINDOWS下，请勿使用记事本等编辑器。推荐的编辑器是： Editplus 2.12版本以上； EmEditor； UltraEdit（需要取消‘添加BOM’的相关选项）； Dreamweaver（需要取消‘添加BOM’的相关选项） 等。 

     对于已经添加了BOM的文件，要取消的话，可以用以上编辑器另存一次。（Editplus需要先另存为gb，再另存为UTF-8。） 

DreamWeaver解决办法如下: 
用DreamWeaver打开指定文件，按Ctrl+J->标题/编码->编码选择“UTF-8”，去掉或者勾选"包括Unicode签名(BOM)"勾选->保存/另存为，即可！