java中主要有四个场景需要进行编码解码

在java中主要有四个场景需要进行编码解码操作：
 (1)：I/O操作

 (2)：内存

 (3)：数据库

 (4)：javaWeb

I/O操作

在前面LZ就提过乱码问题无非就是转码过程中编码格式的不统一产生的，比如编码时采用UTF-8，解码采用GBK，但最根本的原因是字符到字节或者字节到字符的转换出问题了，而这种情况的转换最主要的场景就是I/O操作的时候。当然I/O操作主要包括网络I/O（也就是javaWeb）和磁盘I/O。网络I/O下节介绍。

首先我们先看I/O的编码操作。

InputStream为字节输入流的所有类的超类，Reader为读取字符流的抽象类。java读取文件的方式分为按字节流读取和按字符流读取，其中InputStream、Reader是这两种读取方式的超类。

按字节

我们一般都是使用InputStream.read()方法在数据流中读取字节（read()每次都只读取一个字节，效率非常慢，我们一般都是使用read(byte[])），然后保存在一个byte[]数组中，最后转换为String。在我们读取文件时，读取字节的编码取决于文件所使用的编码格式，而在转换为String过程中也会涉及到编码的问题，如果两者之间的编码格式不同可能会出现问题。例如存在一个问题

test.txt编码格式为UTF-8，那么通过字节流读取文件时所获得的数据流编码格式就是UTF-8，而我们在转化成String过程中如果不指定编码格式，则默认使用系统编码格式（GBK）来解码操作，由于两者编码格式不一致，那么在构造String过程肯定会产生乱码，如下：

File file = new File("C:\\test.txt");        
InputStream input = new FileInputStream(file);       
StringBuffer buffer = new StringBuffer();        
byte[] bytes = new byte[1024];        
for(int n ; (n = input.read(bytes))!=-1 ; ){            
  buffer.append(new String(bytes,0,n));        
}        
System.out.println(buffer);

输出结果：锘挎垜鏄?cm

test.txt中的内容为：我是 cm。

要想不出现乱码，在构造String过程中指定编码格式，使得编码解码时两者编码格式保持一致即可：

buffer.append(new String(bytes,0,n,"UTF-8"));

按字符

其实字符流可以看做是一种包装流，它的底层还是采用字节流来读取字节，然后它使用指定的编码方式将读取字节解码为字符。在java中Reader是读取字符流的超类。所以从底层上来看按字节读取文件和按字符读取没什么区别。在每次读取的时候字符流读取2个字节，字节流每次读取一个字节。

字节&字符转换

字节转换为字符一定少不了InputStreamReader。

API解释如下：InputStreamReader 是字节流通向字符流的桥梁：它使用指定的 charset 读取字节并将其解码为字符。它使用的字符集可以由名称指定或显式给定，或者可以接受平台默认的字符集。 

每次调用 InputStreamReader 中的一个 read() 方法都会导致从底层输入流读取一个或多个字节。要启用从字节到字符的有效转换，可以提前从底层流读取更多的字节，使其超过满足当前读取操作所需的字节。API解释非常清楚，InputStreamReader在底层读取文件时仍然采用字节读取，读取字节后它需要根据一个指定的编码格式来解析为字符，如果没有指定编码格式则采用系统默认编码格式。

String file = "C:\\test.txt";
String charset = "UTF-8";          
// 写字符换转成字节流         
FileOutputStream outputStream = new FileOutputStream(file);          
OutputStreamWriter writer = new OutputStreamWriter(outputStream, charset);         
try {             
    writer.write("我是 cm");          
} finally {             
    writer.close();          
}                   
// 读取字节转换成字符         
FileInputStream inputStream = new FileInputStream(file);          
InputStreamReader reader = new InputStreamReader(inputStream, charset);
StringBuffer buffer = new StringBuffer();          
char[] buf = new char[64];          
int count = 0;          
try {
  while ((count = reader.read(buf)) != -1) {                 
   buffer.append(buf, 0, count);             
  }          
} finally {            
   reader.close();          
  }         
System.out.println(buffer);

内存

首先我们看下面这段简单的代码

String s = "我是 cm";          
byte[] bytes = s.getBytes();         
String s1 = new String(bytes,"GBK");          
String s2 = new String(bytes);

在这段代码中我们看到了三处编码转换过程（一次编码，两次解码）。先看String.getBytes():

public byte[] getBytes() {        
    return StringCoding.encode(value, 0, value.length);    
}

内部调用StringCoding.encode()方法操作：

encode(char[] paramArrayOfChar, int paramInt1, int paramInt2)方法首先调用系统的默认编码格式，如果没有指定编码格式则默认使用ISO-8859-1编码格式进行编码操作，进一步深入如下：
String csn = (charsetName ==  null) ? "ISO-8859-1" : charsetName;

同样的方法可以看到new String 的构造函数内部是调用StringCoding.decode()方法：

decode方法和encode对编码格式的处理是一样的。

对于以上两种情况我们只需要设置统一的编码格式一般都不会产生乱码问题。

