神秘的UTF-8类编码

神秘的UTF-8类编码,utf-8,Utf 8,我收到了一个文件,该文件应该是UTF-8格式的,但是对于一些非英语字符有一些奇怪的编码。例如,在这个神秘的编码中,Hangul字符串 한국경북영덕군강구면 编码为: 0xED959C 0xEAB5AD 0xEAB2BD0xEBB63F0xEC983F0xEB3F950xEAB5B0 0xEAB095 0xEAB5AC 0xEBA9B4 (粗体的差异)而非标准UTF-8: 0xED959C 0xEAB5AD 0xEAB2BD0xEBB6810xEC98810xEB8D950xEAB5B0 0xE

我收到了一个文件,该文件应该是UTF-8格式的,但是对于一些非英语字符有一些奇怪的编码。例如,在这个神秘的编码中,Hangul字符串

한국경북영덕군강구면

编码为:

0xED959C 0xEAB5AD 0xEAB2BD0xEBB63F0xEC983F0xEB3F950xEAB5B0 0xEAB095 0xEAB5AC 0xEBA9B4

(粗体的差异)而非标准UTF-8:

0xED959C 0xEAB5AD 0xEAB2BD0xEBB6810xEC98810xEB8D950xEAB5B0 0xEAB095 0xEAB5AC 0xEBA9B4“

我在西里尔文和中文字符中看到了同样的现象——有些字符与UTF-8编码相同,但有些不同。乱码字符与非乱码字符具有相同的字节宽度,我已经验证了它们不是扩展集的一部分。此外,我已经验证了这是而不是Java”修改的UTF-8”

关于这可能是什么,还有其他想法吗

顺便说一句:我没有权限访问代码或最初编写文件的人


此外,我使用的是Mac 10.11.6,以防与此有关。

您的示例字符串由UTF-8组成,但某些字节值(即x81和x8D)被ASCII问号替换为
(x3F)。唯一合理的解释是,您的示例字符串已通过一个软件,该软件试图根据其他编码(可能是单字节字符集)解释其内容,并将“无效”字符替换为
(类似于Unicode文本处理器如何用U+FFFD替换无效的Unicode字符)

不幸的是,这个过程实际上是不可逆的,因为至少有两个不同的字节值(在您的示例中可能没有出现更多)已被替换,因此无法保证在每种情况下都能识别原始字节值。根据这一点的重要性-也就是说,取决于它值得花费多少时间-您可以潜在地识别被替换的完整字节集,然后为每个字节编写尝试每个可能值的内容,compa使用(比如)相关语言中某些文本语料库中的双字符频率将生成的字符序列圈起来,然后选择最可能的字节。(当然,它会出错。要估计生成的错误率,可以在已知文本上尝试相同的过程。)