zip 文件格式以中央目录部分结尾，然后指向文件中的各个 zip 条目。这似乎允许 zip 条目出现在 zip 文件本身的任何位置。事实上，自解压 zip 文件就是一个很好的例子:它们以可执行文件开头，所有 zip 条目都出现在可执行字节之后。
问题是:zip 文件格式真的允许稀疏或不连续的 zip 条目吗？ zip 条目之间是否有空字节或未说明的字节？最终的 PK 说明和维基百科文章似乎都允许这样做。所有/大多数典型的 zip 实用程序都可以处理这种稀疏的 zip 文件吗？
用例是这样的:我希望能够删除或替换 zip 文件中的 zip 条目。为此，典型的 minizip 等库希望您复制出整个 zip 文件，而不复制出已删除或替换的 zip 条目，这看起来既浪费又慢。
过度分配不是更好吗，比如为一个条目分配 1.5 倍的存储空间，然后在删除或替换条目时，您可以找出未分配字节的位置并直接使用它们？使用 1.5 倍的存储意味着如果 zip 条目线性增长，重新分配也应该线性摊销。它类似于文件系统 block 分配，但可能没有那么复杂。
这也有助于处理许多基于 zip 的文件格式。不必在某个地方(甚至在内存中)有一些临时目录，其中包含临时解压缩的文件以进行编辑/更改，然后必须将这些文件重新压缩回文件格式，这将减少重新压缩和重写 zip 部分的需要文件。
是否有任何 C/C++ 库可以执行此操作？
最佳答案
没有。读取中央目录是可选的。 zip 解码器可以(有些确实如此)简单地从头开始按顺序读取 zip 文件，期望看到连续的本地 header 和条目数据。他们可以完成解码工作，甚至无需查看中央目录。
为了做你想做的事，你需要在有用的条目之间放入虚拟的 zip 条目以保留该空间。至少如果您想与 zip 世界的其他部分兼容。
关于c++ - zip 文件可以是稀疏的/不连续的吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12385984/