中文化和国际化问题权威解析之七：JS中的escape、encodeURI、encodeURIComponent解惑

lipeijs3 2009-11-30

展开全文

前面一篇文档《中文化和国际化问题权威解析之五：URL编码/Misc》主要是从服务端、浏览器两个角度来看待URL编码；除此之外，我们还可能在客户端执行一些js脚本来进行URL编码，与此相关的最主要的三个js function为：
escape()：采用ISO Latin字符集对指定的字符串进行编码。所有的空格符、标点符号、特殊字符以及其他非ASCII字符都将被转化成%xx格式的字符编码（xx等于该字符在字符集表里面的编码的16进制数字）。比如，空格符对应的编码是%20。unescape方法与此相反。不会被此方法编码的字符： @ * / +
encodeURI()：把URI字符串采用UTF-8编码格式转化成escape格式的字符串。不会被此方法编码的字符：! @ # $& * ( ) = : / ; ? + '
encodeURIComponent()：把URI字符串采用UTF-8编码格式转化成escape格式的字符串。与encodeURI()相比，这个方法将对更多的字符进行编码，比如 / 等字符。所以如果字符串里面包含了URI的几个部分的话，不能用这个方法来进行编码，否则 / 字符被编码之后URL将显示错误。不会被此方法编码的字符：! * ( )

这是目前互联网上随处可见的对这3个function的解释，很多文章里面还附带了英文便于对照；对escape还有一些文档这么解释：直接使用"%"加字符的Unicode内码来表示字符；
比如：escape("我是中国人") = %u6211%u662F%u4E2D%u56FD%u4EBA
这几句话MS很简单、明了，但细思之下发现有几点疑惑，比如：

1. Escape中ISO Latin指什么，是ISO-5899-1？但怎么会另一种解释中说是Unicode内码？
2. 三个function的编码结果是否会依赖于html内部的content-type或meta中的charset？
于是，我用如下这段html代码进行测试，文件格式为ANSI/ASCII；view plaincopy to clipboardprint?
<head>
    <meta http-equiv=content-type content="text/html; charset=XXX">
</head>
<script language = 'javascript'>
        document.write(escape('/我爱') + '<br/>');
        document.write(encodeURI('/我爱') + '<br/>');
        document.write(encodeURIComponent('/我爱') + '<br/>');
        document.write(escape('http://mall./我爱') + '<br/>');
        document.write(encodeURI('http://mall./我爱') + '<br/>');
        document.write(encodeURIComponent('http://mall./我爱') + '<br/>');
</script>
<head>
<meta http-equiv=content-type content="text/html; charset=XXX">
</head>
<script language = 'javascript'>
  document.write(escape('/我爱') + '<br/>');
  document.write(encodeURI('/我爱') + '<br/>');
  document.write(encodeURIComponent('/我爱') + '<br/>');
  document.write(escape('http://mall./我爱') + '<br/>');
  document.write(encodeURI('http://mall./我爱') + '<br/>');
  document.write(encodeURIComponent('http://mall./我爱') + '<br/>');
</script>

将代码中charset设置为不同的字符编码，得到的结果却是完全不一样！
测试结果为：

字符编码测试结果
charset=UTF-8 /%u0392%3F%3F
/%CE%92??
%2F%CE%92%3F%3F
http%3A//mall./%u0392%3F%3F
http://mall./%CE%92??
http%3A%2F%2Fmall.%2F%CE%92%3F%3F
charset=GBK /%u6211%u7231
/%E6%88%91%E7%88%B1
%2F%E6%88%91%E7%88%B1
http%3A//mall./%u6211%u7231
http://mall./%E6%88%91%E7%88%B1
http%3A%2F%2Fmall.%2F%E6%88%91%E7%88%B1
charset=ISO-5899-1 /%CE%D2%B0%AE
/%C3%8E%C3%92%C2%B0%C2%AE
%2F%C3%8E%C3%92%C2%B0%C2%AE
http%3A//mall./%CE%D2%B0%AE
http://mall./%C3%8E%C3%92%C2%B0%C2%AE
http%3A%2F%2Fmall.%2F%C3%8E%C3%92%C2%B0%C2%AE

当把文件格式修改为UTF-8/Unicode时，测试结果和上面不一样；同样设置三种不同charset进行测试，结果却是完全相同，和文件格式为ANSI/ASCII、charset=GBK时的结果完全一样！

从上面几项测试结果信息来回答前面提出的几个问题：
对于第1点：显然，ISO Latin并不是指ISO-8859-1编码，但也并不一定是Unicode内码！按照我的分析，只有当文件格式与charset相匹配时，该三个function才能正常工作（当不匹配时执行结果也是乱码）；
对于第2点：MS是无关的，编码结果依赖于文件格式！当使用ANSI/ASCII保存时，因为系统编码为GBK，所以此时文件实际上是以GBK编码保存的，所以在function执行时会出现第一种测试情况；而当文件以UTF/Unicode保存时，各种charset情况下都能正常执行，估计是js引擎在底层做了很多事情；

总结起来，要想让这3个function正常工作，最好是用Unicode系列文件格式，这样就和charset无关了；若采用ANSI/ASCII文件格式，则charset需要设置为与系统默认编码一致，否则function执行会出现意想不到的结果；在此基础上，三个function执行的结果可以解释为：
Escape：将非ASCII @ * / +转义为%uxxxx格式，其中xxxx为字符的Unicode内码；
其他两个function描述不变，直接转换成UTF-8的%格式，只不过两者的编码字符范围不一样而已。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/sfdev/archive/2009/01/20/3842857.aspx