<p>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.</p>

<p>Obviously, there is information loss, and the best way to fix this problem is to transfer again, in FTP binary mode.</p>

<p>However, if the original is lost, and it's important, how recoverable is the data?</p>

<p>[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.]</p>

[{'answer_id': 59746, 'author': 'jsight', 'author_id': 1432, 'author_profile': 'https://Stackoverflow.com/users/1432', 'pm_score': 2, 'selected': False, 'text': "<p>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.</p>\n\n<p>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.</p>\n"}, {'answer_id': 59836, 'author': 'Adam Davis', 'author_id': 2915, 'author_profile': 'https://Stackoverflow.com/users/2915', 'pm_score': 3, 'selected': True, 'text': '<p>From <a href="http://wayback.archive.org/web/jsp/Interstitial.jsp?seconds=5&amp;date=1195189396000&amp;url=http%3A%2F%2Fwww.bukys.com%2Fservices%2Frecovery%2Fexamples%2F&amp;target=http%3A%2F%2Fweb.archive.org%2Fweb%2F20071116050316%2Fhttp%3A%2F%2Fwww.bukys.com%2Fservices%2Frecovery%2Fexamples%2F" rel="nofollow noreferrer">Bukys Software</a></p>\n\n<blockquote>\n  <p>Approximately 1 in 256 bytes is known\n  to be corrupted, and the corruption is\n  known to occur only in bytes with the\n  value \'\\012\'. So the byte error rate\n  is 1/256 (0.39% of input), and 2/256\n  bytes (0.78% of input) are suspect.\n  But since only three bits per smashed\n  byte are affected, the bit error rate\n  is only 3/(256*8): 0.15% is bad, 0.29%\n  is suspect.</p>\n  \n  <p>...</p>\n  \n  <p>An error in the compressed input\n  disrupts the decompression process for\n  all subsequent bytes...The fact that\n  the decompressed output is\n  recognizably bad so quickly is cause\n  for hope -- a search for the correct\n  answer can identify wrong answers\n  quickly.</p>\n  \n  <p>Ultimately, several techniques were\n  combined to successfully extract\n  reasonable data from these files:</p>\n  \n  <ul>\n  <li>Domain-specific parsing of fields and quoted strings</li>\n  <li>Machine learning from previous data with low probability of damage</li>\n  <li>Tolerance for file damage due to other causes (e.g. disk full while\n  logging)</li>\n  <li>Lookahead for guiding the search along the highest-probability paths</li>\n  </ul>\n  \n  <p>These techniques identify 75% of the\n  necessary repairs with certainty, and\n  the remainder are explored\n  highest-probability-first, so that\n  plausible reconstructions are\n  identified immediately.</p>\n</blockquote>\n'}]
['https://Stackoverflow.com/questions/59735', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/5845/']