解压缩文件时出现额外字节错误

28

当我输入时unzip ../founation-latest.zip，它输出以下内容：

警告[../foundation-latest.zip]：开头或zipfile中有248个额外的字节（无论如何都试图处理）

文件为138KB。它可以正确解压缩，但是为什么会出现此错误？

zip

— 雨水11
source

2

一个可能的原因是，在进入系统的第一步中，它是以ftpASCII模式而不是BINARY模式传输的，并且添加了一些字节。如果您ftp在任何阶段ftp使用过，请在任何“放置”或“获取”之前使用“ bin”命令再次运行。

— 马克·普洛特尼克

一开始它可能具有恶意负载。这是一个敌对的互联网。请注意使用哪种解压缩工具来打开这样的zip文件。

— jbrahy

当前的答案有很多猜想，因为可能的原因很多。链接或复制有问题的文件将有帮助。

— duozmo

关于可能的恶意额外有效载荷：以这种大小，您可以将文件上传到virustotal.com进行检查-以防万一其中没有个人信息。但是，只要将原始文件复制到其他地方，我就不必担心Linux中的病毒。（如果您认为数据完整，则可以始终重新打包文件。）

— Ned64

只是为了确认这是一个问题。我尝试使用zip和一起创建iTunes文件空间的备份ditto。两者unzip（以及10.11）提供的（截至10.11）均失败7za。MacOS解压缩只是不喜欢（大？）zip文件。

— Otheus

37

我的问题是因为我试图在MAC OSX上使用“解压缩”，因此无法处理用PKZIP压缩的内容。

我能够brew install p7zip使用命令解压缩7za x some_file.zip。

我最初在本文中找到了解决方案：need-pk-compat-v4-5-can-do-v2-1

— 杜克
source

4

我从microsoft.com下载了Windows VM，这是解压缩的解决方案。

— 草皮

1

这也适用于解压在Linux上：（在我的情况2009年4月20日的6.00解压由Debian的。）

— BradHards

2

还值得一提的是它速度更快并且显示了进度。

— previous_developer

p7z还可以处理较大的文件和带有较新zip的文件

— Konrads

今天在AWS linux映像上也存在同样的问题。从timeoff.wsisiz.edu.pl/rpms.html下载了p7zip RPM，并测试并提取了档案文件，没有任何问题。

— 链轮

23

我发现这个线程有类似的问题。错误报告的标题为：在5.4GB的ZIP上解压缩失败，带有“开头或zipfile中有额外的字节”。建议的修补程序之一是在.zip文件上使用此命令。

$ zip -FFv foo.zip --out fixed.zip

示例运行

$ zip -FFv foo.zip --out fixed.zip
Fix archive (-FF) - salvage what can
 Found end record (EOCDR) - says expect single disk archive
Scanning for entries...
 Local ( 1      0): copying: d1/f1   (651734 bytes)
 Local ( 1 651817): copying: d1/d2/  (0 bytes)
 Local ( 1 651905): copying: d1/d2/f3   (80 bytes)
 Local ( 1 652083): copying: d1/f23   (891 bytes)
 Local ( 1 653021): copying: d1/f27   (8764 bytes)
 Local ( 1 661837): copying: d1/f24   (14818 bytes)
 Local ( 1 676709): copying: d1/f25   (17295 bytes)
...
 Cen   ( 1 5488799949): updating: d1/f13
 Cen   ( 1 5488800052): updating: d1/f14
Zip64 EOCDR found ( 1 5488800155)...
Zip64 EOCDL found ( 1 5488800211)...
EOCDR found ( 1 5488800231)...
$ echo $?
0

zip的-FF开关

zip手册页摘录

       -FF
       --fixfix
              Fix the zip archive. The -F option can be used if some 
              portions of the archive are missing, but requires a reasonably 
              intact central directory.   The  input  archive is scanned as 
              usual, but zip will ignore some problems.  The resulting 
              archive should be valid, but any inconsistent entries will be 
              left out.

              When doubled as in -FF, the archive is scanned from the 
              beginning and zip scans  for  special  signatures  to  
              identify  the  limits between the archive members. The single 
              -F is more reliable if the archive is not too much damaged, so 
              try this option first.

              If  the archive is too damaged or the end has been truncated, 
              you must use -FF.  This is a change from zip 2.32, where the 
              -F option is able to read a truncated archive.  The -F option 
              now more reliably fixes archives with minor damage and the -FF 
              option is  needed to fix archives where -F might have been 
              sufficient before.
              ...

— slm
source

3

在通过有问题的Web服务传输zip存档之前，我已经看到这种类型的错误。直接检查该zip文件后，我发现该zip文件前面已发送了来自Web服务的错误消息。

您可以尝试将zip文件作为文本进行检查，看看前面是否有有趣的内容。

— 迈克尔·科恩
source

3

也有这个警告。在我的情况下，这是由于使用“ curl -i”下载导致的，导致http-header出现在zip文件的开头。愚蠢的我。可以肯定的是，这并不是所有情况下的原因/解决方案，但也许可以帮助某人...

— 德克瑙斯
source

2

它可能是自解压的归档文件（windows .exe），或者由于某种原因已被填充。

— 瑞奇光束
source

1

“填充”是什么意思？

— rainwater11

使文件具有特定长度的额外字节（通常为null（零））。这曾经是文件传输块大小（例如xmodem）的假象，但是在现代世界中，这不会发生。它也可以是加密签名。（我没有文件，所以我不知道那248个字节是什么。）

— Ricky Beam

0

我也有同样的问题。在不使用bin模式的情况下将文件从Windows复制到Unix服务器时，我观察到该问题。解决此问题的最佳方法是在bin模式下传输文件。

— 阿米特
source

（1）该信息已在评论中显示。可以，但是…（2）注释中的信息比此答案还要详细。（3）您应该通过描述自己在说什么来改善这个答案。请不要在评论中回复；编辑您的答案，使其更清晰，更完整。

— 斯科特，

0

我在Linux上遇到了同样的问题，.zip文件大小超过4GB，并伴有only DEFLATED entries can have EXT descriptor错误。

该命令7z x虽然解决了我所有的问题。

但是请注意，该命令7z x将提取所有文件，且其文件路径均以当前目录为根。该选项-o允许指定输出目录。

— Serge Stroobandt
source