我有一个应用程序生成应该采用Zip格式的文件，确切地说是PKZIP版本6.3.3。 （对于好奇的：SIARD 2.0）
我已将示例文件上传到Google云端硬盘：
sample.siard
当我将Infozip的unzip指向Linux下的文件时，它会抱怨：
testing: content/ OK
testing: content/schema0/ OK
testing: content/schema0/table0/ OK
testing: content/schema0/table0/table0.xml
error: invalid compressed data to inflate
...
对所有实际文件都给出了同样的错误。 （不是目录）
详细文件列表（unzip -v file）给出：
...
6064 Defl:F 1868 69% 2018-01-30 10:41 055f9f61 content/schema0/table0/table0.xml
...
（此处没有错误）
我有一个合理的Infozip新版本。 unzip -v给出了
UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.
Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
Compiled with gcc 4.9.2 for Unix (Linux ELF) on Jan 28 2017.
UnZip special compilation options:
ACORN_FTYPE_NFS
COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
SET_DIR_ATTRIB
SYMLINKS (symbolic links supported, if RTL and file system permit)
TIMESTAMP
UNIXBACKUP
USE_EF_UT_TIME
USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
UNICODE_SUPPORT [wide-chars, char coding: UTF-8] (handle UTF-8 paths)
LARGE_FILE_SUPPORT (large files over 2 GiB supported)
ZIP64_SUPPORT (archives using Zip64 for large files supported)
USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.6, 6-Sept-2010)
VMS_TEXT_CONV
WILD_STOP_AT_DIR
[decryption, version 2.11 of 05 Jan 2007]
唯一列为不支持的是unreducing，但这不应该是相关的。
当我尝试使用Python的zipfile模块时，它可以毫无问题地进行测试和提取。我也听说PKZIP本身对这些文件没有问题，但我个人没有安装。
所以，我自己使用这些文件没有问题，但是它们用于长时间存档，我真的需要知道：
有没有办法让我知道这些文件的生成是否存在错误，或unzip处理这些文件时是否存在错误？
我在网上搜索过，发现很多人都遇到大文件和Zip64格式的问题。但是，我的文件不大。 （高达20Mb未压缩）
此外，此版本的unzip应支持Zip64。 （参见上面的版本信息）
我首选的工具是Python，十六进制编辑器和bash命令行。
答案 0 :(得分：1)
在面值上，消息“无效压缩数据以充气”表明您的zip文件已损坏。您确定使用PKZIP可以成功读取完全相同的文件，但不能使用Infozip吗？
在（非常）快速浏览SIARD标准之后，看起来它只是使用带有deflate / store压缩的沼泽标准zip文件。这意味着zip文件将不会使用只有PKZIP才能处理的功能。
一种可能性是存档是使用Zip64扩展创建的，但您的Infozip版本不支持它。
如果您运行unzip -v，则应该打印包含字符串ZIP64_SUPPORT的行（如果有）。
供参考，这就是我得到的
$ unzip -v
UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.
Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
Compiled with gcc 4.8.3 20140911 (Red Hat 4.8.3-7) for Unix (Linux ELF) on Feb 25 2015.
UnZip special compilation options:
COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
SET_DIR_ATTRIB
SYMLINKS (symbolic links supported, if RTL and file system permit)
TIMESTAMP
UNIXBACKUP
USE_EF_UT_TIME
USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
UNICODE_SUPPORT [wide-chars, char coding: UTF-8] (handle UTF-8 paths)
MBCS-support (multibyte character support, MB_CUR_MAX = 6)
LARGE_FILE_SUPPORT (large files over 2 GiB supported)
ZIP64_SUPPORT (archives using Zip64 for large files supported)
USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.6, 6-Sept-2010)
VMS_TEXT_CONV
[decryption, version 2.11 of 05 Jan 2007]
UnZip and ZipInfo environment options:
UNZIP: [none]
UNZIPOPT: [none]
ZIPINFO: [none]
ZIPINFOOPT: [none]
要检查zip文件是否使用Zip64，请检查zip文件的最后6个字节。如果前4个都是0xFF（这是偏向中央目录字段），那么很可能你有一个Zip64档案。请注意，如果您的zip文件有注释，这将不起作用。
作为参考，下面是来自使用Zip64的zip文件的转储。请注意 Offset to Central Dir 字段的值为 FFFFFFFF
10000020C 000000004 50 4B 05 06 END CENTRAL HEADER 06054B50
100000210 000000002 00 00 Number of this disk 0000
100000212 000000002 00 00 Central Dir Disk no 0000
100000214 000000002 04 00 Entries in this disk 0004
100000216 000000002 04 00 Total Entries 0004
100000218 000000004 DA 00 00 00 Size of Central Dir 000000DA
10000021C 000000004 FF FF FF FF Offset to Central Dir FFFFFFFF
100000220 000000002 00 00 Comment Length 0000
答案 1 :(得分：0)
自的答案。
我的主题是
找出Infozip解压缩的内容
答案结果是要求将源代码下载到unzip，添加大量调试消息并阅读它们。
在这种特殊情况下，unzip抱怨说zip文件使用了文件后数据描述符而没有设置标题标志来指示它。 （一般标志3）
通常应设置此标志并将标头CRC /长度字段设置为全零。
此文件没有设置了标志但仍将字段设置为零。然后unzip认为＆＃34;哦，长度真的必须为零！＆＃34;
然后出现实际的非零文件，unzip变得脾气暴躁。后文件数据描述符没有帮助。
在问题正文中我问：
有没有办法让我知道这些文件的生成是否存在错误，或
unzip处理这些文件时是否存在错误？
我个人认为这些文件已被破坏。我还没有和那些负责产生这些产品的人交谈过，但我认为我有一个很好的理由说他们做得不好。
更哲学的说明：
关于解压缩者应该如何工作，有两所学校。
一个是最好的努力＆＃34;学校，它表示程序应尽其所能恢复内部文件，无论格式有多么错误。 （这显然有局限性）
另一所学校是＆＃34;不是我的问题＆＃34;学院认为如果zip文件的格式错误，那么解压缩器就不应该触摸它。让zipfile的制作者修改他们的问题。
Pkware本身就是第一个思想流派，而Infozip则排在第二位。