你不知道的 頁面編碼，瀏覽器選擇編碼，get，post各種亂碼由來

asp.net頁面編碼和瀏覽器的選擇編碼

每個asp.net的朋友都知道，在新版本的visual studio，在沒有任何設置的情況下，新建頁面時的默認編碼為utf-8

我們可以從兩個地方可以看出：

第一：打開aspx頁面，“文件”->“高級保存選項”，如下圖，可以看出編碼為：Unicode（UTF-8帶簽名）

第二：找到aspx存放路徑，用系統自帶的文本編輯器打開，然后“文件”->"另存為"，如下圖，可以看出編碼為UTF-8

很多時候我們有些疑問，我們經常在aspx頁面的<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />強制把carset改為gb2312

然后我們在“文件”->“高級保存選項”，可以看出編碼為：GB2312（如果你前面把carset改為gb2312，vs會自動在高級保存選項中進行綁定改變）,然后編譯運行后，右擊html“查看源”發現<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />沒有變化，這時候一切正常

下面以IE為例：我們以為此時 “右擊瀏覽器”->“編碼” 看到的是 瀏覽器會選中簡體中文（GB2312）,但是事實上，你看到的還是選中的Unicode（UTF-8）  (再勾選了‘自動選擇’前提下)

現象已經很明顯，但是需要驗證瀏覽器為何會這樣，F12調試瀏覽器（如下圖），我們發現content-type竟然是“text/html；charset=utf-8”！

 

這個現象至少說了兩個問題點：

1、asp.net機制至少在某個地方改變了response的ContentEncoding，導致雖然html頁面代碼上看到的設置<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />並沒有生效

2、瀏覽器再自動選擇編碼方式的時候不會優先根據html源碼中的所展示的<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />代碼來決定選擇什么編碼方式，很明顯，以上的現象證明瀏覽器是優先根據“響應標頭-response header”中的鍵為“Content-Type”的值來自動選擇判斷，導致html中的所看到的<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />形同虛設。

 

以上兩個問題點很快得到論證：

問題1、
出現這個現象，我們知道<META http-equiv="content-type" content="text/html; charset=xxx"> 標簽是設置頁面編碼的，meta標簽是屬於html的，https標頭是服務器以HTTP協議傳送HTML信息到瀏覽器前所送出的字串，所以header發送的內容先到達瀏覽器
在任意新建一個測試頁面，在第一個“}”處設置斷點,然后命中斷點后再“即時窗口”中寫入“Response.ContentEncoding.EncodingName”，按enter執行，輸出什么？沒錯："Unicode (UTF-8)"

protected void Page_Load(object sender, EventArgs e)
{

}

如果了解asp.net生命機制的朋友知道，在執行到Page_Load之前已經執行了很多潛在的初始化事件，類似：Page_Init，LoadViewState， LoadPostData等等，可以想象一定是在某個地方系統為響應頁面指定修改了ContentEncoding的值，也就是“響應標頭-response header”中的鍵為“Content-Type”的值為“UTF-8”

我們不妨做一個測試，上面說過，我把<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />的carset改為gb2312,是沒有效果的，那么我如果在Page_Load事件中如下寫上代碼：

protected void Page_Load(object sender, EventArgs e)
{
            Encoding gb2312 = Encoding.GetEncoding("gb2312");
            Response.ContentEncoding = gb2312;
 }

即我在load事件中再次強制性把響應標頭中的“Content-Type”改為gb2312，那么瀏覽器表現如何呢？

這正是我們想看到的，我相信很多朋友有過中文亂碼的情況，我先不說具體亂碼的解決方案，但是至少搜索發現很多解決方案是在web.config下添加如下節點，即把網站內所有網頁的請求編碼和響應編碼都改為utf-8

<system.web>
<globalization requestEncoding="utf-8" responseEncoding="utf-8" />
</system.web>

其實，上面案例其實只是單個頁面的修改response Encoding為gb2312，我們也可以在web.config中添加<globalization requestEncoding="gb2312" responseEncoding="gb2312" />，即整個網站有效

