Python中双编码utf8的解码

我从一个客户端通过xmlrpc获取的字符串有问题。他给我发送了两次编码的utf8字符串：（所以当我在python中得到它们时，我有一个unicode对象，必须再次解码，但显然python不允许这样做。我注意到我的客户机，但是我现在需要在他修复它之前做一些快速的变通

tcp转储中的原始字符串：

<string>Rafa\xc3\x85\xc2\x82</string>

我们得到的最好结果是：

eval(repr(u'Rafa\xc5\x82')[1:]).decode("utf8") 

这将产生正确的字符串，即：

u'Rafa\u0142' 

但是，这种方法非常难看，不能在生产代码中使用。 如果有人知道如何以更合适的方式解决此问题，请写信。 谢谢 克里斯

>>>s=u'Rafa\xc5\x82' >>>s.encode（'raw_unicode_escape'）。decode（'utf-8'）） u'Rafa\u0142' >>> 哟，真有趣

>>> original = "Rafa\xc3\x85\xc2\x82"
>>> first_decode = original.decode('utf-8')
>>> as_chars = ''.join([chr(ord(x)) for x in first_decode])
>>> result = as_chars.decode('utf-8')
>>> result
u'Rafa\u0142'

因此，首先进行解码，得到一个Unicode字符串，其中每个字符实际上是一个UTF-8字节值。通过这些字符中每个字符的整数值，得到一个真正的UTF-8字符串，然后按照正常方式进行解码

>>> weird = u'Rafa\xc5\x82'
>>> weird.encode('latin1').decode('utf8')
u'Rafa\u0142'
>>>

latin1只是Richie的螺母和螺栓方法的缩写

---

非常奇怪的是，在这种情况下，被严重低估的

raw\u unicode\u escape

编解码器会给出与

latin1

相同的结果。他们总是给出相同的结果吗？如果是，为什么会有这样的编解码器？如果不是，最好确切地知道OP的客户机是如何从

'Rafa\xc5\x82'进行转换的。

到

u'Rafa\xc5\x82'

然后完全反转该过程——否则，如果在修复双重编码之前出现不同的数据，我们可能会失败。

@partisann:Neat！我不知道原始unicode转义（显然是8-）谢谢partisann，我也不知道。愿你的声誉超越预期，即使在这么多年之后！：）似乎你没有回答这个问题，你不是从双编码utf-8字符串开始的，它以欧元符号失败：python-c'import sys；print sys.argv[1]。encode（“raw_unicode_escape”）“$”\xc3\xa2\xc2\x82\xc2\xac”序号不在python 2.x中的范围（128）@JulienPalard中，必须手动解码

str

对象才能获得unicode字符串。修正2.x:

[etc.]argv[1]。解码（“utf-8”）。编码（“原始”[etc.]

。在3.x

str

中，str已经是unicode，解释器会自动从系统的默认编码对其进行解码。修复3.x:print周围的括号，使用python3运行。当字符串仅包含代码点0-255时，它始终是相同的。不同之处在于上面的字符；原始unicode\u转义将转义，例如。\u1234，其中latin1将抛出UnicodeEncodeError（解码具有对称性差异——原始unicode解释器解码\u1234解释器，latin1没有，但它只是在这里编码。）它们在这里是等价的，但我还是坚持使用拉丁语1，因为这与转义无关，拉丁语1是一种更为广泛理解的编码方式。感谢格伦，午夜后的反斜杠让我的大脑变成了一个南瓜：-）你没有得到

AttributeError:'str'对象没有属性“decode”

？

>>> original = "Rafa\xc3\x85\xc2\x82"
>>> first_decode = original.decode('utf-8')
>>> as_chars = ''.join([chr(ord(x)) for x in first_decode])
>>> result = as_chars.decode('utf-8')
>>> result
u'Rafa\u0142'

>>> weird = u'Rafa\xc5\x82'
>>> weird.encode('latin1').decode('utf8')
u'Rafa\u0142'
>>>