我有一个文本文件，其中所有 ASCII 字符都正确显示，但其他一些字符则不正确。特别是这个单词：
don‰Ûªt
在十六进制中，字节为64 6f 6e 89 db aa 74。显然，几乎可以肯定‰Ûª应该是一个花括号，可能U+02BC，U+2019， 或者U+0092。 [编辑后添加：根据从包含相同文本的 PDF 中复制正确的撇号，我现在相当确定它是U+2019。
此网页说
如果某个位序列在任何编码中（对人类来说）都无法理解，那么文档很可能在某个时候被错误地转换了。... 如果文档被误解并转换为不同的编码，那么它就被破坏了。试图“修复”它可能成功，也可能不成功，通常不会成功。任何手动位移位或其他编码巫术大多都是巫术。
但是我肯定应该能够弄清楚我的文件发生了什么，因为我知道这些字节，也知道它们应该代表什么字符。有人能告诉我如何弄清楚文件是如何损坏的，以及如何修复它吗？
答案1
谁能告诉我如何找出文件是如何损坏的......
我不能，但也许你会幸运。
给定一个魔方的乱序配置，很容易找出一组移动方法使其返回到起始状态。通常不可能找出哪些移动方法达到了乱序状态 - 因为可能的移动序列数量巨大。
你的问题类似。部分原因是你没有提供任何有关创建此文本文件时可能使用的平台、语言环境和工具的线索。
对于字符的三字节 UTF8 编码，0x89 不是有效的首字节。0xDBAA 是阿拉伯空中心低位停止。这当然是不可信的。也许 UTF8 被误解为某种 8 位编码，然后保存为不同的 8 位编码。如果文件靠近日本，您可能会将 JIS、Shift-JIS 和 EUC 的一些误用混入其中。
可能有十几个合理的 Unicode 字符，并且可能有更多合理的 8 位和 16 位编码。这太多了，无法手动尝试。如果它足够重要，我可能会编写代码来尝试起始字符加上两个加扰的所有排列，看看是否有任何排列达到 0x89DBAA。
从统计学上来说，我预计最有可能的情况是几乎但不完全不像：
- 创建一个没有 BOM 的 UTF8 文本文件（按照 Unicode 联盟的建议）。
- 使用 MS-Windows Notepad 在“Windows-Latin-1”区域设置下读取该文件。Notepad 将 UTF8 误读为 CP-1252，部分原因是 UTF-8 没有字节顺序标记，并且许多 Microsoft 工具滥用/误用字节顺序标记作为编码指示器。
- 将文件保存为“Unicode”。记事本使用了微软的错误术语，并将其认为的 CP-1252 翻译成 UTF-16 小端序（带 BOM）
但这太简单了（所以我还没有尝试过）。
我确信回想起来答案会一目了然。但现在这只能算是一种小小的安慰。
...以及如何解决它？
鉴于唯一披露的内容是英文单词，don't我们可以推断整个数据是95％ ASCII。这使得使用人工检查变得可行……
列出所有以
0x89dbaa->开头的不同的胡言乱语序列和合理的替换'。使用面向字节的工具（例如
sed）进行这些替换。???
利润！
答案2
’我遇到了同样的问题（仅供参考 - 在 Natural Earth 数据集中）。我编写了一个 C# 程序来查找应用了哪些转换，最后我找到了从花括号到的路径‰Ûª：
- 首先，
’以 UTF-8 编码（E2 80 99）。 - 将三个字节读为 Windows-1252（又名 CP1252，西欧（Windows））；从而产生三个字符
’。 ’在 Mac OS Roman 中编码（在 Windows 上又称为 CP10000）（89 DB AA）。- 再次，将三个字节读为 Windows-1252；结果是
‰Ûª。
因此，为了获得原始文本，我们可以执行完全相反的操作：
- 首先，使用 Windows-1252 对文本进行编码。
- 将字节读取为 Mac OS Roman。
- 再次使用 Windows-1252 对文本进行编码。
- 将字节读取为 UTF-8。