为什么Mac OS X python与CentOS Linux python对字符串中的\ U转换有不同的解释？

Question

两个python解释器会话.第一个来自CentOS上的python.第二个来自Mac OS X 10.7上的内置python.为什么第二个会话从\ U转义序列创建长度为2的字符串,然后错误输出？

$ python
Python 2.6.6 (r266:84292, Dec  7 2011, 20:48:22) 
[GCC 4.4.6 20110731 (Red Hat 4.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> u'\U00000020'
u' '
>>> u'\U00000065'
u'e'
>>> u'\U0000FFFF'
u'\uffff'
>>> u'\U00010000'
u'\U00010000'
>>> len(u'\U00010000')
1
>>> ord(u'\U00010000')
65536

---

$ python
Python 2.6.7 (r267:88850, Jul 31 2011, 19:30:54) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
>>> u'\U00000020'
u' '
>>> u'\U00000065'
u'e'
>>> u'\U0000FFFF'
u'\uffff'
>>> u'\U00010000'
u'\U00010000'
>>> len(u'\U00010000')
2
>>> ord(u'\U00010000')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: ord() expected a character, but string of length 2 found

Answer 1

我对此完全不确定，但可能你的 Mac OS X 系统使用了 python 的“窄构建”，它表示只有 16 位用于 unicode 内部编码的 unicode，并表示高于 2* 的 unicode 代码点*16 作为字符对（这可以解释len(u'\U00010000') == 2.

在 OS X 上尝试一下unichr(0x10000)，看看是否出现有关窄版本的错误。另请参阅普通 python 字符串使用什么编码？，特别是IVH的回答。

即使系统上的默认 python 使用窄构建，也可以重新编译 python 以使用宽构建。