URL编码与解码.doc

URL 编码与解码通常如果一样东西需要编码，说明这样东西并不适合传输原因多种多样，如 Size过大，包含隐私数据，对于 Url 来说，之所以要进行编码，是因为 Url 中有些字符会引起歧义例如，Url 参数字符串中使用 key=value 键值对这样的形式来传参，键值对之间以&符号分隔，如/s?q=abc&ie=utf-8如果你的 value 字符串中包含了 =或者&，那么势必会造成接收 Url 的服务器解析错误，因此必须将引起歧义的&和=符号进行转义，也就是对其进行编码又如，Url 的编码格式采用的是 ASCII 码，而不是 Unicode，这也就是说你不能在Url 中包含任何非 ASCII 字符，例如中文否则如果客户端浏览器和服务端浏览器支持的字符集不同的情况下，中文可能会造成问题Url 编码的原则就是使用安全的字符（没有特殊用途或者特殊意义的可打印字符）去表示那些不安全的字符预备知识：URI 是统一资源标识的意思，通常我们所说的 URL 只是 URI 的一种典型 URL 的格式如下所示下面提到的 URL 编码，实际上应该指的是 URI 编码foo://:8042/over/there?name=ferret#nose\_/ \______________/ \________/\_________/ \__/| | | | |scheme authority path query fragment哪些字符需要编码RFC3986 文档规定，Url 中只允许包含英文字母（ a-zA-Z）、数字（0-9 ）、-_.~4个特殊字符以及所有保留字符。

RFC3986 文档对 Url 的编解码问题做出了详细的建议，指出了哪些字符需要被编码才不会引起 Url 语义的转变，以及对为什么这些字符需要编码做出了相应的解释US-ASCII 字符集中没有对应的可打印字符：Url 中只允许使用可打印字符 US-ASCII 码中的 10-7F 字节全都表示控制字符，这些字符都不能直接出现在 Url 中同时，对于 80-FF 字节（ISO-8859-1），由于已经超出了 US-ACII 定义的字节范围，因此也不可以放在 Url 中保留字符：Url 可以划分成若干个组件，协议、主机、路径等有一些字符（:/?#[]@）是用作分隔不同组件的例如：冒号用于分隔协议和主机，/用于分隔主机和路径，?用于分隔路径和查询参数，等等还有一些字符（!$&'()*+,;=）用于在每个组件中起到分隔作用的，如=用于表示查询参数中的键值对，&符号用于分隔查询多个键值对当组件中的普通数据包含这些特殊字符时，需要对其进行编码RFC3986 中指定了以下字符为保留字符：! * ' ( ) ; : @ & = + $ , / ? # [ ]不安全字符：还有一些字符，当他们直接放在 Url 中的时候，可能会引起解析程序的歧义。

这些字符被视为不安全字符，原因有很多 空格：Url 在传输的过程，或者用户在排版的过程，或者文本处理程序在处理 Url的过程，都有可能引入无关紧要的空格，或者将那些有意义的空格给去掉 引号以及这样浏览器就会使用 gb2312 去渲染此文档（注意，当 HTML 文档中没有设置此meta 标签，则浏览器会根据当前用户喜好去自动选择字符集，用户也可以强制当前网站使用某个指定的字符集）当提交表单时，Url 编码使用的字符集就是 gb2312之前在使用 Aptana（为什么专指 aptana 下面会提到）遇到一个很迷惑的问题，就是在使用 encodeURI 的时候，发现它编码得到的结果和我想的很不一样下面是我的示例代码： document.write(encodeURI("中文"));运行结果输出%E6%B6%93%EE%85%9F%E6%9E%83显然这并不是使用UTF-8 字符集进行 Url 编码得到的结果（在 Google 上搜索"中文"，Url 中显示的是%E4%B8%AD%E6%96%87）所以我当时就很质疑，难道 encodeURI 还跟页面编码有关，但是我发现，正常情况下，如果你使用 gb2312 进行 Url 编码也不会得到这个结果的才是。

后来终于被我发现，原来是页面文件存储使用的字符集和 Meta 标签中指定的字符集不一致导致的问题Aptana 的编辑器默认情况下使用 UTF-8 字符集也就是说这个文件实际存储的时候使用的是 UTF-8 字符集但是由于 Meta 标签中指定了 gb2312，这个时候，浏览器就会按照gb2312 去解析这个文档，那么自然在"中文"这个字符串这里就会出错，因为"中文"字符串用 UTF-8 编码过后得到的字节是 0xE4 0xB8 0xAD 0xE6 0x96 0x87，这 6 个字节又被浏览器拿 gb2312 去解码，那么就会得到另外三个汉字"涓枃"（GBK 中一个汉字占两个字节），这三个汉字在传入 encodeURI 函数之后得到的结果就是%E6%B6%93%EE%85%9F%E6%9E%83因此，encodeURI 使用的还是 UTF-8，并不会受到页面字符集的影响对于包含中文的 Url 的处理问题，不同浏览器有不同的表现例如对于 IE，如果你勾选了高级设置"总是以 UTF-8 发送 Url"，那么 Url 中的路径部分的中文会使用 UTF-8 进行 Url 编码之后发送给服务端，而查询参数中的中文部分使用系统默认字符集进行 Url 编码。

为了保证最大互操作性，建议所有放到 Url 中的组件全部显式指定某个字符集进行Url 编码，而不依赖于浏览器的默认实现另外，很多 HTTP 监视工具或者浏览器地址栏等在显示 Url 的时候会自动将 Url 进行一次解码（使用 UTF-8 字符集），这就是为什么当你在 Firefox 中访问 Google 搜索中文的时候，地址栏显示的 Url 包含中文的缘故但实际上发送给服务端的原始 Url 还是经过编码的你可以在地址栏上使用 Javascript 访问 location.href 就可以看出来了在研究Url 编解码的时候千万别被这些假象给迷惑了。