問題2、瀏覽器編碼方式是根據“響應標頭-response header”中的鍵為“Content-Type”的值來自動選擇判斷，而不會簡單的根據你在html中看到的標簽值<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />來判定，雖然這個標簽一般情況下會寫入header，但是有時候會被暗中修改掉，導致html中看到的和調試捕捉到的Content-Type不一致的情況

當然在老版本的ie中，有時候出現的頁面全部為空白，右擊ie瀏覽器編碼發現沒有勾選“自動選擇”的情況下會出現這種白屏現象，那不是本文討論的范圍，但是簡單的說下原因（拷貝）：老版本的ie瀏覽器解析網頁編碼時以HTML內的標簽優先，而后才是HTTP header內的訊息，而mozilla系列的瀏覽器則剛剛相反，由於UTF-8為3個字節表示一個漢字，而普通的GB2312或BIG5是兩個。頁面輸出時，由於上述原因，使瀏覽器解析、輸 出<title$amp;>amp;$lt;/title>的內容時，如果在</title>前有奇數個全角字符時，IE把UTF-8當作兩 個字節解析時出現半個漢字的情況，這時該半個漢字會和</title>的<結合成一個亂碼字，導致IE無法讀 完<title>部分，使整個頁面為空百輸出。而這個時候如果察看源文件的話，會發現實際上整個葉面全部已經輸出了

解決方法：將<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />放在<title>測試標題</title>之前（好像現在新建網頁默認都在title之前）

 

asp.net URL參數編碼

幾乎所有的朋友都會遇到中文情況下亂碼的問題，其原因到底是為何？

我先不說亂碼問題，先說get和post的區別，幾乎沒有人不知道

我們在新建asp.net頁面時，是很少去對form進行修改的，即保持默認的<form id="form1" runat="server">，可是編譯運行后查看代碼發現變成<form method="post" action="Default2.aspx" id="form1">

很顯然，asp.net默認會為form的method寫上post，但是需要注意的是如果僅僅是單純的html頁面，form默認的method是get

 

我這邊可以舉一個例子詮釋一些無關緊要但是又比較重要的東西：

情況1（post）：

瀏覽器選擇編碼 ：  utf-8

編譯前的aspx  ：  <form id="form1"  runat="server">

運行后的html  ：  <form id="form1" action="Default2.aspx" method="post">

點擊服務器按鈕(按鈕文本：阿道夫)：F12在請求正文中有如下圖內容

 

 情況2（get）：

瀏覽器選擇編碼 ：  utf-8

編譯前的aspx  ：  <form id="form1"  runat="server" method="get">

運行后的html  ：  <form id="form1" action="Default2.aspx" method="get">

點擊服務器按鈕(按鈕文本：阿道夫)：F12在請求正文中有如下圖內容

 

其實，情況1和情況2的對比，並不是我今天想說的意圖，但是我還是要稍微順帶說下：

1、我們可以看到get方式的提交，參數僅僅是拼接在url后面，然后直接向web服務器請求，所以我們圖中“請求標頭-request header”中就可以看到參數的值，而post可以從圖中看到，在“請求標頭”中並看不到值，而在“請求正文”中看到值，說明post提交時值是包裝在請求的body中，發送給服務器，然后向服務器請求數據

2、在asp.net中，圖中可以看到不管是get還是post，提交形式不一樣，內容確是一樣的，本文僅為測試，所以內容相對較少，但是看起來也非常的長了，如果用get提交方式，這就帶來隱患，瀏覽器到底支持多長的uri，web服務器到底支持多長的uri，反正是有限制的（具體長度見：http://www.cnblogs.com/henryhappier/archive/2010/10/09/1846554.html），不僅僅是長度，數據量也是有限制，get數據量較小，不能大於2KB。post傳送的數據量較大，一般被默認為不受限制。但理論上，web服務器載體例如iis應該會有限制，比如IIS5的post最大傳輸量為100kb等

3、安全性，get更加容易暴露參數，而且會被保存在瀏覽器的歷史記錄中，但是對於稍微專業點的人來說，post請求傳送的數據也是可以被捕捉到的

4、緩存和seo優化等就不提了

5、編碼問題！！！（這邊上面說這么多，就是為了最后一個“編碼問題”）

我將着重講解編碼問題：

