为什么按照 PEP 100 中的描述实现 Python Unicode 内部格式？答案

【问题标题】：Why was the Python Unicode internal format implemented as described in PEP 100?为什么按照 PEP 100 中的描述实现 Python Unicode 内部格式？
【发布时间】：2011-11-05 20:53:08
【问题描述】：

http://www.python.org/dev/peps/pep-0100/

PEP 100 声明内部格式 Python Unicode 保存 UTF-16 编码，但将值寻址为 UCS-2（或使用标志 --enable-unicode=ucs4 编译时的 UCS-4）。

为什么不选择 UTF-16（可变长度格式）而不是 UCS-2（固定长度）？

虽然这两种编码基本相同，但 UTF-16 在 PEP-100 发布时（2000 年 3 月）已经 4 岁了。 Python Unicode 是否旨在解决向后兼容性问题？

我真的很好奇为什么 Python 的内部格式是使用这种（看似）混合方法在内部存储编码数据来实现的？

问我的问题的更好方法可能是：是否有人引用或链接来自官方文档，具体说明为什么 PEP 100 选择将 UTF-16 视为 UCS-2 而不是使用 UTF-16？

【问题讨论】：

更好的是，为什么不使用 UTF-8 或 UTF-32？
我也希望看到 UTF-8，但我的猜测是，自从 RFC 2279 ietf.org/rfc/rfc2279.txt 未发布以来，当时 UTF-8 可能有点过于前沿直到 1998 年 1 月。我对 UTF-32 知之甚少，但我怀疑它不是出于存储问题而选择的。不错的评论:)
注意：使用 UTF-8 处理长度、索引和切片的字符术语比 UTF-16 更困难且效率低下。使用 UTF-8 作为 internal 格式（相对于 external 格式）不是一个好主意。
@eryksun 不。我在问为什么选择 UCS-2 而不是 UTF-16。虽然我很想了解更多关于“为什么它不是为了正确处理 UTF-16 代理对而编写的”。
@JohnMachin 为什么 utf-8 “使用 UTF-8 在长度、索引和切片方面更加困难和低效”？

标签： python unicode encoding utf-16 ucs2

【解决方案1】：

进一步阅读：“UCS-2 和 UTF-16 对于所有当前定义的 Unicode 字符点都是相同的”……这在 2000 年编写 PEP 时是正确的。初始实现仅涵盖 BMP（前 64K 代码点）。

【讨论】：

我阅读并理解它们在代码点方面基本相同，但是如果它们对于所有代码都相同，为什么要选择旧的 UCS-2 而不是新的 UTF-16写作时的要点？固定长度格式相对于可变长度格式的优势是什么？
固定宽度更容易处理。此外，Unicode 是并且一直是一个移动的目标。采用已经存在了几年的 unicode 功能是有意义的。
@tchrist 我在这里的目的不是讨论或批评实施的优点。我同意你的前两句话以及你关于代理的其他陈述，但你对 Java 和 Python 的攻击对回答我的问题没有任何帮助。你的 cmets 中的消极情绪也会影响你所说的实际上可能是真的事情的可信度。太糟糕了。
@JohnMachin 感谢您的提示。我会看一下，看看我是否能够带回任何有用的信息来添加这里。
@tchrist：可能是被一个使用 Python 和/或 Java 以错误方式处理 XML 的糟糕编码器烧毁了。 Python 和 Java 可以并且确实可以处理 BMP 之外的所有代码点。许多 Linux 系统都带有准备这样做的 Python。我在 Mac OS X 上编译了 Python 来处理 BMP 之外的代码点。请停止拖钓。