html 接受参数乱码,Request 接收参数乱码原理解析

起因:

今天早上被同事问了一个问题:说接收到的参数是乱码,让我帮着解决一下。

实际情景:

69c5a8ac3fa60e0848d784a6dd461da6.png

81178cc93a2a3bb5048d90d76e7ec935.png

同事负责的平台是Ext.js框架搭建的,web.config配置文件里配置了全局为“GB2312”编码:当前台提交“中文文字”时,后台用Request.QueryString["xxx"]接收到的是乱码。

无论用System.Web.HttpUtility.UrlDecode("xxx","编码类型")怎么解码都无效。

69c5a8ac3fa60e0848d784a6dd461da6.png

原理说明:

1:首先确定的是:客户端的url参数在提交时,Ext.js会对其编码再提交,而客户端的编码默认是utf-8编码

客户端默认有三种编码函数:escape() encodeURI() encodeURIComponent()

2:那为什么用Request.QueryString["xxx"]接收参数时,收到的会是乱码?

为此,我们必须解开Request.QueryString的原始处理逻辑过程

我们步步反编绎,

2.1:看QueryString属性的代码:

69c5a8ac3fa60e0848d784a6dd461da6.png

81178cc93a2a3bb5048d90d76e7ec935.png

publicNameValueCollection QueryString

{get{if(this._queryString==null)

{this._queryString=newHttpValueCollection();if(this._wr!=null)

{this.FillInQueryStringCollection();//重点代码切入点

}this._queryString.MakeReadOnly();

}if(this._flags[1])

{this._flags.Clear(1);

ValidateNameValueCollection(this._queryString,"Request.QueryString");

}returnthis._queryString;

}

}

69c5a8ac3fa60e0848d784a6dd461da6.png

69c5a8ac3fa60e0848d784a6dd461da6.png

81178cc93a2a3bb5048d90d76e7ec935.png

privatevoidFillInQueryStringCollection()

{byte[] queryStringBytes=this.QueryStringBytes;if(queryStringBytes!=null)

{if(queryStringBytes.Length!=0)

{this._queryString.FillFromEncodedBytes(queryStringBytes,this.QueryStringEncoding);

}

}//上面是对流字节的处理,即文件上传之类的。elseif(!string.IsNullOrEmpty(this.QueryStringText))

{//下面这句是对普通文件提交的处理:FillFromString是个切入点,编码切入点是:this.QueryStringEncodingthis._queryString.FillFromString(this.QueryStringText,true,this.QueryStringEncoding);

}

}

69c5a8ac3fa60e0848d784a6dd461da6.png

69c5a8ac3fa60e0848d784a6dd461da6.png

81178cc93a2a3bb5048d90d76e7ec935.png

internalEncoding QueryStringEncoding

{get{

Encoding contentEncoding=this.ContentEncoding;if(!contentEncoding.Equals(Encoding.Unicode))

{returncontentEncoding;

}returnEncoding.UTF8;

}

}//点击进入this.ContentEncoding则为:publicEncoding ContentEncoding

{get{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);

}returnthis._encoding;

}set{this._encoding=value;this._flags.Set(0x20);

}

}

69c5a8ac3fa60e0848d784a6dd461da6.png

说明:

从QueryStringEncoding代码得出,系统默认会先取globalization配置节点的编码方式,如果取不到,则默认为UTF-8编码方式

cdec0645add3fc3c328197dda5c76203.png代码有点长,就折叠起来了

说明:

从这点我们发现:所有的参数输入,都调用了一次:HttpUtility.UrlDecode(str2, encoding);

3:结论出来了

当客户端js对中文以utf-8编码提交到服务端时,用Request.QueryString接收时,会先以globalization配置的gb2312去解码一次,于是,产生了乱码。

所有的起因为:

1:js编码方式为urt-82:服务端又配置了默认为gb23123:Request.QueryString默认又会调用HttpUtility.UrlDecode用系统配置编码去解码接收参数。

文章补充:

69c5a8ac3fa60e0848d784a6dd461da6.png

81178cc93a2a3bb5048d90d76e7ec935.png

1:系统取默认编码的顺序为:http请求头->globalization配置节点-》默认UTF-82:在Url直接输入中文时,不同浏览器处理方式可能不同如:ie不进行编码直接提交,firefox对url进行gb2312编码后提交。3:对于未编码“中文字符”,使用Request.QueryString时内部调用HttpUtility.UrlDecode后,由gb2312->utf-8时,

如果查不到该中文字符,默认转成"%ufffd",因此出现不可逆乱码。

69c5a8ac3fa60e0848d784a6dd461da6.png

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/2021年06月16日/1891124.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值