在Form元素的語法中，EncType表明提交數據的格式
用 Enctype 屬性指定將數據回發到服務器時瀏覽器使用的編碼類型。
一般是下面幾種類型：
application/x-www-form-urlencoded： 窗體數據被編碼為名稱/值對。這是標准的編碼格式。
multipart/form-data： 窗體數據被編碼為一條消息，頁上的每個控件對應消息中的一個部分。
text/plain： 窗體數據以純文本形式進行編碼，其中不含任何控件或格式字符。

假設此時使用get提交form方式：

瀏覽器則會用x-www-form-urlencoded的數據格式，雖然在F12瀏覽器調試或者cs代碼中的Request.ContentType都看不出來。注意如下是我的get提交的url：

GET /Default2.aspx?__VIEWSTATE=MGASeC9kBMq4iDCI2YLRzkZYqkKYhDhWH2jlP5mpv7idP8gAoNcy0T0y6g6wRvccP%2BFz%2FVx4HdMGwLLW%2BYPbJsMEOTMi5PjS7Ea66DmHQJc%3D&__VIEWSTATEGENERATOR=9BD98A7D&__EVENTVALIDATION=BFMAr0Q6mSwngMhaCLeScGaXywIIRlFClDYAnVhHprxOeifBIGWKNbsunWO9yVOAV6jWHW%2FJ4g2laHQpTvJe%2Fc7X8vralK3hyO5Y0nuiJkT%2FdfxEj9NnCb8S5BfNvZKXVJA%2FOy8yH4Bf9K5DN%2FRI9aDR3EFR86Zm6fN4iEkvJfc%3D&Button2=%E9%98%BF%E9%81%93%E5%A4%AB

我只看最后部分“Button2=%E9%98%BF%E9%81%93%E5%A4%AB”，這是我的服務器按鈕“阿道夫”，這一串“%E9%98%BF%E9%81%93%E5%A4%AB”是“阿道夫”三個漢字編碼后的，究竟這個編碼方式到底是什么？又是如何經常引起亂碼問題的呢？

首先：get只能向服務器發送ASCII字符，這是W3C組織規定的，所以任何參數最后都要以ASCII碼的形式傳遞，例如“Button2=%E9%98%BF%E9%81%93%E5%A4%AB”都是ASCII碼中的英文字符和符號等字符，沒有任何中文字符，其次編碼方式是根據當前網頁采用選擇的編碼來編碼，例如asp.net網頁使用的是utf-8碼，那么“阿道夫”用utf-8的編碼后的十六進制字符串就是“E9-98-BF-E9-81-93-E5-A4-AB”，和上面提到的“%E9%98%BF%E9%81%93%E5%A4%AB”是不是非常的類似，只是多了百分號

如何查看中文字符的十六進制字符串？方法：BitConverter.ToString(System.Text.Encoding.UTF8.GetBytes("阿道夫"));

如果用本文一開始介紹的方法，在Page_Load中加上

Encoding gb2312 = Encoding.GetEncoding("gb2312");
Response.ContentEncoding = gb2312;

強制把當前頁面編碼改為gb2312，然后點擊按鈕，那么我們猜測在F12瀏覽器調試時，get提交的url的最后部分一定不再是“%E9%98%BF%E9%81%93%E5%A4%AB”，

調試后發現是：“%B0%A2%B5%C0%B7%F2”

那么用BitConverter.ToString(System.Text.Encoding.Default.GetBytes("阿道夫"))生成的值呢？答案是：B0-A2-B5-C0-B7-F2

這一切證明了url參數編碼方式是根據當前網頁采用選擇的編碼來編碼

然后我將在服務端接受參數，這邊有兩種情況

情況1、ok，我再次以get方式提交form，並是以utf-8編碼（默認），此時，我在服務端通過Request.QueryString["Button2"]，我將得到“阿道夫”，一切正常

情況2、ok，我繼續以get方式提交form，並是以gb2312編碼（如何設置上文講過），此時，我在服務端通過Request.QueryString["Button2"]，我將得到“������”，正如我願

 

為何一開始正常，后面會出現亂碼，我這邊做幾個假設：

假設1、對於情況1 的Request.QueryString["Button2"]沒有出現亂碼，我是否可以猜測微軟Request.QueryString內部自帶有解碼的操作？並且在這種情況下該操作是utf-8的解碼方式

