起因：
今天早上被同事问了一个问题：说接收到的参数是乱码，让我帮着解决一下。
实际情景：
同事负责的平台是ext.js框架搭建的，web.config配置文件里配置了全局为“gb2312”编码:
<globalization requestencoding="gb2312" responseencoding="gb2312" fileencoding="gb2312" culture="zh-cn"/>
当前台提交“中文文字”时，后台用request.querystring["xxx"]接收到的是乱码。
无论用system.web.httputility.urldecode("xxx","编码类型")怎么解码都无效。
原理说明：
1：首先确定的是：客户端的url参数在提交时，ext.js会对其编码再提交，而客户端的编码默认是utf-8编码
客户端默认有三种编码函数：escape() encodeuri() encodeuricomponent()
2：那为什么用request.querystring["xxx"]接收参数时，收到的会是乱码？
为此，我们必须解开request.querystring的原始处理逻辑过程
我们步步反编绎，
2.1：看querystring属性的代码：
public namevaluecollection querystring
{
get
{
if (this._querystring == null)
{
this._querystring = new httpvaluecollection();
if (this._wr != null)
{
this.fillinquerystringcollection();//重点代码切入点
}
this._querystring.makereadonly();
}
if (this._flags[1])
this._flags.clear(1);
validatenamevaluecollection(this._querystring, "request.querystring");
return this._querystring;
}
}
private void fillinquerystringcollection()
byte[] querystringbytes = this.querystringbytes;
if (querystringbytes != null)
if (querystringbytes.length != 0)
this._querystring.fillfromencodedbytes(querystringbytes, this.querystringencoding);
}//上面是对流字节的处理，即文件上传之类的。
else if (!string.isnullorempty(this.querystringtext))
//下面这句是对普通文件提交的处理:fillfromstring是个切入点,编码切入点是：this.querystringencoding
this._querystring.fillfromstring(this.querystringtext, true, this.querystringencoding);
internal encoding querystringencoding
encoding contentencoding = this.contentencoding;
if (!contentencoding.equals(encoding.unicode))
return contentencoding;
return encoding.utf8;
//点击进入this.contentencoding则为：
public encoding contentencoding
if (!this._flags[0x20] || (this._encoding == null))
this._encoding = this.getencodingfromheaders();
if (this._encoding == null)
globalizationsection globalization = runtimeconfig.getlkgconfig(this._context).globalization;
this._encoding = globalization.requestencoding;
this._flags.set(0x20);
return this._encoding;
set
this._encoding = value;
this._flags.set(0x20);
说明：
从querystringencoding代码得出，系统默认会先取globalization配置节点的编码方式，如果取不到，则默认为utf-8编码方式
代码有点长，就折叠起来了
从这点我们发现：所有的参数输入，都调用了一次：httputility.urldecode(str2, encoding);
3：结论出来了
当客户端js对中文以utf-8编码提交到服务端时，用request.querystring接收时，会先以globalization配置的gb2312去解码一次，于是，产生了乱码。
所有的起因为：
1：js编码方式为urt-8
2：服务端又配置了默认为gb2312
3：request.querystring默认又会调用httputility.urldecode用系统配置编码去解码接收参数。
文章补充：
1：系统取默认编码的顺序为：http请求头->globalization配置节点-》默认utf-8
2：在url直接输入中文时，不同浏览器处理方式可能不同如：ie不进行编码直接提交，firefox对url进行gb2312编码后提交。
3：对于未编码“中文字符”，使用request.querystring时内部调用httputility.urldecode后，由gb2312->utf-8时，
如果查不到该中文字符，默认转成"%ufffd"，因此出现不可逆乱码。
4：解决之路
知道了原理，解决的方式也有多种多样了：
1：全局统一为utf-8编码，省事又省心。
2：全局指定了gb2312编码时，url带中文，js非编码不可，如ext.js框架。
这种方式你只能特殊处理，在服务端指定编码解码，
因为默认系统调用了一次httputility.urldecode（"xxx",系统配置的编码)，
因此你再调用一次httputility.urlencode（"xxx",系统配置的编码)，返回到原始urt-8编码参数
再用httputility.urldecode（"xxx",utf-8)，解码即可。
5：其它说明：默认对进行一次解码的还包括uri属性,而request.rawurl则为原始参数
版权声明：本文原创发表于博客园，作者为路过秋天，原文链接：
http://www.cnblogs.com/cyq1162/archive/2010/11/29/1891124.html