Windows 文档反复引用了 UNICODE 和 UTF-16。我知道这是文件系统的谎言(即它接受任何wchar_t序列(，其他文档表明无效的 UTF-16 只是"未定义"。所以我很困惑。我可以假设非文件系统 API 将返回有效的 UTF-16 吗？还是我应该假设它不会？
编辑：由于它引起了一些混乱，我将解释一些术语
UTF-16
UTF-16 在 Unicode 规范 (pdf( 中定义。常见问题解答清楚地说明了什么是格式正确的 UTF-16，什么是格式不正确的 UTF-16：
是否有任何 16 位值无效？
未配对的代理项在 UTF 中无效。其中包括 D80016到 DBFF 16 范围内未后跟 DC00 16 到 DFFF 16 范围内的值的任何值，或 DC00 16 到 DFFF 16 范围内未跟 D800 16 到 DBFF16范围内值的任何值。
非字符呢？它们无效吗？
一点也不。非字符在 UTF 中有效，必须正确转换。有关非字符的定义和使用以及它们在每个 UTF 中的正确表示的更多详细信息，请参阅非字符常见问题解答。
因此，唯一的限制是前导代理项后必须跟着尾随代理项(又名代理项对(。所有其他wchar_t(16 位(值应按原样接受。
UCS-2
正如本·沃格特的回答中提到的。这是一种现已过时的编码，允许任何wchar_t值。由于它没有与 UTF-16 相同的限制，因此 UCS-2 字符串的子集是无效的 UTF-16。
Windows 宽字符是任意的 16 位数字(以前称为"UCS-2"，在 Unicode 标准联盟清除该表示法之前(。 因此，您不能假设它将是一个有效的 UTF-16 序列。 (MultiByteToWideChar是一个值得注意的例外，它只返回 UTF-16(
仅当生成字符串的程序使用 UTF-16 约定时，解码为 UTF-16 才有意义，但不能保证这一点，就像不能保证 8 位字符包含 UTF-8 一样。