TCHAR仍然相关吗？

Question

TCHAR仍然相关吗？

Fáb*_*bio 86 c c++ windows unicode wchar-t

我是Windows编程的新手,在阅读了Petzold的书后,我想知道:

使用TCHAR类型和_T()函数来声明字符串或者我是否应该在新代码中使用wchar_t和L""字符串仍然是一种好习惯？

我将只针对Windows 2000及以上版本,我的代码将从一开始就是i18n.

Answer 1

Sas*_*cha 89

简短的回答: 没有.

像所有其他人已经写过的一样,很多程序员仍然使用TCHAR和相应的功能.在我看来,整个概念都是一个坏主意.UTF-16字符串处理与简单的ASCII/MBCS字符串处理有很大不同.如果你对它们使用相同的算法/函数(这就是TCHAR的想法所基于的!),如果你做的不仅仅是简单的字符串连接,你会在UTF-16版本上获得非常糟糕的性能(比如解析等).主要原因是代理人.

唯一的例外是当您真的需要为不支持Unicode的系统编译应用程序时,我认为没有理由在新应用程序中使用过去的这个行李.

有趣的事实:UTF-16并不总是在NT平台上.1996年,Unicode 2.0引入了代理代码点,同年NT 4发布.直到IIRC,(包括)Windows 2000,所有NT版本都使用UCS-2,实际上是UTF-16的一个子集,它假设每个字符可用一个代码点表示(即没有代理). (6认同)
你歪曲了,最初为TCHAR引入了什么:为了简化基于Win 9x和Windows NT的Windows版本的代码开发.那时,Windows NT的UTF-16实现是UCS-2,字符串解析/操作的算法是相同的.没有代理人.即使使用代理,DBCS(Windows唯一支持的MBCS编码)和UTF-16的算法也是相同的:在任一编码中,代码点由一个或两个代码单元组成. (4认同)
顺便说一句,虽然我同意不再使用"TCHAR",但我不同意这是一个坏主意.我也认为*如果*你选择明确而不是使用`TCHAR`你应该明确*到处*.也就是说,他们的声明中也没有使用`TCHAR` /`_TCHAR`(例如`_tmain`)的函数.简单地说:保持一致.+1,仍然. (3认同)
当它被引入时,它是一个好主意**,但它在新代码中应该是无关紧要的. (3认同)

Answer 2

dan*_*n04 77

我必须同意Sascha.TCHAR/ _T()/等的基本前提是你可以编写一个基于"ANSI"的应用程序,然后通过定义宏来神奇地给它支持Unicode.但这是基于几个不好的假设:

您主动构建软件的MBCS和Unicode版本

否则,你会char*在许多地方滑倒并使用普通的琴弦.

您不在_T("...")文字中使用非ASCII反斜杠转义

除非您的"ANSI"编码恰好是ISO-8859-1,否则结果char*和wchar_t*文字将不代表相同的字符.

UTF-16字符串的使用方式与"ANSI"字符串类似

他们不是.Unicode引入了大多数遗留字符编码中不存在的几个概念.代孕.结合人物.正常化.条件和语言敏感的套管规则.

也许最重要的是,UTF-16很少保存在磁盘上或通过Internet发送:UTF-8往往是外部表示的首选.

您的应用程序不使用Internet

(现在,这可能是您软件的有效假设,但......)

网络运行在UTF-8和大量罕见的编码.该TCHAR概念仅识别两个:"ANSI"(不能是UTF-8)和"Unicode"(UTF-16).它可能有助于使您的Windows API调用支持Unicode,但是对于使您的Web和电子邮件应用程序具有Unicode感知能力是无用的.

您不使用非Microsoft库

没有其他人使用TCHAR. Poco使用std::string和UTF-8. SQLite有其API的UTF-8和UTF-16版本,但没有TCHAR. TCHAR甚至不在标准库中,所以std::tcout除非你想自己定义它.

我推荐的不是TCHAR

