为什么UTF-16在UCS数据库中有保留范围？
UTF-16只是一种使用一个或两个unsigned 16-bits表示字符标量值的方法，这些值的布局不应与字符标量值相关，因为我们应该应用一些算法来获取实际字符来自这种表示的标量值。
假设保留范围D800-DBFF和DC00-DFFF未在UCS数据库中保留，并且还有另一种UTF-16表示，可以表示单个范围0-7FFF中的所有字符unsigned 16-bits当高位设置然后另一个
其余的位跟随16位，对于字节顺序标记，我们将保留两个可能的值，就是它。
如果我错了，你可以向我解释一下吗。
由于
答案 0 :(得分：6)
您提出的方案效率低于目前的代理对方案，这是一个问题。
目前，只有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-0xFFFF，那么某些方面可能会更容易，但到那时已经太晚了。
答案 1 :(得分：0)
保留代码点D800-DFFF，因为它们在当前的UTF-16编码方案中不能表示为自己的代码。由于它们属于0000-FFFF范围，因此它们将使用一个UTF-16代码单元按原样编码。如果允许这样做，当处理器通过UTF-16序列解码/寻找转发并遇到D800-0xDBFF范围内的代码单元时，则必须确定该代码单元是代表独立代码点还是代理代码的开始对。唯一的方法是查看下一个代码单元，看它是否在DC00-DFFF范围内。类似于解码/向后搜索序列时，如果遇到DC00-DFFF范围内的代码单元，请查看下一个代码单元以查看它是否在D800-DBFF范围内。这使解码/搜索更难，更容易出错。
为实际字符使用而取消保留代码点DB00-DFFF将需要对UTF-16编码方案进行逻辑更改，以便以不会导致歧义的不同方式转义这些特定代码点。但是，在当前的编码方案下，AFAIK不可能进行这样的改变。所以他们永远保留。