編碼(ACSII unicod UTF-8)、QT輸出中文亂碼深刻分析

總結：

1. qt輸出中文亂碼緣由分析

qt的編程環境默認是utf-8編碼格式（關於編碼見下文知識要點一）；

cout << "中文" << endl;

程序運行，程序並不認識ANSI,UTF-8以及任何其餘編碼.系統只知道處理你給它的字符的二進制表示.

 

關於  "中""文" 的3種編碼二進制內容:

 

ANSI(GBK): 0xd6d0  0xcec4

 

UTF-8: 0xe4b8ad 0xe69687

 

Unicode: 0x4e2d 0x6587

1)在簡體中文Windows下的控制檯顯示環境是ANSI編碼(代碼頁936, GBK),先明確這點.

重點區別,MinGW看到的是"0xe4b8ad"和"0xe69687"(gcc默認UTF-8).注意,用MinGW編譯的源文件中有中文寬字符必須保存爲UTF-8編碼.

2)測試代碼：

#include <iostream>
using namespace std;

int main()
{
    char a[] = "中文";
    cout << a << endl;
    return 0;
}

3)經在qt5.8中測試亂碼；

分析：參見（下文知識要點一，知識要點二）不難發現UTF-8只是一種編碼實行方案，並非實際編碼；再參見（知識要點五），程序運行是能過最後編譯完成的二進制碼輸出

在vs2017中，用unicode編碼方式，編譯運行輸出正常；緣由我想很好理解了，當程序編譯後保存的是「中文」unicode二進制編碼，而控制檯輸出時CodePage (GBK 936) 這個CodePage就會根據映射表去一一對應GBK中的中文字，再進行輸出；

而在qt5.8(MinGW)中，輸出則是亂碼；由於qt5.8默認的編碼方式是UTF-8;當程序編譯後保存的是「中文」UTF-8二進制編碼，而控制檯輸出時CodePage (GBK 936) 這個CodePage就會根據映射表去一一對應GBK中的中文字，好像哪裏不對，好了，問題就出在這兒了，CodePage是各國與unicode的映射表，並非與UTF-8的（知識要點二CodePage），在qt5.8(MinGW)中，原程被編譯二進制文件，保存下來的「中文」地址是，UTF-8編碼，而映射表是在unicode中找內容，再進行輸出，天然就是亂碼；

網上解決方法1.修改註冊表CodePage 65001  經測試仍是亂碼

理論分析：CodePage(GBK 936)找不到映射，那麼把控制檯換成UTF-8;那麼然先保存的，UTF-8中文，再經過UTF-8對應的漢字碼，不就能輸出漢字；理論好像可行，但在個人win7 64位中文系統上，qt5.8，vs2017均失敗；

可能性緣由：我係統中cmd控制檯並不支持UTF-8編碼方式（有機會在win10中測試後再作補充）

解決方法2：經過（知識點一，二， 五），總結，當要在控制檯進行中文輸出時，編碼方式應該保存爲unicode,或ACSI(GBK);

4)關於寬字節輸出亂碼的問題；

輸出寬字節中文（詳見知識要點四）：例

#include <iostream>
using namespace std;

int main()
{
    wcout << L"中文" << endl;
    return 0;
}

輸出則要用wcout而不能是cout;關於寬字符詳見；知識要點二後續，知識要點三

在vs2017中，輸出中文，爲空；

一、cout和wcout

　在C++下，cout能夠直接輸出中文，但對於wcout卻不行。對於wcout，須要將其locale設爲本地語言才能輸出中文：

　wcout.imbue(locale(locale(),"",LC_CTYPE));

　也有人用以下語句的，但這會改變wcout的全部locale設置，好比數字「1234」會輸出爲「1,234」。

　wcout.imbue(locale(""));

　在C語言下，locale設置爲本地語言（C語言中只有全局locale）就能夠正常輸出了：

　setlocale(LC_CTYPE, "");

　在qt5.8(MinGW)環境中，以上並不實用，目前還沒找到輸出中文的方法，未完待續；

 

知識要點一：編碼

ASCII: 早期的字符集,7位,128個字符,包括大小寫a-z字母,0-9數字以及一些控制字符.

　　擴展ASCII: 1個字節8位,只用7位不合理.因而第8位用於擴展ASCII字符集,這樣就又多了128個字符.因而用着後128個字符來擴展表示如拉丁字母,希臘字母等特殊符號.但問題是歐洲那一票國家不少互相都擁有不相同的特殊字母,一塊兒塞進後128個明顯不夠,因而代碼頁出現了.

