16预留码点

Question

为什么UTF-16在UCS数据库中有一个预留范围？

UTF-16只是一种用一两个unsigned 16-bits表示字符标量值的方法，这些值的布局不应该与字符标量值有关，因为我们应该应用一些算法从这种表示中得到实际的字符标量值。

让我们假设保留范围D800-DBFF和DC00-DFFF在UCS中没有保留，并且UTF-16的另一种表示形式可以用单个unsigned 16-bits表示range 0-7FFF中的所有字符，并且当设置高阶位时，另一个16位跟着其余的位，对于字节顺序标记，我们将保留两个可能的值，仅此而已。

如果我错了，你能给我解释一下吗？

谢谢

Answer 1

您提出的方案比当前的代理对方案效率低，这是一个问题。

目前，只有0xD800-0xDFFF (2048个代码单元)作为普通字符“超出范围”，只剩下63488个代码单元映射到单个字符。根据您的建议，0x8000-0xFFFF ( 32768 )代码单元是为多代码单元代码点保留的，只剩下其他32768个代码单元代码点。

我不知道目前在基本的多语言平面上指定了多少个代码点，但是如果它超过32768，当然它还可以增长，我也不会感到惊讶。一旦超过32768，就会有更多的字符需要在您的建议下表示两个代码单元，而不是目前的UTF-16。

现在我同意，所有这些都不需要UCS包含一个保留的范围(在某些方面，这是一个丑陋的含义组合)--但是这样做使得将UTF-16映射到UCS很简单(在代码中)，同时仍然保持了一个非常有效的解决方案。

这样做的缺点很少--在UCS中有大量的空间，所以这不像保留这个小块意味着我们将有更少的空间用于未来的扩展。

假设

这一点是有根据的猜测。你可以做研究，找出哪些字符被使用在哪些版本的Unicode，但我相信这至少是一个合理的解释。

使用这个特定块的真正原因可能是历史原因--在很长一段时间里，Unicode实际上只有16位，所有的东西.字符已在上限范围内分配(您的方案认为不允许的部分)。通过采用以前没有分配的2048个值块，所有以前有效的UCS-2序列都被保留为具有相同含义的有效UTF-16序列，同时将UCS的范围扩展到BMP以外。如果范围是0xF800-0xFFF，那么某些方面可能会更容易一些，但到那时已经太晚了。

Answer 2

Codepoint D800-DFFF是保留的，因为它们在当前的UTF-16编码方案中不能表示为它们自己。由于它们属于0000-FFFF范围，它们将按照使用UTF-16编码单元的方式进行编码。如果允许这样做，当处理器通过UTF-16序列解码/寻找转发，并在D800-0xDBFF范围内遇到一个代码单元时，它必须决定该编码单元是代表独立的编码点还是代理项对的开始。要做到这一点，唯一的方法是查看下一个代码单元，看看它是否在DC00-DFFF范围内。类似地，当解码/通过序列向后查找时，如果遇到DC00-DFFF范围内的代码单元，请查看下一个代码单元是否在D800-DBFF范围内。这使得解码/寻找变得更加困难，而且更容易出错。

对于实际的字符使用，不保留代码点DB00-DFFF将需要对UTF-16编码方案进行逻辑更改，以不引起歧义的不同方式对这些特定的编码点进行转义。但是，在目前的编码方案下，这种改变是不可能的，AFAIK。所以他们会永远保留下来。