恢复损坏的 zip 或 gzip 文件？
损坏压缩文件的最常见方法是无意中进行 ASCII 模式 FTP 传输，这会导致 CR 和/或 LF 字符的多对一废弃。
显然，存在信息丢失的情况，解决这个问题的最好方法就是重新传输，以FTP二进制模式。
但是，如果原始数据丢失，而且这很重要，那么数据如何恢复？
[实际上，我已经知道我认为最好的答案是什么（这非常困难，但有时是可能的 - 我稍后会发布更多），以及常见的非答案（许多现成的程序用于修复 CRC 而不修复数据） ），但我认为在 stackoverflow beta 期间尝试这个问题会很有趣，看看是否有其他人走上了成功恢复的道路或发现了我不知道的工具。]
The most common method for corrupting compressed files is to inadvertently do an ASCII-mode FTP transfer, which causes a many-to-one trashing of CR and/or LF characters.
Obviously, there is information loss, and the best way to fix this problem is to transfer again, in FTP binary mode.
However, if the original is lost, and it's important, how recoverable is the data?
[Actually, I already know what I think is the best answer (it's very difficult but sometimes possible - I'll post more later), and the common non-answers (lots of off-the-shelf programs for repairing CRCs without repairing data), but I thought it would be interesting to try out this question during the stackoverflow beta period, and see if anyone else has gone down the successful-recovery path or discovered tools I don't know about.]
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以尝试编写一个小脚本，将所有 CR 替换为 CRLF（假设垃圾的方向是 CRLF 到 CR），每个块随机交换它们，直到获得正确的 crc。 假设数据不是特别大，我猜想在宇宙热寂完成之前可能不会使用所有的 CPU。
由于肯定存在信息丢失，我不知道有更好的方法。 CR 到 CRLF 方向的丢失可能会更容易回滚。
You could try writing a little script to replace all of the CRs with CRLFs (assuming the direction of trashing was CRLF to CR), swapping them randomly per block until you had the correct crc. Assuming that the data wasn't particularly large, I guess that might not use all of your CPU until the heat death of the universe to complete.
As there is definite information loss, I don't know that there is a better way. Loss in the CR to CRLF direction might be slightly easier to roll back.
来自Bukys软件
From Bukys Software