我的任务是将非常旧的文本文件（逗号分隔表）转换为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
答案 0 :(得分：1)
此文件包含合法的UTF-8和非法数据的奇怪组合
可能无法可靠地恢复数据。虽然chardet之类的东西可以用来“猜测未知编码”，但如果你有一个文件，其中每个行可以使用不同的编码，那么每个文件可能都没有足够的数据即使你有标准的编码，它也可以做出合理的猜测，看起来你没有。
这应该是引号中的“abaddhaṃ”，但正如你所看到的那样“ṃ”是A2
没有标准编码将字节0xA2映射到U + 1E43（拉丁小写字母'm'，下面有点）。您可能有错误的数据，或者您可能有自定义编码，即只能使用特殊字体读取的文本。
EE 83 93 EE 8297│EE82 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-16引号和行尾中编码为UTF-16LE。这特别棘手，因为你无法确定引号和行结尾的位置，因为0x22和0x0A是代码单元内部完全有效的字节。
似乎这个文件有点像一个缸，如果没有大量的手动黑客攻击，它可能根本不可用。看看你是否可以找到有关它的遗产的任何信息，如果还有其他任何东西消耗它。如果其自定义“可视编码”周围有自定义字体，您可能会更接近。