浏览器发送请求过程解析
HTTP协议是B/S体系结构应用程序的基础，只有了解了HTTP协议，才能理解如何在B/S体系结构下实现应用程序的国际化。
1．HTTP请求
当用户在浏览器的地址栏中输入一个URL并按回车键之后，浏览器会向HTTP服务器发送HTTP请求。HTTP请求主要分为“Get”和“Post”两种方法。
2．采取“Get”方法的HTTP请求
“Get”请求的典型用途是从HTTP服务器获取指定的资源，这样的请求不包含请求体。在浏览器中输入一个URL并按回车键后，浏览器就会生成这种 类型的请求。HTTP服务器根据该请求所包含URL中的参数来动态产生响应内容，即“Get”请求的参数是URL的一部分。
例如： http://www.baidu.com/s?wd=Chinese
上述URL是一个使用百度搜索关键字“Chinese”的URL，参数“wd”包含在URL中，一起发送到HTTP服务器，参数的值是“Chinese”。当参数名和参数值都是ASCII字符时不会出现问题，但当参数名或参数值中包含非ASCII字符时就有可能出现问题。 由于URL通过网络传递，因此，为了保证信息的兼容性和通用性，当URL包含非 ASCII字符时，必须对其进行转义。
如果将上例中的参数值改为“中文”，则URL变为：http://www.baidu.com/s?wd=中文
当在浏览器（我们使用的是Firefox2.0）的地址栏中输入上述URL并按回车键后，可以看到浏览器会自动对URL进行转义，得到的是： http://www.baidu.com/s?wd=%D6%D0%CE%C4
可以看到“中文”已经被浏览器自动转义成为了%D6%D0%CE%C4，它们是汉字“中文”的GBK编码对应的转义形式。另外，不同的浏览器对URL进行转义的行为是不同的，具体内容请参阅6.1.2节的介绍
当HTTP服务器收到这样的请求时，必须先将转义的字符解释为有效的字符，再对URL进行处理。但是，HTTP协议中并没有指定使用何种编码和字符 集来解释URL中的非ASCII字符（细节可参阅RFC2396，2.1节），因此，是否能成功解析就完全取决于URL中非ASCII内容的编码是否与 HTTP服务器的解析编码一致。例如，如果我们希望在Google中也搜索“中文”，构造如下URL：
http://www.google.com/search?q=%D6%D0%CE%C4
在浏览器地址栏中输入这个URL并按回车键后，会发现搜索结果页面查询的关键字并不是“中文”而是一个不能识别的乱码。这是因为Google的HTTP服务器使用UTF8编码来解释URL中的非ASCII字符。如果使用下面以UTF8编码的URL就能得到正确的结果：
http://www.google.com/search?q=%E4%B8%AD%E6%96%87
请注意：Google在不同区域的服务器可能会使用不用的编码方式来解析URL。例如www.google.cn可以正确解析：http://www.google.cn/search?q=%D6%D0%CE%C4；而www.google.com只能正确解析：http: //www.google.com/search?q=%E4%B8%AD%E6%96%87。 而且，由于Google可以根据用户浏览器的区域设置自动将用户重定向到某个特定区域的服务器上，因此在Firefox中，如果浏览器的首选区域是 zh-cn，那么访问如下url：http://www.google.com/search?q=%D6%D0%CE%C4会被自动重定向到http: //www.google.cn /search?q=%D6%D0%CE%C4，因此，显示的结果是正确的。
3．采取“Post”方法的HTTP请求
“Post”请求通常用来向HTTP服务器提交量比较大的数据（比如请求中包含许多参数或者文件上传操作等），它与“Get”方法的主要区别在于请求的参数包含在消息体而非 URL中，服务器同样需要获得正确的编码信息才能够正确解析在消息体中的请求参数。在 “Post”方法的HTTP请求中，通常包含一个“Content-Type”消息头指明该消息体的媒体类型和编码，如“Text/XML; charset=gb2312”，指明该请求的消息体中包含的是纯文本的XML类型的数据，字符编码采用“gb2312”。 (在request方式中就不行吗？) 使用一些Firefox插件可以辅助开发人员分析请求的消息头和消息体，较常用的有Firebug等。
4．HTTP响应
HTTP响应是HTTP服务器在接收请求之后向客户端返回的信息。一个HTTP响应通常由状态行、消息头和消息体组成。HTTP响应消息的第一行是 状态行，表示服务器对请求的应 答。常见的应答有：“200：OK”、“404：Not Found””、“500：Internal Server Error”等。 与HTTP请求类似，HTTP响应消息也包含一个“Content-Type”消息头，它指定了消息体中内容的类型和编码，例如 “text/html; charset=UTF-8”。只有正确指定了“Content-Type”消息头，浏览器才能正确解析收到响应消息体中的数据并呈现页面。
6.1.2 浏览器行为分析
浏览器是发送HTTP请求和接收HTTP响应的客户端，HTTP协议保证了大多数情况下浏览器行为的一致性，但不同浏览器之间仍有许多差异。这些差异经常导致B/S体系结构应用程序的开发变得困难。本节着重解释不同浏览器在涉及国际化方面的不同行为。
1．发送请求
使用浏览器发送HTTP请求有多种方式：
地址栏URL提交；
表单提交；
超链接提交；
JavaScript脚本的XMLHTTPRequest对象提交
（1）在浏览器地址栏中直接输入URL
当URL中包含非ASCII码字符时，Firefox会自动将这些字符进行转义，转义使用的编码由浏览器的语言版本决定。例 如，“http://www.baidu.com/s?wd=中文”将会转义为http://www.baidu.com/s?wd=%D6%D0%CE %C4。
Firefox也提供了使用UTF-8进行URL编码的选项。在地址栏中输入“about:config”，并按回车键打开配置页面，在过滤器中输 入“network.standard-url.encode-utf8”以定位到该选项，如图6-1所示。将该选项的值修改为true，以使 Firefox始终用UTF-8对URL进行转义。这样，上述URL将转义为http://www.baidu.com/s?wd=%E4%B8%AD %E6%96%87。
默认情况下，中文Windows平台上的IE浏览器将URL分为两个部分，“？”之前的部分URL使用UTF8进行转义，而“？”之后的参数部分， 则不进行转义而直接使用GBK编码发送。例如URL“http://localhost/中文.jsp?test=中文”，前一个“中文”将按照UTF8 编码的转义形式“%E4%B8%AD%E6%96%87”发送，而参数部分的“中文”则直接以GBK编码发送，因此，最终发送的URL如图6-2所示。
在IE的“Internet选项”的“高级”选项卡页中有一个选项“总是以UTF-8发送URL”，在缺省情况下该选项是选中的。如果去掉这个选项，IE将会以系统当前的代码页来对URL进行编码。在中文Windows中整个URL都将以GBK编码发送，如图6-3所示。
（2）在页面中通过单击“提交”按钮来提交表单
在表单中属性“method”用来指定提交表单时所使用的HTTP请求方法，可以选择Post 或者Get。用户不指定时，默认采用Get方法。而表单所提交内容采用的编码则由页面当前的编码决定。例如，在一个JSP中包含以下表单代码：
===formencoding.jsp====
<%@ page language="java" contentType="text/html; charset=GBK" pageEncoding="GBK"%>
<form action="formencoding.jsp" >
<input type="text" name="中文" ></input>
<input type="submit"/>
</form>
在IE或Firefox浏览器中打开该页面，在“中文”输入框中填入“中文”并单击“提交”按钮，会产生一个Get请求，所使用的URL为：
http://localhost:8080/jsbook/formencoding.jsp?%D6%D0%CE%C4=%D6%D0%CE%C4即使用GBK编码对URL进行转义。
如果将该页面的contentType重置为contentType="text/html; charset=UTF-8"，则该表单所产生的URL为： http://localhost:8080/jsbook/formencoding.jsp? %E4%B8%AD%E6%96%87= %E4%B8%AD%E6%96%87%即使用UTF-8编码对URL进行转义。
（3）在页面中单击超链接产生的请求
用户单击页面中的超链接时，浏览器将会产生一条“Get”请求。这个请求的URL使用的编码方式由当前页面使用的编码及使用的浏览器共同决定。我们仍然使用前文的例子“http://localhost/中文.jsp?test=中文”来说明。
在IE中，页面编码为UTF8时，这一请求中“？”前的部分将以UTF8编码转义，而“？”后的参数部分将直接使用UTF8编码发送；当页面编码为GBK时，请求中“？”前的部分仍以UTF8编码转义，而“？”后的参数部分将直接使用GBK编码发送。
在Firefox中，页面编码为UTF8时，整个URL将以UTF8编码转义。如果页面编码为GBK，则请求以GBK编码转义。
如果在IE中禁用了“总是以UTF-8发送URL”选项，那么当页面编码为UTF8时，这一请求中“？”前的部分将以UTF8编码转义，而“？”后的参数部分将直接使用UTF8编码发送；当页面编码为GBK时，整个请求都将直接使用GBK编码发送。
（4）使用XMLHTTPRequest对象发送请求
最后，我们来看一下使用JavaScript脚本来发送请求的情形。XMLHTTPRequest对象（下面简称XHR）是构成Ajax应用程序的基础，它允许JavaScript脚本直接向服务器发送HTTP请求，在页面不刷新的前提下与服务器通信，提交和获取数据。
使用XHR对象发送请求也分为Get和Post两种
IE中使用XHR对象发送“Get”请求时，对URL所使用的编码规则和在地址栏中输入URL是一致的。
Firefox中使用XHR对象发送“Get”请求时始终使用UTF-8编码对URL进行转义，而发送“Post”请求时，参数和URL分离，参数 部分在消息体中，使用UTF-8编码。要使Web服务器能够正确识别，最好在Content-type消息头中添加“Charset”信息，如以下代码段 所示：
//创建 XHR 对象，并准备 URL 和请求参数
xmlHttp.open("Post",url,true);
xmlHttp.setRequestHeader("Content-type", "application/x-www-form-urlencoded；charset=UTF-8");
xmlHttp.setRequestHeader("Content-length", params.length);
xmlHttp.setRequestHeader("Connection", "close");
xmlHttp.send(params);
请注意，设置上述请求的消息头只能用来告知服务器该消息体所使用的编码，并不能通过修改此消息头的值来改变该请求所使用的编码。
2．接受响应
前文描述了浏览器在发送HTTP请求时选取编码的行为。那么从服务器端返回HTTP响应时，浏览器又是如何判断该响应使用了何种编码的呢？
浏览器判断返回的HTTP响应消息所使用的编码遵循以下一系列规则。
首先，浏览器会检查HTTP响应中的“Content-type”消息头。
如“text/html; charset=UTF-8”，表明该消息所包含的内容是纯文本的HTML文档，采用UTF-8编码。
但在很多情况下，服务器返回的Content- type消息头并不包含“charset”信息。 当响应消息不包含“charset”信息时，浏览器会尝试自动探测编码。第一个步骤是检查响应消息体的开头是否包含UTF-8的BOM（字节顺序标 记，Byte Order Marker）。BOM是一种用来判断文件编码的特定字节标记，如果一个文件的开头几个字节包含了UTF-8的BOM，那么浏览器就可以断定这个HTML 文件是采用UTF-8编码的。
如果该HTML中不包含BOM，那么，浏览器就会尝试寻找HTML页面中的<meta>标记，如：
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
如果页面中又不包含<meta>标记，那么，浏览器将采用默认的编码来解析。在中文的IE和Firefox里就是采用GBK或GB2312编码。
因此，要使服务器端返回的响应消息能够正确地被浏览器解析，最简单有效的方法就是在响应的“Content-type”消息头中设置charset属性。
在Servlet编程中可以在doGet()或doPost()方法中调用： response.setCharacterEncoding("UTF-8")
在JSP编程中可以在页面开头指定响应的编码：
<%@ page language="java" contentType="text/html; charset=UTF-8" import="java. util.*" pageEncoding="UTF-8"%>
6.1.3 简单总结
本节描述了HTTP协议中数据传输时需要考虑的编码问题，以及在浏览器中发送请求时所使用的不同编码设置。由于编码设置在整个B/S体系结构的“请求－处理－响应”各个环节中无处不在，其中任何一个环节的错误设置都会导致最终呈现给用户的数据出现乱码，因此，理解这些编码设置的原理将有助于我们在遇到问题时检测和判断究竟是哪个环节设置错误。 而避免这些错误和复杂的编码设置的最好办法，就是在所有的环节都统一使用UTF-8编码，这也可以说是在设计B/S体系结构的Web应用程序时需要贯穿始终的设计原则。