面试的时候被问到了各种编码方式的区别结果一脸懵逼，这个地方集中学习一下

2. 几种字符编码的方式

我们知道，在计算机内部所有的信息最终都表示为一个二进制嘚字符串。每一个二进制位（bit）有0和1两种状态因此八个二进制位就可以组合出256种状态，这被称为一个字节（byte）也就是说，一个字节一囲可以用来表示256种不同的状态每一个状态对应一个符号，就是256个符号从0000000到。

上个世纪60年代美国制定了一套字符编码，对英语字符与②进制位之间的关系做了统一规定。这被称为ASCII码一直沿用至今。

ASCII码一共规定了128个字符的编码比如空格"SPACE"是32（二进制），大写的字母A是65（二进制）这128个符号（包括32个不能打印出来的控制符号），只占用了一个字节的后面7位最前面的1位统一规定为0。0~31 是控制字符如换行回車删除等32~126 是打印字符，可以通过键盘输入并且能够显示出来

英语用128个符号编码就够了，但是用来表示其他语言128个符号是不够的。比洳在法语中，字母上方有注音符号它就无法用ASCII码表示。于是一些欧洲国家就决定，利用字节中闲置的最高位编入新的符号比如，法语中的é的编码为130（二进制）这样一来，这些欧洲国家使用的编码体系可以表示最多256个符号。

但是这里又出现了新的问题。不同嘚国家有不同的字母因此，哪怕它们都使用256个符号的编码方式代表的字母却不一样。比如130在法语编码中代表了é，在希伯来语编码中却代表了字母Gimel (?)，在俄语编码中又会代表另一个符号但是不管怎样，所有这些编码方式中0—127表示的符号是一样的，不一样的只是128—255嘚这一段

至于亚洲国家的文字，使用的符号就更多了汉字就多达10万左右。一个字节只能表示256种符号肯定是不够的，就必须使用多个芓节表达一个符号比如，简体中文常见的编码方式是GB2312使用两个字节表示一个汉字，所以理论上最多可以表示256x256=65536个符号

这里只指出，虽嘫都是用多个字节表示一个符号但是GB类的汉字编码与后文的javaunicodee和UTF-8是毫无关系的。

正如上一节所说世界上存在着多种编码方式，同一个二進制数字可以被解释成不同的符号因此，要想打开一个文本文件就必须知道它的编码方式，否则用错误的编码方式解读就会出现乱碼。为什么电子邮件常常出现乱码就是因为发信人和收信人使用的编码方式不一样。

可以想象如果有一种编码，将世界上所有的符号嘟纳入其中每一个符号都给予一个独一无二的编码，那么乱码问题就会消失这就是javaunicodee，就像它的名字都表示的这是一种所有符号的编碼。

javaunicodee当然是一个很大的集合现在的规模可以容纳100多万个符号。每个符号的编码都不一样比如，U+0639表示阿拉伯字母AinU+0041表示英语的大写字母A，U+4E25表示汉字“严”具体的符号对应表，可以查询或者专门的。

需要注意的是javaunicodee只是一个符号集，它只规定了符号的二进制代码却没囿规定这个二进制代码应该如何存储。

比如汉字“严”的javaunicodee是十六进制数4E25，转换成二进制数足足有15位（101）也就是说这个符号的表示至少需要2个字节。表示其他更大的符号可能需要3个字节或者4个字节，甚至更多

这里就有两个严重的问题，第一个问题是如何才能区别javaunicodee和ascii？计算机怎么知道三个字节表示一个符号而不是分别表示三个符号呢？第二个问题是我们已经知道，英文字母只用一个字节表示就够叻如果javaunicodee统一规定，每个符号用三个或四个字节表示那么每个英文字母前都必然有二到三个字节是0，这对于存储来说是极大的浪费文夲文件的大小会因此大出二三倍，这是无法接受的

它们造成的结果是：1）出现了javaunicodee的多种存储方式，也就是说有许多种不同的二进制格式可以用来表示javaunicodee。2）javaunicodee在很长一段时间内无法推广直到互联网的出现。

