Java ZipInputStream跳过未使用的ZipEntry内容，而不是将其耗尽

我正试图从zip中获得ZipEntry内容的最佳阅读。为了实现这一点，我需要标准的ZipInputStream使用InputStream.skip来获取不需要的条目内容，而不是将其耗尽

只要我从维基上了解到：

因为ZIP存档中的文件是单独压缩的，所以可以提取它们或添加新文件，而无需对整个存档应用压缩或解压缩。这与压缩tar文件的格式形成对比，对于压缩tar文件，这种随机访问处理不容易实现

因此，我假设在使用ZIP解压缩条目内容之前，跳过不需要的内容是确定的

然而，我看到ZipInputStream（Java标准）和ZipArchiveInputStream（apache）都在将流排空，直到下一个条目，而不是跳过它，这使得我使用它的效率非常低

我并不完全了解ZIP规范，看到两个主要使用的ZIP API的这种行为让我觉得这可能是不可能的

---

是我的理解不正确，这样的最佳行为不可能实现，还是您建议使用什么Java API来高效读取Zip条目？

这里的问题是

ZipInputStream

是一个流。首先读取第一个条目的LOC（本地文件头），读取该条目（解压缩、校验和等），重复该操作，直到没有更多条目（或LOC）

文件/流的结尾包含用于随机访问（或显示zip文件结构）的整个zip内容的目录。流式传输数据时，您无法访问流的结尾。所以，即使你可以寻找，你也不知道去哪里寻找。您必须解压缩以知道条目的数据何时结束，然后获取下一个条目的LOC，依此类推

---

在这篇文章中，据说唯一的真相来源是中央目录，因此我们无论如何都不能依靠条目的压缩大小来跳过。

@Kayaman我明白你的意思，但我甚至不需要检查被删除条目的正确性，更不用说我的数据完整性已经得到验证。对我来说，对1KB进行1TB的校验和是一种过分的做法。。。因此，我不能从ZIP的带宽权衡中获益。谢谢您的检查！这是一个古老的类，即使我注意到它具有本机依赖性。我认为它没有使用skip，因为它在所有的

输入流上都不受支持，但我不认为这是真正的原因。@Kayaman我看到了你的链接，但只要我理解，它需要从我这边实现java.nio.FileSystem，因为我当前正在从我的源代码的未实现文件系统读取文件。@Kayaman正在从网络读取。我认为应该给出输入流的一般答案，而不是对其来源的进一步期望。您确定您的流是可查找的吗？来自URL和套接字的流通常不是本地文件头记录压缩大小，对吗？为什么你不能跳过它？@另一个家伙，我假设它是数据压缩到的大小，与可以跳过的字节不同。嗯，这可能值得测试，因为
ZipInputStream.closeEntry（）
可以被覆盖，而
skip（）
的实现非常简单（我认为）。啊，不，它只是转到超类
InflaterInputStream.skip（）
，它执行
read（）
来膨胀数据。要想在不增加字节膨胀的情况下跳过字节，需要颠覆设计，即使这样，我也不相信没有EOF目录也能做到。如果压缩的大小不是要跳过的大小，我会非常惊讶。我有种感觉，OP认为这会减少传输的数据量，但通常情况下并非如此。Zip文件可能很棘手，而且没有中央目录的东西。定制解决方案可能是可行的，但实施起来几乎毫无用处。如果目标是避免解压和校验和，那么更容易投资更多的CPU。如果避免数据传输，则将服务器更改为仅发送所需数据（如果可能）。