如何审核我的 Windows 应用程序以进行正确的 Unicode 处理？

Question

我不能使用预打包的 Unicode 字符串库，例如 ICU，因为它们会将二进制文件的大小扩大到疯狂的程度（这是一个 200k 的程序；ICU 是 16MB+！）。

我已经对所有内容使用了内置的 wchar_t 字符串类型，但我想确保在对字符串进行迭代或类似的事情方面我不会做任何愚蠢的事情。

是否有像 Fuzzers 这样的工具用于安全性但用于 Unicode？也就是说，在我的代码中抛出基本多语言平面之外的字符，并确保将事情正确处理为 UTF-16？

（哦，显然跨平台解决方案是可行的，尽管大多数跨平台的东西必须同时支持 UTF-8 和 UTF-16）

编辑：还要注意比 UTF-16 代理对不太明显的东西——比如重音符号！

Answer 1

错误的答案

使用WM_UNICHAR，它处理UTF-32并且可以处理Unicode Supplementary Plane字符。

虽然这几乎是真的，但完整的事实看起来像这样：

1. WM_UNICHAR 是为 ANSI Windows 设计的用于接收 Unicode 字符的 hack。创建一个 Unicode 窗口，您将永远不会收到它。
2. 创建一个 ANSI 窗口，您会惊讶地发现它仍然不能按预期工作。需要注意的是，当创建窗口时，您会收到带有0xffff 的WM_UNICHAR，您必须通过返回1 做出反应（默认窗口过程将返回0）。如果不这样做，您将永远不会再看到WM_UNICHAR。干得好，官方文档没有告诉你。
3. 在一个出于神秘原因不支持WM_UNICHAR 的系统（例如我的 Windows 7 64 系统）上运行您的程序，即使您正确执行所有操作，它仍然无法运行。

理论上正确答案

没有什么需要审计或注意的。

在定义UNICODE 的情况下编译，或使用“W”函数显式创建窗口类和窗口，并使用WM_CHAR，就好像这是最自然的事情一样。就是这样。这确实是最自然的事情。

WM_CHAR 使用 UTF-16（除非它不使用，例如在 Windows 2000 下）。当然，单个 UTF-16 字符不能表示 BMP 之外的代码点，但这不是问题，因为您只需得到 两个 WM_CHAR 包含代理对的消息。它对您的应用程序完全透明，您不需要做任何特别的事情。任何接受宽字符串的 Windows API 函数也很乐意接受这些代理项。
唯一需要注意的是，现在字符串的字符长度（显然）不再只是 16 位字的数量。但无论如何，这是一个错误的假设。

悲伤的真相

实际上，在许多（大多数？全部？）系统上，您只会收到一条带有wParam 的WM_CHAR 消息，其中包含密钥代码的低16 位。这对于 BMP 中的任何东西都很好，但在其他方面很糟糕。

我已经通过使用 Alt 键盘代码和创建自定义键盘布局来验证这一点，该布局在 BMP 之外生成代码点。无论哪种情况，都只会收到一个WM_CHAR，其中包含字符的低16 位。高 16 位被简单地丢弃。

为了让您的程序在 Unicode 上 100% 正确运行，您显然必须使用输入法管理器 (ImmGetCompositionStringW)，这很麻烦，而且文档记录不充分。就我个人而言，这只是意味着：“好吧，搞砸了”。但是，如果您对 100% 正确感兴趣，请查看使用 Scintilla (link to line) 的任何编辑器的源代码，它可以完美地做到这一点。

Answer 2

需要检查的一些事项：

• 确保您处理的是WM_UNICHAR，而不是WM_CHAR：

  WM_UNICHAR 消息与WM_CHAR 相同，但它使用 UTF-32。它旨在将 Unicode 字符发送或发布到 ANSI 窗口，它可以处理 Unicode 补充平面字符。

• 不要不假设第 i^th 字符位于索引 i。显然不是，如果你碰巧使用这个事实，比如说，把一根绳子分成两半，那么你可能会把它搞砸了。

• 不要仅仅因为字符数组的长度为 N，就告诉用户（在状态栏或其他地方）用户有 N 个字符。