我试图通过使用 Unix 的 zip 命令和 PHP 的 passthru 函数来组合一个 zip 流解决方案，但我遇到了一个障碍。
脚本看起来像这样：
<?php
header("Content-Type: application/octet-stream");
header("Content-Disposition: attachement; filename=myfile.zip");
passthru("zip -r -0 - /stuff/to/zip/");
exit();
?>
zip 命令工作正常，浏览器接收输出并保存为 zip 文件。然后可以在 Windows 和 Unix 上很好地提取 zip，但在 Mac OS X 上，内置提取器 (BOMArchiveHelper) 无法提取文件。不过，在 OS X 上使用其他应用程序效果很好。
如果 zip 受密码保护（不由应用程序处理），BOMArchiveHelper 给出的错误与它给出的错误相同。我使用了某种 zip 分析程序，它表明 zip 存档中的某些文件被标记为受密码保护。就像我说的那样，显然没有其他提取应用程序注意到这一点。
在仔细检查 zip 文件时，我发现 PHP 文件生成的文件比服务器上 zip 命令直接生成的文件大几个字节。似乎带有 passthru 的流进程向文件中添加了一些可能导致 BOMArchiveHelper 出现问题的内容。
为了测试这一点，我使用 passthru 流式传输我已经在服务器上创建的 zip： passthru("cat stuff.zip") 这与 BOMArchiveHelper 配合得很好。
因此，问题似乎出在 passthru 函数获取 zip 命令动态生成的二进制数据并将其传递给浏览器的过程中的某个地方。
我试图消除所有可能产生额外字节的来源（将 zip 命令设置为安静等），但添加的数据仍然存在。流式 zip 和预先生成的 zip 的二进制差异表明，额外的数据分散在整个 zip 中，而不仅仅是在结尾或开头。
任何人都有线索，或者以前见过这个问题并决定无法解决？
注意：由于其他人已经在我面前遇到并很好地描述了这个问题而没有任何答案，我只是在这里复制/粘贴了他的信息，并确保他的所有测试都确实失败了，而且我的任何一个都没有通过......
显然，让这个工作的唯一方法是要求人们使用 unzip 或 suffitexpander ...