假設2、對於情況2 的Request.QueryString["Button2"]出現亂碼,我是否可以猜測是因為微軟Request.QueryString內部自帶有解碼的操作，並按照utf-8解碼方式 解碼我用gb2312編碼的字符，這種不對稱的解碼肯定是錯誤的

如何驗證我的結論？路過秋天  的這篇文章寫的很詳細，我總結下大概就是：

反編譯Request.QueryString屬性，你會發現有這么如下代碼：最后深入到代碼關鍵點：this._queryString.FillFromEncodedBytes(queryStringBytes, this.QueryStringEncoding);從FillFromEncodedBytes方法中可以看出調用HttpUtility.UrlDecode(bytes, num2, num3 - num2, encoding)的解碼方法，我們現在知道Request.QueryString內部實現是調用了HttpUtility.UrlDecode解碼的方法，那么關鍵點就在HttpUtility.UrlDecode方法的第三個參數encoding到底是哪種解碼方式

public NameValueCollection QueryString
{
    get
    {
        this.EnsureQueryString();
        if (this._flags[1])
        {
            this._flags.Clear(1);
            this.ValidateHttpValueCollection(this._queryString, RequestValidationSource.QueryString);
        }
        return this._queryString;
    }
}

 

internal HttpValueCollection EnsureQueryString()
{
    if (this._queryString == null)
    {
        this._queryString = new HttpValueCollection();
        if (this._wr != null)
        {
            this.FillInQueryStringCollection();
        }
        this._queryString.MakeReadOnly();
    }
    return this._queryString;
}

 

private void FillInQueryStringCollection()
{
    byte[] queryStringBytes = this.QueryStringBytes;
    if (queryStringBytes != null)
    {
        if (queryStringBytes.Length != 0)
        {
            this._queryString.FillFromEncodedBytes(queryStringBytes, this.QueryStringEncoding);  9             return;
        }
    }
    else
    {
        if (!string.IsNullOrEmpty(this.QueryStringText))
        {
            this._queryString.FillFromString(this.QueryStringText, true, this.QueryStringEncoding);
        }
    }
}

 下面是FillFromEncodedBytes方法實現：

internal void FillFromEncodedBytes(byte[] bytes, Encoding encoding)
{
    int num = (bytes != null) ? bytes.Length : 0;
    for (int i = 0; i < num; i++)
    {
        this.ThrowIfMaxHttpCollectionKeysExceeded();
        int num2 = i;
        int num3 = -1;
        while (i < num)
        {
            byte b = bytes[i];
            if (b == 61)
            {
                if (num3 < 0)
                {
                    num3 = i;
                }
            }
            else
            {
                if (b == 38)
                {
                    break;
                }
            }
            i++;
        }
        string name;
        string value;
        if (num3 >= 0)
        {
            name = HttpUtility.UrlDecode(bytes, num2, num3 - num2, encoding); 33             value = HttpUtility.UrlDecode(bytes, num3 + 1, i - num3 - 1, encoding); 34         }
        else
        {
            name = null;
            value = HttpUtility.UrlDecode(bytes, num2, i - num2, encoding); 39         }
        base.Add(name, value);
        if (i == num - 1 && bytes[i] == 38)
        {
            base.Add(null, string.Empty);
        }
    }
}

this.QueryStringEncoding是HttpUtility.UrlDecode解碼的關鍵，我們發現系統默認會先取globalization配置節點的編碼方式，如果取不到，則默認為UTF-8編碼方式

internal Encoding QueryStringEncoding
{
    get
    {
        Encoding contentEncoding = this.ContentEncoding;
        if (!contentEncoding.Equals(Encoding.Unicode))
        {
            return contentEncoding;
        }
        return Encoding.UTF8; 11     }
}

public Encoding ContentEncoding
{
    get
    {
        if (this._flags[32] && this._encoding != null)
        {
            return this._encoding;
        }
        this._encoding = this.GetEncodingFromHeaders();
        if (this._encoding is UTF7Encoding && !AppSettings.AllowUtf7RequestContentEncoding)
        {
            this._encoding = null;
        }
        if (this._encoding == null)
        {
            GlobalizationSection globalization = RuntimeConfig.GetLKGConfig(this._context).Globalization; 17   this._encoding = globalization.RequestEncoding; 18         }
        this._flags.Set(32);
        return this._encoding;
    }
    set
    {
        this._encoding = value;
        this._flags.Set(32);
    }
}

 

