我的任务是将非常旧的文本文件（逗号分隔表）转换为 UTF-8 JSON。该文件包含合法 UTF-8 和非法数据的奇怪组合。有很多正确的2-byte字符3-byte（带有0x1110xxxx一种长度前缀），大多数数据是 ASCII 范围32-127。非法字节样本是164, 188, 166, 178, 162, 180, 182, 170.
这是否意味着我要处理必须解密的自定义编码，或者这可能是某种记录在案的编码？或者我对 UTF-8 编码的理解不正确？有什么见解吗？
我觉得这是 UTF-8 和一些旧代码页的混合。
样品 1
22 2C 22 61 62 61 64 64 68 61 A2 22
这应该是引号中的“abaddhaṃ”一词，但正如您所见，“ṃ”是 A2
样本 2几个字节后看起来像奇怪编码中的同一个词
22 83 E0 86 E0 83 E0 8B E0 8B E0 93 E0 83 E0 B4 E0 22
样本 3几个字节后似乎是有效的 UTF-8：
EE 83 93 EE 82 97 │ EE 82 B2 EE 82 83
此文件包含合法 UTF-8 和非法数据的奇怪组合
可能无法可靠地恢复数据。虽然类似的东西chardet可以用来“猜测未知的编码”，但如果你有一个文件，其中每一行都可以采用不同的编码，那么即使你有标准，每一行上可能没有足够的数据来做出合理的猜测编码，看起来你没有。
这应该是引号中的“abaddhaṃ”一词，但正如您所见，“ṃ”是 A2
没有将字节 0xA2 映射到 U+1E43 的标准编码（拉丁文小写字母“m”，下方带有点）。您可能有损坏的数据，或者您可能有自定义编码，即只能使用特殊字体读取的文本。
EE 83 93 EE 82 97 │ EE 82 B2 EE 82 83
这些是 U+E0xx 范围内的私人使用区域字符。它们没有标准含义，只能使用特殊字体才能正确阅读。
22 83 E0 86 E0 83 E0 8B E0 8B E0 93 E0 83 E0 B4 E0 22
这些是类似的私人使用区字符，但编码为 UTF-16LE，在正常的非 UTF-16 引号和行尾内。这特别棘手，因为您无法确定引号和行尾在哪里，因为 0x22 和 0x0A 是代码单元中完全有效的字节。
看起来这个文件有点像一个瓦罐，如果没有大量的手动黑客攻击，它可能根本无法使用。看看你是否能找到关于它的遗产的任何信息，以及周围是否有其他东西消耗它。如果它的自定义“视觉编码”有一个自定义字体，你可能会更接近。