我正在修改一些非常古老（10 年）的 C 代码。该代码在 Unix/Mac 上使用 GCC 编译，并在 Windows 上使用 MinGW 进行交叉编译。目前有 TCHAR 字符串贯穿始终。我想摆脱 TCHAR 并改用 C++ 字符串。是否仍然需要使用 Windows 范围的功能，或者我现在可以使用 Unicode 和 UTF-8 做所有事情吗？
问问题
2860 次
5 回答
9
Windows 仍然使用 UTF16，而且很可能会一直使用。你需要使用wstring而不是string因此。Windows API 不直接提供对 UTF8 的支持，主要是因为 Windows 在 UTF8 发明之前就支持 Unicode。
因此，编写可以在 Windows 和 Unix 平台上编译的 Unicode 代码是相当痛苦的。
于 2011-06-11T13:56:41.067 回答
4
是否仍然需要使用 Windows 范围的功能，或者我现在可以使用 Unicode 和 UTF-8 做所有事情吗？
是的。不幸的是，Windows 没有对 UTF-8 的本机支持。如果您想要正确的 Unicode 支持，您需要使用wchar_tWindows API 函数的版本，而不是char版本。
我应该从 Windows 代码中消除 TCHAR 吗？
是的你应该。存在的原因TCHAR是同时支持 Unicode 和非 Unicode 版本的 Windows。早在 2001 年，当 Windows 98 仍然流行时，非 Unicode 支持可能是一个主要问题，但今天不是。
并且任何非 Windows 特定的库都不太可能具有相同类型的char/wchar_t重载以使其TCHAR可用。
所以继续用 s 替换你所有的TCHARs wchar_t。
该代码在 Unix/Mac 上使用 GCC 编译，并在 Windows 上使用 MinGW 进行交叉编译。
我以前必须编写跨平台的 C++ 代码。（现在我的工作是编写跨平台的 C# 代码。）当 Windows 不支持 UTF-8 并且 Un*x 不支持 UTF-16 时，字符编码是相当痛苦的。我最终使用 UTF-8 作为我们的主要编码并在 Windows 上根据需要进行转换。
于 2011-06-11T16:10:28.243 回答
0
是的，现在编写非 unicode 应用程序是在自取其辱。只需在任何地方使用广泛的 API，您以后就不必为此哭泣。如果您不需要平台之间的（网络）通信（或使用 Win32 API 将 wchar_t 转换为 UTF-8），您仍然可以在 UNIX 上使用 UTF8 并在 Windows 上使用 wchar_t，或者在任何地方都使用 UTF-8 并转换当您使用 Win32 API 函数时（这就是我所做的）。
于 2011-06-11T13:58:40.587 回答
0
直接回答你的问题：
是否仍然需要使用 Windows 范围的功能，或者我现在可以使用 Unicode 和 UTF-8 做所有事情吗？
不，绝大多数 Windows API 函数不接受（非 ASCII）UTF-8。您仍然必须使用广泛的 API。
类似地，人们可能会抱怨其他操作系统仍然不支持wchar_t. 所以你还必须支持 UTF-8。
其他答案为如何在跨平台代码库中管理它提供了一些很好的建议，但听起来好像您已经有一个支持不同字符类型的实现。尽管为了简化代码而将其剥离出来可能听起来很可取，但不要这样做。
于 2011-06-11T14:07:07.760 回答
0
我预测有一天，尽管可能不会在 2020 年之前，Windows 将添加 UTF-8 支持，只需添加所有 API 函数的 U 版本，以及 A 和 W，以及相同类型的链接器破解。8 位 A 函数只是原生 W (UTF-16) 函数的转换层。我打赌他们可以从 A 层半自动生成 U 层。
一旦他们被嘲笑足够长，足够长，关于他们的“20世纪”Unicode支持......
通过使用精心挑选的宏和默认的 Visual Studio 设置，它们仍然会设法使其编写起来笨拙、阅读起来难看并且默认情况下不可移植。
于 2012-09-13T01:39:33.713 回答