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

协议及扫瞄器编码行为
协议和扫瞄器是Web 国际化的根底，在进入 Java 效劳器端之前，必需先对它们的编码行为有所了解。
协议
协议是B/S 体系构造应用程序的根底，只有了解了 312”，指明该恳求的消息体中包含的是纯文本的XML 类型的数据，字符编码承受“gb2312”。
使用一些Firefox 插件可以关心开发人员分析恳求的消息头和消息体，较常用的有Firebug
等。
响应
响应是 效劳器在接收恳求之后向客户端返回的信息。一个 响应通常由状态行、消息头和消息体组成。 响应消息的第一行是状态行，表示效劳器对恳求的应答。常见的应答有：“200：OK”、“404：Not Found””、“500：Internal Server Error”等。
与 恳求类似， 响应消息也包含一个“Content-Type”消息头，它指定了消息体中内容的类型和编码，例如“text/html; charset=UTF-8”。只有正确指定了“Content-Type”消息头，扫瞄器才能正确解析收到响应消息体中的数据并呈现页面。
扫瞄器行为分析
扫瞄器是发送 恳求和接收 响应的客户端， 协议保证了大多数状况下扫瞄器行为的全都性，但不同扫瞄器之间仍有很多差异。这些差异经常导致B/S 体系构造应用程序的开发变得困难。本节着重解释不同扫瞄器在涉及国际化方面的不同行为。
1．发送恳求
使用扫瞄器发送 恳求有多种方式： 在扫瞄器地址栏中直接输入URL；
在页面中通过点击“提交”按钮提交表单； 用户在页面中点击超链接产生的恳求；
使用 JavaScript 脚本的XML Request 对象发送恳求。
在扫瞄器地址栏中直接输入URL
当 URL 中包含非ASCII 码字符时，Firefox 会自动将这些字符进展转义，转义使用的编码由扫瞄器的语言版本打算。例如，“ :// baidu /s?wd=中文”将会转义为 :// baidu /s?wd=%D6%D0%CE%C4。
图 6-1 Firefox 中的 URL 编码选项
默认状况下，中文 Windows 平台上的IE 扫瞄器将URL 分为两个局部，“？”之前的局部 URL使用UTF8 进展转义，而“？”之后的参数局部，那么不进展转义而直接使用GBK 编码发送。例如 URL“ ://localhost/?test=中文”，前一个“中文”将依据 UTF8 编码的转义形式“%E4%B8%AD%E6%96%87” 发送，而参数局部的“中文”那么直接以 GBK 编码发送，因此， 最终发送的URL 如图 6-2 所示。
图 6-2 URL 编码图解〔1〕
在 IE 的“Internet 选项”的“高级”选项卡页中有一个选项“总是以UTF-8 发送 URL”，在缺省状况下该选项是选中的。假设去掉这个选项，IE 将会以系统当前的代码页来对URL 进展编码。在中文Windows 中整个URL 都将以GBK 编码发送，如图 6-3 所示。
图 6-3 URL 编码图解〔2〕
在页面中通过单击“提交”按钮来提交表单
在表单中属性“method”用来指定提交表单时所使用的 恳求方法，可以选择Post 或者
Get。用户不指定时，默认承受Get 方法。而表单所提交内容承受的编码那么由页面当前的编码打算。例如，在一个JSP 中包含以下表单代码：
=======
<%@ page language=“java“ contentType=“text/html; charset=GBK“ pageEncoding=“GBK“%>
<form action=““ >
<input type=“text“ name=“中文“ ></input>
<input type=“submit“/>
</form>
在 IE 或 Firefox 扫瞄器中翻开该页面，在“中文”输入框中填入“中文”并单击“提交”按钮，会产生一个Get 恳求，所使用的URL 为：
://localhost:8080/jsbook/?%D6%D0%CE%C4=%D6%D0%C