編碼(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中，輸出中文，為空；
1、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. 在中國，大陸最常用的就是GBK18030編碼，除此之外還有GBK，GB2312，這幾個編碼的關系是這樣的。
最早制定的漢字編碼是GB2312，包括6763個漢字和682個其它符號
95年重新修訂了編碼，命名GBK1.0，共收錄了21886個符號。
之後又推出了GBK18030編碼，共收錄了27484個漢字，同時還收錄了藏文、蒙文、維吾爾文等主要的少數民族文字，現在WINDOWS平臺必需要支持GBK18030編碼。
按照GBK18030、GBK、GB2312的順序，３種編碼是向下兼容，同一個漢字在三個編碼方案中是相同的編碼。
2. 臺灣，香港等地使用的是BIG5編碼
3. 日本：SJIS編碼
二、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萬編碼。
三、 兼容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之間的轉換。
四、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.鏈接
由匯編程序生成的目標文件並不能立即就被執行，其中可能還有許多沒有解決的問題。例如，某個源文件中的函數可能引用了另一個源文件中定義的某個符號（如變量或者函數調用等）；在程序中可能調用了某個庫文件中的函數，等等。所有的這些問題，都需要經鏈接程序的處理方能得以解決。
編碼(ACSII unicod UTF-8)、QT輸出中文亂碼深入分析