为什么 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 的“窄构建”，它表示 unicode，只有 16 位用于 unicode 的内部编码，并表示 unicode 代码点以上 2**16 作为字符对（这将解释len(u'\U00010000') == 2。

在 OS X 上尝试unichr(0x10000)，看看您是否收到有关窄构建的错误。另请参阅What encoding do normal python strings use?，尤其是 IVH 的回答。

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