据说here UTF-16的最大代码点为10FFFF
此外，该页面上写着
BMP字符需要一个16位代码单元来处理或存储。
但是位代表10FFFF是
0001 0000 1111 1111 1111 1111
我们发现它占用超过15位的16位wchar_t
（允许实现仅支持＆gt; = 0值的宽字符，与wchar_t的签名无关）
16位wchar_t的真实最大代码点是什么？
答案 0 :(得分：4)
这里说UTF-16的最大代码点是10FFFF
是的，但你错误地解释了你从中抽取的表格。
U + 10FFFF是最大的Unicode 代码点值。 UTF-16本身不是Unicode，它是使用 16位代码单元的Unicode代码点的编码（正如UTF-8是编码使用8位代码单元）。正如您所说，16位不足以表示Unicode代码点的全部范围。 Unicode代码点的UTF-16编码U + 0000 - U + FFFF只需要1个代码单元，但代码点U + 10000 - U + 10FFFF的编码需要2个代码单元一起工作，称为＆＃34;代理对＆＃34 ;. UTF-16是UCS-2的后续版本，UCS-2是Unicode的原始16位编码，但它只能编码代码点U + 0000 - U + FFFF。 UTF-16向后兼容UCS-2，但添加代理对允许UTF-16支持所有Unicode代码点。
设计UTF-16，以便为此目的保留可以形成代理对的代码单元值。它们不能被误解为常规字符，即使它们看起来不配对（因此必须是无效的代码序列）。
另请注意，对于C实现来说，将UTF-16（或UTF-8）作为其字符集＆＃34;作为其代码，有点滥用，尽管这是一种常见的滥用行为单位并不都与Unicode字符对应1-1。或者，至少它们对应的字符必须被解释为它们所代表的代码单元。它是一种务实的方法，可以有效地表示大范围内的角色。
此外，该页面上写着
BMP字符需要一个16位代码单元来处理或存储。
这也是事实。您显然忽略了BMP（基本多语言平面，代码点U + 0000 - U + FFFF）字符是所有Unicode字符的子集这一事实。事实上，其中1/17，或者更少，取决于你的数量。事实上，他们的代码点值都可以用16位表示（即在一个UTF-16代码单元中），实际上可以作为该子集的定义。
我们看到它占用超过15位的16位wchar_t（一个 允许实现支持＆gt; = 0值的宽字符 只有，与wchar_t的签名无关。
不，正如我在one of your other recent questions的回答中所述。该标准对C实现没有任何限制，只支持非负代码点值。这只是所有当前广泛使用的编码字符集的代码点分配的事实上的状态。符合wchar_t签名的C实现可以提供一个字符集，其中某些扩展字符具有负的对应wchar_t值。
16位wchar_t的最大代码点是什么？
这与上述任何内容无关。事实上，它没有多大意义。代码点值是（编码）字符集的特征，而不是任何C数据类型的特征。它们是与该集支持的字符对应的数字。
如果C实现声称提供UTF-16作为支持的字符集，那么它的wchar_t必须至少有16个值位，因为该类型必须能够代表所有UTF-16代码单位价值。如果该类型总共只有16位，那么它们必须都是值位，使得类型必须是无符号的，并且能够支持最多0xFFFF的值。