各浏览器对url非ASC字符的处理.docx

URI 的组成如下所示： foo://:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment | _____________________|__ / \ / \ urn:example:animal:ferret:nose 根据 HTML 4.01 规范中的描述，URI 中不应该包含非 ASCII 字符。如以下 href 属性的值是不合法的：A href=/H?kon.../A 规范中建议，用户端在这种情况下应采取以下方式处理非 ASCII 字符： 将每个字符转换为 UTF-8 编码的相同字符，每个字符将有一或多个字节。 用 URI 编码机制对这些字节进行编码。如：每个字节转换为 %HH，其中的 HH 为这些字节的值的十六进制表示。这种方式称为“百分号编码”。 关于 URI 类型及 URI 属性值中的非 ASCII 字符（Non-ASCII characters in URI attribute values）的详细信息，请参考 HTML4.01 规范  HYPERLINK /TR/html4/types.html \l type-uri 6.4 URIs 及  HYPERLINK /TR/html4/appendix/notes.html \l h-B.2.1 附录B.2.1 中的内容。 关于“百分号编码”的详细信息，请参考 RFC-3986  HYPERLINK /html/rfc3986 \l section-2.1 2.1. Percent-Encoding 中的内容。 关于 URI 组成的更多信息，请参考 RFC-3986  HYPERLINK /html/rfc3986 \l section-3 3. Syntax Components 中的内容。 问题描述 对于 URI 中非 ASCII 字符，并非所有浏览器都是按照 HTML 4.01 规范中的建议实现的，而且不同浏览器在处理不同形式的 URI 时，表现也有差异。 造成的影响 这个问题将导致在服务端或客户端通过代码获取 URI 中的非 ASCII 字符信息时无法分辨编码信息，并产生乱码。 受影响的浏览器 所有浏览器问题分析 下面测试各种情况下各浏览器对于 URI 中非 ASCII 字符的编码方式。 在应用中经常使用的编码是 GB2312 和 UTF-8，一个汉字在 GB2312 编码下占 2 个字节，在 UTF-8 编码下占 3 个字节，因此通过对比这两种编码更容易看出区别。下面的例子中将分别使用这两种编码测试。 测试使用的非 ASCII 字符均为中文字符“汉”，“汉”在 GB2312 编码中的字节码为“BA BA”，在 UTF-8 编码中的字节码为“E6 B1 89”。 测试结果的截图中，所有字符均为 ASCII 编码，GB2312 编码的“汉”以 ASCII 编码显示时，为“oo”，UTF-8 编码的“汉”以 ASCII 编码显示时，为“?±?”（第三个字节在 ASCII 字符集中无对应字符，因此显示为“?”）。 测试的访问地址均为：http://local.test/BrowserName/汉?汉=汉1为了便于区分各浏览器的表现，BrowserName 将在测试中替换为各浏览器名。 另外，当声明一段测试代码是 GB2312 编码时，其含义为该 HTML 文件的编码为 GB2312，并且在该文件中声明了：meta http-equiv=Content-Type content=text/html; charset=gb2312/同样，当声明一段测试代码是 UTF-8 编码时，其含义为该 HTML 文件的编码为 UTF-8，并且在该文件中声明了：meta http-equiv=Content-Type content=text/html; charset=utf-8/ 注：1. 此处的“汉”字，在不同测试中，实际的编码也不相同。 1. 在浏览器的地址栏直接输入包含非 ASCII 字符的 URI 时 在各浏览器的地址栏中，直接输入“http://local.test/BrowserName/汉?汉=汉”，结果如下：