破壞壓縮文件的最常見方法是無意中進行ASCII模式的FTP傳輸，這會導致多對一的CR和/或LF字符被破壞。恢復損壞的zip或gzip文件？
顯然，信息丟失，解決此問題的最佳方法是在FTP二進制模式下再次傳輸。
但是，如果原件丟失，而且很重要，數據的可恢復性如何？ [其實，我已經知道我認爲是最好的答案（這很困難，但有時候可能 - 我會稍後發佈），以及常見的非答案（大量現成的修復程序不用修復數據的CRC），但我認爲在stackoverflow測試期間嘗試這個問題會很有趣，並且看看其他人是否成功恢復了路徑或發現了我不知道的工具。]
中約1個256個字節已知 被破壞，而腐敗是 已知只發生在與 值「\ 012」個字節。所以字節錯誤率爲爲1/256（輸入的0.39％），並且2/256 字節（輸入的0.78％）是可疑的。 但是由於每個字節只有三位被影響，因此誤碼率爲 只有3 /（256 * 8）：0.15％不好，0.29％ 是可疑的。
...
在壓縮輸入 錯誤破壞了減壓過程 所有後續字節......這 解壓後的輸出是 可辨別差這麼快令人 了希望的事實 - 搜索正確的 答案可以快速識別錯誤答案 。
最終，幾個技術是 相結合，從這些文件中提取成功 合理的數據：場
- 特定領域的分析和引用字符串
- 機從損壞
的低概率以前的數據學習- 由於其他原因造成的文件損壞公差（例如磁盤已滿而 記錄）
- 先行用於引導沿最高概率的路徑搜索
這些技術識別與確定性 必要的修理的75％，和 其餘的是探索 最高probability-首先，讓 合理的重建是立即識別 。
你可以嘗試編寫一個腳本來用CRLF替換所有的CR（假設垃圾的方向是CRLF到CR），每個塊都隨機交換，直到你有正確的crc。假設數據不是特別大，我想這可能不會使用所有的CPU，直到完成宇宙的熱死亡。
由於存在明確的信息損失，我不知道有更好的方法。 CR到CRLF方向的損失可能稍微更容易回滾。