6.1 HTTP 协议及浏览器编码行为

HTTP 协议和浏览器是 Web 国际化的基础，在进入 Java 服务器端之前，必须先对它们的
编码行为有所了解。

6.1.1 HTTP 协议

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 编码