HTTP协议及浏览器编码行为.doc

HTTP协议及浏览器编码行为
HTTP协议和浏览器是Web国际化的基础,在进入Java服务器端之前,必须先对它们的编码行为有所了解。
HTTP协议
HTTP协议是B/S体系结构应用程序的基础,只有了解了HTTP协议,才能理解如何在B/S体系结构下实现应用程序的国际化。

当用户在浏览器的地址栏中输入一个URL并按回车键之后,浏览器会向HTTP服务器发送HTTP请求。HTTP请求主要分为“Get”和“Post”两种方法。
“Get”方法的HTTP请求
“Get”请求的典型用途是从HTTP服务器获取指定的资源,这样的请求不包含请求体。在浏览器中输入一个URL并按回车键后,浏览器就会生成这种类型的请求。HTTP服务器根据该请求所包含URL中的参数来动态产生响应内容,即“Get”请求的参数是URL的一部分。例如:
?wd=Chinese
上述URL是一个使用百度搜索关键字“Chinese”的URL,参数“wd”包含在URL中,一起发送到HTTP服务器,参数的值是“Chinese”。当参数名和参数值都是ASCII字符时不会出现问题,但当参数名或参数值中包含非ASCII字符时就有可能出现问题。
由于URL通过网络传递,因此,为了保证信息的兼容性和通用性,当URL包含非 ASCII字符时,必须对其进行转义。如果将上例中的参数值改为“中文”,则URL变为:
?wd=中文
当在浏览器()的地址栏中输入上述URL并按回车键后,可以看到浏览器会自动对URL进行转义,得到的是:
?wd=%D6%D0%CE%C4
可以看到“中文”已经被浏览器自动转义成为了%D6%D0%CE%C4,它们是汉字“中文”的GBK编码对应的转义形式。另外,不同的浏览器对URL进行转义的行为是不同的,。
当HTTP服务器收到这样的请求时,必须先将转义的字符解释为有效的字符,再对URL进行处理。但是,HTTP协议中并没有指定使用何种编码和字符集来解释URL中的非ASCII字符(细节可参阅RFC2396,),因此,是否能成功解析就完全取决于URL中非ASCII内容的编码是否与HTTP服务器的解析编码一致。例如,如果我们希望在Google中也搜索“中文”,构造如下URL:
rch?q=%D6%D0%CE%C4
在浏览器地址栏中输入这个URL并按回车键后,会发现搜索结果页面查询的关键字并不是“中文”而是一个不能识别的乱码。这是因为Google的HTTP服务器使用UTF8编码来解释URL中的非ASCII字符。如果使用下面以UTF8编码的URL就能得到正确的结果:
rch?q=%E4%B8%AD%E6%96%87
请注意:Google在不同区域的服务器可能会使用不用的编码方式来解析URL。例如析:rch?q=%D6%D0%CE%C4;而解析:rch?q=%E4%B8%AD%E6%96%87。
而且,由于Google可以根据用户浏览器的区域设置自动将用户重定向到某个特定区域的服务器上,因此在Firefox中,,那么访问如下url:rch?q=%D6%D0%CE%C4会被自动重定向到/search?q=%D6%D0%CE%C4,因此,显示的结果是正确的。
“Post”方法的HTTP请求
“Post”请求通常用来向HTTP服务器提交量比较大的数据(比如请求中包含许多参数或者文件上传操作等),它与“Get”方法的主要区别在于请求的参数包含在消息体而非 URL中,服务器同样需要获得正确的编码信息才能够正确解析在消息体中的请求参数。在“Post”方法的HTTP请求中,通常包含一个“Content-Type”消息头指明该消息体的媒体类型和编码,如“Text/XML; charset=gb2312”,指明该请求的消息体中包含的是纯文本的XML类型的数据,字符编码采用“gb2312”。
使用一些Firefox插件可以辅助开发人员分析请求的消息头和消息体,较常用的有Firebug等。

HTTP响应是HTTP服务器在接收请求之后向客户端返回的信息。一个HTTP响应通常由状态行、消息头和消息体组成。HTTP响应消息的第一行是状态行,表示服务器对请求的应答。常见的应答有:“200:OK”、“404:Not Found””、“500:Internal Server Error”等。
与HTTP请求类似,HTTP响应消息也包含一个“Content-Type”消息头,它指定了消息体中内容的类型和编码,例如“text/html; charset=UTF-8”。只有正确指定了“Content-Type”消息头,浏览器才能正确解析收到响