5

损坏压缩文件的最常见方法是无意中执行 ASCII 模式 FTP 传输，这会导致 CR 和/或 LF 字符的多对一丢弃。

显然，存在信息丢失，解决此问题的最佳方法是再次传输，以 FTP 二进制模式。

但是，如果原件丢失，而且很重要，那么数据的可恢复性如何？

[实际上，我已经知道我认为最好的答案（这非常困难但有时可能 - 我稍后会发布更多），以及常见的非答案（大量用于修复 CRC 而不修复数据的现成程序)，但我认为在 stackoverflow 测试期间尝试这个问题会很有趣，看看是否有其他人走上了成功恢复的道路或发现了我不知道的工具。]

4

2 回答 2

4

来自Bukys 软件

已知大约 256 个字节中的 1 个已损坏，并且已知损坏仅发生在值为“\012”的字节中。所以字节错误率为 1/256（输入的 0.39%），2/256 字节（输入的 0.78%）是可疑的。但是由于每个被破坏的字节只有三位受到影响，因此误码率只有 3/(256*8)：0.15% 是坏的，0.29% 是可疑的。

...

压缩输入中的错误会破坏所有后续字节的解压缩过程......解压缩输出如此之快就可以识别出糟糕的事实是令人希望的原因 - 搜索正确答案可以快速识别错误答案。

最终，结合了多种技术，成功地从这些文件中提取了合理的数据：

  • 字段和引用字符串的特定于域的解析
  • 从损坏概率低的先前数据中进行机器学习
  • 容忍其他原因导致的文件损坏（例如，记录时磁盘已满）
  • 引导搜索沿着最高概率路径的前瞻

这些技术可以确定地确定 75% 的必要修复，其余的则以最高概率优先进行探索，以便立即确定合理的重建。

于 2008-09-12T20:05:05.633 回答
1

您可以尝试编写一个小脚本，用 CRLF 替换所有 CR（假设垃圾的方向是 CRLF 到 CR），每个块随机交换它们，直到您获得正确的 crc。假设数据不是特别大，我猜可能不会使用你所有的 CPU，直到宇宙热寂完成。

由于存在一定的信息丢失，我不知道有没有更好的方法。CR 到 CRLF 方向的损失可能更容易回滚。

于 2008-09-12T18:52:12.157 回答