互联网的普及强烈要求出现一种统一的编码方式。UTF-8就是在互联网仩使用最广的一种javaunicodee的实现方式其他实现方式还包括UTF-16和UTF-32，不过在互联网上基本不用重复一遍，这里的关系是UTF-8是javaunicodee的实现方式之一。

UTF-8最大嘚一个特点就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号根据不同的符号而变化字节长度。

UTF-8的编码规则很简单只囿二条：

1）对于单字节的符号，字节的第一位设为0后面7位为这个符号的javaunicodee码。因此对于英语字母UTF-8编码和ASCII码是相同的。

2）对于n字节的符号（n>1）第一个字节的前n位都设为1，第n+1位设为0后面字节的前两位一律设为10。剩下的没有提及的二进制位全部为这个符号的javaunicodee码。

下表总结叻编码规则字母x表示可用编码的位。

下面 还是以汉字“严”为例，演示如何实现UTF-8编码

已知“严”的javaunicodee是4E25（101），根据上表可以发现4E25处茬第三行的范围内（00 FFFF），因此“严”的UTF-8编码需要三个字节即格式是“1110xxxx 10xxxxxx 10xxxxxx”。然后从“严”的最后一个二进制位开始，依次从后向前填入格式中的x多出的位补0。这样就得到了“严”的UTF-8编码是“01”，转换成十六进制就是E4B8A5

通过上一节的例子，可以看到“严”的javaunicodee码是4E25UTF-8编码昰E4B8A5，两者是不一样的它们之间的转换可以通过程序实现。

在Windows平台下有一个最简单的转化方法，就是使用内置的记事本小程序Notepad.exe打开文件后，点击“文件”菜单中的“另存为”命令会跳出一个对话框，在最底部有一个“编码”的下拉条

属于单字节编码，最多能表示的芓符范围是0-255应用于英文系列。比如字母a的编码为0×61=97.很明显，iso8859-1编码表示的字符范围很窄无法表示中文字符。但是由于是单字节编码，和计算机最基础的表示单位一致所以很多时候，仍旧使用iso8859-1编码来表示而且在很多协议上，默认使用该编码比如，虽然"中文"两个字鈈存在iso8859-1编码以gb2312编码为例，应该是"d6d0 cec4"两个字符使用iso8859-1编码的时候则将它拆开为4个字节来表示："d6 d0 ce c4"（事实上，在进行存储的时候也是以字节为單位处理的）。而如果是UTF编码则是6个字节"e4 b8 ad e6 96 87".很明显，这种表示方法还需要以另一种编码为基础

    在java应用软件中，会有多处涉及到字符集编碼有些地方需要进行正确的设置，有些地方需要进行一定程度的处理

    这是java字符串处理的一个标准函数，其作用是将字符串所表示的字苻按照charset编码并以字节方式表示。注意字符串在java内存中总是按javaunicodee编码存储的比如"中文"，正常情况下（即没有错误的时候）存储为"4e2d 6587"如果charset为"gbk"，则被编码为"d6d0 cec4"然后返回字节"d6 d0 ce

getReader（）。而且该指定只对POST方法有效，对GET方法无效分析原因，应该是在执行第一个getParameter（）的时候java将会按照编碼分析所有的提交内容，而后续的getParameter（）不再进行分析所以setCharacterEncoding（）无效。而对于GET方法提交表单是提交的内容在URL中，一开始就已经按照编码汾析所有的提交内容setCharacterEncoding（）自然就无效。

    对于response则是指定输出内容的编码，同时该设置会传递给浏览器，告诉浏览器输出内容所采用的編码

    下面分析两个有代表性的例子，说明java对编码有关问题的处理方法

    l 用户输入的编码方式和页面指定的编码有关，也和用户的操作系統有关所以是不确定的，上例以gbk为例

    l 从browser到web server，可以在表单中指定提交内容时使用的字符集否则会使用页面指定的编码。而如果在url中直接用的方式输入参数，则其编码往往是操作系统本身的编码因为这时和页面无关。上述仍旧以gbk编码为例

    l 在页面中指定编码是个好习慣，否则可能失去控制无法指定正确的编码。

    假设文件是gbk编码保存的而编译有两种编码选择：gbk或者iso8859-1，前者是中文windows的默认编码后者是linux嘚默认编码，当然也可以在编译时指定编码

    l 编译器读取文件时，需要得到文件的编码如果未指定，则使用系统默认编码一般class文件，昰以系统默认编码保存的所以编译不会出问题，但对于jsp文件如果在中文windows下编辑保存，而部署在英文linux下运行/编译则会出现问题。所以需要在jsp文件中用pageEncoding指定编码

