是否有可能恢復損壞的部分之外的損壞的Zlib數據？

Question

我有一個Zip文件，其中包含一個不會提取的大（重要）文件。我嘗試過的所有Zip實用程序，包括聲稱恢復/修復損壞的Zip歸檔文件的那些實用程序都無法提取包含損壞的zlib壓縮數據的文件。他們獲取存檔中的所有文件，除了已損壞的條目被跳過。

我在C＃中編寫了一個小實用程序，用於解析zip歸檔文件，識別每個條目並解析出字段，解密數據部分，然後使用DeflateStream（從zlib的.Net實現） 。一切工作正常，直到我到達損壞的條目。已損壞的條目成功完全解密（在CTR模式下使用AES），但在投擲「錯誤狀態（超額訂閱動態位長度樹）」之前，DeflateStream閱讀器僅能夠解密大約40MB的數據。

是否有可能以某種方式「尋找」過損壞的部分並繼續解壓數據？我想盡可能地恢復文件，即使有一些漏洞。 DeflateStream沒有實現一個Seek方法，如果我試圖創建一個新的DeflateStream並且底層的FileStream定位到最後一個讀取位置，它會拋出相同的「Bad State」異常。

Answer 1

放氣協議根據滑動窗口和前向流調整表格。

這不是一個塊 - 每個部分不是獨立的數據單元，所以沒有辦法只是「跳過」一個壞塊 - 而是一個移動的「視圖」流用於計算/恢復表信息。話雖這麼說，我的簡單結論：實際上不可能:(

見An Explanation of the "Deflate" Protocol

高於脾氣暴躁以下數據修復

---

這種deflate協議實際上有「塊」，這允許在所使用的壓縮器之間切換，但是我懷疑它們可用於任何類型的恢復，它與MPEG-4相差甚遠，實際上它是可以恢復的。

從RFC 1951，這表明它會多麼複雜：

注意，頭位不一定開始字節邊界上，因爲塊不一定佔用字節的整數倍。

和談論的LZ77壓縮機能夠以跨越各個塊：（它是流的是，用於建立壓縮信息的窗口內的全部）。

請注意，重複的字符串引用可能引用前一個塊中的字符串;即後向距離可以跨越一個或多個塊邊界。

然而，存在希望的提示：

壓縮機終止塊當它確定開始用新鮮的樹木的新塊將是有用的，或者當塊大小填滿了壓縮機的塊緩衝區。

沒有一絲光亮我會追： - /也許個別位尋（不是所有的比特序列有效塊開始），然後運行該算法，直到它失敗（可證明「無效」放氣）然後退出並再次嘗試，直到這樣的起始位在某個「可接受」的時間段內不會產生無效狀態。

此方法需要修改放氣協議引擎 - 這不是普通放氣流處理器可以處理的任務。