只是谨慎的一句话：用list( '...' )（PY 3中;这是u'...'对的Py2）将 不会 在一般意义上，给你 个字符 的Unicode字符串; 相反，它很可能会导致一系列16位代码点。对于所有“狭窄”的cpython构建都是如此，它占了当今绝大多数python安装的比例。
当在1990年代首次提出unicode时，有人建议16位足以满足通用文本编码的所有需求，因为它支持从128个代码点（7位）和256个代码点（8位）转移高达65,536个代码点。然而，很快就意识到那是一厢情愿的想法；如今，在Unicode版本5.2中定义了大约100‘000个代码点，还有数千个代码点有待纳入。为了使之成为可能，unicode必须从16位移到（概念上）32位（尽管它没有充分利用32位地址空间）。
为了保持与以unicode仍为16位的假设为基础的软件的兼容性，设计了所谓的代理对，其中使用了来自特定指定块的两个16位代码点来表示65‘536以上的代码点，即unicode称为“基本多语言平面”或BMP，由于它们相对难以捉摸且经常给文本处理和编码领域的人们带来麻烦，因此被戏称为该编码的“星空”平面。
现在，尽管狭窄的cpython在某些情况下可以透明地处理代理对，但在其他情况下它仍然做不到正确的事情，字符串拆分是较麻烦的情况之一。在狭窄的python版本中list( 'abc大
602392714
清零编程群