いくつかのファイルは間違ったモードで FTP にアップロードされました (コマンド ライン経由)。TEXT モードでアップロードされたバイナリ ファイルがあると思いますが、それらを開くことができません。
元のファイルにアクセスできないのですが、どうにかして回復できますか? ファイルを正しい形式で取得できるツールはありますか?
答え1
最近、同じ問題に直面しました。Linux -> Windows、ASCII モード。ASCII で転送されたバイナリを復元できる Python のプログラムを書き終えました。これはバイト ブルートフォーサーで、その仕組みは次のとおりです。
- 破損したアーカイブをバイト ストリームとして開きます。
- 0d の後に 0a (ASCII 13、ASCII 10) が続くすべての出現を検索します。
- 0d の後に 0a が続くすべての出現を削除し、バイト アドレスを保存します。
- 各アドレスを循環して、バイナリ内に存在するはずの 0d の数を復元し、復元して開こうとします (私の場合は bz2 アーカイブを扱っており、CRC チェックサム アルゴリズムを使用して、圧縮されていないデータの整合性をチェックし、アーカイブにハードコードされているデータと照合しました)。
バイナリ内の有効な 0d 0a バイト ペアの数はそれほど多くありません。バイナリに有効な 0d 0a ペアが存在する可能性は非常に低いです。このブルートフォース メソッドを使用して bz2 アーカイブを修正するのにかかる時間は、100kb 未満のファイルの場合 10 秒未満です。他の種類のファイルでは確認していませんが、可能です。
この質問はプログラミングに関連したものではなく、一種の競争課題であり、ソースを公開することに抵抗があるため、ここにコードを貼り付けるつもりはありませんが、必要な場合はお知らせください。
みなさん、メリークリスマス！ :)
答え2
破壊を元に戻すことが可能かどうかを知るには、関係するオペレーティング システムを知る必要があります。結果は、サーバーとクライアントで使用するオペレーティング システムの組み合わせによって異なります。
最も深刻な問題は、行末文字です。Windows では、キャリッジ リターン (ASCII 値 13) の後にライン フィード (ASCII 値 10) が続きますが、Linux ではライン フィードのみが使用されます。
テキスト モードの FTP 転送ではこれが変換されます。バイナリ モードでは変換されません。ここで破壊が発生します。
Windows から Linux に転送された場合、LF が元々 LF であったか、CR-LF の組み合わせであったかを判断することは不可能です。データが失われるため、破壊を元に戻すのはほぼ不可能です。
答え3
他の人が指摘しているように、データは破損しており、回復できない可能性があります。
ただし、0x0D 0x0A は、ほとんどのバイナリ ファイル形式では特に一般的なバイト シーケンスではありません [引用が必要]。そのため、それらを置き換えて、ファイルが修正されるかどうか試してみる価値はあります。
のfixgz ユーティリティまさにそれを行います。名前にもかかわらず、.gzip ファイルに固有のものではなく、どのファイルでも使用できます。
幸運を！