在远方_所谓日志

　　在做网站的时候，用到动态网址：url = "FindUser.asp?name=" & Server.UrlEncode("偷猫")。好像一切都是顺理成章的事，然而，许多人对此基本都是“知其然，而不知其所以然”。
　　如果你做网站只用gb2312或者utf-8，而且不用分析来自其他网站的referrer，那么不了解Server.UrlEncode在这两种编码下的区别也没关系。如果要在两个网站之间这样传递内容，或者要分析来自搜索引擎的关键词，更或者你还想用AJAX来传递信息。那么编码问题立即会出现在你的面前。
　　在试图明确这个问题之前，可以先到百度和谷歌搜索一下同一个关键词。如“一级棒”，百度搜索，URL里显示的是“http://www.baidu.com/s?wd=%D2%BB%BC%B6%B0%F4”，谷歌则显示“http://www.google.cn/search?hl=zh-CN&q=%E4%B8%80%E7%BA%A7%E6%A3%92”。它们分别代表着GB2312和utf-8两种编码下的UrlEncode。
　　要说清这两种编码，首先要从“GB”和“UNICODE”说起。当初外国人发明了电子计算机，并使用了狭窄的ASCII码，中国人自己扩展了与之兼容的“GB2312”码，后来几经扩展，从“GB2312”到“GBK”再到“GB18030”，一次次都向下兼容。到头来，外国佬定义了一个与“GB系列”彻底不兼容的“UNICODE”编码。于是，如今在网络应用上产生了gb2312和utf-8两大派系。
　　包含一串“%”的网址，其实它的来源和去向都与编码有关。首先，在不同的编码中，“Server.UrlEncode("偷猫")”会产生不同的结果；第二，不同的结果只能被对应的编码系统识别。一般说来，在同一个网站内部，这两个过程是互不矛盾的。但这只是“一般说来”，因为就算在同一个网站内，每个不同的“ASP”页也可以单独定义编码。
　　就在中国地区来说，很难说这两种编码有什么优缺点。但是离开中国以后就不见得了，人家老外的电脑未必会支持GB2312字符集，但是肯定支持UNICODE字符集。所以，网站制作发展到今天，utf-8越来越成了发展趋势。而AJAX通信则更牛B地直接把编码方式默认为utf-8（与之不同的是form通信会自动判断网页所用的编码）。
　　下面要说说这些包含一串百分号的网址是怎么计算出来的了。它们与“GB2312”和“UNICODE”是有对应关系的。以“偷猫”为例，“偷”字的GB2312码为0xCDB5，所以转化为Url就是“%CD%B5”。utf-8相对复杂些，因为UNICODE与utf-8之间有个转换。“偷”字的UNICODE码为0x5077，转化为utf-8为0xE581B7，所以转化为Url就是“%E5%81%B7”。关于UNICODE到utf-8的转化不在本文讨论。
　　下面再来说说怎样从UrlEncode字符串中提取对应的字符。如果只是按Url传递，那么很简单，Request.QueryString即可。但是这种办法只能用于同编码的网页，而且只能在url中传递时才可以获取。如果在不同编码的情况下要提取，可以先将它们转化为GB2312码或UNICODE码，然后分别用chr()和chrw()函数即可。网上可以找到名叫“URLDecode”的函数，但是都只包含GB2312编码部分，而且代码并不十分科学。
　　不过我在测试中发现两个问题：一是在CODEPAGE="65001"的ASP中chr()函数失效，也就是说只有GB2312的ASP网页可以实现这两种编码的任意转化。二是直接在地址栏输入不经过UrlEncode的“?s=一级棒”，CODEPAGE="65001"不会识别，可是IE却会多此一举地将你输入“?s=%E4%B8%80%E7%BA%A7%E6%A3%92”记忆为“?s=一级棒”。