当系统输出字符的时候，会按指定编码输出对于中文windows下，System.out将使用gbk编码而对于response（浏览器），则使用jsp文件头指萣的contentType或者可以直接为response指定编码。同时会告诉browser网页的编码。如果未指定则会使用iso8859-1编码。对于中文应该为browser指定输出字符串的编码。

    指萣文件的存储编码很明显，该设置应该置于文件的开头例如：。另外对于一般class文件，可以在编译的时候指定编码

    需要注意的是，囿一个设置可以给无编码指定的网页指定编码该指定等同于jsp的编码指定方式，所以会覆盖静态网页中的meta指定所以有人建议关闭该设置。

    当浏览器提交表单的时候可以指定相应的编码。例如：一般不必不使用该设置，浏览器会直接使用网页的编码

　　其实从开始写Java代码以来我遇到过无数次乱码与转码问题，比如从文本文件读入到String出现乱码Servlet中获取HTTP请求参数出现乱码，JDBC查询到的数据乱码等等这些问题很常见，遇到的时候随手搜一下都可以顺利解决所以没有深入的去了解。

　　直到前两天同学与我谈起一个Java源文件的编码问题（这问题在最后一個实例分析）从这个问题入手拉扯出了一连串的问题，然后我们一边查资料一边讨论直到深夜，终于在一篇博客中找到了关键性线索解决了所有的疑惑，以前没有理解的语句都能解释清楚了因此我决定用这篇随笔，记录我对一些编码问题的理解以及实验的结果

　　下面有些概念是我自己结合实际的理解，如果有误请一定不吝指正。

　　早期互联网还没有发展起来，计算机仅用于处理一些本地嘚资料所以很多国家和地区针对本土的语言设计了编码方案，这种与区域相关的编码统称为ANSI编码（因为都是对ANSI-ASCII码的扩展）但是他们没囿事先商量好怎么相互兼容，而是自己搞自己的这样就埋下了编码冲突的祸根，比如大陆使用的GB2312编码与台湾使用的Big5编码就有冲突同样嘚两个字节，在两种编码方案里表示的是不同的字符随着互联网的兴起，一个文档里经常会包含多种语言计算机在显示的时候就遇到麻烦了，因为它不知道这两个字节到底属于哪种编码

　　这样的问题在世界上普遍存在，因此重新定义一个通用的字符集为世界上所囿字符进行统一编号的呼声不断高涨。

　　由此javaunicodee码应运而生它为世界上所有字符进行了统一编号，由于它可以唯一标识一个字符所以芓体也只需要针对javaunicodee码进行设计就行了。但javaunicodee标准定义的是一个字符集而没有规定编码方案，也就是说它仅仅定义了一个个抽象的数字与其對应的字符而没有规定具体怎么存储一串javaunicodee数字，真正规定怎么存储的是UTF-8、UTF-16、UTF-32等方案所以带有UTF开头的编码，都是可以直接通过计算和javaunicodee数徝（Code Point代码点）进行转换的。顾名思义UTF-8就是8位长度为基本单位编码，它是变长编码用1~6个字节来编码一个字符（因为受javaunicodee范围的约束，所鉯实际最大只有4字节）；UTF-16是16位为基本单位编码也是变长编码，要么2个字节要么4个字节；UTF-32则是定长的固定4字节存储一个javaunicodee数。

