一文让你从此告别HTTP乱码（二）Response篇

骑猪看日落 2022-03-29 12:48 80阅读 0赞

摘自：[https://www.cnblogs.com/brucecloud/p/6609781.html][https_www.cnblogs.com_brucecloud_p_6609781.html]

## 概述 ##

开发Web项目的过程中，经常遇到浏览器中显示的内容乱码，或者服务器获取浏览器请求参数时乱码的问题，很多同学基本都是在遇到乱码的时候去网上一顿搜索，然后看哪篇文章比较靠谱就照着上面的内容去配后乱码成功消失了，然后就没然后了...

最后基本只是停留在知道怎么样设置能避免常见的乱码问题，而不知道具体的原理，一旦遇到了网上查不到的乱码场景就不知道如何解决了~

本文会深入的让你了解针对于HTTP请求时，这一去一回（Request，Response）之间，到底做了怎样的事情，让你彻底告别Web项目中的乱码烦恼。本文的内容是基于Tomcat 8.0.23版本的，其他容器也可以参考本文的内容，毕竟理论都是通的~

## Response乱码 ##

当你在浏览器中看到响应的内容是乱码的时候，第一反应就是，是不是我程序的问题，是不是我程序吐出的内容就是个乱码，所以才导致了浏览器里面看到了乱码。那么接下来我将带你过一遍Response的过程，以及对刚才的猜测进行验证~

首先，我建了一个非常简单的Web项目，里面只有一个Servlet，作用是直接返回我要响应的内容~

项目结构如下：

![853900-20170321174711533-522113046.png][]

Servlet内容如下：

![853900-20170321174315643-1812231477.png][]

web.xml内容如下：

![853900-20170321174432736-281253133.png][]

接下来我们在浏览器中访问：http://localhost:8080

首先在Firefox中访问，结果如下：

![853900-20170321174828596-874535992.png][]

接下来再在QQ Browser中访问，结果如下：

![853900-20170321175636424-1660033784.png][]

此时我们看见2个浏览器中展示的内容无论是浏览器正文还是下面的Response标签中显示的字符都是乱码，并且是相同的乱码内容~

那么这个乱码是怎么产生的呢？回头再去看我们servlet中的代码：

![853900-20170321180231643-303949776.png][]

代码中可以看见我们没有指定任何的编码相关内容，那么Tomcat在将result字符串转换成字节数组时会使用HTTP规范的默认编码ISO-8859-1，于是输出的内容就是将result进行ISO-8859-1编码后的字节数组，

因为ISO-8859-1能表示的字符数量有限，它无法表示中文，所以在此时Response的内容与就已经是乱码了。

然后Response到达浏览器，浏览器会获取Response中的内容，因为Response中的响应头中没有指定信息的编码类型，所以浏览器会尝试根据编码规则进行推测，并根据推测进行解码，由于我使用的是中文系统，Firefox

的正文部分采用的是GBK编码，而Response中的内容则使用了UTF-8编码。QQ Browser正文部分使用的也是GBK编码，而Resopnse中的内容则使用了ISO-8859-1编码（不同浏览器，或者同一个浏览器的不同版本解码使用的编码都可能会不一样），

解码之后就是我所看见的 ???~????! 乱码了。

下面这段程序就可以验证上面的内容：

![853900-20170322101641440-878412217.png][]

上面的验证本质上是因为在Servlet中处理Response的时候没有指定编码，从而导致了使用了默认的ISO-8859-1对Response的内容（楚楚街~卖得漂亮!）进行了编码，但是因为ISO-8859-1无法表示中文，结果在Servlet编码

时就已经产生了乱码，之后无论你怎么解码它都是个乱码。

接下来我们改进下Servlet，使其在Response的时候使用UTF-8（因为UTF-8可以表示中文）进行编码，代码如下：

![853900-20170322103128190-1939877214.png][]

然后我们再次请求http://localhost:8080

Firefox结果如下：

![853900-20170322103224502-377310396.png][]

QQ Browser结果如下：

![853900-20170322103254971-1337198282.png][]

从结果我们可以看出，Firefox中正文依然乱码，而Response的内容正确解析了，而QQ Browser中正文和Response中的内容都是乱码。

根据之前的分析，我们已经知道Firefox的正文是GBK编码，Response内容是UTF-8编码，而QQ Browser中的正文也是GBK编码，Response的内容是ISO-8859-1编码。

下面代码对上面的内容进行了验证：

![853900-20170322103927690-1349990098.png][]

我们在对Servlet返回给2个浏览器的Response进行一下抓包，看下Response的内容到底是啥~

对Firefox的抓包：

![853900-20170322105258111-1117363485.png][]

对QQ Browser的抓包：

![853900-20170322105343518-1521432441.png][]

从结果我们可以看到2个浏览器收到的Response的结果都是相同的，其中Data部分都是e6a59ae6a59ae8a1977ee4b9b0e79a84e6bc82e4baae21，这串值就是

对 楚楚街~买的漂亮! 进行UTF-8编码后的值。

到此为止，做一个小总结：

1.Response在返回前会对要返回的内容做编码，在不指定（setCharacterEncoding("UTF-8")）的情况下会使用默认的ISO-8859-1编码。

2.不同的浏览器在收到返回的Response时，获取到的内容是一致的，之后浏览器会根据自身的策略对内容进行解析。

继续上面的乱码问题，为什么这次使用UTF-8对中文进行了编码后，浏览器里面依然是乱码呢？原因就是在Response中没有对响应的内容使用的是哪种编码做说明，导致了

浏览器不知道使用哪种编码做解码，然后就使用了浏览器默认的解码行为进行解码，从而导致了乱码。

接下来我们为Response加上响应头Content-Type:text/plain; charset=utf-8来告诉浏览器，Response内容应该用什么编码来解码，代码如下：

![853900-20170322161848643-479405512.png][]

上面的代码中，我们指定了2次编码并且2次的编码不一致，那么到底会使用哪个编码呢？还会出现乱码么？看实际结果说话~

Firefox结果：

![853900-20170322160416736-693501158.png][]

QQ Browser结果：

![853900-20170322160442971-10801962.png][]

我们可以看到，2个浏览器无论是正文部分还是Response的内容中都正确的解码了~

总结：

1.Response需要告知浏览器使用哪一种编码来解码其内容。

2.Response所使用的编码为最后一次设置的编码，也就是说后面的编码设置信息会覆盖掉前面的编码设置信息。

接下来我们再来使用命令行来请求下试试，如下图：

![853900-20170322174327861-1381140246.png][]

发现结果居然是乱码，难道之前的结论是错误的？什么鬼...

其实之前的结论并没错，而是之前的结论需要加个限定条件（只适用于浏览器），我们把HTTP请求的Response可以划分为2个步骤，第一步是获取到这个Response，第二步就是对

这个Response进行解析，上面的问题就出现在了第二步（解析）。因为浏览器是遵循HTTP规范的，HTTP规范中说明了响应头中的Content-Type属性中的charset指定的编码就是Response

中内容的实际编码，所以浏览器会使用这个charset中指定的编码对Response中的内容进行解码，那么自然没问题了，而命令行则不需要遵循HTTP中的规范，所以命令行并没有关心charset指定

的内容，而是使用命令行默认的编码进行解码的，所以导致了乱码，知道了问题的根本原因，那么是不是我们改变了命令行的编码就可以正确显示了呢？看下面结果：

![853900-20170322175252549-180950200.png][]

首先我们修改了命令行的编码为UTF-8（chcp 65001），然后重新请求后，发现显示正常了~

到此为止~Response时的乱码问题成功解决啦~

Response乱码总结：

1.Response在返回前会对要返回的内容做编码，在不指定编码的情况下会使用默认的ISO-8859-1编码。

2.不同的浏览器在收到返回的Response时，获取到的内容是一致的，之后浏览器会根据自身的策略对内容进行解析。

3.Response需要告知浏览器使用哪一种编码来解码其内容。

4.Response所使用的编码为最后一次设置的编码，也就是说后面的编码设置信息会覆盖掉前面的编码设置信息。

5.浏览器会遵循HTTP规范，使用Content-Type属性中的charset指定的编码去解码，而命令行工具则不会关注charset的内容，而是根据命令行自身的编码方案进行解码。

[https_www.cnblogs.com_brucecloud_p_6609781.html]: https://www.cnblogs.com/brucecloud/p/6609781.html
[853900-20170321174711533-522113046.png]: /images/20220329/68efe03737414570a90835cf2eaad5f1.png
[853900-20170321174315643-1812231477.png]: /images/20220329/5a7bdb5459bf48719e34e37287cc4eca.png
[853900-20170321174432736-281253133.png]: /images/20220329/7f60aa5343064bfb943ce053c9f857ca.png
[853900-20170321174828596-874535992.png]: /images/20220329/259da5fe98674362a7306a93ec0098c7.png
[853900-20170321175636424-1660033784.png]: /images/20220329/ddbc3352cfe14cc4b0085b3c929b8a8d.png
[853900-20170321180231643-303949776.png]: /images/20220329/a62e167a2be84eec9d8e42c87f34524c.png
[853900-20170322101641440-878412217.png]: /images/20220329/58d2e259c1484044b53da7bab7dbf4ed.png
[853900-20170322103128190-1939877214.png]: /images/20220329/4b04bbf60d604b8e88be8c939ea90f1a.png
[853900-20170322103224502-377310396.png]: /images/20220329/da1859cdc40046f4ac173e6ab294475f.png
[853900-20170322103254971-1337198282.png]: /images/20220329/d146495f2d2e4677afda8d862b181c55.png
[853900-20170322103927690-1349990098.png]: /images/20220329/75e2a271d6204f8ab3cb1852ff82bd43.png
[853900-20170322105258111-1117363485.png]: /images/20220329/f055efc2a5ff4c46a35f5b1080bf4dad.png
[853900-20170322105343518-1521432441.png]: /images/20220329/4dc1abc84b6647729ffd1d7f0e6dba94.png
[853900-20170322161848643-479405512.png]: /images/20220329/0a328749b3034756810ca08cf8d28f07.png
[853900-20170322160416736-693501158.png]: /images/20220329/12a8f8979d6b49b3b38b4a48fa3a5b18.png
[853900-20170322160442971-10801962.png]: /images/20220329/fed98057f62340d7af1f668de9adc31a.png
[853900-20170322174327861-1381140246.png]: /images/20220329/75cda109d24241c78e4bfb06e89d1114.png
[853900-20170322175252549-180950200.png]: /images/20220329/6d55b61c73434619b3425ac20c4afccb.png