我的流程正在处理已被破坏的数据。我可以看出它已经用 UTF-8 进行了双重编码，但这只是故事的一半。双倍的-decoding仅适用于单字节（拉丁语）且完好无损地通过 UTF-8 的代码点。双字节（或更大）的代码点不能使用以下命令进行双重解码.decode('utf-8').encode('raw_unicode_escape').decode('utf-8')
我有一个例子可以帮助解决这个问题。我经历过的字符串之一是这样的：
'\xc3\x82\xc2\xa9\xc3\x82\xc2\xae\xc3\xa2\xe2\x80\x9e\xc2\xa2'
这应该解决：
u'\xa9\xae\u2122'
(c) 和 (r) 符号的前两个代码点不需要代理对，因此非常明显地存在于原始字节中。然而，最后一个字符（tm）符号是一个 16 位代码点，并且会被执行此操作的任何进程破坏。
如果我在该点之前截断字符串，那么我可以成功地进行双重解码：
'\xc3\x82\xc2\xa9\xc3\x82\xc2\xae'.decode('utf-8').encode('raw_unicode_escape').decode('utf-8')
但是，这不适用于整个字符串，因为第一次解码会产生以下结果：
u'\xc2\xa9\xc2\xae\xe2\u201e\xa2'
谁能指出我解决这个问题的正确方向？与此同时，我将继续研究这个问题，看看是否能弄清楚。
好吧，所以我基本上只需要对编码进行一些猜测，直到找到解决方案。问题在于数据也是 cp1252 编码的（可能是因为数据来自 Windows 系统）。解决办法是调用.decode('utf-8').encode('cp1252').decode('utf-8') and voila:
>>> raw = '\xc3\x82\xc2\xa9\xc3\x82\xc2\xae\xc3\xa2\xe2\x80\x9e\xc2\xa2'
>>> print raw.decode('utf-8').encode('cp1252').decode('utf-8')
©®™
我希望其他人通过偶然发现这个问题得到帮助！
发现这也有帮助：
https://gist.github.com/litchfield/1282752/653b0c1944741ac90ca9c63c25ee3c2f609b323b https://gist.github.com/litchfield/1282752/653b0c1944741ac90ca9c63c25ee3c2f609b323b
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
