wchar_t 对 Windows API 有用了吗？答案

【问题标题】：Is wchar_t useful for the Windows API anymore?wchar_t 对 Windows API 有用了吗？
【发布时间】：2016-10-02 06:09:40
【问题描述】：

当我在 C 或 C++ 中#include <windows.h> 时，我不得不决定字符的格式，其中TCHAR 等于char 或wchar_t。

我已经环顾了很多地方，就this one 之类的帖子或this 之类的网站而言，wchar_t 的事情在很久以前就出现在 UTF8 之前，出于各种原因，在现代编程中并不是一个特别好的 Unicode 解决方案。然而，这些并没有说明已经在 wchar_t 中运行的现有系统的支持。

所以我的问题是，我应该使用哪一个？如果我使用普通的旧char，这是否会在未来被MS 抛弃，因为归根结底，API 的wchar_t 版本更新？或者如果我使用wchar_t，让我的代码在其他现代平台上运行会很痛苦吗？这些现代平台后来在UTF8 中使用普通的旧char 开发？

【问题讨论】：

Windows 中的 Unicode 是 wchar_t。不推荐使用 ANSI API/char，您应该为所有新的 Windows 应用程序使用 Unicode/wchar_t API。
Windows 是 UTF16，对于 MS VC 意味着 wchar_t，进一步阅读：msdn.microsoft.com/en-us/library/c426s321.aspx
另见：stackoverflow.com/questions/3298569/…、stackoverflow.com/questions/1311953/…、stackoverflow.com/questions/10202969/…、stackoverflow.com/questions/24044676/… 和 stackoverflow.com/questions/166503/utf-8-in-windows
stackoverflow.com/questions/14132260/… 肯定是相关的，但不是重复的。评论@Code Gray 评论references 这也是相关的。
更好的问题是：我应该继续使用TCHAR 还是只使用WCHAR？如前所述，不推荐使用 ANSI/char 函数。 WCHAR/wchar_t 是现在的标准，不管 UTF16 的优点或缺点。

标签： c++ c windows winapi unicode

【解决方案1】：

这绝对是有用的，也是正确处理任意路径名的唯一方法（因为它们允许包含宽字符）。 UTF-16 的选择经常受到批评（有充分的理由），但这无关紧要。操作系统使用它，所以你也必须使用它。您可以做的最好的事情是始终调用 WINAPI 函数的宽字符版本（例如 OpenFileW）并在程序内部使用 UTF-8。是的，这意味着来回转换，但这通常不是性能瓶颈。

我强烈推荐UTF-8 Manifesto，它客观地解释了为什么这是最好的方法。

便携性、跨平台互操作性和简单性更重要比与现有平台 API 的互操作性更重要。所以最好的方法是到处使用 UTF-8 窄字符串并转换它们在使用不支持 UTF-8 的平台 API 时来回切换并接受宽字符串（例如 Windows API）。性能很少是一个处理接受字符串的系统 API 时的任何相关问题（例如 UI 代码和文件系统 API），并且有一个很大的优势在应用程序的其他地方使用相同的编码，所以我们看到没有充分的理由不这样做。

【讨论】：

为什么不在整个程序中使用 UTF-16？如果将 UTF-8 的每个实例都替换为 UTF-16，则 UTF-8 宣言中的那句话读起来会是一样的，所以它既不是支持也不是反对的论据，只是一个/任何标准的论据。
当然，所有标准都有缺点。自然的解决方案是使用您的目标平台本机实现的任何一个。如果你真的在编写跨平台代码，你需要选择一个并为你的公共 API 标准化。但是大多数人并没有编写真正的跨平台代码，并且这些问题与您调用特定于平台的 API 的后端无关。 “UTF-8 宣言”充满了毫无根据的声明和大量假设。任何处理平台 API 的子系统都应该遵守该标准。必要时编写翻译层。
“因为 UTF-8 客观上更好，因为非 MS 操作系统使用这种编码，而网络使用这种编码。” - 我不明白你怎么能得出结论“在你的程序内部使用UTF-8”。当然，没有任何 Linux 发行版会关心你的 Windows 程序在内部做什么。在 Windows 上，通常最好在内部保留所有 UTF-16，并在数据进入/离开应用程序（文件、管道、套接字等）时从/转换为 UTF-8。
@rubenvb：还有很多的差异（请参阅 Naming Files, Paths, and Namespaces，查看其中的一些列表），并且某些 Windows 文件 I/O 函数不会将/ 翻译成`\`，用户代码可以请求不翻译。如果这还不够，NTFS 甚至不关心有效的 UTF-16 序列。只要它是 16 位的偶数倍，它就会愉快地使用你扔给它的任何东西。
如果您正在处理任意路径名，则转换为 UTF-8 并返回是危险，原因 IInspectable 已经指出。如果您坚持这样做，您需要确保使用无损转换 - 一种可以使无效的 UTF-16 序列保持完整 - 并注意 Microsoft API Unicode 函数不是无损的，可能是因为微软希望他们遵循这些标准。大多数库也可能会遵循这些标准，因此您可能必须推出自己的转换器以确保安全。