Windows文档重复引用UNICODE和UTF-16。我知道这是file system的谎言（即它接受wchar_t的任何序列）和other documentation表明无效的UTF-16仅仅是“未定义的。所以我很困惑。我能否假设非文件系统API将返回有效的UTF-16？或者我应该假设它不会？
编辑：由于它引起了一些混乱，我将解释几个术语
UTF-16在Unicode specification (pdf)中定义。 FAQ明确表示UTF-16是什么形式和形式不正确：
是否有任何16位值无效？
未配对的代理在UTF中无效。这些值包括D80016到DBFF16范围内的任何值，后面没有DC0016到DFFF16范围内的值，或者DC0016到DFFF16范围内的任何值都没有在D80016到DBFF16范围内的值之前。
那些非人物呢？它们无效吗？
一点也不。非字符在UTF中有效，必须正确转换。有关非字符的定义和使用的更多详细信息，以及它们在每个UTF中的正确表示，请参阅Noncharacters FAQ。
所以唯一的限制是一个领先的代理人必须跟随一个尾随的代理人（也就是一个代理人对）。应该按原样接受所有其他wchar_t（16位）值。
正如Ben Voigt的回答中提到的那样。这是一个现在过时的编码，允许任何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。