http request乱码的真相

最新推荐文章于 2022-05-15 20:52:06 发布

原创最新推荐文章于 2022-05-15 20:52:06 发布 · 3w 阅读

7 ·

CC 4.0 BY-SA版权

文章标签：

#java #http #tomcat #request #乱码

Java 专栏收录该内容

91 篇文章

订阅专栏

本文深入探讨了HTTP请求中的编码问题，包括浏览器、Web服务器如何处理不同类型的请求编码，以及如何配置和解决可能出现的乱码问题。

当然，终极原因http协议里没有规定request一定要指定编码，导致浏览器，web服务器都各搞一套……

下面一一理清。

首先，从浏览器端看下有多少种情况：

1.在浏览器的地址栏，或者搜索框里输入地址：http://www.test.com/衣服/search?keyword=T恤

2.在一个指定了编码的网页中，提交一个form，如：

<html>
<head>
    <meta charset="gbk">
</head>
<body>
<p>你好</p>
<form id="productSearchForm" action="http://127.0.0.1:8080/test.html" method="post">
	<input name="keyword" class="keyword" value="T恤" maxlength="30">
	<button type="submit">搜索</button>
</form>
</body>
</html>

当然还有，各种细分的选项，如get/post，form里是否指定了编码。

3. ajax请求里的编码。

我们从流程上来看，一个http request要经过哪些东东的处理：

1.浏览器/javascript

2.web server，以tomcat/jetty为例

3.filter/servlet ，以Java为例

4.web 框架，以Spring mvc为例。

对于在浏览器的地址栏支持输入的地址，各种浏览器是如何处理的，可以参考这个：

http://www.ruanyifeng.com/blog/2010/02/url_encoding.html

也可以自己简单的测试，在linux下执行：

nc -l 8080

接着在浏览器里直接访问 http://localhost:8080/衣服/search?keyword=T恤，

然后在就可以看到nc的输出结果了。当然，浏览器的debug工具也可以很方法地看到编码的结果，不过用nc，就不用自己跑一个web服务器了，非常方便。

另外那个keyword=T恤，也是有意选择的，这样可以很方便地看到编码的结果。恤的gbk编码是两个byte，utf-8编码是3个byte，也很容易区别到底是什么编码。

简单地总结下对于浏览器地址栏里直接访问：http://www.test.com/衣服/search?keyword=T恤的编码情况：

对于chrome，“衣服”和“T恤”都是utf-8编码；

对于IE8，“衣服”和“T恤”都是gbk编码。

这里实际上有两个概念，一个是URI的编码，一个是query string（即?后面的字符串）的编码。

http request里的Content-Type设置：

http request是可以指定request的编码信息的，如：

Content-Type: application/x-www-form-urlencoded ; charset=UTF-8

但实际上，浏览器都没有这样提供这样的说明……

form提交里的编码设置：

form可以这样子设置编码：

<form accept-charset="UTF-8" enctype="application/x-www-form-urlencoded;charset=UTF-8"

但是实际上浏览器却不一定会这么做……

比如，把页页编码设置为gbk，再把form编码设置为utf-8。

简单测试，IE8仍然把form编码为gbk，chrome虽然编码为utf-8，但却没有在request里指明。。

当然，还有一个小技巧可以强行使用某种编码，那就是我们先自己转换好编码，如：

<form id="productSearchForm" action="http://127.0.0.1:8080/%A3%A4"

不过，这样意义不大。

web server是如何处理http request的编码的？

只讨论tomcat和jetty。

Tomcat对于URI的编码，有两个参数可以配置：

URIEncoding：这个可以强制指定用什么编码处理URI，默认是ISO-8859-1；

useBodyEncodingForURI：这个是一个兼容性比较好的选项，如果在request指定了编码，则采用request里指定的编码。因此，设置了这个选项为true之后，在java代码里就可以调用request.setCharacterEncoding来设置编码了。

参考：http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q2

Jetty只提供了对query string的编码的指定方式，没有提供对URI编码的设置。因此，对于http:www.test.com/衣服/abcd/ 这样的URI，jetty总是把“/衣服/abcd/”当做是utf-8编码。

参考：http://wiki.eclipse.org/Jetty/Howto/International_Characters#International_characters_in_URLs

Spring mvc是如何处理编码的：

spring mvc里提供了一个Filter：

	<filter>
		<filter-name>encodingFilter</filter-name>
		<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
		<init-param>
			<param-name>encoding</param-name>
			<param-value>UTF-8</param-value>
		</init-param>
		<init-param>
			<param-name>forceEncoding</param-name>
			<param-value>true</param-value>
		</init-param>
	</filter>

到源代码里看一下，可以发现，其实里面只是设置了request的encoding：

		if (this.encoding != null && (this.forceEncoding || request.getCharacterEncoding() == null)) {
			request.setCharacterEncoding(this.encoding);
			if (this.forceEncoding) {
				response.setCharacterEncoding(this.encoding);
			}
		}

但是这个对request URI的编码实际上是不起效的。

再看下源代码里是通过j2ee里的request的API来得到的：

RequestParamMethodArgumentResolver类里：

protected Object resolveName(String name, MethodParameter parameter, NativeWebRequest webRequest) throws Exception {

if (arg == null) {
String[] paramValues = webRequest.getParameterValues(name);
if (paramValues != null) {
arg = paramValues.length == 1 ? paramValues[0] : paramValues;
}
}

最终实际上调用的是底层web server的request实现类，如tomcat的是org.apache.catalina.connector.RequestFacade，而web server到底是怎么处理请求的编码的，参照上一小节。