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

時間 2019-11-10

標籤不知道頁面編碼瀏覽器選擇 post 各類亂碼由來欄目字符編碼简体版

原文原文鏈接

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

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

咱們能夠從兩個地方能夠看出：web

第一：打開aspx頁面，「文件」->「高級保存選項」，以下圖，能夠看出編碼爲：Unicode（UTF-8帶簽名）ajax

第二：找到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」！app

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

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

二、瀏覽器再自動選擇編碼方式的時候不會優先根據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" />形同虛設。

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

問題一、
出現這個現象，咱們知道<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" />，即整個網站有效

問題二、瀏覽器編碼方式是根據「響應標頭-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的對比，並非我今天想說的意圖，可是我仍是要稍微順帶說下：

一、咱們能夠看到get方式的提交，參數僅僅是拼接在url後面，而後直接向web服務器請求，因此咱們圖中「請求標頭-request header」中就能夠看到參數的值，而post能夠從圖中看到，在「請求標頭」中並看不到值，而在「請求正文」中看到值，說明post提交時值是包裝在請求的body中，發送給服務器，而後向服務器請求數據

二、在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等

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

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

五、編碼問題！！！（這邊上面說這麼多，就是爲了最後一個「編碼問題」）

我將着重講解編碼問題：

在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參數編碼方式是根據當前網頁採用選擇的編碼來編碼

而後我將在服務端接受參數，這邊有兩種狀況

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

狀況二、ok，我繼續以get方式提交form，並是以gb2312編碼（如何設置上文講過），此時，我在服務端經過Request.QueryString["Button2"]，我將獲得「��」，正如我願

爲什麼一開始正常，後面會出現亂碼，我這邊作幾個假設：

假設一、對於狀況1 的Request.QueryString["Button2"]沒有出現亂碼，我是否能夠猜想微軟Request.QueryString內部自帶有解碼的操做？而且在這種狀況下該操做是utf-8的解碼方式

假設二、對於狀況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究竟是哪一種解碼方式

 1 public NameValueCollection QueryString
 2 {
 3     get
 4     {
 5         this.EnsureQueryString();
 6         if (this._flags[1])
 7         {
 8             this._flags.Clear(1);
 9             this.ValidateHttpValueCollection(this._queryString, RequestValidationSource.QueryString);
10         }
11         return this._queryString;
12     }
13 }

QueryString

 1 internal HttpValueCollection EnsureQueryString()
 2 {
 3     if (this._queryString == null)
 4     {
 5         this._queryString = new HttpValueCollection();
 6         if (this._wr != null)
 7         {
 8             this.FillInQueryStringCollection();
 9         }
10         this._queryString.MakeReadOnly();
11     }
12     return this._queryString;
13 }

EnsureQueryString

 1 private void FillInQueryStringCollection()
 2 {
 3     byte[] queryStringBytes = this.QueryStringBytes;
 4     if (queryStringBytes != null)
 5     {
 6         if (queryStringBytes.Length != 0)
 7         {
 8             this._queryString.FillFromEncodedBytes(queryStringBytes, this.QueryStringEncoding);  9             return;
10         }
11     }
12     else
13     {
14         if (!string.IsNullOrEmpty(this.QueryStringText))
15         {
16             this._queryString.FillFromString(this.QueryStringText, true, this.QueryStringEncoding);
17         }
18     }
19 }

下面是FillFromEncodedBytes方法實現：

 1 internal void FillFromEncodedBytes(byte[] bytes, Encoding encoding)
 2 {
 3     int num = (bytes != null) ? bytes.Length : 0;
 4     for (int i = 0; i < num; i++)
 5     {
 6         this.ThrowIfMaxHttpCollectionKeysExceeded();
 7         int num2 = i;
 8         int num3 = -1;
 9         while (i < num)
10         {
11             byte b = bytes[i];
12             if (b == 61)
13             {
14                 if (num3 < 0)
15                 {
16                     num3 = i;
17                 }
18             }
19             else
20             {
21                 if (b == 38)
22                 {
23                     break;
24                 }
25             }
26             i++;
27         }
28         string name;
29         string value;
30         if (num3 >= 0)
31         {
32             name = HttpUtility.UrlDecode(bytes, num2, num3 - num2, encoding); 33             value = HttpUtility.UrlDecode(bytes, num3 + 1, i - num3 - 1, encoding); 34         }
35         else
36         {
37             name = null;
38             value = HttpUtility.UrlDecode(bytes, num2, i - num2, encoding); 39         }
40         base.Add(name, value);
41         if (i == num - 1 && bytes[i] == 38)
42         {
43             base.Add(null, string.Empty);
44         }
45     }
46 }

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

 1 internal Encoding QueryStringEncoding
 2 {
 3     get
 4     {
 5         Encoding contentEncoding = this.ContentEncoding;
 6         if (!contentEncoding.Equals(Encoding.Unicode))
 7         {
 8             return contentEncoding;
 9         }
10         return Encoding.UTF8; 11     }
12 }

 1 public Encoding ContentEncoding
 2 {
 3     get
 4     {
 5         if (this._flags[32] && this._encoding != null)
 6         {
 7             return this._encoding;
 8         }
 9         this._encoding = this.GetEncodingFromHeaders();
10         if (this._encoding is UTF7Encoding && !AppSettings.AllowUtf7RequestContentEncoding)
11         {
12             this._encoding = null;
13         }
14         if (this._encoding == null)
15         {
16             GlobalizationSection globalization = RuntimeConfig.GetLKGConfig(this._context).Globalization; 17   this._encoding = globalization.RequestEncoding; 18         }
19         this._flags.Set(32);
20         return this._encoding;
21     }
22     set
23     {
24         this._encoding = value;
25         this._flags.Set(32);
26     }
27 }

得出結論：

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

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

方法一、配置globalization節點，例如<globalization requestEncoding="gb2312" responseEncoding="gb2312" fileEncoding="gb2312" culture="zh-CN"/>
那麼get提交的uri附加的參數會採用gb2312編碼，cs服務端Request.QueryString就會根據globalization配置的requestEncoding值gb2312進行內部的HttpUtility.UrlDecode
方法二、不配置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頁面的按鈕代碼：

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節點<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吧