编码(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.链接
由汇编程序生成的目标文件并不能立即就被执行，其中可能还有许多没有解决的问题。例如，某个源文件中的函数可能引用了另一个源文件中定义的某个符号（如变量或者函数调用等）；在程序中可能调用了某个库文件中的函数，等等。所有的这些问题，都需要经链接程序的处理方能得以解决。
