奋战5个小时解决诡异的PHP--“图像XX因其本身有错无法显示”的问题_PHP教程
IE下是这样：
没办法，开始漫长的调试过程。解决步骤如下：
1. 是否是功能代码的错误：按照 关键字 图像 。。。 因其本身有错无法显示，很快google之几条解决方案。
Header（"Content-type: image/PNG"）;这句代码前加上ob_clean();清除输出
在对应的代码位置加入 ob_clean();
运行的结果没什么改变。
PS：为了定位该错误，事先用echo一步步输出调试了很久，才定位之具体的代码。
2. 思考：为啥在本地好好的，传上去就错了呢？是不是环境配置问题。
本地环境 XAMP,服务器环境 ：windows + IIS7.5。
为了比较Server返回结果的异同，决定用 Fiddler2 来跟踪本地访问同样一个文件和服务器访问同样一个文件的异同。
打开Fiddler2，很快定位出结果。
测试地址：
A、http://www.server.net/index.php?ac=public&at=zoom&filename=upfile%2F2011%2F08%2F30%2F20110830222415_540.jpg&w=&h=120&iszoom=1 B、http://localhost:90/index.php?ac=public&at=zoom&filename=upfile%2F2011%2F08%2F30%2F20110830222415_540.jpg&w=&h=120&iszoom=1
服务器返回结果：
本地返回结果：
异同是：服务器文件头多了一个
这个是什么呢？继续搜索，结果是UTF8的BOM头。也就是IIS返回的文件里多了一个BOM头。
UTF8普及知识见：http://blog.csdn.net/hiruyue/article/details/8747221
3. 开始检查 有那个文件被变成了带BOM头的UTF8，于是找到一个PHP版本的检测BOM头的代码，存成PHP文件，传到服务器。很快定位到结果，系统的配置文件被改成带BOM头的文件了。
这时候，才想起在用FTP上传网站以后，采用FTP自带的编辑工具修改了配置文件。当时是用NOTEPAD修改的。原来如此，赶紧将配置文件重新下载，用NOTEPAD++更改文件类型为 不带BOM的UTF8，保存，上传，访问。网站终于恢复了正常。
看看时间，已经过去了5个小时。
PS：在第二步的时候，还看到IIS在发送图片二进制流之前还发送了一个ICO文件流，这也会导致错误。
结束语：
在修改完成以后，发现了Orain兄弟的文章。他遇到的问题和我类似。PHP 使用流方式下载文件与 UTF-8 的 BOM 问题
总结：
1.遇到问题，先想想原因，再去解决。否则很容易纠结在调试代码中。
2.多搜索