今天，说是下载文件有错，前一阵子试过，记得用flashget下是可以的；开始没有在意，后来想想还是应该再试试，于是用flashget下载站上的WinRAR 3.2，果然有错。用UltraEdit打开16进制一看，最前面多了3字节（EF BB BF），后面的完全正确。但是这样已经破坏了文件的格式，难怪说“文件损坏”呢？

　　想来想去不知道这3字节怎么来的，屏蔽了正常的文件输出，下载下来的愣就是3字节。在UltraEdit中打开一看，空空如也，3字节跑哪儿去了？再一看，乖乖，文件类型咋就成了U8-DOS了！3字节是UTF-8文件的前缀！

　　想到目前站上启用了PHP的output_buffering，首先关掉看看，居然没报错（其实写到下载的文件里了，开始没注意）。于是又起用上，因为我的脚本还是需要他的。折腾了N久，站上的WinRAR都写着已下载两百多次了，终于发现，Drapal将先发送这样一个Head:

HTTP/1.1 200 OK

Date: Wed, 01 Sep 2004 15:57:04 GMT

Server: Apache/2.0.50 (Win32)

Set-Cookie: PHPSESSID=730bbc7f16f2051e81cb8f706adb796a; expires=Fri, 24-Sep-2004 19:30:24 GMT; path=/

Connection: close

Transfer-Encoding: chunked

Content-Type: text/html; charset=utf-8

3

锘?

0

　　因为我是UTF-8的站，因此它有一个UTF-8的文件前缀。然后，由于有Buffering可以修改Head部分，实际到达客户端的Head又变成了：

HTTP/1.1 200 OK

Date: Wed, 01 Sep 2004 16:03:05 GMT

Server: Apache/2.0.50 (Win32)

Set-Cookie: PHPSESSID=730bbc7f16f2051e81cb8f706adb796a; expires=Fri, 24-Sep-2004 19:36:25 GMT; path=/

Expires: Wed, 01 Sep 2004 16:03:05 GMT

Content-Disposition: attachment; filename="winrar v3.20.Final.CHS.Regged.exe"

Content-Length: 990633

Connection: close

Content-Type: application/x-download

锘縈ZP ……（应该是MZP……（这是exe的文件头））

　　Head是对了，可是这个“锘”前缀却请之不去，最终导致下载后的文件出现错误。Google了一番，居然没有找到谁出现相似的问题。

解决方法：

　　在fscache模块的fscache_download函数中调用Header()函数输出Head之前，先调用一下ob_end_clean()函数删除内部缓冲区的内容，并且关闭内部缓冲区，这个函数不会输出内部缓冲区的内容！。这样，前面不知道什么地方输出的UTF-8前缀就没了！经过测试，下载文件完全正常。

　　经过测试发现以上修改还有两个缺陷：一是中文UTF-8文件名下载时是乱码，二是浏览器下载时仍然出错，但是Flashget之类的下载工具能正常下载。

　　问题一解决方案：在fscache模块的fscache_download函数中输出文件名Header之前，添加一行：

$fsitem->filename = iconv("UTF-8", "GB2312", $fsitem->filename);

　　将文件名从UTF-8转换到GB2312即可，英文文件名不受影响。

　　问题二解决方案：这个问题困扰我很长时间，究竟有什么不同在浏览器与下载工具之间。我测试了ＩＥ，Ｍｏｚｉｌｌａ，ＦｉｒｅＦｏｘ等浏览器都有同样的问题。经过Head详细比较，二者的区别仅仅在于浏览器要与服务器协商gzip压缩，而我的Apache PHP中又设定了zlib.output_compression = On，原来是经过zlib的处理后的UTF-8 Head后数据段为空时它大概会自动添加一个UTF-8的空字符串，当真正的数据到达时，浏览器误将多出来到的字符写入了文件。关闭了zlib压缩之后，下载正常了，当时，服务器也损失了性能。测试了一下使用ob_gziphand也是不行的。看来，要是能够指定某些文件类型不使用zlib就好了。

　　使用Apache自带的mod_deflate.so进行gzip压缩没有问题，而且可以根据文件扩展名或类型指定是否压缩。