1. 常见的编码方式
ASCII
American Standard Code for Information Interchange，美国标准信息交换码，由美国人50年代发明。
标准 ASCII 码共有128个字符，包括大小写字母、数字0-9、标点符号、非打印字符（换行符、制表符等4个）以及控制字符（退格、响铃等），每个字符占7位（1字节是8位，剩下的1位二进制为0）。比如 'a'的 ASCII码10进制是97，二进制是 01100001。
0～31及127(共33个)是控制字符或通信专用字符（其余为可显示字符），如控制符：LF（换行）、CR（回车）、FF（换页）、DEL（删除）、BS（退格)、BEL（响铃）等；通信专用字符：SOH（文头）、EOT（文尾）、ACK（确认）等；ASCII值为8、9、10 和13 分别转换为退格、制表、换行和回车字符。它们并没有特定的图形显示，但会依不同的应用程序，而对文本显示有不同的影响。
32～126(共95个)是字符(32是空格），其中48～57为0到9十个阿拉伯数字；65～90为26个大写英文字母；97～122号为26个小写英文字母；其余为一些标点符号、运算符号等。
ISOLatin-1
- ASCII是美国发明针对英语设计的，但欧洲人在用的时候出现了问题。对于一些特殊的拉丁字符，比如法文德文里某些字符，ASCII字符集就不包括。于是欧洲人发明了一种8位字符集是ISO 8859-1Latin 1，也简称为ISOLatin-1。它对ASCII做了个扩充，对于0-127之间的字符还使用ASCII里的字符不变， 把位于128-255之间的字符表示拉丁字母表中特殊语言字符。
UNICODE
计算机不断发展扩展到亚洲非洲，如何用计算机使用的二进制表示这些语言又成了问题。ISOLatin-1的8位字符集只能表示256个字符，而仅汉语就有80000以上个字符。如何把地球上绝大多数语言用一种编码方式表示出来呢？ 于是发明了UNICODE编码，只用2个字节(16位)就可以编码地球上几乎所有地区的文字。
UNICODE只是理论上的编码方式，相当于给世界上每个文字打了个编号，但这编号具体如何在计算机里面存储，可以有多种实现方式。比如utf-8和gbk。
前面说了UNICODE只是给每个文字打了个编号，为啥不把这个编号直接转化成二进制存储在计算机里面呢？ 比如英文字母s的编号是115, 用二进制表示是
00000000 1110011, 中文日的编号是26085 (16进制是65e5) ，二进制是11001011 1100101。老外才没那么傻，对于老外这种日常纯粹是用英文字符的人来说明明之前1个字节就能存储一个字母，现在为了全球大一统非要存储为2个字节，相当于一个之前一个1M的文档，现在变为2M。于是老外耍了赖，英文字母s是115没错，但我就用1个字节1110011表示，而你中文日是26085号也没错，但是你不能在使用2个表示，而是用2个甚至6个字节表示。（为了英文的特权，牺牲其他语言的存储空间的便利），这个编码方式就是UTF-8。
UTF-8
- UTF-8（8-bit Unicode Transformation Format）是一种针对Unicode的可变长度字符编码，又称万国码。UTF-8用1到6个字节编码UNICODE字符。用在网页上可以同一页面显示中文简体繁体及其它语言（如英文，日文，韩文）。
GBK
用2个字节就能表示中文一个汉字，现在UTF-8编码中文竟然需要2个甚至4个字节来表示。于是中国制定一套自己的规则，于是用2个字节来表示一个汉字，总共可以覆盖2万多个文字。 对于英文和UTF-8同样的方式使用一个字节来表示。
GBK 支持简体中文和繁体中文；GB2312 支持简体中文；Big5 支持繁体中文。
记住：UNICODE只是给字符一个代号，而GBK和UTF-8使用不同的规则来表示同一个代号。
ANSI
不同的国家和地区制定了不同的标准，由此产生了 GB2312、GBK、Big5、Shift_JIS 等各自的编码标准。这些使用 1 至 4 个字节来代表一个字符的各种汉字延伸编码方式，称为 ANSI 编码。在简体中文Windows操作系统中，ANSI 编码代表 GBK 编码；在日文Windows操作系统中，ANSI 编码代表 Shift_JIS 编码。 不同 ANSI 编码之间互不兼容，当信息在国际间交流时，无法将属于两种语言的文字，存储在同一段 ANSI 编码的文本中。 当然对于ANSI编码而言，0x00~0x7F之间的字符，依旧是1个字节代表1个字符。这一点是ANSI编码与Unicode编码之间最大也最明显的区别。
ANSI不单指一种编码方式，ANSI指的是各地区和国家各自基于ASCII码对汉字的延伸编码方式，一般与操作系统的语言有关。
2. 乱码产生的原因及解决方案
乱码一般是英文以外的字符才会出现，因为 UTF-8 、GBK 等编码方式对英文都是采用一个字节的编码方式，并且采用了相同的码字，与 ASCII 码保持一致。乱码的根本原因是编码和解码使用的编码方式不一致，解决乱码问题常用方法无非两种：
1. 保证编码、解码使用的编码方式一致。
2. 编码、解码过程中的编码方式不一致的话，进行编码格式转换。
2.1 网页乱码
原因分析
下面这个流程是我们写入文件到展示文件的简单描述：
1. 我们使用编辑器编写 HTML 文件；
2. 保存编写的HTML文件；
3. 使用浏览器打开HTML文件；
4. HTML文件在浏览器展示。
乱码产生的根源就在与第2步骤和第4步。
在第2步保持文件时会把我们写入的文字使用编辑器默认的编码方式进行保存。如果大家使用的是vscode编辑器，默认的编码方式是utf-8。
在第4步浏览器打开网页时，它并不知道你的这个文件是使用什么编码方式，于是自作主张使用了默认解码方式。比如将文件保存为GBK格式，在Chrome打开时默认使用 ISO -8859的解码方式，导致编码和解码不匹配，产生乱码。
解决方案
保证保存浏览器解析html文件用的编码方式和保存html文件时用的编码方式一致。首先，在文件保存的时候你自己要清楚是用哪种编码方式保存的。如果你的文件是保存为utf-8格式，那么一定要在html 的<head>里添加<meta charset="utf-8">，这句话的意思是告诉浏览器在打开这个页面的时候直接用utf-8去解码。 同理，如果你的文件保存为gbk格式，一定在文件里添加<meta charset="gbk">。
2.2 Qt 中文乱码
原因分析
从我们在代码编辑器里输入一个UTF8汉字开始,到最终在窗口或控制台上显示出来，整个流程涉及到三个概念,分别是源码字符集,执行字符集，解析字符集，三个字符集保持一样则不会乱码。
源码字符集：就是你的源代码文本文件的字符集，在Qt Creator中进行如下设置：工具->选项->文本编辑器->行为->文件编码->默认编码UTF-8、UTF-8 BOM：如果编码是UTF-8则添加。统一将我们的源代码文件设置为UTF-8编码。
执行字符集：编译器将源码编译成可执行文件时采用的编码字符集。本次项目采用MSVC2013 32bit编译器，MSVC编译器默认根据系统的Locale来决定执行字符集，一般大家都是windows中文系统，Locale是中国，那么就是GBK编码。
解析字符集：最终要还原显示这些二进制字节编码的时候，就需要用到它。Qt默认采用UTF-8（不确定）作为解析字符集。
综上可知，Qt中乱码的原因是因为MSVC编译器采用GBK编码字符集作为执行字符集，前后字符集不一致导致乱码。
解决方案
要解决乱码问题，其实只要使得MSVC编译器采用UTF-8字符集进行编译即可。在需要使用中文的类的头文件上方加入如下语句：#pragma execution_character_set("utf-8")，即可使得MSVC编译器采用UTF-8字符集进行编译。
2.3 Arcmap 解析 shp 文件乱码
原因分析
一般来说，组成一个 Shapefile，需要包含以下文件：
.shp：矢量图形格式，用于保存元素的几何实体；
.shx：图形索引格式。几何体位置索引，记录每一个几何体在shp文件中的位置，能够加快几何体的搜索效率；
.dbf：属性数据格式，以dBase的数据表格式存储每个几何形状的属性数据；
.prj：投影格式，用于保存地理坐标系统与投影信息，是一个存储well-known text投影描述符的文本文件；
.cpg：用于描述 .dbf 文件的代码页，指明其使用的字符编码。
其中 .shp、.shx、.dbf 三个文件是必需的。
解析shp文件乱码指的是读取或写入 .dbf 文件中的中文属性乱码。值的注意的是，.dbf 文件中的第29个字节表示的是LanguageDriverID，代码编码方式，如 87 代表 ANSI 编码。具体对应关系参看 http://www.autopark.ru/ASBProgrammerGuide/DBFSTRUC.HTM 。
Arcmap 解析 .dbf 文件的过程如下：
1. 查看 .dbf 文件的LanguageDriverID，如果LanguageDriverID有效，则使用LanguageDriverID对应的编码方式解析.dbf文件；
2. 如果LanguageDriverID无效（LanguageDriverID没有对应的编码方式，如LanguageDriverID为0），则查看是否有 .cpg文件，如果有 .cpg 文件，则根据 .cpg文件中指定的编码方式解析 .dbf 文件；
3. 如果没有 .cpg 文件，则采用默认的编码方式解析 .dbf 文件，Arcmap 10.2之后默认采用UTF-8编码。
因此Arcmap解析shp文件乱码原因是.dbf 文件的LanguageDriverID有误或缺乏正确的.cpg文件。
解决方案
确保.dbf文件的LanguageDriverID正确或添加必要的.cpg文件。
2.4 Gdal 读取写入shp文件乱码
读取shp乱码解决
经过上图设置：gdal支持中文路径、中文文件名、中文字段和中文属性的读取，但是使用CreateLayer()或者CopyLayer()函数生成的shp文件用arcmap打开中文字段和属性会乱码。
写入或创建shp乱码
乱码原因如下：gdal默认创建的dbf文件的LanguageDriverID（dbf文件的第29个字节）为87，代表ANSI编码，而shp文件实为UTF-8编码，arcmap解析shp时会先根据dbf确定文件编码，因此会采用ANSI字符集解析shp文件，导致乱码。
解决思路就是使得创建的dbf文件的LanguageDriverID为0，而不是87，为0不表示任何编码，没有编码的情况下，arcmap采用UTF-8字符集解析shp，即可正常显示。查阅源码和对应API文档可知。CreateLayer()或者CopyLayer()函数有个参数可以设置创建的dbf文件LanguageDriverID，如下图所示：