　　Code Page(代碼頁): 1個字節前128個字符你們統一和ASCII同樣,然後128個字符,根據不一樣系統所謂代碼頁來區分各個語言不相同的字母和符號.

　　DBCS(雙字節字符集): 對於亞洲國家,後128個字符依然沒法包含大量的象形文字,DBCS正是爲此的一個解決方案.DBCS由一個或兩個字節表示一個字符,這說明DBCS並不必定是兩個字節,對於如英文字母,是向ASCII兼容的,依然由1個字節表示,而對於如中文則用2個字節表示.英文和中文能夠統一地處理,而區分是否爲中文編碼的方法是2個字節中的高字節的首位爲1,就必須檢查後面跟隨的那個字節,2個字節一塊兒解釋爲1個字符.GB2312,GBK到GB18030都屬於DBCS.另外,簡體中文Windows下的ANSI編碼一般是指GBK(代碼頁936).

DBCS很大問題在於字符串的字符數不能經過字節數來決定,如"中文abc",字符數是5,而字節數是7.對於用++或--運算符來遍歷字符串的程序員來講,這簡直就是夢魘!

　　Unicode: 學名爲"Universal Multiple-Octet Coded Character Set",簡稱"UCS".UCS能夠看做是"Unicode Character Set"的縮寫.

也是一種字符集/字符編碼方法,它統一用惟一的字符集來包含這個星球上多數語言的書寫系統.UCS向ASCII兼容(即前128個字符是一致的),但並不兼容DBCS,由於其餘字符在UCS中被從新編碼(從新安排位置).

UCS有兩種格式:UCS-2和UCS-4.前者用2個字節(16位)編碼,後者用4個字節(實際上只用31位)編碼.USC-4前2個字節都爲0的部分稱爲BMP(基本多語言平面),就是說BMP去掉前2個零字節就是UCS-2.目前的UCS-4規範中尚未任何字符被分配在BMP以外.(說白了,USC-4就是爲當16位的USC-2都被分配完時候作再作擴展用的,如今還沒用到)

　　UTF-8,UTF-16,UTF-32: "Unicode transformation format"(UTF) ,即Unicode的傳輸格式.Unicode規定了怎麼編碼字符,而UTF規定怎麼將一個Unicode字符單元映射到字節序來傳輸或保存.

UTF-16和UTF-32分別表示以16位和32位爲一個Unicode單元進行編碼,其實UTF-16對應就是UCS-2,UTF-32對應就是UCS-4(UCS-2和UCS-4是陳舊的說法,應拋棄). 另外,一般說的Unicode就是指UTF-16.

UTF-8是關鍵!若是統一Unicode都用2字節表示,英文字母以爲本身就很吃虧(高字節始終是0字節).UTF-8提供了一種靈活的解決辦法:以單字節(8bit)做爲編碼單元,變長多字節編碼方式.如ASCII字母繼續使用1字節儲存,中文漢字用3字節儲存,其餘最多可直6字節.

UTF-16和UTF-32須要有字節序標誌BOM(FEFF)解決大端小端問題.UTF-8沒有字節序的問題(由於以1個字節爲單元).

 

===============================================================================

其餘注意點:

DBCS準確說,應該是MBCS(Multi-Byte Chactacter System, 多字節字符系統).

字符集(Charset)和編碼(Encoding)注意區別.如GBK,GB2312以及Unicode都既是字符集,也是編碼方式,而UTF-8只是編碼方式,並非字符集.

Linux下The GUN C Library(從glibc 2.2開始)中寬字符wchar_t是以32位的Unicode(USC-4)表示.如寬字符"中"字爲 "0x00004e2d".而Windows下的CRT使用寬字符還是16位的.

 

知識要點二：關於Unicode的認知（加深對編碼的理解）

析Unicode和UTF-8　

