web开发中的中文编码问题

时间 2019-11-12

标签 web 开发中文编码问题栏目 HTML 繁體版

原文原文链接

1、发起http请求时的字符编码方式一般有两种：

1 以某种编码直接发送字符，好比发送“飞”的gbk编码，程序若是以Latin1(iso-8859-1)字符集去识别它，将获得”难读“的字符信息："·É"javascript

要转换为正常的字符须要以下处理：html

String correct = new String(word.getBytes("iso-8859-1"),"gbk");    //word为上述的难读的latin1字符串

2 以某种编码如GBK进行Base64编码的转换，如"飞"字符以GBK进行Base64转换可得："%B7%C9"；以UTF-8进行Base64转换得：”%E9%A3%9E“java

要转换为正常的字符须要以下处理：web

String correct = URLDecoder.decode(word, "gbk");       //若是是utf-8转来的则使用utf-8

2、而经过浏览器发起http请求一般有如下几种行为：

  1 在浏览器地址栏输入地址进行访问
  2 页面表单的get和post提交
  3 页面超连接
  4 ajax异步请求

其中ajax异步请求的编码方式可由javascript控制，此处再也不讨论。ajax

对于其余的三种行为，不一样的浏览器的编码处理方式并不一致，如下以IE和Firefox进行比较分析：浏览器

浏览器：IE8.0 和 Firefox6.0tomcat

web服务器：tomcat 6.0.18(本文的服务器都采用tomcat来描述，适用的版本是5.x、6.x)服务器

测试方式：分别以地址栏输入、页面超连接、表单的get/post几种不一样的请求行为去访问web服务器，经过web服务器的access_log来查看中文数据的编码方式。异步

测试的中文请求数据：http://localhost:8083/struts/飞?word=飞(uri部分为/struts/飞、参数部分为word=飞)ide

html页面：分别有GBK编码和UTF8编码的页面两个(除了页面编码外，其余内容一致)：

 1 <html>
 2 <head>
 3 <meta http-equiv="Content-Type" content="text/html; charset=gbk">  <!-- 指定页面编码 -->
 4 </head>
 5 <body>
 6 <hr/>
 7 <center>
 8   <form action="http://localhost:8083/struts/飞" method="get">     <!-- 表单get方式发起请求 -->
 9  get表单： 10   <input name="word" type="text" value="飞"/>
11   <input type="submit" value="submit"/>
12   </form>
13 <hr/>
14    <a href="http://localhost:8083/struts/飞?word=飞">页面超连接</a>   <!-- 超连接方式发起请求-->
15 <hr/>
16  <form action="http://localhost:8083/struts/飞" method="post">       <!-- 表单post方式发起请求 -->
17  post表单： 18   <input name="input" type="text" value="飞"/>
19   <input type="submit" value="submit"/>
20   </form>
21 </center>
22 </body>
23 </html>

View Code

IE测试结果：

IE浏览器有一个高级选项：是否以UTF8发送URL。该选项对于请求数据的编码有一些影响。

请求方式	access_log(开启以UTF8发送URL的高级选项)	access_log(不开启...)
地址栏输入	"GET /struts/%E9%A3%9E?word=·É HTTP/1.1" 200	"GET /struts/%B7%C9?word=·É HTTP/1.1"
GBK页面超连接	”GET /struts/%E9%A3%9E?word=·É HTTP/1.1" 200	"GET /struts/%B7%C9?word=·É HTTP/1.1" 200
GBK页面表单GET方式	"GET /struts/%E9%A3%9E?word=%B7%C9 HTTP/1.1" 500	"GET /struts/%B7%C9?word=%B7%C9 HTTP/1.1" 500
GBK页面表单POST方式	"POST /struts/%E9%A3%9E HTTP/1.1" 500	"POST /struts/%B7%C9 HTTP/1.1" 500
UTF8页面超连接	"GET /struts/%E9%A3%9E?word=·É HTTP/1.1" 200	"GET /struts/%B7%C9?word=·É HTTP/1.1" 200
UTF8页面表单GET方式	"GET /struts/%E9%A3%9E?word=%E9%A3%9E HTTP/1.1" 500	"GET /struts/%B7%C9?word=%E9%A3%9E HTTP/1.1" 500
UTF8页面表单POST方式	"POST /struts/%E9%A3%9E HTTP/1.1" 500	"POST /struts/%B7%C9 HTTP/1.1" 500

