5

圧縮ファイルを破損する最も一般的な方法は、CR および/または LF 文字の多対 1 の破棄を引き起こす ASCII モードの FTP 転送を不注意に行うことです。

明らかに、情報が失われます。この問題を解決する最善の方法は、FTP バイナリ モードで再度転送することです。

ただし、元のデータが失われ、それが重要な場合、データはどの程度回復可能でしょうか?

[実際には、私が考える最良の答え (非常に難しいですが、場合によっては可能です。後で詳しく説明します) と、一般的な非回答 (データを修復せずに CRC を修復するための多くの既製のプログラム) をすでに知っています。 ）、しかし、スタックオーバーフローのベータ期間中にこの質問を試してみて、他の誰かが成功した回復パスをたどったり、私が知らないツールを発見したりしたかどうかを確認するのは興味深いと思いました.]

4

2 に答える 2

4

Bukys ソフトウェアから

約 256 バイトに 1 バイトが破損していることがわかっており、破損は値が '\012' のバイトでのみ発生することがわかっています。したがって、バイト エラー率は 1/256 (入力の 0.39%) であり、2/256 バイト (入力の 0.78%) が疑わしいです。しかし、破壊されたバイトごとに 3 ビットのみが影響を受けるため、ビット エラー率は 3/(256*8) にすぎません。0.15% は不良で、0.29% は疑わしいものです。

...

圧縮された入力にエラーがあると、後続のすべてのバイトの解凍プロセスが中断されます...解凍された出力がすぐに認識できるほど悪いという事実は、希望の原因です-正しい答えを検索すると、間違った答えをすぐに特定できます.

最終的に、これらのファイルから適切なデータを正常に抽出するために、いくつかの手法が組み合わされました。

  • フィールドと引用符で囲まれた文字列のドメイン固有の解析
  • 損傷の可能性が低い以前のデータからの機械学習
  • 他の原因によるファイルの損傷に対する許容度 (ログ中にディスクがいっぱいになるなど)
  • 最も可能性の高いパスに沿って検索を導くための先読み

これらの手法は、必要な修復の 75% を確実に特定し、残りは最も可能性の高いものから順に調査されるため、もっともらしい再構築がすぐに特定されます。

于 2008-09-12T20:05:05.633 に答える
1

すべての CR を CRLF に置き換える小さなスクリプトを作成してみてください (トラッシュの方向が CRLF から CR であると仮定します)。正しい crc になるまでブロックごとにランダムに入れ替えます。データがそれほど大きくなかったと仮定すると、宇宙の熱死が完了するまで、CPU のすべてを使用しない可能性があると思います。

確実に情報が失われるので、他に良い方法があるかどうかはわかりません。CR から CRLF 方向への損失は、ロールバックするのが少し簡単かもしれません。

于 2008-09-12T18:52:12.157 に答える