这是非常好的结果文件可以打开每个zip程序,我尝试没有错误,除了OS X的默认解压缩程序,存档实用程序.您双击.zip文件,并且Archive Utility决定它不是真正的zip,而是压缩到.cpgz文件中.
在OS X终端或StuffIt Expander中使用unzip或ditto解压缩文件,但无需任何问题,但我需要默认程序(Archive Utility)才能为我们的用户服务.
否则可接受的zip文件中的什么样的东西(标志等)可以将Archive Utility设为考虑文件不是有效的zip？
我已经阅读了this question,这似乎描述了一个类似的问题,但我没有任何一个通用的bitfield位设置,所以这不是第三个问题,我很确定我有有效的crc-32的,因为当我不,WinRAR扔了一个合适.
我很高兴发布一些代码或链接到一个“坏”的zip文件,如果它有帮助,但我几乎只是使用ZipStream,强制它进入“大文件模式”,并使用“存储”作为压缩方法.
编辑 – 我也尝试过“压缩”压缩算法,并获得相同的结果,所以我不认为这是“商店”.还有一点值得指出的是,我从存储服务器一次将文件从存储服务器中拉出,并在发送出去时将它们发送出去,以便在发送任何内容之前需要下载所有文件的解决方案不会变得可行(极端例如是5GB的20MB文件,用户不能等待所有的5GB在下载开始之前转移到压缩服务器,否则他们会认为它是坏的)
这是一个140字节的“存储”压缩测试zip文件,表现出这样的行为：http://teknocowboys.com/test.zip
ZipStream默认设置为0x0603. Info-zip将其设置为0x000A.具有前一个值的Zip文件似乎不在Archive Utility中打开.也许它不支持该版本的功能？
强制“需要提取的版本”到0x000A使得生成的文件也在Archive Utility中以及其他地方都可以打开.
编辑：导致此问题的另一个原因是如果使用Safari(用户代理版本> = 537)下载了zip文件,并且在发送了Content-Length头文件时,低于该文件的大小.
我们采用的解决方案是检测Safari> = 537服务器端,如果这是您正在使用的,我们可以确定Content-Length大小与实际大小之间的差异(您的具体取决于具体应用程序)以及之后调用$zipStream-> finish(),我们回显chr(0)以达到正确的长度.所产生的文件在技术上是格式错误的,您在zip中放置的任何注释都不会显示,但是所有的zip程序都可以打开并解压缩文件.
如果您误报了Content-Length,IE需要相同的黑客攻击,而不是下载不起作用的文件,则不会完成下载并引发“下载中断”.
