IE导致ZIP文件损坏

Question

我正在使用PHP循环以64k块的方式传递ZIP文件（但任何服务器端语言都会遇到这个问题）。

使用FF获取文件时，一切正常。

使用IE7获取文件时，有些位被损坏。这导致了一个关于错误CRC（哈希）的错误消息，并且一些未压缩的文件最终会被损坏。

发送的头信息如下：

Expires: 0
Cache-Control: must-revalidate, post-check=0, pre-check=0
Pragma: public
Content-Description: File Transfer
Content-Disposition: attachment; filename="671fb8f80f5e94984c59e61c3c91bb70.zip";
Content-Transfer-Encoding: binary
Vary: Accept-Encoding
Content-Encoding: gzip
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/octet-stream

有人知道这个腐败现象是从哪里来的吗？

- Pierre Spring

---

你如何定义64k块？ - Rubens Farias

Answer 1

感谢之前的回答，我成功解决了问题：

Apache的mod_deflate对响应进行gzip编码。这在分块发送文件时产生了两个影响：

1. Content-Length头未被发送出去。
2. 使用IE7时，传递的文件会损坏。

解决方案是，在php中使用以下命令禁用响应的编码：

apache_setenv('no-gzip', '1');

- Pierre Spring

Answer 2

Content-Encoding: gzip

你是不是想压缩已经被压缩的zip文件？我猜测你的web服务器会添加这个头信息，但如果是你用PHP自己添加的，那么可能就是问题所在。

- finalman

---

我并没有自己添加这个头文件。这是由Apache设置的头文件。 - Pierre Spring

Answer 3

这篇MSDN文章解释了IIS使用gzip编码ZIP文件，但如果没有正确的标头，在发送到解压程序之前不会对其进行解码。 Firefox可能足够智能以自动解码它。 文章中提到了一个修复方法，尽管文章标题并没有完全涉及您的问题。

我建议您再次检查您的IIS设置。

- Cᴏʀʏ

---

抱歉没有提到我们使用的是 lamp 技术栈 ;) 这个 zip 文件是由 PHP 生成并由 PHP 自己发送出去的。 - Pierre Spring

我应该推断出来...我已经在.NET世界里被卡住了这么久，以至于我喜欢立即责怪IIS :) - Cᴏʀʏ