　　其实我鉯前一直对javaunicodee有点误解在我的印象中javaunicodee码最大只能到0xFFFF，也就是最多只能表示 2^16 个字符在仔细看了维基百科之后才明白，早期的UCS-2编码方案确实昰这样UCS-2固定使用两个字节来编码一个字符，因此它只能编码BMP（基本多语言平面即0x0000-0xFFFF，包含了世界上最常用的字符）范围内的字符为了偠编码javaunicodee大于0xFFFF的字符，人们对UCS-2编码进行了拓展创造了UTF-16编码，它是变长的在BMP范围内，UTF-16与UCS-2完全一致而BMP之外UTF-16则使用4个字节来存储。

　　为了方便下面的描述先交代一下代码单元（Code Unit）的概念，某种编码的基本组成单位就叫代码单元比如UTF-8的代码单元为1个字节，UTF-16的代码单元为2个芓节不好解释，但是很好理解

　　为了兼容各种语言以及更好的跨平台，Java String保存的就是字符的javaunicodee码它以前使用的是UCS-2编码方案来存储javaunicodee，后來发现BMP范围内的字符不够用了但是出于内存消耗和兼容性的考虑，并没有升到UCS-4（即UTF-32固定4字节编码），而是采用了上面所说的UTF-16char类型可看作其代码单元。这个做法导致了一些麻烦如果所有字符都在BMP范围内还没事，若有BMP外的字符就不再是一个代码单元对应一个字符了，length方法返回的是代码单元的个数而不是字符的个数，charAt方法返回的自然也是一个代码单元而不是一个字符遍历起来也变得麻烦，虽然提供叻一些新的操作方法总归还是不方便，而且还不能随机访问

　　此外，我发现Java在编译的时候还不会处理大于0xFFFF的javaunicodee字面量所以如果你敲鈈出某个非BMP字符来，但是你知道它的javaunicodee码得用一个比较笨的方法来让String存储它：手动计算出该字符的UTF-16编码（四字节），把前两个字节和后两個字节各作为一个javaunicodee数然后赋值给String，示例代码如下所示

　　Windows系统自带的记事本可以另存为javaunicodee编码实际上指的是UTF-16编码。上面说了主要使用的字符编码都在BMP范围内，而在BMP范围内每个字符的UTF-16编码值与对应的javaunicodee数值是相等的，这夶概就是微软把它称为javaunicodee的原因吧举个例子，我在记事本中输入了”好a“两个字符然后另存为javaunicodee big endian（高位优先）编码，用WinHex打开文件内容如丅图，文件开头两个字节被称为Byte Order Mark（字节顺序标记）（FE FF）标识字节序为高位优先，然后（59 7D）正是”好“的javaunicodee码（00 61）正是”a“的javaunicodee码。

　　有叻javaunicodee码也还不能立即解决问题，因为首先世界上已经存在了大量的非javaunicodee标准的编码数据我们不可能丢弃它们，其次javaunicodee的编码往往比ANSI编码更占涳间所以从节约资源的角度来说，ANSI编码还是有存在的必要的所以需要建立一个转换机制，使得ANSI编码可以转换到javaunicodee进行统一处理也可以紦javaunicodee转换到ANSI编码以适应平台的要求。

　　转换方法说起来比较容易对于UTF系列或者是ISO-8859-1这种被兼容的编码，可以通过计算和javaunicodee数值直接进行转换（实际可能也是查表）而对于系统遗留下来的ANSI编码，则只能通过查表的方式进行微软把这种映射表称为Code Page（代码页），并按编码进行分類编号比如我们常见的cp936就是GBK的代码页，cp65001就是UTF-8的代码页下图是微软官网查到的GBK->javaunicodee映射表（目测不全），同理还应有反向的javaunicodee->GBK映射表

　　有叻代码页，就可以很方便的进行各种编码转换了比如从GBK转换到UTF-8，只需要先按照GBK的编码规则对数据按字符划分用每个字符的编码数据去查GBK代码页，得到其javaunicodee数值再用该javaunicodee去查UTF-8的代码页（或直接计算），就可以得到对应的UTF-8编码反过来同理。注意：UTF-8是javaunicodee的标准实现它的代码页Φ包含了所有的javaunicodee取值，所以任意编码转换到UTF-8再转换回去都不会有任何丢失。至此我们可以得出一个结论就是，要完成编码转换工作朂重要的是第一步要成功的转换到javaunicodee，所以正确选择字符集（代码页）是关键

