java中的字符编码方式

1. 问题由来

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

2. 几种字符编码的方式

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。0~31 是控制字符如换行回车删除等，32~126 是打印字符，能够经过键盘输入而且可以显示出来。

二、非ASCII编码

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

可是，这里又出现了新的问题。不一样的国家有不一样的字母，所以，哪怕它们都使用256个符号的编码方式，表明的字母却不同。好比，130在法语编码中表明了é，在希伯来语编码中却表明了字母Gimel (ג)，在俄语编码中又会表明另外一个符号。可是无论怎样，全部这些编码方式中，0—127表示的符号是同样的，不同的只是128—255的这一段。

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

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

3.Unicode

正如上一节所说，世界上存在着多种编码方式，同一个二进制数字能够被解释成不一样的符号。所以，要想打开一个文本文件，就必须知道它的编码方式，不然用错误的编码方式解读，就会出现乱码。为何电子邮件经常出现乱码？就是由于发信人和收信人使用的编码方式不同。

能够想象，若是有一种编码，将世界上全部的符号都归入其中。每个符号都给予一个独一无二的编码，那么乱码问题就会消失。这就是Unicode，就像它的名字都表示的，这是一种全部符号的编码。

Unicode固然是一个很大的集合，如今的规模能够容纳100多万个符号。每一个符号的编码都不同，好比，U+0639表示阿拉伯字母Ain，U+0041表示英语的大写字母A，U+4E25表示汉字“严”。具体的符号对应表，能够查询unicode.org，或者专门的汉字对应表。

4. Unicode存在的问题：

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

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

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

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

5.UTF-8

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

UTF-8（8-bit Unicode Transformation Format）是一种针对Unicode的可变长度字符编码，又称万国码。由Ken Thompson于1992年建立。如今已经标准化为RFC 3629。UTF-8用1到4个字节编码Unicode字符。用在网页上能够统一页面显示中文简体繁体及其它语言（如英文，日文，韩文）。

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

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

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

2）对于n字节的符号（n>1），第一个字节的前n位都设为1，第n+1位设为0，后面字节的前两位一概设为10。剩下的没有说起的二进制位，所有为这个符号的unicode码。

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

Unicode符号范围 | UTF-8编码方式
UTF字节数                  (十六进制) | （二进制）
--------------------+---------------------------------------------

一个字节 0000 0000-0000 007F | 0xxxxxxx
两个字节 0000 0080-0000 07FF | 110xxxxx 10xxxxxx
三个字节 0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
四个字节 0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

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

已知“严”的unicode是4E25（100111000100101），根据上表，能够发现4E25处在第三行的范围内（0000 0800-0000 FFFF），所以“严”的UTF-8编码须要三个字节，即格式是“1110xxxx 10xxxxxx 10xxxxxx”。而后，从“严”的最后一个二进制位开始，依次从后向前填入格式中的x，多出的位补0。这样就获得了，“严”的UTF-8编码是“11100100 10111000 10100101”，转换成十六进制就是E4B8A5。

6. Unicode与UTF-8之间的转换

经过上一节的例子，能够看到“严”的Unicode码是4E25，UTF-8编码是E4B8A5，二者是不同的。它们之间的转换能够经过程序实现。

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

7. iso8859-1编码

    属于单字节编码，最多能表示的字符范围是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应用软件中，会有多处涉及到字符集编码，有些地方须要进行正确的设置，有些地方须要进行必定程度的处理。

1. getBytes（charset）

    这是java字符串处理的一个标准函数，其做用是将字符串所表示的字符按照charset编码，并以字节方式表示。注意字符串在java内存中老是按unicode编码存储的。好比"中文"，正常状况下（即没有错误的时候）存储为"4e2d 6587"，若是charset为"gbk"，则被编码为"d6d0 cec4"，而后返回字节"d6 d0 ce c4".若是charset为"utf8"则最后是"e4 b8 ad e6 96 87".若是是"iso8859-1"，则因为没法编码，最后返回 "3f 3f"（两个问号）。

java   .class类的编码为：unicode;

windows 默认的编码为：中文：gb2312; 英文：iso8859;

String str = "张三" ;

byte[] jiema= str.getBytes("gb2312") ; //解码

String   bianma = new String(jiema,"UTF-8");//编码 若是上面的解码不对 可能出现问题

2. new String（charset）

    这是java字符串处理的另外一个标准函数，和上一个函数的做用相反，将字节数组按照charset编码进行组合识别，最后转换为unicode存储。参考上述getBytes的例子，"gbk" 和"utf8"均可以得出正确的结果"4e2d 6587"，但iso8859-1最后变成了"003f 003f"（两个问号）。

    由于utf8能够用来表示/编码全部字符，因此new String（ str.getBytes（ "utf8" ）， "utf8" ） === str，即彻底可逆。

