是否可以恢复损坏部分之外的损坏的 Zlib 数据？

Question

我有一个 Zip 存档，其中包含一个无法解压的大（重要）文件。我尝试过的所有 Zip 实用程序，包括那些声称可以恢复/修复损坏的 Zip 存档的实用程序，都无法提取包含损坏的 zlib 压缩数据的文件。他们获取存档中的所有文件，但损坏的条目除外，该条目会被跳过。

我用 C# 编写了一个小型实用程序应用程序，它解析 zip 存档、识别每个条目并解析字段、解密数据部分，然后使用 DeflateStream（来自 zlib 的 .Net 实现）解压缩它们。一切正常，直到我找到损坏的入口。损坏的条目成功且完全解密（在 CTR 模式下使用 AES），但 DeflateStream 读取器在抛出“错误状态（超额订阅动态位长度树）”之前只能读取大约 40MB 的解密数据。

是否有可能以某种方式“寻找”损坏的部分并继续解压缩数据？我想恢复尽可能多的文件，即使有一些漏洞。DeflateStream 没有实现 Seek 方法，如果我尝试创建一个新的 DeflateStream，并将底层 FileStream 定位到最后读取的位置，它会抛出相同的“Bad State”异常。

Answer 1

deflate 协议基于滑动窗口和前向流来调整表。

这不是一个块——每个部分都不是独立的数据单元，因此无法“跳过”坏块——​​而是用于计算/恢复表信息的流的移动“视图” 。话虽这么说，我的简单结论是：不太可能:(

请参阅“Deflate”协议的说明。

不那么脾气暴躁的数据恢复。

deflate 协议实际上具有允许在所使用的压缩器之间切换的“块”。但是，我怀疑它们是否可用于任何类型的恢复。它与 MPEG-4 相去甚远，后者实际上是相当可恢复的。

来自RFC 1951，它显示了它有多么复杂：

请注意，标头位不一定从字节边界开始，因为块不一定占用整数个字节。

并谈论能够跨越各个块的 LZ77 压缩器：（它是用于构建压缩信息的窗口内的整个流）。

请注意，重复的字符串引用可能引用前一个块中的字符串；即，后向距离可能跨越一个或多个块边界。

不过，还是有一丝希望的：

当压缩器确定用新鲜树开始新块将是有用的，或者当块大小填满压缩器的块缓冲区时，压缩器终止块。

我不会追逐任何光线：-/也许单独的位搜索（并非所有位序列都是有效的块开始），然后运行算法直到它失败（可证明“无效”放气），然后后退并再次尝试，直到这样起始位在某个“可接受”的时间内没有生成无效状态。

此方法需要修改 deflate 协议引擎——这不是普通 deflate 流处理器可以处理的任务。