寫的不錯(cuò)，轉(zhuǎn)一下：
首先呢，聲明一下，QString 是不存在中文支持問題的，很多人遇到問題，并不是本身 QString 的問題，而是沒有將自己希望的字符串正確賦給QString。
很簡單的問題，"我是中文"這樣寫的時(shí)候，它是傳統(tǒng)的 char 類型的窄字符串，我們需要的只不過是通過某種方式告訴QString 這四個(gè)漢字采用的那種編碼。而問題一般都出在很多用戶對自己當(dāng)前的編碼沒太多概念，
于是
一個(gè)簡 單的 Qt 程序
下面這個(gè)小程序，估計(jì)大家會(huì)感到比較親切。似乎有相當(dāng)多的中文用戶嘗試寫過這樣的代碼：
#include <QtGui/QApplication>
#include <QtGui/QLabel>
int main(int argc, char **argv)
{
QApplication app(argc, argv);
QString a= "我是漢字";
QLabel label(a);
label.show();
return app.exec();
}
編碼，保存，編譯，運(yùn)行，一切都很順利，可是結(jié)果呢？
|
多數(shù)用戶看到
|
其他用戶看到
|
|
ÎÒÊǺº×Ö
|
æˆ‘æ˜¯æ±‰å —
|
出乎意料，界面上中文沒顯示出來，出現(xiàn)了不認(rèn)識字符。 于是開始用搜索引擎搜索，開始上論壇發(fā)帖或抱怨
最后被告知，下面的語句之一可以解決問題：
QTextCodec::setCodecForCStrings(QTextCodec::codecForName("GB2312"));
QTextCodec::setCodecForCStrings(QTextCodec::codecForName("UTF-8"));
兩條指令挨個(gè)一試，確實(shí)可以解決(多數(shù)用戶是第一條，其他用戶是第二條)。那么，為什么會(huì)這樣呢？
兩種亂碼什么時(shí)候出現(xiàn)
對這個(gè)問題，我想大家可能都有話說。在繼續(xù)之前，我們先列個(gè)表，看看兩種亂碼分別在那種情況下出現(xiàn)：
我們只列舉大家最常用的3個(gè)編譯器(微軟VS的中的cl，Mingw中的g++，Linux下的g++)，源代碼分別采用 GBK 和 不帶BOM的UTF-8 以及 帶BOM的UTF-8 這3中編碼進(jìn)行保存。
|
源代碼的編碼
|
編譯器
|
結(jié)果
|
|
|
GBK
|
cl
|
1
|
*
|
|
mingw-g++
|
1
|
*
|
|
g++
|
1
|
|
|
UTF-8(不帶BOM)
|
cl
|
2
|
|
|
mingw-g++
|
2
|
|
|
g++
|
2
|
*
|
|
UTF-8(帶BOM)
|
cl
|
1
|
|
|
mingw-g++
|
2
|
|
|
g++
|
編譯失敗
|
|
采用3種不同編碼保存的源代碼文件，分別用3種不同的編譯器編譯，形成9種組合，除掉一種不能工作的情況，兩種亂碼出現(xiàn)的情況各占一半。
從中我們也可以看出，亂碼和操作系統(tǒng)原本是沒有關(guān)系的。但我們在 Windows 一般用的GBK，linux一般用的是不帶BOM的UTF-8。如果我們只考慮帶*的情況，也可以說兩種亂碼和系統(tǒng)有關(guān)。
QString 為什么會(huì)亂碼呢？
真的是 QString 亂碼了嗎？我們可以問問自己，我們抱怨的對象是不是搞錯(cuò)了？
繼續(xù)之前，先明確幾個(gè)概念：
明確概念1：
"我是漢字" 是C語言中的字符串，它是char型的窄字符串。上面的例子可寫為
const char * str = "我是漢字";
QString a= str;
或
char str[] = "我是漢字";
QString a= str;
等
明確概念2：
源文件是有編碼的，但是這種純文本文件卻不會(huì)記錄自己采用的編碼
這個(gè)是問題的根源，不妨做個(gè)試驗(yàn)，將前面的源代碼保存成GBK編碼，用16進(jìn)制編輯器能看到引號內(nèi)是ce d2 ca c7 ba ba d7 d6這樣8個(gè)字節(jié)。
現(xiàn)在將該文件拷貝到正體(繁體)中文的Windows中，用記事本打開會(huì)什么樣子呢？
...
QString a= "扂岆犖趼";
QLabel label(a);
label.show();
...
那么放到歐美人的Windows系統(tǒng)中，再用記事本打開呢？
...
QString a= "ÎÒÊǺº×Ö";
QLabel label(a);
label.show();
...
同一個(gè)文件，未做任何修改，但其中的8個(gè)字節(jié)ce d2 ca c7 ba ba d7 d6,對用GBK的大陸人，用BIG5的港澳臺同胞，以及用Latin-1的歐洲人看來，看到的卻是完全不同的文字。
明確概念3：
如同我們都了解的'A'與'\x41'等價(jià)一樣。
GBK編碼下的
const char * str = "我是漢字"
等價(jià)于
const char * str = "\xce\xd2\xca\xc7\xba\xba\xd7\xd6";
當(dāng)用UTF-8編碼時(shí)，等價(jià)于
const char * str = "\xe6\x88\x91\xe6\x98\xaf\xe6\xb1\x89\xe5\xad\x97";
注意：這個(gè)說法不全對，比如保存成帶BOM的UTF-8，用cl編譯器時(shí)，漢字本身是UTF-8編碼，但程序內(nèi)保存時(shí)卻是對應(yīng)的GBK編碼。
明確概念4：
QString 內(nèi)部采用的是Unicode。
QString內(nèi)部采用的是 Unicode，它可以同時(shí)存放GBK中的字符"我是漢字",BIG5中的字符"扂岆犖趼" 以及Latin-1中的字符"ÎÒÊǺº×Ö"。
一個(gè)問題是，源代碼中的這8個(gè)字節(jié)"\xce\xd2\xca\xc7\xba\xba\xd7\xd6"，該怎么轉(zhuǎn)換成Unicode并存到 QString 內(nèi)？按照GBK、BIG5、Latin-1還是其他方式...
在你不告訴它的情況下，它默認(rèn)選擇了Latin-1，于是8個(gè)字符"ÎÒÊǺº×Ö"的unicode碼被存進(jìn)了QString中。最終，8個(gè)Latin字符出現(xiàn)在你期盼看到4中文字符的地方，所謂的亂碼出現(xiàn)了
QString 工作方式
const char * str = "我是漢字";
QString a= str;
其實(shí)很簡單的一個(gè)問題，當(dāng)你需要從窄字符串 char* 轉(zhuǎn)成Unicode的QString字符串的，你需要告訴QString你的這串char* 中究竟是什么編碼？GBK、BIG5、Latin-1
理想情況就是：將char* 傳給QString時(shí)，同時(shí)告訴QString自己的編碼是什么：
就像下面的函數(shù)一樣，QString的成員函數(shù)知道按照何種編碼來處理 C 字符串
QString QString::fromAscii ( const char * str, int size = -1 )
QString QString::fromLatin1 ( const char * str, int size = -1 )
QString QString::fromLocal8Bit ( const char * str, int size = -1 )
QString QString::fromUtf8 ( const char * str, int size = -1 )
單QString 只提供了這幾個(gè)成員函數(shù)，遠(yuǎn)遠(yuǎn)滿足不了大家的需求，比如，在簡體中文Windows下，local8Bit是GBK，可是有一個(gè)char串是 BIG5 或 Latin-2怎么辦？
那就動(dòng)用強(qiáng)大的QTextCodec吧，首先QTextCodec肯定知道自己所負(fù)責(zé)的編碼的，然后你把一個(gè)char串送給它，它就能正確將其轉(zhuǎn)成Unicode了。
QString QTextCodec::toUnicode ( const char * chars ) const
可是這個(gè)調(diào)用太麻煩了，我就想直接
QString a= str;
或
QString a(str);
這樣用怎么辦？
這樣一來肯定沒辦法同時(shí)告訴 QString 你的str是何種編碼了，只能通過其他方式了。這也就是開頭提到的
QTextCodec::setCodecForCStrings(QTextCodec::codecForName("GBK"));
QTextCodec::setCodecForCStrings(QTextCodec::codecForName("UTF-8"));
設(shè)置QString默認(rèn)采用的編碼。而究竟采用哪一個(gè)，一般來說就是源代碼是GBK，就用GBK，源代碼是UTF-8就用UTF-8。但有一個(gè)例外，如果你保存成了帶BOM的UTF-8而且用的微軟的cl編譯器，此時(shí)仍是GBK。