我有这个：
-rw-r--r-- 1 user user 36166999908 Jan 29 2022 tmp.archive.part1.zip
-rw-r--r-- 1 user user 5579574562 Jan 29 2022 tmp.archive.part2.zip
-rw-r--r-- 1 user user 5097536636 Jan 29 2022 tmp.archive.part3.zip
-rw-r--r-- 1 user user 10612382236 Dec 29 02:19 tmp.archive.part4.zip
G M k
因此，这些 ZIP 文件的大小分别为 36 GB、5、5 和 10 GB，所有这些文件都超过了我在一个地方读取的最大 2^32 4GB。他们说“zip64”允许 2^64 大小，但我不知道我有什么，zip -h 说：
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
Zip 3.0 (July 5th 2008). Usage: ...
文件告诉我：
file tmp.archive.part1.zip
tmp.archive.part1.zip: Zip archive data, at least v1.0 to extract
那怎么可能呢？
我确实注意到 zipmerge 完全无法操作这些文件。
我的问题是，我需要将这些 zip 文件合并为一个（如果可能），并且无需实际提取它们（系统上没有空间和文件计数配额）。我尝试了一个 zip2tar python 脚本，有人在此处发布了另一个问题，但也失败了。他们不喜欢这个文件，说它不是 zip 文件，或者只是因核心转储而崩溃。
如果这些 zip 文件是用我展示的 zip 3.0 创建的，那么是否有更好的 zipmerge 或不会因大小而阻塞的东西？
Aus*_*arn 28
因为 \xe2\x80\x98ZIP\xe2\x80\x99 存档有不止一种类型。
\n由 PKZIP 第一个版本实现的原始 ZIP 格式确实对存档大小有 4 GiB 限制（以及对存档成员大小（压缩和未压缩）的相应限制）。然而，在该格式的 4.5 版本中，引入了 ZIP64 扩展，通过将文件头和存档条目中的相关字段移动到存档中其他位置存储的补充字段，并将此限制扩展到 16 EiB，并扩展了对以类似的方式调整档案成员的数量（经典 ZIP 仅限于 65535 个档案成员）。
\n但是，除非工具实际上正在查找这些扩展字段，否则它们会被忽略，并且该工具将无法正常工作。这是因为 ZIP64 存档在技术上仍然是有效的 \xe2\x80\x98classic\xe2\x80\x99 ZIP 存档，除非您尝试验证成员大小（这是一个很好的例子，说明为什么向后兼容性有时可能是一件坏事）。
\n可能值得注意的是，ZIP 格式实际上还存在许多其他潜在的不兼容性。特别值得注意的是，有多种不兼容的加密机制可以与 ZIP 存档一起使用，并且几乎有十几种不同的压缩算法，大多数实现并不支持所有这些算法（尽管您必须不遗余力地使用除 \xe2 之外的其他算法） \x80\x98Store\xe2\x80\x99、\xe2\x80\x98Deflate\xe2\x80\x99 或 \xe2\x80\x98Deflate64\xe2\x80\x99，几乎所有东西都支持这些）。
\n