标签:编译 ott wchar_t nbsp ase color idt 环境 存在
一.
Qt5假定的执行字符集是UTF8,不再允许用户擅自改动。这样一来,Qt4中setCodecXXX的各种副作用不再存在,而且中文问题更为简单。
QString s1 = "汉语";
QString s2("漢語");
QString s3 = tr("中文")
QString s4 = QStringLiteral("中文");//只要字符串不需要翻译,请关注这个
QString s5 = QString::fromWCharArray(L"中文");
QString s6 = u8"中文";//C++11
QString s7 = tr(u8"中文")
...
所有这些在Qt5默认都会正常工作,唯一要求就是:确保你的C++的执行字符集(the execution character set)是UTF-8
被误用最多的:此种方法解析结果是错误的
在Qt4中,QObject::tr()是被滥用(误用)的函数之一:
QString s3 = tr("中文")
...
原因:
它的用途是用来进行翻译(I18N和L10N)的,如果你没有这方面的需求,真的没必要用它。(在Qt4中,我只注意到有2个大陆网友和1个日本网友有需求并真正进行过这方面的尝试,那么其他应该算误用吧?)
让人困惑的wchar_t
刚开始接触Qt和QString时,曾多次想过,为什么不用wchar_t,为什么,...
QString s5 = QString::fromWCharArray(L"中文");
这个东西在Windows下真的很有用:首先它是Windows系统API所用字符串,其次它和QString内部表示相同。但是由于MSVC处于种种考虑,鼓励大家使用TEXT/_T,反倒使大家对它比较陌生。
但是从C++标准来说,wchar_t毕竟不是char16_t,所以跨平台性不好。在linux下,这行代码需要utf32到utf16的转换。
这是一个宏,一个蛮复杂的宏:
QString s4 = QStringLiteral("中文");
在介绍这个宏之前,我们先看看下面写法有什么劣势:
QString s1 = "汉语";
QString s2("漢語");
QString s3 = tr("中文")
QString s6 = u8"中文";//C++11
...
首先,2个汉字的字符串以UTF-8编码的形式被编译器放到了常量区。(至少占7个字节吧?)
然后,程序运行时,构造QString实例,需要在堆上申请空间,存放utf16格式的相应字符串。
有没有存在浪费?
QString 内部是UTF16,如果C++编译器在编译期直接提供了UTF16的字符串,那么我们在QString内部直接保存也就够了。这样
目前,我们还没有可靠的方式在C++使用UTF16的执行字符集(the execution character set)。
这两点,导致了QStringLiteral的复杂性
源码见 qtbase/src/corelib/tools/qstring.h
(代码中使用宏、模板、lambda表达式,还是相当复杂的,此处只摘片段)
#define QT_UNICODE_LITERAL_II(str) u"" str
typedef char16_t qunicodechar;
...
#if defined(Q_CC_MSVC)
# define QT_UNICODE_LITERAL_II(str) L##str
#else
# define QT_UNICODE_LITERAL_II(str) L"" str
#endif
typedef wchar_t qunicodechar;
...
# define QStringLiteral(str) QString::fromUtf8(str, sizeof(str) - 1)
标签:编译 ott wchar_t nbsp ase color idt 环境 存在
原文地址:https://www.cnblogs.com/mercedes-Benz/p/8855406.html