Web开发乱码问题原理分析

Java web开发过程常常遇到乱码，本篇咱们探讨一下乱码产生的缘由与解决思路。

一次完整的Web请求会有4次编解码转换，以下所示。

 

第一次：客户端（一般为浏览器）将字符转换成TCP字节流发向服务器。

这里有一次字符到字节的转换。

第二次：服务器读取客户端发来的TCP字节流，转换成字符串。

这里是一次字节到字符的转换。

第三次：服务器将结果字符串换成TCP字节流发向客户端。

这里又有一次字符到字节的转换。

第四次：客户端读取服务端发过来的响应字节流。转换成字符串显示。

一个完整的Web请求就结束了。

 

聪明的你已经发现了，第一次转换和第二次转换是一对对应的编解码。第三次和第四次转换是一对对应的编解码。也就是第一次会哪一种字符集编码，第二次就要用相同的字符集解码。

第三次能够选择与前两次不一样的字符集，但第四次必须第三次相同。不错，你已经入门了。

 

咱们怎么找到第一次的编码的字符。Web客户端程序的做者定然知道他用什么字符发送Web请求，咱们就很少说了。咱们这里只说浏览器，由于绝大数请求是浏览器发出来的。

 

浏览器在提交post或get表单时，采用是浏览器当前页面的编码。

查看chrome浏览器、360极速浏览器等当前页面编码：点击浏览器右侧菜单图标，而后依次将鼠标移到“工具”→“编码”便可查看或更改当前页面的编码模式。

而当前页的编码是当浏览器获取该页面时，第四次转换决定的。浏览器是根据响应头和响应正文决定采用哪一种编码。

发现没有，上面咱们说到第一次转换决定了第二次转换的编码，第三次决定了第四次转换的编码。而这里第四次又决定第一次转换的编码。一个环形转换造成了。

A1=A2, A3=A4, A4=A1因此A1=A2=A3=A4. 证实选择相同的字符是完成正确编码的转换的充分条件。

 

说完了第一次编码，咱们讲一下第二次解码。

客户端发过的请求报文，分三部分： 请求行，请求头，POST正文。存在乱码可能的位置有两个地方，请求URL的参数部分和POST正文。（英文字符为何没乱码？ 由于采用ASCII码，绝大部分字符集对英文的编码都同样的）。

服务器在解析这两部分时，分别有自已的字符集。拿Tomcat来讲，urlEncoding参数指定解析URL参数部分的编码。而request.getCharsetEncoding()指定的是解析POST正文的字符集。

 

说完第二次解码，说一下第三次的编码。

服务端将字符发向客户端，必须转换成字节流。用什么编码好呢？ JSP页面有两个设置选项：pageEncoding和contentType。你注意到了吗？

通常状况他们都会同时出现。pageEncoding表示是JSP文件的编码，而contentType是服务端将字符发向客户端的字符集编码。这个字符集会写在响应报文头的Content-Type字段中的。Content-Type:"text/javascript;charset=gbk"。只有contentType存在，好理解。pageEncoding的出现，与contentType有了点情感纠葛。记得是一点。你们知道JSP文件须要编译成Java文件. 

这个过程：1. 读取JSP文件，2. 转换Java类字符串，3.写入JAVA文件。文件都是字节流。读取JSP文件就是采用pageEncoding字符集来解码。写入JAVA的编码一概为UTF-8（由于JAVAC用UTF-8去编译java到class）.

 

这一点情感纠葛就在，contentType不存在时候，pageEncoding字符集会代替他。

 

下面第四次是在浏览器显示最终结果的时候。

浏览器采用响应头中的Content-Type字段来解析响应报头，并显示。

若是Content-Type不存在，则浏览器会采用:
<meta http-equiv=Content-Type content="text/html;charset=gb2312"> 

指定的字符集来解码。

 

完了，听上去好像很简哦，但为何会出现那么多乱码的状况？常见状况：

1. AJAX请求。

AJAX请求的编码是程序设定的。不在A1到A4这环形家庭中。程序

员没能理解各个编码参数做用点，因此出错，由上面4步的分析。若是还不能理解，我只能呵呵。

1. urlEncoding各平不同。

Post正文是由request.getCharsetEncoding()字符集解析，这个字符集是程序控制的。URL的请求参数是由urlEncoding字符集解析的。而urlEncoding通常由服务器设定不同，好比Tomcat默认为iso8859-1。迁移过程当中注意这个。

 

1. JSP文件保存格式不对。

JSP中pageEncoding指定为GBK，JSP文件却保存成UTF-8，转换就成乱码了。后续不用看，确定乱。解决乱码问题必定要先排除这个问题。

 

1. 编码不统一。

一个项目几种编码，什么样的团队呀。子系统内部能够，一跨界，完蛋。

 

若是出现乱码，怎么排查？

 

通常二分法，看看服务端显示是否是正确的，通常将参数System.out输出到Console或者日志（必定要注意日志文件你打开时的编码，原本输出是对的，你反而打开乱了）。

若是能看到正确字符串，通常是第三次或第四次转换不正确，若是看到乱码，前二次转换不正确。第二种状况为绝大多数，由于前一种状况，程序员的参与度很小。

我只说第二种状况：

1. 首先肯定是URL参数，仍是POST参数乱码。

2. 根据1获取urlEncoding或request.getCharsetEncoding.

3. 经过查看浏览器，或经过httpwatch或tcpdump等工具来肯定客户端请求的编码。在我国基本上GBK，UTF-8。UTF-8基本用3个字节表示中文，GBK用两处，很好区分。

4. 改为一致就行了。

                                              2016-12-24夜，苏州