忘记存在"ANSI"编码,除非您需要读取无效的UTF-8文件.别忘TCHAR了.始终调用Windows API函数的"W"版本. #define _UNICODE只是为了确保你不小心打电话给"A"功能.

始终对字符串使用UTF编码:UTF-8用于char字符串,UTF-16(在Windows上)或UTF-32(在类Unix系统上)用于wchar_t字符串. typedef UTF16和UTF32字符类型,以避免平台差异.

@ 0xC0000022L问题是关于*new*代码.当您维护旧代码时,您显然必须使用*代码编写的环境*.如果您正在维护COBOL应用程序,那么COBOL是否是一门优秀的语言并不重要,您会坚持使用它.如果您正在维护一个依赖于TCHAR的应用程序,那么无论这是否是一个好的决定并不重要,您就会坚持下去. (11认同)
2012年呼吁:即使现在,仍然有一些应用程序没有`#define _UNICODE`.传输结束:) (6认同)
实际上,除非在COBOL中,否则TCHAR没用 (2认同)
“_UNICODE”控制如何在 CRT 中解析通用文本映射。如果您不想调用 ANSI 版本的 Windows API，则需要定义“UNICODE”。 (2认同)

Answer 3

Aar*_*ark 18

如果你想知道它是否还在实践中,那么是 - 它仍然使用了很多.如果它使用TCHAR和_T(""),没有人会看你的代码有趣.我正在研究的项目是从ANSI转换为unicode - 我们将采用便携式(TCHAR)路由.

然而...

我的投票将是忘记所有ANSI/UNICODE可移植宏(TCHAR,_T("")和所有_tXXXXXX调用等...)并且只是假设unicode到处都是.如果你永远不需要ANSI版本,我真的没有看到便携的重点.我会直接使用所有宽字符函数和类型.使用L预先添加所有字符串文字.

-1表示UTF-16推荐.这不仅会创建非可移植(以窗口为中心)的代码,这对于库来说是不可接受的 - 即使可能用于最简单的UI代码 - 即使在Windows本身也不高效.http://www.utf8everywhere.org (7认同)
您可能会编写一些您想要在其他需要ANSI版本的地方使用的代码,或者(如Nick所说)Windows可能转移到DCHAR或其他任何地方,所以我仍然认为使用TCHAR而不是TCHAR是一个非常好的主意. WCHAR. (3认同)

Answer 4

Nic*_*ick 15

如果我今天正在做一个新项目,我仍然会使用TCHAR语法.使用它和WCHAR语法之间没有太大的实际区别,我更喜欢在字符类型中明确的代码.由于大多数API函数和辅助对象采用/使用TCHAR类型(例如:CString),因此使用它是有意义的.此外,如果您决定在某个时刻使用ASCII应用程序中的代码,或者Windows曾经演变为Unicode32等,它会为您提供灵活性.

如果您决定采用WCHAR路线,我会明确表示.也就是说,使用CStringW而不是CString,并在转换为TCHAR时转换宏(例如:CW2CT).

无论如何,这是我的意见.

您更喜欢在字符类型中明确的代码,因此使用有时是这种类型的类型,有时也会这样？非常有说服力. (9认同)
** - 1**表示@Deduplicator注意到的不一致性,以及使用宏可以是任何事情的负面支付建议(并且通常不会针对多个特定值进行测试). (3认同)

Answer 5

Ste*_*ven 11

在介绍了Windows编程的文章在MSDN上说:

新应用程序应始终调用(API的)Unicode版本.

该TEXT和TCHAR宏是用处不大的今天,因为所有的应用程序应该使用Unicode.

我会坚持wchar_t和L"".

史蒂文,你引用了一个不明白"Unicode"这个词含义的人写的文字.这是UCS-2混淆时的那些不幸文件之一. (4认同)
@PavelRadzivilovsky:该文档是为系统编写的,其中*Unicode*和*UTF-16LE*通常可互换使用.虽然技术上不准确,但它仍然是明确的.在相同文本的引言中也明确指出了这一点:*"Windows表示使用UTF-16编码的Unicode字符[...]"*. (2认同)

