Mik*_*eC8 19 linux macos bash zip
我使用如下命令在我的计算机(Mac OS X)上创建了一堆zip文件:
zip -r bigdirectory.zip bigdirectory
然后,我将这些zip文件保存在某处并删除了原始目录.
现在,当我尝试解压缩zip文件时,我遇到了这样的错误:
$ unzip -l bigdirectory.zip
Archive: bigdirectory.zip
warning [bigdirectory.zip]: 5162376229 extra bytes at beginning or within zipfile
(attempting to process anyway)
error [bigdirectory.zip]: start of central directory not found;
zipfile corrupt.
(please check that you have transferred or created the zipfile in the
appropriate BINARY mode and that you have compiled UnZip properly)
我发现这可能是因为zip无法处理超过一定大小的文件,也许是4演出.至少我在某处读过.
但为什么zip命令会让我创建这些文件？有问题的zip文件是9457464293字节,它让我更像这样,绝对没有错误.
很明显它可以创建这些文件.
我真的希望我的档案不会丢失.我已经吸取了教训,将来我会在删除原始文件之前检查我的档案,并且我可能还会使用其他文件格式,如tar/gzip.
但就目前而言,我该怎么办？我真的需要我的文件.
有些人建议我的unzip工具不支持足够大的文件(这很奇怪,因为我使用了内置的OS X zip和unzip).无论如何,我安装了一个新unzip的homebrew,并且看,我现在得到一个不同的错误:
$ unzip -t bigdirectory.zip
testing: bigdirectory/1.JPG OK
testing: bigdirectory/2.JPG OK
testing: bigdiretoryy/3.JPG OK
testing: bigdirectory/4.JPG OK
:
:
file #289: bad zipfile offset (local header sig): 4294967295
(attempting to re-compensate)
file #289: bad zipfile offset (local header sig): 4294967295
file #290: bad zipfile offset (local header sig): 9457343448
file #291: bad zipfile offset (local header sig): 9457343448
file #292: bad zipfile offset (local header sig): 9457343448
file #293: bad zipfile offset (local header sig): 9457343448
:
:
这真的令人担忧,因为我需要这些文件.使用系统zip工具创建此zip文件时肯定没有错误.事实上,我同时制作了其中的几个,现在他们都表现出同样的问题.
如果文件确实已损坏,我该如何解决？
或者,如果它没有损坏,我该如何提取它？
Geo*_*org 24
在6以下解压缩看似失败,使用
jar -xf <zipfile>
如果您已经安装了Java,或者在关闭文件之前还有另一个解压缩.
请参阅:https://serverfault.com/questions/235139/how-to-unzip-files-bigger-than-4gb
noo*_*non 10
在执行硬盘格式之前,我在备份12GB目录时遇到了类似的问题.有趣的是,我使用了与你相同的命令.
我四处阅读并找到了建议:
zip -F
和
zip -FF
尝试修复该文件.
不幸的是这些没有用,我仍然收到错误.
在查看了一些之后,我发现了ditto命令,它完全符合我的原始(未触摸)zip文件:
ditto -x -k original-file.zip dst-directory
-x to extract an archive
-k Specifies it to be a PKZip archive instead of the default CPIO
使用此命令后,我成功提取了所有文件.
7z x我unzip %x在Linux上遇到了与.zip4GB以上文件相同的问题,并且出现了only DEFLATED entries can have EXT descriptor错误.
该命令7z x解决了我的所有问题.
但要小心,该命令7z x将使用以当前目录为根的路径提取所有文件.该选项-o允许指定输出目录.
当存档中的文件大小超过 4 GB 时，内置的 macOS 存档实用程序（这是您在 Finder 中选择某些内容并转到文件 -> 压缩“<item>”时使用的默认设置）也会创建“损坏的”存档，存档本身的大小超过 4 GB，或者您正在尝试将超过 65536 个文件压缩到一个 zip 文件中。发生这种情况是因为它不使用 Zip64 扩展格式。
这是在https://apple.stackexchange.com/questions/221020/large-zip-files-created-in-os-x-cannot-be-opened-in-windows上提到的，并且在“Apple Archive实用程序（和同上）和非常大的 ZIP 档案” 2009 博客文章，用于现已解散的 Springy 实用程序。您还可以看到7-Zip 人员也知道 Apple 工具会导致损坏的 zip 问题。
但是为什么 zip 命令会让我创建这些文件？
严格来说，原始 zip 格式仅支持最多 2^32 字节 (4GiB) 的档案，并且不包含最初大于 4GiB 的文件，并且您必须少于 65535 个文件。由于 OSX 随附的 Infozip 命令工具的命令行版本一直到 OSX 10.11 (El Capitan) 版本不高于 5.52，因此如果您强制它超过原始 zip 格式限制，它只能生成不符合要求的存档。Infozip 6.0 及更高版本知道如何制作 Zip64 档案，并且该标准具有更高的限制。该Infozip 6.0命令行工具开始与MacOS的10.12（塞拉利昂）出货。2014 年最初提出这个问题时，最新的 OSX 是 10.10 (Yosemite)。
如上所述，即使在 macOS 10.15 (Catalina) 中，GUI 存档实用程序仍会创建此类“损坏”的 zip。
如果文件确实已损坏，我该如何修复？
从某种意义上说它是腐败的，它不符合标准，并且会导致许多符合标准的工具窒息。您可以提取（见下文），然后使用知道如何制作 Zip64 文件的工具再次压缩...
或者，如果它没有损坏，我如何提取它？
从技术上讲，来自已压缩文件的所有数据仍在存档中，但允许快速列出 zip 内容的标头已损坏。使用其他工具时，此类 zip 可能很难处理（即使unzip在同一版本的 macOS 上使用命令行工具测试此类 zip也可能会出现invalid compressed data to inflate/ 之类的问题bad zipfile offset (local header sig)）。
要获取此类 zip 的文件，您需要使用一个程序，该程序将安静地提取压缩的任何内容，而无需检查一致性或尝试检查/列出文件。可以执行此操作的工具示例如下：
dittojar工具一旦您制作了此类有问题的 zip 文件，基于 Infozip 的工具将无法使用或修复此类 zip 文件。