一.
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("中文")
...
原因：
- 在Qt4，不少用戶被鋪天蓋地的setCodecForTr()所影響，進而靠它來解決中文問題。
它的用途是用來進行翻譯(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的轉換。
QStringLiteral
這是一個宏，一個蠻復雜的宏：
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內部直接保存也就夠了。這樣
- 省掉存在兩份不同的拷貝(即相應的轉換，malloc的成本)
- 對漢字來說，UTF16本身就是UTF8省空間
現實
目前，我們還沒有可靠的方式在C++使用UTF16的執行字符集(the execution character set)。
- 盡管 L"..."(wchar_t*) 在Windows下是UTF16，但是不具備跨平台性。
- C++11可以保證這一點，u"..."(char16_t)，但主流編譯器尚未提供完美支持。
這兩點，導致了QStringLiteral的復雜性
實現
源碼見 qtbase/src/corelib/tools/qstring.h
（代碼中使用宏、模板、lambda表達式，還是相當復雜的，此處只摘片段）
- 如果編譯器支持char16_t，則直接使用
#define QT_UNICODE_LITERAL_II(str) u"" str
typedef char16_t qunicodechar; ...
- 否則。如果在Windows平台下，或者在其他的wchar_t寬度為2的環境下，使用wchar_t
#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; ...
- 否則。編譯器不支持，Qt作為一個庫，肯定也沒有辦法
# define QStringLiteral(str) QString::fromUtf8(str, sizeof(str) - 1)