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

面一篇文档《中文化和国际化问题权威解析之五: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;

  1. < head >
  2. < meta http-equiv = content -type content = "text/html;charset=XXX" >
  3. </ head >
  4. < script language = 'javascript' >
  5. document.write(escape('/我爱')+'< br /> ');
  6. document.write(encodeURI('/我爱')+'< br /> ');
  7. document.write(encodeURIComponent('/我爱')+'< br /> ');
  8. document.write(escape('http://mall.alisoft.com/我爱')+'< br /> ');
  9. document.write(encodeURI('http://mall.alisoft.com/我爱')+'< br /> ');
  10. document.write(encodeURIComponent('http://mall.alisoft.com/我爱')+'< br /> ');
  11. </ script >

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

字符编码 测试结果
charset=UTF-8 /%u0392%3F%3F
/%CE%92??
%2F%CE%92%3F%3F
http%3A//mall.alisoft.com/%u0392%3F%3F
http://mall.alisoft.com/%CE%92??
http%3A%2F%2Fmall.alisoft.com%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.alisoft.com/%u6211%u7231
http://mall.alisoft.com/%E6%88%91%E7%88%B1
http%3A%2F%2Fmall.alisoft.com%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.alisoft.com/%CE%D2%B0%AE
http://mall.alisoft.com/%C3%8E%C3%92%C2%B0%C2%AE
http%3A%2F%2Fmall.alisoft.com%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的%格式,只不过两者的编码字符范围不一样而已。

你可能感兴趣的:(中文化和国际化问题权威解析之七:JS中的escape、encodeURI、encodeURIComponent解惑)