UTF-32的最后一位已归零

这可能是不正确的,取决于你如何计算。通常我们从左开始计数,因此UTF-32的高位(即第一位)将为零

这也不正确。UTF-16使用它的所有位。只是范围[0xD8000xDFFF]是为 UTF-16 surrogate pairs 因此,这些值将不会被分配任何字符,也不会出现在UTF-32中。如果需要使用UTF-16对BMP之外的字符进行编码,则将使用这些值

实际上,Unicode仅限于U+10FFFF是因为UTF-16,即使UTF-8和UTF-32本身能够分别表示U+7fffff和U+FFFFFFFF。使用代理项对使得无法在UTF-16中编码大于0x10FFFF的值

看见 Why Unicode is restricted to 0x10FFFF?

是否有一种16位编码,它将所有的位组合映射到某个值,最好是UTF的子集,比如7位的ASCII?

UTF isn't a character set but a way to encode Unicode code points

在UTF-16出现之前,Unicode是一个固定的16位字符集,用 UCS-2 . 因此UCS-2可能是最接近的,它只编码BMP中的字符。其他固定的16位非Unicode字符集也有一种编码,它将所有的位组合映射到某些字符

但是你为什么要这样?UCS-2早就被弃用了。一些旧的工具和经验不足的程序员仍然暗示Unicode总是16位长,这是正确的,将打破现代文本处理

还要注意的是,并非0xFFFF以下的所有值都被赋值,因此没有编码可以将每一个16位值映射到一个Unicode码位

• The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
• What is a "surrogate pair" in Java?