一些文件以错误的模式上传到 FTP（通过命令行）。我相信我有一些以文本模式上传的二进制文件，现在我无法打开它们。
我无法访问原始文件，我能以某种方式恢复吗？是否有某种工具可以让我以正确的格式获取文件？
答案1
我最近也遇到了同样的问题。Linux -> Windows，ASCII 模式。我已经用 Python 编写了一个程序，可以恢复 ASCII 传输的二进制文件。这是一个字节暴力破解器，它的工作原理如下：
- 以字节流形式打开损坏的档案。
- 查找所有出现 0d 且后跟 0a 的情况 (ASCII 13, ASCII 10)。
- 删除所有出现的 0d 后跟 0a 并存储字节地址。
- 循环遍历每个地址来恢复一些 0d，以防它们应该存在于二进制文件中，然后恢复并尝试打开（在我的情况下，我处理的是 bz2 档案，并使用 CRC 校验和算法检查未压缩数据的完整性并将其与硬编码到档案中的数据进行匹配）。
二进制文件中可能的有效 0d 0a 字节对的数量不会很高；二进制文件中具有有效 0d 0a 对的概率相当低。对于小于 100kb 的文件，使用这种强力方法修复 bz2 存档所需的时间不到 10 秒。我还没有用其他类型的文件检查过，但这是可能的。
我不会在这里粘贴代码，因为这个问题与编程无关，这是一种竞赛任务，我认为我不太愿意公开这些源代码，但如果你需要，请告诉我。
欢呼吧，祝大家圣诞快乐！:)
答案2
要知道是否可以撤销破坏，需要了解所涉及的操作系统。后果取决于您在服务器和客户端上使用的操作系统组合。
最严重的问题是行尾字符。Windows 使用回车符（ASCII 值 13），然后是换行符（ASCII 值 10），而 Linux 仅使用换行符。
文本模式 FTP 传输会转换此内容。二进制模式则不会。这就是破坏发生的地方。
如果从 Windows 转移到 Linux，则无法确定 LF 最初是 LF 还是 CR-LF 的组合。由于数据丢失，几乎不可能恢复破坏。
答案3
正如其他人所指出的，数据已损坏且可能无法恢复。
但是，0x0D 0x0A 在大多数二进制文件格式中并不是一个特别常见的字节序列 [需要引用！]，因此值得尝试替换它们以查看是否能修复文件。
这fixgz 实用程序就是这样。尽管它的名字如此，但它并不特定于 .gzip 文件，并且可以用于任何文件。
祝你好运！