我有一个来自旧源的文本文件，其中包含损坏的字符。
起初我以为损坏的文本只是胡言乱语，但仔细检查后发现，部分损坏的文本可能可以重建。
为了集中我的精力，即使我无法完全重建它，了解原件的样子也会有所帮助。
不幸的是，这份文件来自一个我无法自由分享的集合，但这里有一个片段。该消息已转换为 UTF-8，但转换在某个地方失败了，因此大部分内容都难以辨认。捷克语的文本片段可见，其中带重音的捷克语字符已被替换为西里尔语字符（在转换之前，它们可能完全不同）。
0001f80: 33d1 936e 6576 79d1 87d0 bd7a 656e d18c 3..nevy....zen..
0001f90: 6368 7e58 3833 d193 7e58 3945 d19b d0b1 ch~X83..~X9E....
0001fa0: 646f 7374 d0bd 7e58 3833 d193 6e61 7e58 dost..~X83..na~X
0001fb0: 3833 d193 7ad1 87d0 bd7a 656e 20d0 bd7e 83..z....zen ..~
0001fc0: 5838 33d1 936e 6562 6f7e 5838 33d1 9370 X83..nebo~X83..p
0001fd0: d187 656b 6cd0 b164 6b75 7e58 3833 d193 ..ekl..dku~X83..
0001fe0: 7465 6c65 666f 6e6e d0bd 7e58 3833 d193 telefonn..~X83..
0001ff0: 7374 616e 6963 657e 5838 33d1 9376 207e stanice~X83..v ~
0002000: 5838 33d1 9372 6567 696f 6e75 7e58 3833 X83..regionu~X83
0002010: d193 5072 6168 617e 5838 33d1 9365 7669 ..Praha~X83..evi
0002020: 6475 6a65 7e58 3833 d193 5350 547e 5838 duje~X83..SPT~X8
0002030: 33d1 9354 656c 6563 6f6d 2e7e 5838 33d1 3..Telecom.~X83.
0002040: 934e 617e 5838 33d1 9364 6e65 7e58 2039 .Na~X83..dne~X 9
0002050: 41d1 996e d0bd 7e58 3833 d193 7469 736b A..n..~X83..tisk
0002060: 6f76 d0b9 7e58 3833 d193 6b6f 6e66 6572 ov..~X83..konfer
0002070: 656e 6369 7e58 3833 d193 746f 7e58 3833 enci~X83..to~X83
0002080: d193 d187 656b 6c7e 5838 33d1 93d1 8765 ....ekl~X83....e
我隐约猜测编码可能与ISO-2022，但我对它不够熟悉，无法确定。显然，在它变成这样之前，它至少经历过一次损坏的过滤器，也可能经历过多次损坏。
查看第一行，d1 93是 ѓ，在转换之前可能是一个 8 位字节。一般模式后面似乎跟着~XFF一个信号字节，其中 FF 是纯 ASCII 中的某个十六进制序列（这里大部分是 83，但在整个样本中通常是从 80 到 9E），最后一个字节现在是一个 UTF-8 字符。（当然，它也可能是输入中的多个字节。）这个序列出现在单词之间（总是~X83ѓ？），有时出现在单词内。
这是与文本相同的片段，因为它现在在 UTF-8 下呈现。
3ѓnevyчнzenьch~X83ѓ~X9Eћбdostн~X83ѓna~X83ѓzчнzen н~X83ѓnebo
~X83ѓpчeklбdku~X83ѓtelefonnн~X83ѓstanice~X83ѓv ~X83ѓregionu
~X83ѓPraha~X83ѓeviduje~X83ѓSPT~X83ѓTelecom.~X83ѓNa~X83ѓdne~
X 9Aљnн~X83ѓtiskovй~X83ѓkonferenci~X83ѓto~X83ѓчekl~X83ѓчe
我还有其他语言的样本，所以整理捷克语并不是我的重点。这是其中一个的开头，我不知道，可能是某种远东语言？
X1B%0 ~XD0^?~X98^?~XD0^?^?^?~X82^?~XD0^?~XB5^?^?~X80^?^?~X84^?~XD0^?~XB0^?~XD0
^?^?^?~X81^? ~XD0^?~XB1^?^?~X83^?~XD0^?^?~XD0^?~XB2^?~XD0^?~XB0^?~XD0^?^?^?~X8C
^?~XD0^?^?~XD0^?~XBE^? ~XD0^?~XB7^?~XD0^?~XB0^? ~XD0^?^?~XD0^?~XB5^?^?~X81^?~XD
0^?^?~XD0^?~XBE^?~XD0^?^?^?~X8C^?~XD0^?^?~XD0^?~XBE^? ~XD0^?^?~XD0^?~XB8^?~XD0^
?^?^?~X83^?^?~X82^? ~XD0^?~XB4^?~XD0^?~XBE^? ^?~X81^?~
（^?:s 是文字 DEL 字符，ASCII 0x7F。）
开头波浪号位置的空格可能暗示了转换过程中出现了什么问题，但这只是猜测。
ESC% 0看起来像 ISO-2022 代码，用于“指定其他编码系统”，但0在这里它代表什么？如果没有进一步的例子，我可能太笨了，无法理解维基百科文章，而我能找到的其他所有内容似乎都非常关注某些子集，例如 ISO-2022-JP。
到目前为止，我的分析对你来说有意义吗？你能帮我弄清楚发生了什么吗？甚至能就如何扭转腐败提供建议吗？
我已经发布了这两个示例的扩展片段的十六进制转储，网址为http://pastebin.com/ffn7CtdG
答案1
在此回答中，我详细说明了我对这些文件来源的想法。这不是一个完整的答案，因为更详细的取证分析需要亲自访问至少部分完整文件。
我看到的片段中，有几点让我印象深刻：
- 这些词是捷克语
- 单词之间有奇怪的序列，并且重复很多次
- 这些奇怪的序列由 UTF-8 字符组成，根本没有任何意义，除非其中一些字符本质上是西里尔字母。
我的结论是，这些文件原本不是文本文件，而是被错误地转换为 UTF-8，就像它们是文本一样，使用了包含西里尔字符的代码页。
例如，无处不在的序列d193是西里尔字母小的gje其不同的代码页表示形式为：
这为我们提供了原始文件可能的编码列表，具体取决于原始操作系统。如果它们是在 Windows 计算机上创建的，则其原始代码页可能是 Windows-1251，但在 Mac 上，它们可能是 Macintosh 西里尔文。当然，转换为 UTF-8 也完全有可能使用了错误的编码。
例如，我们发现序列SPT~X83..Telecom。“SPT Telecom”公司正是捷克国家电信公司，成立于 1993 年，该公司出现在路透社新闻专线文本中是合乎逻辑的。但是，除了两个单词之间的空格外，没有任何分隔符。
对于这些在单词中重复出现的令人费解的字符串，我的解释是它们不是文本的一部分，也不可能是文本的一部分。我相信它们一定是放在单词之间的二进制字符，这可能与文件的格式有关。将文件转换为 UTF-8 的转换程序因此盲目地将它们转换为毫无意义的 UTF-8 字符。
即使尝试使用上面列表中的任何代码页将这些序列转换为二进制，我也没有得到任何有意义的序列。但是，我曾使用过来自某些旧文本编辑器的文本文件，这些文本编辑器在文本中放置了“不可见”字符，而这些字符的目的不是显示，而是控制显示。
我相信这就是这些文件的解释，但我不知道这种奇怪的文件格式。它可能是某个未知的捷克文本编辑器（至少我不知道）。如果可以扫描文件以查找文本中包含的日期，这可能有助于缩小可能性。
我不相信你的理论，即原始文件结构良好，并且编码为ISO-2022，因为这些奇怪的序列似乎不是（或者从来不是）ISO-2022控制序列。