我应该从 Windows 代码中消除 TCHAR 吗？答案

【问题标题】：should I eliminate TCHAR from Windows code?我应该从 Windows 代码中消除 TCHAR 吗？
【发布时间】：2011-09-13 00:29:54
【问题描述】：

我正在修改一些非常古老（10 年）的 C 代码。该代码在 Unix/Mac 上使用 GCC 编译，并在 Windows 上使用 MinGW 进行交叉编译。目前有 TCHAR 字符串贯穿始终。我想摆脱 TCHAR 并改用 C++ 字符串。是否仍然需要使用 Windows 范围的功能，或者我现在可以使用 Unicode 和 UTF-8 来做所有事情吗？

【问题讨论】：

相关：stackoverflow.com/questions/234365/is-tchar-still-relevant
不建议在 C 代码中使用 C++ std::wstring。
我已经成功地使用TCHAR 获得了几个在 Windows、Linux 和 Solaris 下编译的小型工具，每个工具都使用其原生 Unicode 格式（UTF-16 或 UTF-8）。但它确实需要为 *nix 平台创建自己的 tchar.h。
事实上，这就是我们最终所做的。

标签： c winapi unicode utf-8 tchar

【解决方案1】：

Windows 仍然使用 UTF16，而且很可能会一直使用。因此，您需要使用 wstring 而不是 string。 Windows API 不直接提供对 UTF8 的支持，主要是因为 Windows 在 UTF8 发明之前就支持 Unicode。

因此编写可在 Windows 和 Unix 平台上编译的 Unicode 代码是相当痛苦的。

【讨论】：

Windows 使用了UCS-2 和UTF-16 的可怕混合。使用 BMP 之外的字符有点成问题。
字符数表示 wchars 的数量。问题在于函数是否返回了代码点的数量。但他们没有。
@ben 你们都搞混了。那些功能很好。字符数正是您分配缓冲区所需的。如果函数使用代码点的数量，这只会是一个问题。他们没有。
@David：从字符到码点有 1:1 的映射关系（反之则不然，有几个码点不是字符）。一个字符的编码可能需要多个char，在UTF-8的情况下，或多个wchar_t，在UTF-16的情况下。一个字符是一个wchar_t 的假设适用于 (1) 32 位 wchar_t，这在 Windows 上不是这种情况，或者 (2) UCS-2。这是使用单词 character 的方式，就像它在 Unicode 文献中使用的那样。当 MS 以不同的方式使用这个词时，它们会造成可怕的混乱，这仅适用于 UCS-2。
@ben 字符是一个加载项。但是 MS 的意思是 TCHAR。

【解决方案2】：

是的，现在编写非 unicode 应用程序是在自取其辱。只需在任何地方使用广泛的 API，您以后就不必为此哭泣。如果您不需要平台之间的（网络）通信（或使用 Win32 API 将 wchar_t 转换为 UTF-8），您仍然可以在 UNIX 上使用 UTF8 并在 Windows 上使用 wchar_t，或者在任何地方都使用 UTF-8 并转换当你使用 Win32 API 函数时到 wchar_t （这就是我所做的）。

【讨论】：

【解决方案3】：

直接回答你的问题：

是否仍然需要使用 Windows 范围的功能，或者我现在可以使用 Unicode 和 UTF-8 完成所有操作吗？

不，绝大多数 Windows API 函数不接受（非 ASCII）UTF-8。您仍然必须使用广泛的 API。

同样可以哀叹其他操作系统仍然不支持wchar_t。所以你还必须支持 UTF-8。

其他答案提供了一些关于如何在跨平台代码库中管理它的好建议，但听起来好像您已经有了一个支持不同字符类型的实现。尽管为了简化代码而删除它听起来很可取，但不要这样做。

【讨论】：

【解决方案4】：

是否还需要使用 Windows范围的功能，或者我可以做现在一切都使用 Unicode 和 UTF-8 了吗？

是的。不幸的是，Windows 没有对 UTF-8 的本机支持。如果您想要正确的 Unicode 支持，您需要使用 Windows API 函数的wchar_t 版本，而不是char 版本。

我应该从 Windows 代码中删除 TCHAR 吗？

是的，你应该这样做。 TCHAR 存在的原因是同时支持 Unicode 和非 Unicode 版本的 Windows。早在 2001 年，当 Windows 98 仍然流行时，非 Unicode 支持可能是一个主要问题，但今天不是。

而且任何非 Windows 特定库都不太可能具有相同类型的 char/wchar_t 重载，从而使 TCHAR 可用。

所以继续用wchar_ts 替换你所有的TCHARs。

代码在 Unix/Mac 上使用 GCC 编译，并在 Windows 上使用 MinGW 进行交叉编译。

我以前必须编写跨平台的 C++ 代码。（现在我的工作是编写跨平台的 C# 代码。）当 Windows 不支持 UTF-8 并且 Un*x 不支持 UTF-16 时，字符编码是相当痛苦的。我最终使用 UTF-8 作为我们的主要编码并在 Windows 上根据需要进行转换。

【讨论】：

UTF-8 Everywhere 还建议在任何地方使用 UTF-8 并根据需要进行转换

【解决方案5】：

而且我预测有一天，尽管可能不会在 2020 年之前，Windows 将添加 UTF-8 支持，只需添加所有 API 函数的 U 版本，以及 A 和 W，以及相同类型的链接器破解。 8 位 A 函数只是原生 W (UTF-16) 函数的转换层。我打赌他们可以从 A 层半自动生成 U 层。

一旦他们被戏弄了足够长的时间，关于他们的“20 世纪”Unicode 支持......

通过使用精心挑选的宏和默认的 Visual Studio 设置，它们仍然会设法使其在默认情况下难以编写、难以阅读和不可移植。

【讨论】：