JAVAWEB中的编码解码

对于我们从事java开发的人而言，其实最容易也是产生乱码最多的地方就是web部分。首先我们来看在javaWeb中有哪些地方存在编码转换操作。

编码&解码

通过下图我们可以了解在javaWeb中有哪些地方有转码：

用户想服务器发送一个HTTP请求，需要编码的地方有url、cookie、parameter，经过编码后服务器接受HTTP请求，解析HTTP请求，然后对url、cookie、parameter进行解码。在服务器进行业务逻辑处理过程中可能需要读取数据库、本地文件或者网络中的其他文件等等，这些过程都需要进行编码解码。当处理完成后，服务器将数据进行编码后发送给客户端，浏览器经过解码后显示给用户。在这个整个过程中涉及的编码解码的地方较多，其中最容易出现乱码的位置就在于服务器与客户端进行交互的过程。

上面整个过程可以概括成这样，页面编码数据传递给服务器，服务器对获得的数据进行解码操作，经过一番业务逻辑处理后将最终结果编码处理后传递给客户端，客户端解码展示给用户。所以下面我就请求对javaweb的编码&解码进行阐述。

请求

客户端像服务器发送请求无非就通过四种情况：

1、URL方式直接访问。

2、页面链接。

3、表单get提交

4、表单post提交

URL方式

对于URL，如果该URL中全部都是英文的那倒是没有什么问题，如果有中文就要涉及到编码了。如何编码？根据什么规则来编码？又如何来解码呢？下面LZ将一一解答！首先看URL的组成部分：

在这URL中浏览器将会对path和parameter进行编码操作。为了更好地解释编码过程，使用如下URL

http://127.0.0.1:8080/perbank/我是cm?name=我是cm

将以上地址输入到浏览器URL输入框中，通过查看http 报文头信息我们可以看到浏览器是如何进行编码的。下面是IE、Firefox、Chrome三个浏览器的编码情况：

可以看到各大浏览器对“我是”的编码情况如下：

	path部分	Query String
Firefox	E6 88 91 E6 98 AF	E6 88 91 E6 98 AF
Chrome	E6 88 91 E6 98 AF	E6 88 91 E6 98 AF
IE	E6 88 91 E6 98 AF	CE D2 CA C7

查阅上篇博客的编码可知对于path部分Firefox、chrome、IE都是采用UTF-8编码格式，对于Query String部分Firefox、chrome采用UTF-8，IE采用GBK。至于为什么会加上%，这是因为URL的编码规范规定浏览器将ASCII字符非 ASCII 字符按照某种编码格式编码成 16 进制数字然后将每个 16 进制表示的字节前加上“%”。

当然对于不同的浏览器，相同浏览器不同版本，不同的操作系统等环境都会导致编码结果不同，上表某一种情况，对于URL编码规则下任何结论都是过早的。由于各大浏览器、各个操作系统对URL的URI、QueryString编码都可能存在不同，这样对服务器的解码势必会造成很大的困扰，下面我们将以tomcat，看tomcat是如何对URL进行解码操作的。

解析请求的 URL 是在 org.apache.coyote.HTTP11.InternalInputBuffer 的 parseRequestLine 方法中，这个方法把传过来的 URL 的 byte[] 设置到 org.apache.coyote.Request 的相应的属性中。这里的 URL 仍然是 byte 格式，转成 char 是在 org.apache.catalina.connector.CoyoteAdapter 的 convertURI 方法中完成的：

对URI的解码操作是首先获取Connector的解码集，该配置在server.xml中

<Connector URIEncoding="utf-8"  />

如果没有定义则会采用默认编码ISO-8859-1来解析。

从上面代码可以看出对query String的解码格式要么采用设置的编码，要么采用默认的解码格式ISO-8859-1

URIEncoding是对所有GET方式的请求的数据进行统一的重新编码（解码），而useBodyEncodingForURI是根据post请求的编码决定URI的编码

上面部分详细介绍了URL方式请求的编码解码过程。其实对于我们而言，我们更多的方式是通过表单的形式来提交。

表单GET

我们知道通过URL方式提交数据是很容易产生乱码问题的，所以我们更加倾向于通过表单形式。当用户点击submit提交表单时，浏览器会根据设定的编码来编码数据传递给服务器。通过GET方式提交的数据都是拼接在URL后面（可以当做query String）来提交的，所以tomcat服务器在进行解码过程中URIEncoding就起到作用了。tomcat服务器会根据设置的URIEncoding来进行解码，如果没有设置则会使用默认的ISO-8859-1来解码。假如我们在页面将编码设置为UTF-8，而URIEncoding设置的不是或者没有设置，那么服务器进行解码时就会产生乱码。这个时候我们一般可以通过new String(request.getParameter("name").getBytes("iso-8859-1"),"utf-8") 的形式来获取正确数据。

表单POST

