注：本文主要摘自《深入分析Java Web技术内幕》-许令波著
1) ASCII码
ASCII码，总共有128个，用一个字节的低7位来表示，0-31是控制字符（换行、回车等），32-126是打印字符，可以通过键盘输入并且能够显示出来。
2) ISO-8859-1
128个字符显然是不够用的，于是ISO组织在ASCII码基础上又指定了一系列标准来扩展ASCII编码，它们是ISO-8859-1~ISO-8859-15，其中ISO-8859-1涵盖了大多数西欧语言字符，应用比较广泛。然而ISO-8859-1仍是单字节编码，可以表示256个字符。
3) GB2312
GB2312是双字节编码，总的编码范围是A1-F7，其中A1-A9是符号区，包含682个字符，从B0~F7是汉字区，包含6763个汉字。
4) GBK
GBK扩展了GB2312，加入了更多的汉字，它的编码范围为8140-FEFE（去掉XX7F），总共有23940个码位，可以表示21003个汉字，并兼容GB2312。
5) UTF-16
UTF-16定义了Unicode字符在计算机中的存取方法。UTF-16用两个字节表示Unicode格式，它是定长的表示方法，不论什么字符都可以用两个字节表示，两个字节是16bit，所以叫UTF-16。UTF-16表示字符非常方便，每两个字节表示一个字符，简化了字符串操作，这也是Java以UTF-16作为内存的字符格式的一个很重要的原因。
6) UTF-8
UTF-16统一采用两个字节表示一个字符，虽然在表示上非常方便；但是也存在缺点，有很大一部分字符用一个字节就可以表示的，现在要用两个字节表示，存储空间多了一倍，在网络传输中，无疑会增大网络传输流量。UTF-8采用了一种变长技术，每个编码区域有不同的字码长度，不同类型的字符可以由1-6个字节组成，规则如下：
l 如果一个字节，最高位为0，表示这是一个ASCII字符；
l 如果一个字节，以11开头，连续的1的个数暗示这个字符的字节数，如110xxxxx表示它是双字节UTF-8字符的首字节；
l 如果一个字节，以10开始，表示它不是首字节，需要向前查找才能得到当前字符的首字节；
对中文字符GB2312、GBK、UTF-16、UTF-8都可以处理，那如何选择编码格式呢？
GB2312与GBK编码规则类似，只是GBK所包含的范围更大，可以处理所有汉字。UTF-16与UTF-8都是处理Unicode编码，一个是定长编码，一个是变长编码。UTF-16为定长编码，编码效率最高，进行字符到字节的转换也简单，适合本地磁盘和内存之间使用，可以进行字节和字符的快速切换（Java的内存编码采用的是UTF-16）。UTF-16并不适合在网络中传输， UTF-16占用的空间较大；而UTF-8比较适合网络传输，在编码效率上介于GBK和UTF-16，是理想的中文编码方式。
在JavaIO中，IO操作主要涉及字节流和字符流。当字节流和字符流相互转换时（包括磁盘IO和网络IO），需要进行编码，字节流和字符流相互转换过程如下所示:
字节到字符的转换，发生在文件读操作，InputStreamReader是字节到字符转换的桥梁，在转换过程中需要指定编码字符集，若没有指定则采用操作系统默认字符集（由于Java是跨平台的，最好指定编码字符集，否则容易出现乱码问题）。
字符到字节的转换，发生在文件写操作时，在进行转换时，同样需要指定编码格式，若没有指定则也将采用操作系统默认字符集。
在应用程序中只要涉及IO操作，只要指定统一的编码格式，一般不会出现乱码问题。特别是跨平台的应用程序，必须指定编码格式；否则，应用程序的编码格式将和操作系统环境关联起来，在其他环境很可能出现乱码问题。
此外，在内存中进行字符到字节的转换，也要指定编码格式。
当用户从浏览器发起一个HTTP请求，存在编码的地方有URL、Cookie、Parameter。服务器端接受到HTTP请求后解析HTTP协议，其中URI、Cookie和Parameter都需要解码；此外服务端可能还要访问其他资源文件，如数据库、文本文件等，这些数据也存在编码问题。当Servlet处理完请求后，需要将数据返回给浏览器，经浏览器解析后才显示，这个过程也存在编码问题。这些过程如下所示
一次HTTP请求会有很多地方需要编码和解码，它们的编码、解码规则是什么呢？
用户提交一个URL，若存在中文，就需要对URL编码。URL是由多个部分组成的，如下
以Tomcat为例，URL的各个组成部分对应关系如下:
1) domain对应Tomcat配置文件server.xml中Host节点
<Host appBase="webapps"name="localhost" …>
2) port对应Tomcat配置文件server.xml中Connector节点
<Connectorport="9090"protocol="HTTP/1.1"… />
3) context path对应Tomcat配置文件server.xml的Host节点的子节点Context
<Context docBase="jzt"path="/jzt" … />
4) servlet path对应web应用w配置文件web.xml中的url-pattern节点
5) path info对应请求的servlet
6) parameter为对应GET请求的参数
在上面的请求中pathinfo和parameter中都出现了中文，那么在浏览器中输入URL时，浏览器是如何编码这个URL呢？最终浏览器（ChromeVersion 44.0.2403.157 Mac版）将URL编码为:
http://localhost:8080/examples/servlets/servlet/%E5%90%9B%E5%B1%B1?author=%E5%90%9B%E5%B1%B1
经过测试pathinfo和parameter中“君山”的编码为UTF-8编码。为什么会有%，URL编码规范RFC3986可知，浏览器编码URL将非ASCII字符按照某种编码格式编码成16进制后，将每个16进制表示的字节前加上“%”。
虽然上面pathinfo和parameter中的中文采用的是相同的编码，但不同浏览器对pathinfo的编码可能并不相同，对服务器的解码造成了很大困难。所以在实际应用中pathinfo一般并不采用中文。
Tomcat对URI部分进行解码的字符集是在connect中定义的，<ConnectorURIEncoding="UTF-8"port="9090"protocol="HTTP/1.1"…/>，如果没有定义将以默认编码ISO-8859-1来解析。所以有中文URI时最好将URIEncoding设置为UTF-8编码。
服务器对请求的参数是如何解析呢？GET请求的参数和POST请求的参数在服务端都是通过HttpRequest对象的getParameter方法获取。对请求参数的解码是第一次调用getParameter时进行的（以Tomcat为例，详情可参考Tomcat源码）。但是对GET请求和POST请求解析参数时，使用的字符集可能并不相同。那么GET请求参数和POST请求参数的解码字符集是在哪里定义的呢？
GET请求参数的解码字符集要么是Header中ContentType定义的Charset，要么就是默认的ISO-8859-1，要使用ContentType中定义的编码解码就需要设置Tomcat配置文件server.xml中connector的useBodyEncodingForURI属性为true，<ConnectorURIEncoding="UTF-8"useBodyEncodingForURI="true" …/>
useBodyEncodingForURI为true，将会对GET请求参数采用BodyEncoding（HTML页面中的contentType属性中定义的字符集）进行解码，而并不是对URI整体采用BodyEncoding进行解码。
URL编码和解码是比较复杂的，在应用程序中尽量避免使用非ASCII字符，不然很可能会遇到乱码问题。此外，服务器最好在<Connector/>设置URIEncoding和useBodyEncodingForURI两个参数。
当客户端发起一个HTTP请求时，除了URL外还可能会在Headr中传递其他参数，如Cookie等，这些参数很可能也会存在编码问题。
Tomcat对Header中参数解码也是调用HttpRequest对象的getHeader方法时进行的。如果请求的Header中没有解码字符集，将采用默认编码ISO-8859-1对参数进行解码，如果请求Header中有非ASCII字符则很可能会产生乱码。
当向服务器返回数据时，如果需要添加头信息，如Cookie，最好不要在Header中传递非ASCII码。如果一定要传递，可以先将这些字符采用URLEncoder进行编码，再添加到Header中。这样浏览器将Cookie信息发送到服务器时就可可以采用同样的字符集解码就好了。
POST请求的参数是通过HTTP的BODY传递到服务器端的。浏览器是如何对POST请求的参数进行编码呢？浏览器将根据请求页面的contentType中的charset编码格式对参数进行编码，然后提交到服务器。在服务器端，服务器也是根据contentType中的charset编码对其解码的（服务如何获取该值呢？），所以POST请求参数一般不会出现乱码。
注意；Tomcat在解析请求参数前会先获取Header中的contentt-type请求头，并检查这个content-type中的charset值，默认情况下浏览器在提交form表单时，提交的content-type中是不会含有charset信息的。所以如果没有调用requet.setCharacterEncoding方法设置解析编码集，那么表单的数据会按照系统的默认编码方式解析。注意一定要在第一次调用getParameter方法之前设置，否则POST请求参数也可能出现乱码。
此外，对multipart/form-data类型的参数，也就上传文件的编码，同样也使用ContentType中的字符集。上传文件是用字节流的方式传输到服务器的本地临时目录，这个过程并没有涉及字符编码。当将文件内容添加到parameters中时，将会进行编码，如果没有编码集可用，将采用默认编码ISO-8859-1。
当用户请求成功后，请求的资源将通过Response返回给浏览器。这个过程先要经过编码再到浏览器进行解码，编码字符集可以通过response.serCharacterEncoding方法来设置，并通过Header的Content-Type返回给客户端。浏览器接收到响应后将根据Content-Type中的charset来解码。如果返回的HTTPHeader中没有charset，那么浏览器将根据HTML的
<metahttp-equiv="Content-Type"content="text/html; charset=UTF-8">
中charset来解码；如果也没有定义，那么浏览器将采用默认的编码来解码。
在HTML页面或JSP页面引入外部JS文件时，外部文件可能存在中文。这时，如果没有在<script>标签内设置charset，浏览器就会以当前页面的默认的字符集来解析js文件。所以在引入外部js文件时，需要在<script>标签内添加charset属性，如下
<scripttype="text/javascript"src=""charset="utf-8"/>
此外，通过js发起异步调用的URL默认编码也是受浏览器影响的，如果使用原始的ajax调用，URL的默认编码，随浏览器的不同而不同；而且，不同的js框架对URL编码的处理也不同。为了解决该问题，在发送异步请求时可以调用JS的encodeURI方法来对URL中的字符进行UTF-8编码;解码时可以通过decodeURI。此外encodeURIComponent方法比encodeURI编码还要彻底，该函数通常用于将一个URL当作一个惨呼放在另一个URL中；解码可以通过decodeURIComponent。
当经过编码的URL传递到服务器时，需要使用java.net.URLDecoder来对参数进行解码，或将结果经编码后返回到浏览器可以通过java.net.URLEncoder。（服务器端的URLEncoder和URLDecoder与JS的encodeURIComponent和decodeURIComponent对应）。
1) 数据库编码
访问数据库时一般都是通过JDBC驱动来完成的，用JDBC来存取数据要和数据的内置编码一致。在创建数据库时（以mysql为例）要显示指定字符集，如下
CREATE DATABASE IF NOT EXISTS db DEFAULT CHARSET utf8 COLLATEutf8_general_ci;
在连接数据库通过URL指定字符编码，如
url=”jdbc:mysql://localhost:3306/DB?useUnicode=true&characterEncoding=UTF-8”。
2) 下载文件
当我们下载文件时，若资源名为中文，有可能会出现乱码，此时我们可以先将资源名，采用URLEncoding进行编码，再将其写入到相应头中，如下
public void doPost(HttpServletRequest request, HttpServletResponse response)
throwsServletException,IOException
{
ServletContext context=this.getServletContext();
String path= context.getRealPath("/res/许嵩.bmp");
/*获取下载的资源*/
File file =new File(path);
/*构造文件的输入流*/
InputStream is=new FileInputStream(file);
/*写：输出流*/
/*文件的下载头信息*/
response.setHeader("content-disposition","attachment;filename="+URLEncoder.encode(file.getName(),"UTF-8"));
OutputStream os= response.getOutputStream();
bytebuffer[]=newbyte[1024];
int len=0;
while((len=is.read(buffer))!=-1){
os.write(buffer,0,len);
}
3) xml、jsp等编码格式
xml编码格式：<?xmlversion="1.0"encoding="UTF-8"?>
jsp编码格式: <%@ page language="java"contentType="text/html; charset=UTF-8"pageEncoding="UTF-8"%>
当我们使用request.getParameter获取参数后，若存在乱码，我们可能会采用下面的方式转码：
String(request.getParameter(name).getBytes(“ISO-8859-1”),”GBK”)
转码后可能会得到正确的汉字。由于ISO-8859-1字符集的编码范围为0000-00FF，正好和一个字节的编码范围对应。这种特性保证了使用ISO-8859-1进行编码和解码时可以保持编码数值“不变”。虽然中文字符经过网络传输时，被错误地“拆分”为两个欧洲字符，但由于在服务端第一次解析时也采用默认字符集IOS-8859-1进行解码，被错误拆分的两个字符又被合并在一起，从而组成一个正确的汉字。不建议使用该种解码方式，会增加额外的编码与解码过程。
版权声明：本文为博主原创文章，未经博主允许不得转载。
原文地址：http://blog.csdn.net/sunshuolei/article/details/48135505
