asp url编码

写ASP的编码人迟早会撞上URL编码这堵墙。不是编码被坑在参数传不过去，就是编码被坑在中文变成乱码。我见过一个老系统，编码表单里填“张三”，编码提交后数据库里存的编码是“%D5%C5%C8%FD”，查半天查不出原因。编码这就是编码URL编码在作祟。

URL编码的编码本质很简单：URL里只能出现ASCII字符集里的安全字符。空格、编码中文、编码&、编码=、编码+这些字符直接扔进URL会出问题。编码浏览器和服务器约定了一套规则，编码把不安全的字符转成百分号加两位十六进制。比如空格变成%20，中文“张”在GBK编码下是%D5%C5。问题在于，这套规则没有强制统一编码标准，GBK、UTF-8、ISO-8859-1都能往里塞，谁解谁头疼。

ASP里处理URL编码主要靠三个函数：Server.URLEncode、Server.URLDecode和Request.QueryString的隐式解码。看起来够用，实际用起来处处是坑。

Server.URLEncode默认用系统代码页编码。中文Windows服务器上，它把“张”编成%D5%C5（GBK）。如果客户端页面是UTF-8，提交的“张”是%E5%BC%A0，服务器拿GBK去解，直接乱码。反过来也一样。我调试过一个跨系统接口，ASP这边URLEncode后发出去，Java那边用UTF-8解码，中文全部变成问号。折腾了一下午，最后在ASP端手动把字符串转成UTF-8字节数组再逐字节编码才解决。

Request.QueryString更隐蔽。它自动帮你解码URL参数，但解码用的编码取决于ASP页面的@CODEPAGE指令或者Session.CodePage。默认情况下它按系统默认代码页解。你传个UTF-8编码的中文参数，它用GBK解，拿到的就是乱码字符串。更麻烦的是，你没法控制它不解码——Request.QueryString永远返回解码后的值。想拿原始编码串？只能用Request.ServerVariables("QUERY_STRING")，然后自己写解析函数。

还有个经典问题：加号。URL编码里空格可以编成%20，也可以编成+。Request.QueryString会把+解成空格。但如果你传的参数值本身包含加号，比如Base64字符串里的+，它也会被解成空格，数据就毁了。解决办法是先把+替换成%2B再传。这种细节文档里不写，踩过才知道。

Server.URLDecode也有坑。它把+解成空格，把%XX解成对应字节。但如果%XX序列不完整或者非法，它不报错，直接原样返回。调试时看到一堆%符号别惊讶，八成是编码串本身有问题。

实际项目里我的做法是：统一用UTF-8。ASP页面顶部加<%@ CODEPAGE=65001 %>，Response.Charset设成UTF-8。自己写URLEncode函数，把字符串先转成UTF-8字节数组，再对每个字节做%XX编码。URLDecode同理，先按%拆分，转回字节数组，再用UTF-8解码成字符串。这样跨平台跨语言都不会乱。虽然多写几十行代码，但省下的调试时间远超这点工作量。

老系统迁移时更要注意。GBK编码的URL参数在新系统里必须转码。我见过有人直接改数据库连接字符串的字符集，结果URL参数还是GBK，一半数据正常一半乱码。URL编码和数据库编码是两回事，别混在一起调。

说到底，URL编码不是什么高深技术，但它像空气里的灰尘，平时看不见，一旦出问题就呛得你喘不过气。搞清楚你的数据从哪来、经过什么编码、到哪去，比背函数用法重要得多。