对于POST方式，它采用的编码也是由页面来决定的即contentType。当我通过点击页面的submit按钮来提交表单时，浏览器首先会根据contentType的charset编码格式来对POST表单的参数进行编码然后提交给服务器，在服务器端同样也是用contentType中设置的字符集来进行解码（这里与get方式就不同了），这就是通过POST表单提交的参数一般而言都不会出现乱码问题。当然这个字符集编码我们是可以自己设定的：request.setCharacterEncoding(charset) 。

JSP页面编码过程

我们知道JSP页面是需要转换为servlet的，在转换过程中肯定是要进行编码的。在JSP转换为servlet过程中下面一段代码起到至关重要的作用。

1. <%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="GBK" %>  

在上面代码中有两个地方存在编码：pageEncoding、contentType的charset。其中pageEncoding是jsp文件本身的编码，而contentType的charset是指服务器发送给客户端时的内容编码。

在前面一篇博客中就提到过jsp在转换为Servlet的过程中是需要经过主要的三次编码转换过程（除去数据库编码转换、页面参数输入编码转换）：

第一次：转换为.java文件；

第二次：转换为.class文件；

第三次：业务逻辑处理后输出。

第一阶段

JVM将JSP编译为.jsp文件。在这个过程中pageEncoding就起到作用了，JVM首先会获取pageEncoding的值，如果该值存在则采用它设定的编码来编译，否则则采用file.encoding编码来编译。

第二阶段

JVM将.java文件转换为.class文件。在这个过程就与任何编码的设置都没有关系了，不管JSP采用了什么样的编码格式都将无效。经过这个阶段后.jsp文件就转换成了统一的Unicode格式的.class文件了。

第三阶段

后台经过业务逻辑处理后将产生的结果输出到客户端。在这个过程中contentType的charset就发挥了功效。如果设置了charset则浏览器就会使用指定的编码格式进行解码，否则采用默认的ISO-8859-1编码格式进行解码处理。

流程如如下：

数据库编码

最近做项目的时候，有时会遇到中文乱码的问题，网上查询了很多资料，发现大多都是只讲解决方案，并没有讲到为什么要使用这种方案，这种方案的原理是什么？

最典型的就是连接数据库的URL，我们一般把它放到classpath下的db.properties中，然后尽管我们的Java代码设置了UTF-8，JSP也设置了UTF-8，数据库也设置了UTF-8，但是插入数据到数据库中仍然会出现中文乱码，最后我们的解决方案是在连接数据库的URL上加上连接使用的编码格式UTF-8，但是我们会纳闷为什么要这么做呢？

下面我们来聊下java编码的问题，为什么要编码，有哪些编码，怎么编码和解码，为什么会有中文乱码，怎么解决中文乱码。

1.为什么要编码

这个问题必须要回到计算机是如何表示我们人类能够理解的符号的，这些符号也就是我们人类使用的语言。由于人类的语言太多，因而表示这些语言的符号太多，无法使用计算机中一个基本的存储单元---byte来表示，因而必须要经过拆分或一些翻译工作，才能让计算机理解我们的语言。我们可以把计算机能够理解的语言假定为英语，其他语言要能够在计算机中使用必须经过一次翻译，把它翻译成英语。这个翻译的过程就是 编码。

所以总的来说，编码的原因可以总结为：计算机中存储信息的最小单元是一个字节，即8个bit，所以能表示的字符范围是0-255个；人类要表示的符号太多，无法用一个字节来完全表示。

要解决这个矛盾必须要有一个新的数据结构char，从char到byte必须编码。

2.常见的编码

明白了各种语言需要交流，经过翻译是必须的，那么又如何来翻译呢？计算机中提供了多种翻译方式，常见的有ASCII，ISO-8859-1，GB2312，GBK，UTF-8，UTF-16等。他们可以被看做字典，他们规定了转化的规则，按照这个规则可以让计算机正确地标识我们的字符。目前的编码格式很多，如GB2312，GBK，UTF-8，UTF-16都可以标识一个汉字，那我们到底选择哪种编码格式来存储汉字呢？这就要考虑其他因素呢，是存储空间重要还是编码的效率重要。

3.怎么编码，解码

以String为例，代码如下：

1. String s="这是一段中文字符串";  
2. byte[] b=s.getBytes("UTF-8");  
3. String n=new String(b,"UTF-8");  

编码的用途：把我们用户能够认识的语言转化为计算机能够认识的语言，一般用在传输或者存储时，也就是涉及到计算机的操作而不是针对用户而言。

解码：把字节码解释为我们用户能够认识的语言。

4.为什么有中文乱码

第一种情况：使用不能识别中文的字符集来编码，这种情况比较少见

第二种情况，使用一种字符集来编码，却用另一种字符集来解码，这种比较多见，比如，java代码采用UTF-8编码，但是访问数据库的时候，数据库采用GBK来解码，这就会出现中文乱码。

Charset使用

1. Charset charset=Charset.forName("UTF-8");  
2. ByteBuffer byteBuffer=charset.encode(string);  
3. CharBuffer charBuffer=charset.decode(byteBuffer);