Firefox测试结果：

请求方式	access_log
地址栏输入	"GET /struts/%E9%A3%9E?word=%B7%C9 HTTP/1.1" 200
GBK页面超连接	"GET /struts/%E9%A3%9E?word=%B7%C9 HTTP/1.1"
GBK页面表单GET方式	"GET /struts/%E9%A3%9E?word=%B7%C9 HTTP/1.1" 500
GBK页面表单POST方式	"POST /struts/%E9%A3%9E HTTP/1.1" 500
UTF8页面超连接	"GET /struts/%E9%A3%9E?word=%E9%A3%9E HTTP/1.1" 200
UTF8页面表单GET方式	"GET /struts/%E9%A3%9E?word=%E9%A3%9E HTTP/1.1" 500
UTF8页面表单POST方式	"POST /struts/%E9%A3%9E HTTP/1.1" 500

注：由表单POST方式发起的请求中参数数据被包含在请求的body体中，所以在access_log的uri中看不到参数部分的数据。但能够确定表单POST行为的编码方式是以页面编码转Base64的方式。

access_log的编码说明：

”%B7%C9“为"飞“的GBK转Base64形式；

%E9%A3%9E”为"飞"的UTF-8转Base64形式；

“·É”为“飞"的GBK编码形式（使用Latin1字符集去识别GBK编码所得的字符串）

结果分析：

1 IE 对于uri部分的编码与“是否开启UTF8发送URL”的高级选项相关，若是开启，则一概使用UTF8转Base64的编码；不然使用GBK转Base64的编码。

对于参数部分的编码：

A. 地址栏输入与页面超连接的处理一致，都直接使用GBK编码直接发送；

B. 页面表单Get和Post，使用页面编码转Base64编码。

2 Firefox 对于uri部分的编码一概采用UTF8转Base64编码的方式；

对于参数部分的编码：

A. 地址栏输入使用GBK转Base64编码；

B. 页面表单Get和Post，以及超连接都使用页面编码转Base64编码的方式。

3、web服务器端的编码处理：

对于URI部分的编码设置，tomcat服务器在Server.xml里面作以下配置：

URIEncoding="UTF-8"  <!-- 该设置负责将URI部分进行反转义，至关于调用URIDecoder.decode(uri,"utf-8") -->

对于表单POST提交(附在请求Body体中)的的参数，须要对HttpServletRequest对象进行编码设置：

request.setCharacterEncoding("utf-8");   //负责将参数进行反转义，至关于调用URIDecoder.decode(uri,"utf-8")

而对于超连接、表单Get、地址栏访问形式提交请求的参数(附在URI中)，则通常由上述的URIEncoding来肯定编码转义；也能够使其与POST参数的处理一致，这须要在Server.xml作以下配置：

useBodyEncodingForURI="true"

以上所述的编码设置都是针对某种编码(如UTF-8)转Base64的请求编码的，对于直接用某种编码发送请求参数的状况却无能为力(如上面案例中IE直接用GBK编码直接发送参数)。为了能处理这样的数据，须要在程序中手工转换：

String word = request.getParameter("word"); word = new String(word.getBytes("iso-8859-1"),"gbk"); //传输的GBK编码被tomcat服务器以latin1字符集进行识别，成为latin1字符串，在URI转义过程当中未被改变(不符合%xxx的转义形式)，因而从request对象取得的是latin1字符串，所以能够作如此转换。

4、采用统1、可靠的编码方案：

通过上面的一系列分析，得一些总结的方案：

1 URI部分不要含有中文字符，由于IE和Firefox的转义编码多是不一致的。

2 超连接参数部分不要含有中文，由于IE会直接发送GBK编码的参数，在后台须要另外处理，而Firefox则以页面编码作Base64转义...

3 统一页面编码，推荐使用UTF-8(因其更加国际化)；

4 表单Get和Post容许含有中文参数，web服务器将Get和Post参数的编码处理设置为一致：useBodyEncodingForURI=“true"

此外使用过滤器（或其余统一的方式）对HttpServletRequest对象进行编码设置如：request.setCharacterEncoding("utf-8");

5 以Ajax进行交互的状况下，中文参数也使用页面统一的编码进行Base64转义发送。

原文地址：http://blog.csdn.net/littleatp2008/article/details/6767062