Request.Form和Request.QueryString 自动 解码问题。
1.可以自动解析URL编码后的URL。如：encodeURL编码的URL和URLEncode编码的URL。所有按照URL编码规则的都可以正常解码。
2.可以自动解析所有unicode编码的字符串。如：可以解析%u533F自动解析为"匿",解析\u533F自动解析为"匿"。所以所有escape编码的和unicode编码的
字符串都可以正常解码。
偶尔发现一个问题：
客户端js escape编码数据 post form 表单提交 同步方式提交Request.Form不能解析编码,
ajax异步提交却能自动解析为汉字。
究其原委往下看：
1.ajax异步提交
<script>
jQuery(function ($) {
$('#voteform').submit(function () {
$.ajax({
url: 'tt.aspx',
data: "replynickname=%u533F%u540D%2889%29&replycode=86",
type: "post",
cache: false,
contentType: "application/x-www-form-urlencoded",
success: function (data) {
var request = eval("(" + data + ")");
if ("True" == request.result) {
alert("提交成功！感谢您的参与！");
}
else
{ alert("提交出错！"); }
jQuery("#votebox").hide();
}
});
return false;
});
});
</script>
<form id="voteform">
<input name="replynickname" value="29"/>
<input name="replycode" value=""/>
<input type="submit" />
post 数据流为
2.post form 同步提交
<form id="voteform" enctype="application/x-www-form-urlencoded" action="tt.aspx" method="post"> <input name="replynickname" value="%u533F%u540D%2889%29"/> <input name="replycode" value="86"/> <input type="submit" /> </form>
post 数据流为
对比可以发现一个%u533F 一个%u25u533F,原来浏览器根据编码规则转为%转换为%25,所有导致两次结果会不同。
下面是URL译码与解码的原理：
由于Web服务器和浏览器不能正确处理一些特殊的字符，Web服务器和浏览器之间可能会因此而产生某种程度的误会，所以在数据被传送之前，浏览器都要对表单内客户输入的数据中的特殊字符进行URL译码。
例如，Web系统用“=”分解表单各元素的NAME和VALUE属性，用“&”分解不同表单元素的输入数据。如果在表单的输入数据中包含这些特殊的字符，并且表单的数据在传送给Web服务器前不作任何处理，则Web服务器将无法知道哪一个“=”、“&”是用户输入的，哪一个是浏览器加上的。在由表单属性ACTION定义的URL中，也可能会出现一些特殊的字符，当在CGI程序的名称和路径信息（Path Information）中出现“=”、“&”和“？”时，都会影响数据的正确传送。
URL译码（URL Encoding）就是将Web服务器所不能正确处理的特殊字符转换成它的十六进制数的形式，比如将“%”转换成“%25”、“=”转换成“%3D”等等。这些特殊的字符通常被称作Web系统的保留字符。在Web系统上无论是用GET方法还是用POST方法传送的数据都要进行URL译码。CGI程序要想处理表单传送来的数据，还必须对浏览器URL译码过的数据进行解码。因此，理解URL译码对于我们进行CGI编程是非常重要的。URL译码一般包括以下步骤：
1、浏览器将所传送的数据根据表单所包含的元素分解成“NAME=VALUE”形式，NAME和VALUE分别是表单元素的属性。其中，VALUE属性中存储客户机在表单中输入的数据：如果客户机没有输入数据，则VALUE存储的是表单定义的缺省值；如果缺省值也没有定义，则VALUE值为空。
2、代表表单中各元素的各个“NAME=VALUE”对被浏览器用“&”连接起来。
3、VALUE属性中存放的数据若含有空格，则被转换成“+”。
4、URL和输入数据中所包含的Web系统的保留字符必须被译码成其十六进制数形式。
5、被译码后的字符被表示成一个“%”和它们的十六进制数形式（即%HH）。
CGI程序从环境变量“QUERY_STRING”或标准输入中读入的数据是经过浏览器URL译码过的，故在使用这些数据以前还必须对它们进行URL解码。解码的目的是将数据还原成客户端用户在Web页面上输入时的形式。本文已经介绍了URL译码过程，URL解码过程与它正好相反，它一般包括以下步骤：
1、从浏览器用GET或POST方法所传送来的数据中找出代表各个表单元素所储存数据的“NAME=VALUE”对。
2、VALUE属性中所存放的数据若含有“+”，则被转换成空格。
3、将VALUE属性中所存放的数据的十六进制数“%HH”转换成相应的字符。
Web系统将汉字当成特殊的字符，对它也要进行URL译码。对于一个特殊的单字节字符（比如“/”），浏览器通常将它译码成十六进制数的形式（比如%2F），“%”表示它后面跟的是两位十六进制数。当VB程序对其进行处理时调用Chr$函数就可以将其恢复为原貌。而一个汉字则被浏览器译码成四位十六进制数（比如%D5%C5）。如果CGI程序还像以前那样分别调用Chr(D5)和Chr(C5)，则由于D5、C5都不是正常的单字节十六进制数码，故Chr函数返回空，汉字将无法正确还原。正确的做法应该是将有关汉字的四位十六进制数一起传给函数Chr（如Chr(D5C5)），此时汉字才能被正确还原。
因此，可以让CGI程序对四位连续的十六进制数一起进行译码，以便使汉字能够被正确还原。但在这种情况下，当客户端用户输入了两个连续的Web系统保留字符时，CGI程序又可能把它们当成汉字来处理。这时可以让CGI程序在需要对四位连续的十六进制数进行译码时首先检查前面两位是否为Web系统的保留字符，如果是则仍然按照单字节的字符处理。不过如果客户端用户在表单内填写了很多汉字，则CGI程序的负担将会大大加重。事实上，在大多数情况下，客户端用户很少会使用两个连续的Web系统的保留字符，所以可以只让CGI程序对最容易出现的情形如“://”（当客户端用户在表单中输入某一URL时会出现这种情况）进行检查，本文下节提供的函数UrlDecode( )可以实现对汉字和Web系统保留字符的URL解码。