Answer 6

Pav*_*sky 10

我想建议一种不同的方法(两者都不是).

总而言之,使用char*和std :: string,假设使用UTF-8编码,并且只在包装API函数时才转换为UTF-16.

有关Windows程序中此方法的更多信息和理由,请访问http://www.utf8everywhere.org.

*UTF-8 Everywhere* 口头禅不会成为正确的解决方案，只是因为它被更频繁地重复。UTF-8 无疑是一种有吸引力的序列化编码（例如文件或网络套接字），但在 Windows 上，它通常更适合在内部使用本机 UTF-16 编码存储字符数据，并在应用程序边界进行转换。一个原因是，UTF-16 是唯一的编码，可以立即转换为任何其他支持的编码。UTF-8 不是这种情况。 (3认同)
我不明白。对于其他任何事情 - 比如什么？例如UCS-4？为什么不？看起来很简单，全数字算法.. (3认同)
@PavelRadzivilovsky：*“将 UTF-8 编码转换为其他编码有什么问题？”* - 这不是我说的。您可以立即将 UTF-8 转换为 UTF-16，调用“MultiByteToWideChar”。但是，如果不先转换为 UTF-16，则无法从 UTF-8 转换为其他任何内容。 (2认同)

Answer 7

LeO*_*ArD 6

TCHAR/ WCHAR对于一些遗留项目来说可能就够了.但是对于新的应用程序,我会说NO.

由于历史原因,所有这些TCHAR/ WCHAR东西都在那里.TCHAR提供了一种看似简洁的方式(伪装)来在ANSI文本编码(MBCS)和Unicode文本编码(UTF-16)之间切换.过去,人们并不了解世界上所有语言的字符数.他们假设2个字节足以表示所有字符,因此具有固定长度的字符编码方案WCHAR.但是,在1996年发布Unicode 2.0之后,这已不再适用.

也就是说:无论你在CHAR/ WCHAR/中使用哪个TCHAR,程序中的文本处理部分都应该能够处理可变长度的字符以进行国际化.

所以,你真正需要做的不是选择一条由多CHAR/ WCHAR/ TCHAR在Windows编程:

如果您的应用程序很小并且不涉及文本处理(即只是将文本字符串作为参数传递),那么请坚持使用WCHAR.由于这种方式更容易使用支持Unicode的WinAPI.
否则,我建议使用UTF-8作为内部编码并将文本存储在char字符串或std :: string中.在调用WinAPI时将它们转换为UTF-16.UTF-8现在是主要的编码,并且有许多方便的库和工具来处理UTF-8字符串.

查看这个精彩的网站,以获得更深入的阅读:http: //utf8everywhere.org/

*"UTF-8现在是主要的编码"* - 这是错误的,省略了引用的第二部分(*"万维网"*).对于桌面应用程序,最常用的本机字符编码可能仍为UTF-16.Windows使用它,Mac OS X也是如此,.NET和Java的字符串类型也是如此.这占了大量**代码.不要误解我的意思,UTF-8的序列化没有错.但通常情况下(特别是在Windows上),你会发现,在内部使用UTF-16更合适. (2认同)

Answer 8

Nik*_*man 5

是的，一点没错; 至少对于 _T 宏来说是这样。不过，我对宽字符的东西不太确定。

原因是为了更好地支持WinCE或其他非标准Windows平台。如果您 100% 确定您的代码将保留在 NT 上，那么您可能可以只使用常规 C 字符串声明。然而，最好倾向于更灵活的方法，因为与遍历数千行代码并将其添加到各处以备需要移植某些库相比，在非 Windows 平台上#define 该宏要容易得多到 Windows 移动设备。

归档时间：	17 年前
查看次数：	36843 次
最近记录：	7 年，3 月前