189 8069 5689

Web开发乱码问题原理分析-创新互联

Java web开发过程经常遇到乱码,本篇我们探讨一下乱码产生的原因与解决思路。

成都创新互联致力于网站建设、成都网站制作,成都网站设计,集团网站建设等服务标准化,推过标准化降低中小企业的建站的成本,并持续提升建站的定制化服务水平进行质量交付,让企业网站从市场竞争中脱颖而出。 选择成都创新互联,就选择了安全、稳定、美观的网站建设服务!

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

第一次:客户端(通常为浏览器)将字符转换成TCP字节流发向服务器。

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

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

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

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

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

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

Web开发乱码问题原理分析

一个完整的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不存在,则浏览器会采用:

指定的字符集来解码。

完了,听上去好像很简哦,但为什么会出现那么多乱码的情况?常见情况:

  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夜,苏州

另外有需要云服务器可以了解下创新互联scvps.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。


网页题目:Web开发乱码问题原理分析-创新互联
URL标题:http://cdxtjz.cn/article/gdiho.html

其他资讯