得出結論：

在method為get的提交方式中，如果在web.config中不配置任何globalization相關節點，那么Request.QueryString屬性獲取uri參數時會自動用utf-8解碼，如果此時你的頁面是采用gb2312編碼，那么cs端獲取必定會是亂碼

解決方法（form提交method為get）：

方法1、配置globalization節點，例如<globalization requestEncoding="gb2312" responseEncoding="gb2312" fileEncoding="gb2312" culture="zh-CN"/>
那么get提交的uri附加的參數會采用gb2312編碼，cs服務端Request.QueryString就會根據globalization配置的requestEncoding值gb2312進行內部的HttpUtility.UrlDecode
方法2、不配置globalization任何節點，在html端對將要拼接到uri后面的中文參數進行encodeURIComponent或者encodeURI編碼處理，因為encodeURIComponent或者encodeURI就是utf-8的編碼方法（永遠不會變），然后再cs服務端Request.QueryString接收后，再用 HttpUtility.UrlDecode("", Encoding.Default)進行解碼（或者用Server.UrlDecode（）解碼，效果一樣，Server.UrlDecode為使用當前操作系統的編碼解碼方式），如下：

假設form method=get，當前環境ContentEncoding為gb2312

未做任何處理操作時要請求服務器的uri的一部分：
Default2.aspx?Button2=%B0%A2%B5%C0%B7%F2

在腳本端用encodeURIComponent對”阿道夫“進行編碼后的將要請求服務器的uri的一部分：
Default2.aspx?Button2=%E9%98%BF%E9%81%93%E5%A4%AB

cs服務端:
              string param1 = Request.QueryString["Button2"];//param1的值為：%E9%98%BF%E9%81%93%E5%A4%AB，雖然Request.QueryString內部有utf-8解碼操作，但是對於全是英文和符號等屬於assic碼的字符不會做任何解碼操作（utf-8包含assic）
              string param2 = HttpUtility.UrlDecode(param1, Encoding.UTF8);//再針對性的用Encoding.UTF8對在腳本端用encodeURIComponent（編碼方式為：utf-8）編碼的param1進行對應解碼，一切都安靜了。值為“阿道夫”

如果理解了編碼解碼的機制，那么如果僅僅是在cs服務端編碼傳遞帶有中文參數的url到另一個頁面，也需要注意對應的編碼解碼問題，比如A頁面的按鈕點擊后跳轉到B頁面，我舉四種情況，大家判斷哪種情況下在B頁面接收時會有亂碼出現

備注：  HttpUtility.UrlDecode(param1)在沒有第二個參數的情況下默認和HttpUtility.UrlDecode(param1, Encoding.UTF8)等效，除非你強制指定第二個參數比如：HttpUtility.UrlDecode(param1, Encoding.Default)
第一種：沒有配置任何globalization節點（正確）
A頁面的按鈕代碼：

protected void Button1_Click(object sender, EventArgs e)
        {
            string param = "阿道夫";
            Response.Redirect("~/Default.aspx?param=" + param);
        }

B頁面的接收代碼：

string param1 = Request.QueryString["param"];

第二種：配置了globalization節點<globalization requestEncoding="gb2312" responseEncoding="gb2312" fileEncoding="gb2312" culture="zh-CN"/>（正確）

A頁面的按鈕代碼：

1 protected void Button1_Click(object sender, EventArgs e) 2  { 3 string param = "阿道夫"; 4 Response.Redirect("~/Default.aspx?param=" + param); 5 }

B頁面的接收代碼：

1 string param1 = Request.QueryString["param"];

第三種：沒有配置任何globalization節點（正確）
A頁面的按鈕代碼：

1 protected void Button1_Click(object sender, EventArgs e) 2  { 3 string param = "阿道夫"; 4 Response.Redirect("~/Default.aspx?param=" + HttpUtility.UrlEncode(param)); 5 }

B頁面的接收代碼：

1 string param1 = Request.QueryString["param"];

 

