ASP.NET中Request接收參數亂碼解決方案

asp教程.net中request接收參數亂碼解決方案

asp.net教程 request對象的屬性和方法比較多，常用的幾個為：useragent 傳回用戶端瀏覽器的版本資訊，userhostaddress 傳回遠方用戶端機器的主機ip 地址，userhostname 傳回遠方用戶端機器的dns 名稱，physicalapplicationpath 傳回目前請求網頁在server 端的真實路徑。

下面進行正題,我的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的原始處理邏輯過程

切入：querystringencoding

internal encoding querystringencoding
{
    get
    {
        encoding contentencoding = this.contentencoding;
        if (!contentencoding.equals(encoding.unicode))
        {
            return contentencoding;
        }
        return encoding.utf8;
    }
}

從querystringencoding代碼得出，系統預設會先取globalization配置節點的編碼方式，如果取不到，則預設為utf-8編碼方式
結論出來了

當用戶端js對中文以utf-8編碼提交到服務端時，用request.querystring接收時，會先以globalization配置的gb2312去解碼一次，於是，產生了亂碼。

所有的起因為：

1：js編碼方式為urt-8

2：服務端又配置了預設為gb2312

3：request.querystring預設又會調用httputility.urldecode用系統配置編碼去解碼接收參數。

解決之路

知道了原理，解決的方式也有多種多樣了：

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則為原始參數