1、首先說明一下如今經常使用的一些編碼方案：
1. 在中國，大陸最經常使用的就是GBK18030編碼，除此以外還有GBK，GB2312，這幾個編碼的關係是這樣的。
最先制定的漢字編碼是GB2312，包括6763個漢字和682個其它符號
95年從新修訂了編碼，命名GBK1.0，共收錄了21886個符號。
以後又推出了GBK18030編碼，共收錄了27484個漢字，同時還收錄了藏文、蒙文、維吾爾文等主要的少數民族文字，如今WINDOWS平臺必須要支持GBK18030編碼。
按照GBK18030、GBK、GB2312的順序，３種編碼是向下兼容，同一個漢字在三個編碼方案中是相同的編碼。
2.  臺灣，香港等地使用的是BIG5編碼
3.  日本：SJIS編碼
2、Unicode
　　若是把各類文字編碼形容爲各地的方言，那麼Unicode就是世界各國合做開發的一種語言。
　　在這種語言環境下，不會再有語言的編碼衝突，在同屏下，能夠顯示任何語言的內容，這就是Unicode的最大好處。
　　那麼Unicode是如何編碼的呢？其實很是簡單。
　　就是將世界上全部的文字用２個字節統一進行編碼。可能你會問，２個字節最多可以表示65536個編碼，夠用嗎？
　　韓國和日本的大部分漢字都是從中國傳播過去的，字型是徹底同樣的。
　　好比：「文」字，GBK和SJIS中都是同一個漢字，只是編碼不一樣而已。
　　那樣，像這樣統一編碼，２個字節就已經足夠容納世界上全部的語言的大部分文字了。
UCS-2 與UCS-4
　　Unicode的學名是"Universal Multiple-Octet Coded Character Set"，簡稱爲UCS。
　　如今用的是UCS-2，即２個字節編碼，而UCS-4是爲了防止未來２個字節不夠用纔開發的。UCS-2也稱爲基本多文種平面。
　　UCS-2轉換到UCS-4只是簡單的在前面加２個字節0。
　　UCS-4則主要用於保存輔助平面，例如Unicode 4.0中的第二輔助平面
　　20000-20FFF - 21000-21FFF - 22000-22FFF - 23000-23FFF - 24000-24FFF - 25000-25FFF - 　　26000-26FFF 　　- 27000-27FFF - 28000-28FFF - 29000-29FFF - 2A000-2AFFF - 2F000-2FFFF
　　總共增長了16個輔助平面，由原先的65536個編碼擴展至將近100萬編碼。
3、 兼容codepage
　　那麼既然統一了編碼，如何兼容原先各國的文字編碼呢？
　　這個時候就須要codepage了。
　　什麼是codepage？codepage就是各國的文字編碼和Unicode之間的映射表。
　　好比簡體中文和Unicode的映射表就是CP936，點這裏查看官方的映射表。
　　如下是幾個經常使用的codepage，相應的修改上面的地址的數字便可。
　　codepage=936 簡體中文GBK
　　codepage=950 繁體中文BIG5
　　codepage=437 美國/加拿大英語
　　codepage=932 日文
　　codepage=949 韓文
　　codepage=866 俄文
　　codepage=65001 unicode UFT-8
最後一個65001，據我的理解，應該只是一個虛擬的映射表，實際只是一個算法而已。
從936中隨意取一行，例如：
0x9993 0x6ABD #CJK UNIFIED IDEOGRAPH
前面的編碼是GBK的編碼，後面的是Unicode。
經過查這張表，就能簡單的實現GBK和Unicode之間的轉換。
4、UTF-8
　　如今明白了Unicode，那麼UTF-8又是什麼呢？又爲何會出現UTF-8呢？
　　ASCII轉換成UCS-2，只是在編碼前插入一個0x0。用這些編碼，會包括一些控制符，好比 '' 或 '/'，這在UNIX和一些C函數中，將會產生嚴重錯誤。所以能夠確定，UCS-2不適合做爲Unicode的外部編碼。
　　所以，才誕生了UTF-8。那麼UTF-8是如何編碼的？又是如何解決UCS-2的問題呢？
例：
E4 BD A0　　　　　　　　11100100 10111101 10100000
這是「你」字的UTF-8編碼
4F 60　　　　　　　　　　01001111 01100000
這是「你」的Unicode編碼
關於漢字按照UTF-8的編碼規則，分解以下：xxxx0100 xx111101 xx100000
把除了x以外的數字拼接在一塊兒，就變成「你」的Unicode編碼了。
注意UTF-8的最前面３個1，表示整個UTF-8串是由３個字節構成的。
通過UTF-8編碼以後，不再會出現敏感字符了，由於最高位始終爲1。
如下是Unicode和UTF-8之間的轉換關係表：
U-00000000 - U-0000007F: 0xxxxxxx
U-00000080 - U-000007FF: 110xxxxx 10xxxxxx
U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx、
Unicode編碼轉換到UTF-8，針對中文，簡單的把Unicode字節流套到x中就變成UTF-8了。

續篇：

unicode在windows api中的應用
    實際上，常提到的Win32 API的名稱並非它們的真實名稱。這些名稱僅僅是一些宏，你能夠在PSDK的頭文件中找到這些宏對用的函數名稱。因此，若是PSDK的文檔提到一個函數，如CreateFile，開發人員應該意識到它僅僅是一個宏。它的真實名稱是CreateFileA和CreateFileW。是的，它表明了「兩個」函數名，而不是一個，是同一個函數在不一樣Win32函數的兩個不一樣的版本。以'A'結尾的函數接受ANSI字符串(char *)，即Unicode字符串(wchar_t *)而在vs中能夠用WCHAR宏代替，即wchar_ts型字符串。兩種版本的函數都在模塊kernel32.dll中實現，若是你的編程環境是Unicode則，則宏CreateFile在編譯是會被CreateFileW代替，不然用CreateFileA代替。

