WinApi是否曾经验证过UTF-16？

Question

Windows文档重复引用了UNICODE和UTF-16。我知道这是file system的谎言（即它接受wchar_t的任何序列），并且other documentation表示无效的UTF-16只是“未定义。所以我很困惑。可以我假设非文件系统API会返回有效的UTF-16，还是应该不会？

编辑：由于引起一些混乱，我将解释一些术语

---

UTF-16

UTF-16在Unicode specification (pdf)中定义。 FAQ明确说明了什么是格式不正确的UTF-16：

  

是否有无效的16位值？

     

未配对的代理在UTF中无效。这些值包括D800 ₁₆ 到DBFF ₁₆ 范围内的任何值，而不是DC00 ₁₆ 到DFFF _{16 < / sub>或DC00 16 到DFFF 16 范围内的任何值，但不带D800 16 到DBFF 范围内的值> 16 。}

     

非字符呢？它们无效吗？

     

一点也不。非字符在UTF中有效，必须正确转换。有关非字符的定义和使用以及它们在每个UTF中的正确表示的更多详细信息，请参见Noncharacters FAQ。

因此，唯一的限制是前导代理必须后面跟随代理（又称代理对）。所有其他wchar_t（16位）值都应按原样接受。

---

UCS-2

如Ben Voigt的回答所述。这是一种过时的编码，允许任何wchar_t值。由于它与UTF-16的限制不同，因此UCS-2字符串的子集是无效的UTF-16。

Answer 1

Windows宽字符是任意的16位数字（在Unicode标准协会清除该符号之前，以前称为“ UCS-2”）。因此，您不能假定它将是有效的UTF-16序列。 （MultiByteToWideChar是一个值得注意的异常，它仅返回UTF-16）

只有在生成字符串的程序使用UTF-16约定的情况下，解码为UTF-16才有意义，但不能保证如此，就像不能保证8位字符包含UTF-8一样。