3. setCharacterEncoding（）

    该函数用来设置http请求或者相应的编码。

    对于request，是指提交内容的编码，指定后能够经过getParameter（）则直接得到正确的字符串，若是不指定，则默认使用iso8859-1编码，须要进一步处理。参见下述"表单输入".值得注意的是在执行setCharacterEncoding（）以前，不能执行任何getParameter（）。java doc上说明：This method must be called prior to reading request parameters or reading input using getReader（）。并且，该指定只对POST方法有效，对GET方法无效。分析缘由，应该是在执行第一个getParameter（）的时候，java将会按照编码分析全部的提交内容，然后续的getParameter（）再也不进行分析，因此setCharacterEncoding（）无效。而对于GET方法提交表单是，提交的内容在URL中，一开始就已经按照编码分析全部的提交内容，setCharacterEncoding（）天然就无效。

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

4. 处理过程

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

   4.1. 表单输入

    User input *（gbk：d6d0 cec4） browser *（gbk：d6d0 cec4） web server iso8859-1（00d6 00d 000ce 00c4） class，须要在class中进行处理：getbytes（"iso8859-1"）为d6 d0 ce c4，new String（"gbk"）为d6d0 cec4，内存中以unicode编码则为4e2d 6587.

    l 用户输入的编码方式和页面指定的编码有关，也和用户的操做系统有关，因此是不肯定的，上例以gbk为例。

    l 从browser到web server，能够在表单中指定提交内容时使用的字符集，不然会使用页面指定的编码。而若是在url中直接用？的方式输入参数，则其编码每每是操做系统自己的编码，由于这时和页面无关。上述仍旧以gbk编码为例。

    l Web server接收到的是字节流，默认时（getParameter）会以iso8859-1编码处理之，结果是不正确的，因此须要进行处理。但若是预先设置了编码（经过request. setCharacterEncoding （）），则可以直接获取到正确的结果。

    l 在页面中指定编码是个好习惯，不然可能失去控制，没法指定正确的编码。

    4.2. 文件编译

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

    Jsp *（gbk：d6d0 cec4） java file *（gbk：d6d0 cec4） compiler read uincode（gbk： 4e2d 6587； iso8859-1： 00d6 00d 000ce 00c4） compiler write utf（gbk： e4b8ad e69687； iso8859-1： *） compiled file unicode（gbk： 4e2d 6587； iso8859-1： 00d6 00d 000ce 00c4） class.因此用gbk编码保存，而用iso8859-1编译的结果是不正确的。

    class unicode（4e2d 6587） system.out / jsp.out gbk（d6d0 cec4） os console / browser.

    l 文件能够以多种编码方式保存，中文windows下，默认为ansi/gbk.

    l 编译器读取文件时，须要获得文件的编码，若是未指定，则使用系统默认编码。通常class文件，是以系统默认编码保存的，因此编译不会出问题，但对于jsp文件，若是在中文windows下编辑保存，而部署在英文linux下运行/编译，则会出现问题。因此须要在jsp文件中用pageEncoding指定编码。

    l Java编译的时候会转换成统一的unicode编码处理，最后保存的时候再转换为utf编码。

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

    l browser显示网页的时候，首先使用response中指定的编码（jsp文件头指定的contentType最终也反映在response上），若是未指定，则会使用网页中meta项指定中的contentType.

5. 几处设置

    对于web应用程序，和编码有关的设置或者函数以下。

    5.1. jsp编译

    指定文件的存储编码，很明显，该设置应该置于文件的开头。例如：。另外，对于通常class文件，能够在编译的时候指定编码。

    5.2. jsp输出

    指定文件输出到browser是使用的编码，该设置也应该置于文件的开头。例如：。该设置和response.setCharacterEncoding（"GBK"）等效。

    5.3. meta设置

    指定网页使用的编码，该设置对静态网页尤为有做用。由于静态网页没法采用jsp的设置，并且也没法执行response.setCharacterEncoding（）。例如：

    若是同时采用了jsp输出和meta设置两种编码指定方式，则jsp指定的优先。由于jsp指定的直接体如今response中。

    须要注意的是，apache有一个设置能够给无编码指定的网页指定编码，该指定等同于jsp的编码指定方式，因此会覆盖静态网页中的meta指定。因此有人建议关闭该设置。

   5.4. form设置

    当浏览器提交表单的时候，能够指定相应的编码。例如：。通常没必要不使用该设置，浏览器会直接使用网页的编码。