我们最初学习计算机的时候，都学过ASCII编码。但是为了表示各种各样的语言，在计算机技术的发展过程中，逐渐出现了很多不同标准的编码格式，重要的有Unicode、UTF、ISO 8859-1和国人经常使用的GB2312、BIG5、GBK等。
- ISO 8859-1
最早的编码就是ISO 8859-1，属于单字节编码，应用于英文系列。最多能表示的字符范围是0-255（编码范围是0x00-0xFF），其中0x00-0x7F之间完全和ASCII一致，因此向下兼容ASCII。除ASCII收录的字符外，ISO-8859-1收录的字符还包括西欧语言、希腊语、泰语、阿拉伯语、希伯来语对应的文字符号。欧元符号等出现的比较晚，没有被收录在ISO 8859-1当中。
很明显，ISO 8859-1编码表示的字符范围很窄，例如无法表示中文字符。但是由于ISO-8859-1编码范围使用了单字节内的所有空间，在支持ISO 8859-1的系统中传输和存储其他任何编码的字节流都不会被抛弃。换言之，把其他任何编码的字节流当作ISO-8859-1编码看待都没有问题。这是个很重要的特性，所以很多情况下（如很多协议传输数据时）都使用ISO 8859-1编码。我们可以这么说，ASCII编码是一个7位的容器，ISO 8859-1编码是一个8位的容器。
比如，虽然“中文”两个字不存在ISO 8859-1编码，但可以用iso8859-1编码来“表示”。通过查询下文将要介绍的GB2312编码表，“中文”应该是”d6d0 cec4″两个字符，使用ISO 8859-1编码来表示的时候则将它拆开为4个字节来表示，即”d6 d0 ce c4″（事实上，在进行存储的时候，也是以字节为单位处理的）。如果使用Unicode编码，则为”4e2d 6587″；使用UTF编码，则是6个字节”e4 b8 ad e6 96 87″。很明显，这种使用ISO 8869-1对汉字进行表示的方法还需要以另一种编码为基础。
有些环境下，将ISO 8859-1写作Latin-1。
- GB2312/BIG5/GBK
GB2312是汉子的国标码，由中华人民共和国政府制定的，简体汉字编码规范。其表示汉字时是双字节编码，而英文字母和ISO 8859-1一致（兼容ISO 8859-1编码）。与此对应的还有BIG5，是中华民国政府制定的，繁体汉字的编码规范，一般应用于海外计算机的繁体中文显示。所谓的繁体中文Windows，简体中文Windows，指的就是采用BIG5和GB2312编码格式的操作系统。这两种编码方式不兼容，如果使用一种编码的文本阅读器来读另一种编码的文本，就会出现乱码。比如在简体中文Windows上读BIG5编码的文件，就是乱码，反之亦然。使用简体浏览器浏览的时候，到了繁体中文网站，如果不改变码制，也是乱码。
GBK，又称GBK大字符集，简而言之就是将所有亚洲文字的双字节字符，包括简体中文，繁体中文，日语，韩语等，都使用一种格式编码，这样就能够做到在所有的语言平台上面兼容。而且，目前GB2312，BIG5所包含的汉字数量也不足，比如朱总理的名字一般就打不出。而GBK大字符集包含的汉字数量比GB2312和BIG5多的多了，足够使用。简而言之，GBK编码能够用来同时表示繁体字和简体字，而GB2312只能表示简体字，因此GBK又是兼容GB2312编码的。
- Unicode
Unicode是Unicode.org制定的编码标准，目前得到了绝大部分操作系统和编程语言的支持。Unicode.org官方对Unicode的定义是：Unicode provides a unique number for every character。可见，Unicode所做的是为每个字符定义了一个相应的数字表示。比如，”a”的Unicode值是0x0061,“一”的Unicde值是0x4E00，这是最简单的情况，每个字符用2个字节表示。
Unicode是最统一的编码，可以用来表示所有语言的字符，而且是定长双字节（也有四字节的）编码，包括英文字母在内。所以可以说它是不兼容ISO 8859-1编码的，也不兼容任何编码。不过，相对于ISO 8859-1中所编码的字符来说，Unicode编码只是在前面增加了一个0字节，从上面字母a编码为”00 61″即可看出。定长编码便于计算机处理（注意GB2312/GBK不是定长编码），而Unicode又可以用来表示所有字符，所以在很多软件内部是使用Unicode编码来处理的，比如java。
Unicode的编码空间从U+0000到U+10FFFF，共有1,112,064个码位（code point）可用来映射字符. Unicode的编码空间可以划分为17个平面（plane），每个平面包含216（65,536）个码位。17个平面的码位可表示为从U+xx0000到U+xxFFFF， 其中xx表示十六进制值从0016 到1016，共计17个平面。第一个平面称为基本多语言平面（Basic Multilingual Plane, BMP），或称第零平面（Plane 0），码位从U+0000至U+FFFF，包含了最常用的字符。其他平面称为辅助平面(Supplementary Planes)。基本多语言平面内，从U+D800到U+DFFF之间的码位区段是永久保留不映射到Unicode字符。UTF-16就利用保留下来的0xD800-0xDFFF区段的码位来对辅助平面的字符的码位进行编码。
对于在Unicode基本多文种平面定义的字符（无论是拉丁字母、汉字或其他文字或符号），一律使用2字节储存。而在辅助平面定义的字符，会以代理对（surrogate pair）的形式，以两个2字节的值来储存。事实上，下文所述的UTF-16就是这么做的。
- UTF
考虑到Unicode编码不兼容ISO 8859-1编码，而且容易占用更多的空间：因为对于英文字母，Unicode也需要两个字节来表示，所以Unicode不便于传输和存储。因此而产生了UTF编码。
UTF 是 Unicode Translation Format，即把Unicode转做某种格式的意思。可以这么认为，Unicode是一种编码方式，和ACSII是同一个概念，而UTF是一种存储方式（格式）。
UTF编码兼容ISO 8859-1编码，同时也可以用来表示所有语言的字符，显然，UTF编码是不定长编码，每一个字符的长度从1-6个字节不等。另外，UTF编码自带简单的校验功能。
那么，UTF是如何做这种格式转换的呢？
Unicode.org定义了百万个以上的字符，如果将所有的字符用统一的格式表示，需要的是4个字节。”a”的Unicode表示就会变成0x00000061，而“一”的Unicode值是0x00004E00。实际上，这就是UTF32，Linux操作系统上所使用的Unicode方案。
但是，仔细分析可以发现，其实绝大部分字符只使用2个字节就可以表示了。英文的Unicode范围是0x0000-0x007F，中文的Unicode范围是0x4E00-0x9F**，真正需要扩展到4个字节来表示的字符少之又少，所以有些系统直接使用2个字节来表示Unicode。比如Windows系统上，Unicode就是两个字节的。对于那些需要4个字节才能表示的字符，使用一种代理的手法来扩展（其实就是在低两个字节上做一个标记，表示这是一个代理，需要连接上随后的两个字节，才能组成一个字符）。这样的好处是大量的节约了存取空间，也提高了处理的速度。这种Unicode表示方法就是UTF-16。一般在Windows平台上，提到Unicode，那就是指UTF-16了。
至于UTF16-LE和UTF16-BE，与计算机的CPU构架有关。LE指Little Endian，而BE指Big Endian。关于这方面的信息，网上有很多相关的帖子。我们一般的X86系统都是Little Endian的，可以认为UTF16就是UTF16-LE。
另外，UTF有一个BOM（Byte Order Mark）的问题。在Unicode编码中有一个叫做”ZERO WIDTH NO-BREAK SPACE”的字符，它的编码是0xFEFF。而0xFFFE在实际中是不存在的字符，所以不应该出现在实际传输中。UCSUCS (Unicode Character Set)规范建议我们在传输字节流前，先传输字符”ZERO WIDTH NO-BREAK SPACE”。这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little- Endian的。因此字符”ZERO WIDTH NO-BREAK SPACE”又被称作BOM。显然，UTF-8 是不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符”ZERO WIDTH NO-BREAK SPACE”的UTF-8编码是EF BB BF（可以看下面的映射关系）。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。
Windows就是使用BOM来标记文本文件的编码方式的。用UltraEdit的16进制编辑模式查看代码，都是EF BB BF开头的，说明都是带BOM的。参照下面的GB2312/GBK的编码，可以解释为什么在出现编码问题时，经常看到这三个汉字“锘匡豢”：
UTF16比起UTF8，好处在于大部分字符都以固定长度的字节（2字节）储存，但UTF-16却无法兼容于ASCII编码。由于对于欧洲和北美，实际上使用的编码范围在0x0000-0x00FF之间，只需要一个字符就可以表示所有的字符。即使是使用UTF16来作为内存的存取方式，还是会带来巨大的空间浪费，因此就有了UTF8的编码方式。这是一种很灵活的编码，对于只需要1个字节的字符，就使用一个字节；对于中日韩等原本需要两个字节才能表示的字符，则通过一个 UTF16 – UTF8 的算法实现相互之间的转换（一般需要3个字节才能表示），而对于需要4个字节才能表示的字符，UTF8可以扩展到6个字节每个字符。UTF8使用的算法很有意思，大致映射关系如下：
UTF-32 UTF8
0x00000000 – 0x0000007F 0xxxxxxx
0x00000080 – 0x000007FF 110xxxxx 10xxxxxx
0x00000800 – 0x0000FFFF 1110xxxx 10xxxxxx 10xxxxxx
0x00010000 – 0x001FFFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
0x00200000 – 0x03FFFFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
0x04000000 – 0x7FFFFFFF 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
可以发现这和IP的分址算法很是相像。
由于UTF8可以方便的转换为UTF16和UTF32（不需要码表，转换算法可以在Unicode.org上找到C代码）。而且UTF8在每个操作系统平台上的实现都是一样的，也不存在跨平台的问题，所以UTF8成为跨平台的Unicode很好的解决方案。当然，对于中文来说，由于每个字符需要3个字节才能表示，还是有点浪费的。
注意，虽然说UTF是为了使用更少的空间而使用的，但那只是相对于Unicode编码来说，如果已经知道是汉字，则使用GB2312/GBK无疑是最节省的。不过另一方面，值得说明的是，虽然UTF8编码对汉字使用3个字节，但即使对于汉字网页，UTF8编码也会比Unicode编码节省，因为网页中包含了很多的英文字符。
以下是乱码问题分析：
一、字符编码问题举例
1、支付宝代扣签约失败问题。
问题描述：用户在浏览器中输入中文请求，表单post给后台为中文乱码，导致通用代扣签约失败。
主要链路：用户签约->浏览器Post请求->mdeduct
乱码问题分析
原因解析：页面post请求使用GBK编码，后端使用了iso-8859-1进行解码，iso-8859-1不支持中文，所以中文属性解析乱码，导致后续系统鉴权处理时用户名不认识失败，进而整个签约失败。
2、微博红包提现失败问题。
问题描述：
主要链路：微博->Bizfund-> memerprod->淘宝
乱码问题分析
原因解析：微博昵称中含有繁体字，memerprod受理请求后，使用GB2312进行编码，但是GB2312不支持繁体字，所以编码后出现乱码，淘宝使用GBK解码时由于编码时已乱码解析出来乱码，导致昵称查询失败，进而微博提现失败。
二、字符编码介绍
看过了实例，后面我们就对编码做个统一的介绍，并进行一些对比，使我们更深入的了解编码。
1、ASCII：在计算机内部，所有的信息最终都表示为一个二进制的字符串。每一个二进制位（bit）有0和1两种状态，因此八个二进制位就可以组合出256种状态，这被称为一个字节（byte）。也就是说，一个字节一共可以用来表示256种不同的状态，每一个状态对应一个符号，就是256个符号，从0000000到11111111。上个世纪60年代，美国制定了一套字符编码，对英语字符与二进制位之间的关系，做了统一规定。这被称为ASCII码，一直沿用至今。ASCII码一共规定了128个字符的编码，比如空格“SPACE”是32（二进制00100000），大写的字母A是65（二进制01000001）。这128个符号（包括32个不能打印出来的控制符号），只占用了一个字节的后面7位，最前面的1位统一规定为0。
2、ISO-8859-1：又称Latin-1，计算机一开始只在美国使用，ASCII可以表示他们的符号，但是后来欧洲一些国家也开始使用计算机，很多国家使用的不是英文，ASCII的256个位置不够了，为了表示这些字符，就重新进行了编码，ISO-8859-1是单字节编码，向下兼容ASCII，其编码范围是0x00-0xFF，0x00-0x7F之间完全和ASCII一致，0x80-0x9F之间是控制字符，0xA0-0xFF之间是文字符号。此字符集主要支持欧洲使用的语言。
3、GB2312：后来计算机普及了，于是就中国要使用计算机了 但是机器不认得中文，于是就有了国际码, GB，是“国标”二字的汉语拼音首字母，1980年制定，由于“历史局限性”，此字符集内收录的字符很少，汉字总共收录了 6763 个，而且全部都是大陆通用的简体汉字。
4、BIG5：在GB2312肆虐横行的同时，我们的港澳台同胞，也制定了一个适用于当地繁体汉字需要的字符集，其对应编码名为 BIG5，也有人称之为大五码。
5、GBK：后来发现一些人名、文言文汉字、少数民族语言都需要支持，GB2312满足不了，就做了扩展，叫GBK标准,基本上采用了原来GB2312-80所有的汉字及码位，并涵盖了原Unicode中所有的汉字20902，总共收录了883个符号，21003个汉字及提供了1894个造字码位。
6、UNICODE：随着计算机的普及，编码也众多，需要统一，一个叫 ISO （国际标谁化组织）的国际组织决定着手解决这个问题。他们采用的方法很简单：废了所有的地区性编码方案，重新搞一个包括了地球上所有文化、所有字母和符号的编码！他们打算叫它”Universal Multiple-Octet Coded Character Set”，简称 UCS, 俗称 “UNICODE”。
7、UTF-8: 互联网的普及，强烈要求出现一种统一的编码方式。UTF-8就是在互联网上使用最广的一种unicode的实现方式。重复一遍，这里的关系是，UTF-8是Unicode的实现方式之一, 其他实现方式还包括UTF-16和UTF-32，不过在互联网上基本不用。
UTF-8最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。
UTF-8的编码规则很简单，只有二条：
a）对于单字节的符号，字节的第一位设为0，后面7位为这个符号的unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的。
b）对于n字节的符号（n>1），第一个字节的前n位都设为1，第n+1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的unicode码。
8、ANSI: 不同的国家和地区制定了不同的标准，由此产生了 GB2312、GBK、GB18030、Big5、Shift_JIS 等各自的编码标准。这些使用多个字节来代表一个字符的各种汉字延伸编码方式，称为 ANSI 编码。在简体中文Windows操作系统中，ANSI 编码代表 GBK 编码；在繁体中文Windows操作系统中，ANSI编码代表Big5；在日文Windows操作系统中，ANSI 编码代表 Shift_JIS 编码。
常用编码对比：
乱码问题分析
三、页面与服务器的交互编码
我们看一下 Java Web 中那些地方可能会存在编码转换？
用户从浏览器端发起一个 HTTP 请求，需要存在编码的地方是 URL、Cookie、Parameter。服务器端接受到 HTTP 请求后要解析 HTTP 协议，其中 URI、Cookie 和 POST 表单参数需要解码，服务器端可能还需要读取数据库中的数据，本地或网络中其它地方的文本文件，这些数据都可能存在编码问题，当 Servlet 处理完所有请求的数据后，需要将这些数据再编码通过 Socket 发送到用户请求的浏览器里，再经过浏览器解码成为文本。这些过程如下图所示：
下图是一次 HTTP 请求的编码示例
乱码问题分析
下面我们来看看页面和服务器交互的字符编码情况。
1、网址路径中包含汉字。
打开IE（我用的是8.0版），输入网址“http://zh.wikipedia.org/wiki/春节 ”。 注意，“春节”这两个字此时是网址路径的一部分。
乱码问题分析
查看HTTP请求的头信息，会发现IE实际查询的网址是“http://zh.wikipedia.org/wiki/%E6%98%A5%E8%8A%82 ”。 也就是说，IE自动将“春节”编码成了“%E6%98%A5%E8%8A%82”。
乱码问题分析
我们知道，“春”和“节”的utf-8编码分别是“E6 98 A5”和“E8 8A 82”，因此，“%E6%98%A5%E8%8A%82”就是按照顺序，在每个字节前加上%而得到的。
在Firefox中测试，也得到了同样的结果。所以，结论1就是，网址路径的编码，用的是utf-8编码。
2、查询字符串包含汉字
在IE中输入网址“http://www.baidu.com/s?wd=春节 ”。注意，“春节”这两个字此时 属于查询字符串，不属于网址路径，不要与情况1混淆。
乱码问题分析
查看HTTP请求的头信息，会发现IE将“春节”转化成了一个乱码。
乱码问题分析
切换到十六进制方式，才能清楚地看到，“春节”被转成了“B4 BA BD DA”。
乱码问题分析
我们知道，“春”和“节”的GB2312编码（我的操作系统“Windows XP”中文版的默认编码）分别是“B4 BA”和“BD DA”。因此，IE实际上就是将查询字符串，以GB2312编码的格式发送出去。
Firefox的处理方法，略有不同。它发送的HTTP Head是“wd=%B4%BA%BD%DA”。也就是说，同样采用GB2312编码，但是在每个字节前加上了%。
乱码问题分析
所以，结论2就是，查询字符串的编码，用的是操作系统的默认编码。
3、Get或Post方法生成的URL包含汉字
前面说的是直接输入网址的情况，但是更常见的情况是，在已打开的网页上，直接用Get或Post方法发出HTTP请求。这时的编码方法由网页的编码决定，也就是由HTML源码中字符集的设定决定。
<meta http-equiv=”Content-Type” content=”text/html;charset=xxxx”>
如果上面这一行最后的charset是UTF-8，则URL就以UTF-8编码；如果是GB2312，URL就以GB2312编码。
举例来说，百度是GB2312编码，Google是UTF-8编码。因此，从它们的搜索框中搜索同一个词“春节”，生成的查询字符串是不一样的。
百度生成的是%B4%BA%BD%DA，这是GB2312编码。
乱码问题分析
Google生成的是%E6%98%A5%E8%8A%82，这是UTF-8编码。
乱码问题分析
所以，结论3就是，GET和POST方法的编码，用的是网页的编码。
4、Ajax调用的URL包含汉字
前面三种情况都是由浏览器发出HTTP请求，最后一种情况则是由Javascript生成HTTP请求，也就是Ajax调用。还是根据吕瑞麟老师的 文章，在这种情况下，IE和Firefox的处理方式完全不一样。
举例来说，有这样两行代码：
url = url + “?q=” +document.myform.elements[0].value; // 假定用户在表单中提交的值是“春节”这两个字
http_request.open(‘GET’, url, true);
那么，无论网页使用什么字符集，IE传送给服务器的总是“q=%B4%BA%BD%DA”，而Firefox传送给服务器的总是“q=%E6%98 %A5%E8%8A%82”。也就是说，在Ajax调用中，IE总是采用GB2312编码（操作系统的默认编码），而Firefox总是 采用utf-8编码。这就是我们的结论4。
我们使用表格来做个比较。
乱码问题分析
不同的操作系统、不同的浏览器、不同的网页字符集，将导致完全不同的编码结果。在前后端交互的时候怎么避免这个问题，就是前端先对发送请求进行编码，然后再向服务器提交，服务器获取前端的编码方式进行解码，不要给浏览器插手的机会。 这样就保证了服务器得到的数据是格式统一的。
四、其它需要编码的地方
除了 URL 和参数编码问题外，在服务端还有很多地方可能存在编码，如可能需要读取 xml、velocity 模版引擎或者从数据库读取数据等。
xml 文件可以通过设置头来制定编码格式
<?xml version=”1.0″ encoding=”UTF-8″?>
Velocity 模版设置编码格式：
services.VelocityService.input.encoding=UTF-8
访问数据库都是通过客户端 JDBC 驱动来完成，用 JDBC 来存取数据要和数据的内置编码保持一致，可以通过设置 JDBC URL 来制定如 MySQL：url=”jdbc:mysql://localhost:3306/DB?useUnicode=true&characterEncoding=GBK”。
五、测试建议
经过以上了解，可以发现，常出现的问题是中文的支持，编码和解码不一致导致乱码。所以日常测试中，对与get、psot、Ajax请求中含有中文属性的，需要做相应的测试验证。
支持中文的话，必须测试中文，另外注意繁体字。
Get请求含有中文测试。
Post请求中含有中文测试。
Ajax请求中含有中文测试。
乱码问题分析
六、常见问题分析
下面看一下，当我们碰到一些乱码时，应该怎么分析这些问题？出现乱码问题的原因都是在转换中编码和解码的字符集不一致导致的，由于往往一次操作涉及到多次编解码，所以出现乱码时很难查找到底是哪个环节出现了问题，下面就几种常见的现象进行分析。
1、中文变成了看不懂的字符
例如，字符串“淘！我喜欢！”变成了“Ì Ô £ ¡Î Ò Ï²»¶ £ ¡”编码过程如下图所示
乱码问题分析
字符串在解码时所用的字符集与编码字符集不一致导致汉字变成了看不懂的乱码，而且是一个汉字字符变成两个乱码字符。
2、一个汉字变成一个问号
例如，字符串“淘！我喜欢！”变成了“？？？？？？”编码过程如下图所示
乱码问题分析
将中文和中文符号经过不支持中文的 ISO-8859-1 编码后，所有字符变成了“？”，这是因为用 ISO-8859-1 进行编解码时遇到不在码值范围内的字符时统一用 3f 表示，这也就是通常所说的“黑洞”，所有 ISO-8859-1 不认识的字符都变成了“？”。
3、一个汉字变成两个问号
例如，字符串“淘！我喜欢！”变成了“？？？？？？？？？？？？”编码过程如下图所示
乱码问题分析
这种情况比较复杂，中文经过多次编码，但是其中有一次编码或者解码不对仍然会出现中文字符变成“？”现象，出现这种情况要仔细查看中间的编码环节，找出出现编码错误的地方。
4、一种不正常的正确编码
乱码问题分析
这种情况是这样的，ISO-8859-1 字符集的编码范围是 0000-00FF，正好和一个字节的编码范围相对应。这种特性保证了使用 ISO-8859-1 进行编码和解码可以保持编码数值“不变”。虽然中文字符在经过网络传输时，被错误地“拆”成了两个欧洲字符，但由于输出时也是用 ISO-8859-1，结果被“拆”开的中文字的两半又被合并在一起，从而又刚好组成了一个正确的汉字。虽然最终能取得正确的汉字，但是还是不建议用这种不正常的方式取得参数值，因为这中间增加了一次额外的编码与解码，这种情况出现乱码时因为 Tomcat 的配置文件中 useBodyEncodingForURI 配置项没有设置为”true”，从而造成第一次解析式用 ISO-8859-1 来解析才造成乱码的。
附：
windows联通之谜事件：
原因解析：
因为GB2312编码与UTF8编码产生了编码冲撞的原因。
下表是从UNICODE到UTF8的转换规则，
乱码问题分析
当你新建一个文本文件时，记事本的编码默认是ANSI, 如果你在ANSI的编码输入汉字，那么他实际就是GB2312系列的编码方式，在这种编码下，”联通”的内码是：
c1 1100 0001
aa 1010 1010
cd 1100 1101
a8 1010 1000
巧合的地方在于联通这两个字的ANSI编码符合utf8编码的第二个模板。第一二个字节、第三四个字节的起始部分的都是”110″和”10″，正好与UTF8规则里的两字节模板是一致的，于是再次打开记事本时，记事本就误认为这是一个UTF8编码的文件，让我们把第一个字节的110和第二个字节的10去掉，我们就得到了”00001 101010″，再把各位对齐，补上前导的0，就得到了”0000 0000 0110 1010″，不好意思，这是UNICODE的006A，也就是小写的字母”j”，而之后的两字节用UTF8解码之后是0368，这个字符什么也不是。这就是只有”联通”两个字的文件没有办法在记事本里正常显示的原因。可以认为，当文档中的所有字符的二进制编码在C0≤AA(第一个字节)≤DF 80≤BB(第二个字节)≤BF时，记事本都无法确认文本的编码格式，就按照UTF-8的格式来显示。
参考：https://cloud.tencent.com/developer/article/2090167
以下是iconv工具处理中文乱码的方法，来自：https://www.cnblogs.com/zwingblog/p/7519469.html
iconv命令是运行于linux/unix平台的文件编码装换工具。当我们在linux/unix系统shell查看文本文件时，常常会发现文件的中文是乱码的，这是由于文本文件的编码与当前操作系统设置的编码不同而引起的，这时可以使用iconv进行编码转换，从而解决乱码问题。
解决文本文件乱码问题分3步：1.确定文件编码,2.确定iconv是否支持此编码的转换,3.确定Linux/Unix操作系统编码,4.转换文件编码为与系统编码一致；下面通过对test.txt文件来举例。
1、 使用file命令来确定文件编码：
$ file -bi gbk.txt | sed -e 's/.*[ ]charset=//' |tr '[a-z]' '[A-Z'
ISO-8859-1
可见test.txt文件编码为ISO-8859-1编码。
2、 使用iconv -l确定iconv是否支持此种编码的转换：
$ iconv -l | grep ISO-8859-1
ISO-8859-1//
ISO-8859-10//
ISO-8859-11//
ISO-8859-13//
ISO-8859-14//
ISO-8859-15//
ISO-8859-16//
3、 确定Linux/Unix操作系统编码：
$ echo $LANG
zh_CN.UTF-8
当前操作系统坏境编码为"UTF-8"
4、 转换编码
$ iconv -f ISO-8859-1 -t UTF-8 test.txt
测试
注：由于file命令常常会误判编码，如发现转换出来的编码依然是乱码，可将iconv -f的输入编码换成其他常用编码试试: GBK、BIG5、HZ、GB2312、GB18030、ASCII
iconv命令的详细语法:
iconv [选项..] 文件
选项：
-f 输入编码
-t 输出编码
-l 列出所有已知的编码
-o 输出文件
附录字符编码表：
编码集：
ISO-8859-2 ISO 8859-2 standard; ISO Latin 2
ISO-8859-4 ISO 8859-4 standard; Latin 4
ISO-8859-5 ISO 8859-5 standard; ISO Cyrillic
ISO-8859-13 ISO 8859-13 standard; ISO Baltic; Latin 7
ISO-8859-16 ISO 8859-16 standard
CP1125 MS-windows code page 1125
CP1250 MS-Windows code page 1250
CP1251 MS-Windows code page 1251
CP1257 MS-Windows code page 1257; WinBaltRim
IBM852 IBM/MS code page 852; PC (DOS) Latin 2
IBM855 IBM/MS code page 855
IBM775 IBM/MS code page 775
IBM866 IBM/MS code page 866
baltic ISO-IR-179; Baltic
KEYBCS2 Kamenicky encoding; KEYBCS2
macce Macintosh Central European
maccyr Macintosh Cyrillic
ECMA-113 Ecma Cyrillic; ECMA-113
KOI-8_CS_2 KOI8-CS2 code ('T602')
KOI8-R KOI8-R Cyrillic
KOI8-U KOI8-U Cyrillic
KOI8-UNI KOI8-Unified Cyrillic
TeX (La)TeX control sequences
UCS-2 Universal character set 2 bytes; UCS-2; BMP
UCS-4 Universal character set 4 bytes; UCS-4; ISO-10646
UTF-7 Universal transformation format 7 bits; UTF-7
UTF-8 Universal transformation format 8 bits; UTF-8
CORK Cork encoding; T1
GBK Simplified Chinese National Standard; GB2312
BIG5 Traditional Chinese Industrial Standard; Big5
HZ HZ encoded GB2312
行结束符：
/LF LF line terminators
/CRLF CRLF line terminators
N.A. Mixed line terminators
N.A. Surrounded by/intermixed with non-text data
/21 Byte order reversed in pairs (1,2 -> 2,1)
/4321 Byte order reversed in quadruples (1,2,3,4 -> 4,3,2,1)
N.A. Both little and big endian chunks, concatenated
/qp Quoted-printable encoded
各国语言编码集：
Bulgarian CP1251 ISO-8859-5 IBM855 maccyr ECMA-113
Czech ISO-8859-2 CP1250 IBM852 KEYBCS2 macce KOI-8_CS_2 CORK
Estonian ISO-8859-4 CP1257 IBM775 ISO-8859-13 macce baltic
Croatian CP1250 ISO-8859-2 IBM852 macce CORK
Hungarian ISO-8859-2 CP1250 IBM852 macce CORK
Lithuanian CP1257 ISO-8859-4 IBM775 ISO-8859-13 macce baltic
Latvian CP1257 ISO-8859-4 IBM775 ISO-8859-13 macce baltic
Polish ISO-8859-2 CP1250 IBM852 macce ISO-8859-13 ISO-8859-16 baltic CORK
Russian KOI8-R CP1251 ISO-8859-5 IBM866 maccyr
Slovak CP1250 ISO-8859-2 IBM852 KEYBCS2 macce KOI-8_CS_2 CORK
Slovene ISO-8859-2 CP1250 IBM852 macce CORK
Ukrainian CP1251 IBM855 ISO-8859-5 CP1125 KOI8-U maccyr
Chinese GBK BIG5 HZ