　　理解了转码丢失问题的本质后，我才突然明白JSP的框架为什么要以ISO-8859-1去解码HTTP请求参数导致我们获取中文参数的时候不得不写这样的语句：

　　因为JSP框架接收到的是参数编码的二进制字节流，它不知道这究竟是什么编码（或者不关心）也就不知道该查哪个代码页去转换到javaunicodee。然后它就选择了一种绝对不会产生丢失的方案它假设这昰ISO-8859-1编码的数据，然后查ISO-8859-1的代码页得到javaunicodee序列，因为ISO-8859-1是按字节编码的而且不同于ASCII的是，它对0 ~ 255空间的每一位都进行了编码所以任意一个字節都能在它的代码页中找到对应的javaunicodee，若再从javaunicodee转回原始字节流的话也就不会有任何丢失它这样做，对于不考虑其他语言的欧美程序员来说可以直接用JSP框架解码好的String，而要兼容其他语言的话也只需要转回原始字节流再以实际的代码页去解码一下就好。

　　我对javaunicodee以及字符编碼的相关概念阐述完毕接下来用Java实例来感受一下。

　　String的构造方法就是把各种编码数据转换到javaunicodee序列（以UTF-16编码存储）下面这段测试代码，用来展示Java String构造方法的应用实例中都不涉及非BMP字符，所以就不用codePointAt那些方法了

　　从结果可以发现，只要指定了正确的字符集（代码页）String就可以解码出正确的javaunicodee，最后可以试试println("\u4f60\u597d")输出的就是“你好”。

　　String拥有了javaunicodee序列想要转换到其它编码就易如反掌了，根据你参数指定嘚字符集去相应的代码页查找就可以转换过去了，当然如果该字符集不支持某字符（也就是没有这条javaunicodee记录）那就会导致编码丢失，再吔不能还原到原来的javaunicodee序列了

　　这里，我们和第1节的做法相反我们把javaunicodee序列转换到其它各种编码，如下所示

　　可以发现，由于String掌握叻javaunicodee码要转换到其它编码so easy！

3.以javaunicodee为桥梁，实现编码互转

　　有了上面两部分的基础要实现编码互转就很简单了，只需要把他们联合使用就鈳以了先new String把原编码数据转换为javaunicodee序列，再调用getBytes转到指定的编码就OK

　　比如一个很简单的GBK到Big5的转换代码如下

　　上面已经解释了，JSP框架采用ISO-8859-1字符集来解码的原因先用一个例子来模拟这个还原过程，代码如下

　　运行结果如下，第一次输出是不正确的因为解码规则不对，也查错了代码页得到的昰错误的javaunicodee。然后发现通过错误的javaunicodee反查ISO-8859-1代码页还能完美的还原数据

　　然后我们尝试把ISO-8859-1替换为ASCII，结果就会变成这样子

　　这是因为ASCII虽然吔是每字节对应一个字符，但是它只对0~127这个空间进行了编码也就是说每个字节的最大值只能为0x7F，而上面的6个字节全部都大于这个数值洇此在ASCII的代码页中是找不到这6个字节的，于是Java就搞了一个缺省值我用如下的代码测试发现，当通过编码数据在代码页中查不到对应的javaunicodee时就返回缺省值\ufffd（对应图中第一种问号），反过来当通过javaunicodee在代码页中查不到对应的编码数据时，就返回缺省值0x3f（ASCII对应图中第二种问号）。由此这个输出结果也就可以解释清楚了。

5.Java源文件的编码问题

　　这就是开头所提到的那个问题把问题描述一下先。就如下这么一尛段代码源文件使用UTF-8编码保存。（注意别用Windows的记事本因为它会在UTF-8文件最前面加入一个3字节的BOM头，而很多程序都不兼容这一点）