第四種：配置了globalization節點<globalization requestEncoding="gb2312" responseEncoding="gb2312" fileEncoding="gb2312" culture="zh-CN"/>（亂碼）

A頁面的按鈕代碼：

1 protected void Button1_Click(object sender, EventArgs e) 2  { 3 string param = "阿道夫"; 4 Response.Redirect("~/Default.aspx?param=" + HttpUtility.UrlEncode(param));
5 }

B頁面的接收代碼：

1 string param1 = Request.QueryString["param"];

參考上面的解釋，應該能理解為何第四種是亂碼，這里不再做太多解釋

另外在jquery被大行其道的現在，$.ajax{}、$.post()、$.get()等函數使用時更是應該注意編碼解碼的問題，大致注意如下：
如果你的頁面使用的是gb2312編碼，不要用jquery的$.get()或$.post()做ajax提交，因為這兩個方法默認為utf-8，而且是無法指定修改contentType的，默認為：contentType:"pplication/x-www-form-urlencoded; charset=UTF-8"，為什么無法修改？因為$.post 和$.get()本身就只是 $.ajax 的 post 或者get方式的一種簡寫形式，既然是簡寫為了方便使用當然會固定死很多屬性
可以用$.ajax()並在其中加入：contentType:"application/x-www-form-urlencoded; charset=GB2312";
寫成以下形式，可以在大多數情況避免亂碼：
$.ajax({
  type: "POST",
 contentType:"pplication/x-www-form-urlencoded; charset=GB2312",
  url: "XXX“,
  data: {},
  success: function(msg){ alert( msg ); }
});

 

*****以上使用get提交form方式的介紹真的可以告一段落，我想我寫的很臃腫，表達上會有很多冗余的地方******

下面介紹post提交form的方式

在asp.net頁面的form不做任何處理的時候，默認編譯生成html時會自動加上method="post" ，F12調試，發現Content-Type的值是：application/x-www-form-urlencoded，這也是我上面提到過的Form元素的EncType屬性：表明提交數據的格式
一般Enctype 屬性指定將數據回發到服務器時瀏覽器使用的編碼類型。
application/x-www-form-urlencoded： 窗體數據被編碼為名稱/值對。這是標准的編碼格式。
multipart/form-data： 窗體數據被編碼為一條消息，頁上的每個控件對應消息中的一個部分。
text/plain： 窗體數據以純文本形式進行編碼，其中不含任何控件或格式字符

那也就是說，假如我使用post方式提交，Enctype為application/x-www-form-urlencoded，那么那些需要提交服務器的值依然會被編碼，只不過這次不是拼接在uri后面，而是存放在body里面，那么這樣依然在不小心的情況下會帶來上面描述的亂碼問題，當然如果你是post提交，（或者你在asp.net頁面不操作form任何屬性，保持默認）那么在cs服務端請不要再用Request.QueryString獲取值了，這是獲取不到的，應該用Request.Form[""]，請盡量少用Request[""]或者Request.Params[""]，這兩個將加大你的遍歷搜索你需要參數值的范圍，Request可以訪問的有QueryString、Form、Cookies 或 ServerVariables這4個集合的數據，get請求用Request.QueryString，post用Request.Form，而Request[""]是依次訪問這4個集合，找到就返回結果，而Request.Params[""]是在訪問時，先將4個集合的數據合並到一個新集合(集合不存在時創建)再去查找，效率可想而知

 

我現在手動將form改為：<form id="form1" enctype="multipart/form-data" method="post" runat="server"> 注意multipart/form-data只能用於post

瀏覽器會把整個表單以控件為單位分割，並為每個部分加上Content-Disposition(form-data或者file),Content-Type(默認為text/plain),name(控件name)等信息，並加上分割符
 

“boundary”是分隔符的意思，一般multipart/form-data用於文件上傳，普通的傳參或者提交form元素列表值還是使用默認的application/x-www-form-urlencoded吧

 

推薦的網址：

http://www.cnblogs.com/cyq1162/archive/2010/11/29/1891124.html
http://blog.sina.com.cn/s/blog_89cd68470101e21m.html 
http://www.cnblogs.com/fish-li/archive/2011/12/06/2278463.html