正常的情况下，现在asp.net的网站很多都直接使用UTF8来进行页面编码的，这与Javascript缺省网站的编码是相同的，但是也有相当一部分采用GB2312
对于GB2312的网站如果直接用javascript进行ajax数据提交，例如：http://www.xxx.com/accept.aspx?name=张三，或者说在UTF8的网站上用以下asp.net的代码进行提交，也是不行的，会导致querystring乱码。
这样在GB2312编码的网站下得到Request.QueryString["name"]是乱码，MS已经把编码转换这块封装好了。
在UTF8编码通讯和GB2312网站通讯方式下的编码转换方式有很多种实现：
第一种：首先对要传输的字符进行UrlEncode，这种编码后的字符在解码时用UTF8编码方式进行手工解码，这样保证结果一致，即使传输给的目标页面时GB2312，结果都是一样的，避免了querystring乱码。解码方式如下代码。
这样可以得到正确的张三，这要求在提交的时候先进行HttpUtility.UrlEncode编码成UTF8先，然后再放到name=(编码后的字符)，这也是目前比较常用和普遍的解决方式，只是缺点有一个就是要告诉别人你先怎么怎么Url编码先，然后再怎么怎么。
第二种：比较另类一些，直接读取客户端提交的字节数据进行转换，之所以Request.QueryString["name"]会是乱码，是MS根据当前页面的编码进行转换导致的，例如当前页面编码是GB2312，而人家提交的是UTF8，你没用人家提交的UTF8编码转当然是乱码，并不是人家传过来就是乱码。这时我们需要得到原始数据进行重新解码来避免querystring乱码，非常遗憾的是我并没有找到直接提供头部原始字节数据方法给我们用，没关系，解剖下MS的源代码，发现代码如下：
顺便说一下，QueryString是在第一次被访问时才初始化的，如果你的程序中没有用到它，那个这个对象会一直保持空值，MS考虑了细节
大家都看到了QueryStringBytes属性，原型如下internal byte[] QueryStringBytes，这个就是原始的QueryString字节了。出招了：
再看看querystring是什么，哈哈name=张三。
各种编码的转换都可以自己完成，毕竟得到提交的原始字节了，希望对大家解决querystring乱码问题有所帮助。
</div>