我一直在 Windows 中使用“unicode 字符串”……我已经了解了 Unicode（例如毕业后）。然而，Win32API 非常松散地提到“unicode”总是让我感到困惑。特别是，MSN 提到的“unicode”变体是 UTF-16（尽管“宽字符”术语来源于它曾经是 UCS-2，而不是 Unicode）。但是，它几乎没有提到 Unicode 规范化。
MSN 有几页关于Unicode和Unicode 规范化形式以及更改规范化形式的功能。规范化页面甚至说：
Win32 和 .NET Framework 支持所有四种规范化形式。
但是，我在文档中的任何地方都没有找到 Win32 API 使用（或理解）什么规范化形式。
问题1：默认情况下用户输入（例如Edit控件）和转换使用什么规范化形式MultiByteToWideChar()？
问题 2：传递给 Win32API 函数的字符串必须采用特定的规范化形式，还是内核和文件系统规范化不可知？
来自 MSDN 文章Using Unicode Normalization to Represent Strings。
Windows、Microsoft 应用程序和 .NET Framework 通常使用普通输入法以 C 格式生成字符。对于 Windows 上的大多数用途，形式 C 是首选形式。例如，形式 C 中的字符是由 Windows 键盘输入产生的。但是，从 Web 和其他平台导入的字符可以将其他规范化形式引入数据流中。
更新：我已经包含了一些与问题 #2 相关的具体细节。
关于文件系统，不需要规范化 - 基于文章Naming Files, Paths, and Namespaces。
无需对路径和文件名字符串执行任何 Unicode 规范化以供 Windows 文件 I/O API 函数使用，因为文件系统将路径和文件名视为不透明的 WCHAR 序列。您的应用程序所需的任何规范化都应在对相关 Windows 文件 I/O API 函数的任何调用之外执行，并牢记这一点。
对于 SQL Server，不需要规范化——数据保存在数据库中时也不需要规范化。也就是说，在比较字符串时，SQL Server 2000在索引内部使用自己的字符串规范化机制；但我找不到关于那是什么的具体细节。SQL Server 2005 的一篇文章也指出了相同的情况。
SQL Server 7.0 的一个重要变化是提供了一个独立于操作系统的字符串比较模型，这样从 Windows 95 到 Windows 2000 的所有操作系统之间的排序规则都是一致的。此字符串比较代码基于 Windows 2000 用于其自己的字符串规范化的相同代码，并且在所有计算机和所有 SQL Server 版本中都被封装为相同。
首先，感谢一个很好的问题。我在Michael Kaplan 的博客中找到了答案：
但是由于 Windows 上的所有文本输入方法都倾向于使用相同的规范化形式（形式 C），...