PSDK的字符串解決方案：TCHARs
    爲了不爲不一樣的windows操做系統開發不一樣版本的PSDK，微軟制訂了一個統一的字符串類型TCHARs。TCHAR以及其餘的相應的宏在頭文件WinNT.h中有定義。程序員在程序中不須要爲使用char仍是wchar_t而糾結，只須要使用宏TCHAR就能夠了。根據Unicode環境是否存在，編譯器會自動進行相應的轉換。一樣道理，程序員不須要爲使用'A'仍是'W'型Win32 API函數糾結。

對於較早期的系統均採用ACSI編碼，而在新型系統中則都統一爲unicode編碼（如:手機系統）

 

知識要點三： L"......", _T(), _TEXT ,TEXT()

L"......": L是表示字符串資源轉爲寬字符的保存(一般轉爲unicode)，卻未必是unicode字符，這與編譯器實現相關。

_T(" ……") 是一個適配的宏     #ifdef _UNICODE(當系統環境是unicod下) _T就是L   而當系統環境是ACSI  _T就是ANSI的。（有便於早期windows系編程文件的移植，達到新舊系統交互）

_T、_TEXT、TEXT 三者效果相同

tchar.h是運行時的頭文件，_T、_TEXT 根據_UNICODE來肯定宏
winnt.h是Win的頭文件根據，TEXT 根據UNICODE 來肯定宏

若是須要同時使用這3個宏，則需同時定義 UNICODE 和 _UNICODE
VS2010之後的版本中 ，設置：項目–屬性–配置屬性–常規–字符集–使用Unicode字符集， 那麼編譯器命令選項中的確同時加入了_UNICODE和UNICODE。

知識要點四： c++ 的cout 與 wcout

cout << "hello world!" << endl; //ACSI 編碼輸出

cout << L「hello world!」 <<endl；// unicode 輸出

當輸出雙字節編碼到控制檯時，cout輸出的將是地址而並不是內容這時就要用到wcout;

改成：

cout << "hello world!" << endl; //ACSI 編碼輸出

wcout << L「hello world!」 <<endl；// unicode 輸出

 

知識要點五：編譯鏈接過程

1.預處理 生成.i文件

C++的預處理是指在C++程序源代碼被編譯以前，由預處理器對C++程序源代碼進行的處理。這個過程並不對程序的源代碼進行解析。

這裏的預處理器（preprocessor）是指真正的編譯開始以前由編譯器調用的一個獨立程序。

預處理器主要負責如下的幾處

1.宏的替換

2.刪除註釋

3.處理預處理指令，如#include，#ifdef

 2.編譯和優化 生成彙編.s原文件

詞法分析 -- 識別單詞,確認詞類;好比int i;知道int是一個類型，i是一個關鍵字以及判斷i的名字是否合法
語法分析 -- 識別短語和句型的語法屬性；

語義分析 -- 確認單詞、短語和句型的語義特徵；

代碼優化 -- 修辭、文本編輯；

代碼生成 -- 生成譯文。

3.生成.o目標文件

彙編過程實際上指把彙編語言代碼翻譯成目標機器指令的過程。

在最終的目標文件中

除了擁有本身的數據和二進制代碼以外，還要至少提供2個表：未解決符號表和導出符號表，分別告訴連接器本身須要什麼和可以提供什麼。

編譯器把一個cpp編譯爲目標文件的時候，除了要在目標文件裏寫入cpp裏包含的數據和代碼，還要至少提供3個表：未解決符號表，導出符號表和地址重定向表。
未解決符號表提供了全部在該編譯單元裏引用可是定義並不在本編譯單元裏的符號及其出現的地址。
導出符號表提供了本編譯單元具備定義，而且願意提供給其餘編譯單元使用的符號及其地址。
地址重定向表提供了本編譯單元全部對自身地址的引用的記錄。

4.連接

由彙編程序生成的目標文件並不能當即就被執行，其中可能還有許多沒有解決的問題。例如，某個源文件中的函數可能引用了另外一個源文件中定義的某個符號（如變量或者函數調用等）；在程序中可能調用了某個庫文件中的函數，等等。全部的這些問題，都須要經連接程序的處理方能得以解決。