Python/Django中的Unicode与UTF-8混淆？

我在Django教程中偶然发现了这段话:

Django模型有一个默认的str()方法,它调用unicode()并将结果转换为UTF-8字节串.这意味着unicode(p)将返回一个Unicode字符串,str(p)将返回一个普通字符串,其字符编码为UTF-8.

现在,我很困惑,因为afaik Unicode不是任何特定的表示,那么Python中的"Unicode字符串"是什么？这是否意味着UCS-2？谷歌搜索出现了这个"Python Unicode教程",大胆地说明了这一点

Unicode是一种双字节编码,涵盖了世界上所有常见的书写系统.

这是完全错误的,还是它？我已经多次被字符集和编码问题搞糊涂了,但在这里我很确定我正在阅读的文档很混乱.当有人给我一个"Unicode字符串"时,是否有人知道Python中发生了什么？

1> bobince..：

---

什么是Python中的"Unicode字符串"？这是否意味着UCS-2？

Python中的Unicode字符串内部存储为UCS-2(固定长度16位表示,几乎与UTF-16相同)或UCS-4/UTF-32(固定长度32位表示).这是一个编译时选项; 在Windows上它始终是UTF-16,而许多Linux发行版为他们的Python版本设置了UTF-32('宽模式').

您通常不应该关心:您将在字符串中看到Unicode代码点作为单个元素,并且您将不知道它们是否存储为两个或四个字节.如果您使用的是UTF-16版本,并且需要处理Basic Multilingual Plane之外的字符,那么您将会做错,但这仍然非常罕见,真正需要额外字符的用户应该编译宽版本.

简单的错,或者是吗？

是的,这是非常错误的.公平地说,我认为教程相当陈旧; 如果不是Unicode 3.1(引入基本多语言平面之外的字符的版本),它可能会预先列出宽的Unicode字符串.

Windows的习惯是使用术语"Unicode"来表示特别是NT内部使用的UTF-16LE编码,还有另外一个混淆源.来自Microsoftland的人可能经常复制这种有些误导性的习惯.

---

窄Unicode构建中的Python Unicode字符串的长度是UTF-16*代码单元*的数量,而不是实际的Unicode代码点.截断任意索引的截断和其他切片选项确实可以将代理对分成两半,结果是一些丢失/替换的字符.在一个狭窄的构建中,`unichr(0x10345)`只是失败; `len(u'\ U00010345')`是'2`.这是您为与Win32 UTF-16LE API轻松交互而支付的价格.大多数其他环境使用UCS-4,它不会遇到任何此类问题.

2> Hanno Fietz..：

---

同时,我做了一个精确的研究,以验证Python中的内部表示是什么,以及它的限制是什么." Python中的Unicode真相 "是一篇非常好的文章,直接引用Python开发人员的话.显然,内部表示是UCS-2或UCS-4,具体取决于编译时开关.所以乔恩,它不是UTF-16,但你的回答无论如何都让我走上正轨,谢谢.