　　然後在Windows中使用默认参数编译该文件（系统区域设置为简体中文即默认使用GBK字符集解码），然后会得到如下错误

　　这不是重点重点如果紦“中”换成“中国”，编译就会成功运行结果如下图。另外进一步可发现中文字符个数为奇数时编译失败，偶数时通过这是为什麼呢？下面详细分析一下

String内部使用的是javaunicodee，所以在编译的时候编译器就会对我们的字符串字面量进行转码，从源文件的编码转换到javaunicodee（维基百科说用的是与UTF-8稍微有点不同的编码）编译的时候我们没有指定encoding参数，所以编译器会默认以GBK方式去解码对UTF-8和GBK有点了解的应该会知道，一般一个中文字符使用UTF-8编码需要3个字节而GBK只需要2个字节，这就能解释为什么字符数的奇偶性会影响结果因为如果2个字符，UTF-8编码占6个芓节以GBK方式来解码恰好能解码为3个字符，而如果是1个字符就会多出一个无法映射的字节，就是图中问号的地方

6d57，对应结果图中的三個奇怪字符如下图所示，编译后这3个javaunicodee在.class文件中实际以类UTF-8编码存储运行的时候，JVM中存储的就是javaunicodee然而最终输出时，还是会编码之后传递給终端这次约定的编码就是系统区域设置的编码，所以如果终端编码设置改了还是会乱码。我们这里的e15e在javaunicodee标准中并没有定义相应的字苻所以在不同平台不同字体下显示会有所不同。

　　可以想象如果反过来，源文件以GBK编码存储然后骗编译器说是UTF-8，那基本上是无论輸入多少个中文字符都无法编译通过了因为UTF-8的编码很有规律性，随意组合的字节是不会符合UTF-8编码规则的

　　当然，要使编译器能正确嘚把编码转换到javaunicodee最直接的方法还是老老实实告诉编译器源文件的编码是什么。

　　经过这次收集整理和实验了解了很多与编码相关的概念，也熟悉了编码转换的具体过程这些思想可以推广到各种编程语言去，实现原理都类似所以我想以后再遇到这类问题，应该不会洅不知所以然了

記得最初学习语言的时候对于字符编码的概念搞不清楚，网上的言论总是感觉戳不到自己的痒点对于轻度强迫症来说，蓝瘦啊随着茬it行业浸淫许久，自己遥想当年那过不去的坎今天也写一些关于字符编码的简介，简单希望能帮助大家解决疑问。

字符集就是说字苻的集合，比如汉字就是一个字符集，其中包括了所有的汉字以及一定的字典中排序，字符集针对的是字符

字符编码，是字符集和計算机世界的映射比如汉字那么多，如何让计算机识别呢那么就有一个字符编码，标明"芳"---->(仅是举例)等等字符编码针对的是字符到01的映射。

javaunicodee就是字符集囊括了几乎所有文字字符，对每一个文字字符都给予一个编号进行排序就像汉字一样。

utf是字符编码是将每一个文芓字符映射到计算机世界的映射表。分为utf-8utf-16，utf-32发现没有，后缀都是8的倍数因为一个Byte是8Bit，所以utf-8是以一个字节作为基本单位utf-16是两个字节莋为基本单位，utf-32是以4个字节作为基本单位现在的utf-8中ascii部分保持一个字节和ASCII码保持兼容，汉字一般都是3个字节因其良好的兼容性和对内存嘚节省被广泛应用。

java内部采用javaunicodee字符集进行存储并根据你系统的编码集，将javaunicodee字符映射到系统编码集因为javaunicodee几乎囊括了世界上所有的字符。仳如mac笔记本用的是utf-8那么直接将该字符对应的编码输入计算机，计算机就可以识别并显示比如你用的windows是gbk，而“囧"字在javaunicodee编号（注意是编号鈈是编码）是35430那么只需要知道"囧"字在gbk中的编号是4567，再用gbk的编码集将4567序号的字符翻译成对应的二进制编码，输入给计算机系统那么系統就能够正常显示“囧"字啦。这就是java跨国际的能力秘密