2011-06-11 75 views
7

我正在修改一些非常陈旧的(10年)C代码。代码在Unix/Mac上使用GCC编译,并与MinGW交叉编译Windows。目前在整个TCHAR字符串中。我想摆脱TCHAR并改为使用C++字符串。是否仍然需要使用Windows宽泛的函数,或者我现在可以使用Unicode和UTF-8来做所有事情吗?我应该从Windows代码中删除TCHAR吗?

+0

相关:http://stackoverflow.com/questions/234365/is-tchar-still-relevant/ – dan04 2011-06-11 15:42:32

+3

使用C++的std :: wstring的C代码是不可取的。 – 2011-06-11 17:23:13

+0

我已经成功地使用'TCHAR'得到一些短小的工具到Windows,Linux和Solaris下编译,分别使用其原生Unicode格式(UTF-16或UTF-8)。但它确实涉及为* nix平台创建自己的'tchar.h'。 – hippietrail 2011-08-10 10:38:49

回答

9

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

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

+2

Windows使用'UCS-2'和'UTF-16'的可怕混合。在BMP之外使用字符有点难以置信。 – 2011-06-11 14:03:57

+1

@Ben我认为UCS-2的东西大多局限于控制台APIS。比这更广泛吗? – 2011-06-11 14:20:12

+0

@大卫:也许这是一个文档错误,但如果您信任的文档,甚至'WideCharToMultiByte'和'MultiByteToWideChar'只处理'UCS-2'(返回的'UTF-16'字符数是无用的缓冲区分配)。 'GetWindowTextLength'同样打破,返回的字符数(有这个暗示多字节字符集的注脚,但指出,混合ANSI和Unicode时,这个特殊的行为只发生)。 – 2011-06-11 14:44:53

0

是的,现在编写非unicode应用程序正在拍摄自己的脚。只要在任何地方使用广泛的API,你就不用再哭了。如果您不需要平台之间的(网络)通信(或将wchar_t与Win32 API转换为UTF-8),那么仍然可以在UNIX上使用UTF8,在Windows上使用wchar_t,或者在硬编码方式中使用UTF-8并转换到wchar_t的时候你使用Win32 API函数(这就是我所做的)。

0

直接回答你的问题:

是否仍然需要使用Windows广泛的功能,或者我现在可以做的一切使用Unicode和UTF-8?

不,绝大多数Windows API函数都不接受(非ASCII)UTF-8。您仍然必须使用广泛的API。

有人可能会同样叹息其他操作系统仍然不支持wchar_t。所以你也必须支持UTF-8。

其他答案提供了一些关于如何在跨平台代码库中管理这些问题的好建议,但听起来好像您已经有支持不同字符类型的实现。如果想要简化代码,可能听起来不错。

4

是它仍然需要使用 窗户大功能,还是现在我所能做的一切 使用Unicode和UTF-8?

是的。不幸的是,Windows不支持UTF-8。如果您需要适当的Unicode支持,则需要使用版本的Windows API函数wchar_t,而不是版本char

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

是的,你应该。 TCHAR存在的原因是为了支持Windows的Unicode和非Unicode版本。非Unicode支持可能在2001年Windows 98仍然流行时受到关注,但不是今天。

而且任何非Windows特定库都会有相同类型的char/wchar_t超载,这使得TCHAR可用。

所以继续,用wchar_t s代替您所有的TCHAR s。

代码在Unix/Mac上用GCC编译,并用MinGW为Windows交叉编译。

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

+1

[UTF-8 Everywhere](http://www.utf8everywhere.org/)也建议在任何地方使用UTF-8并根据需要进行转换 – 2014-03-28 15:09:42

0

我预测总有一天,尽管可能不会在2020年之前,Windows会添加UTF-8支持,只需添加所有API函数的U版本,以及A和W以及相同类型的链接程序黑客。 8位A函数只是本地W(UTF-16)函数的翻译层。我敢打赌,他们可以从A层半自动生成一个U层。

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

他们仍然会设法让它尴尬写的,丑陋的阅读和非便携式的默认情况下,通过使用仔细选择的宏和默认的Visual Studio设置。

相关问题