asp.net頁面編碼和瀏覽器的選擇編碼
每個asp.net的朋友都知道，在新版本的visual studio，在沒有任何設置的情況下，新建頁面時的默認編碼為utf-8
我們可以從兩個地方可以看出：
第一：打開aspx頁面，“文件”->“高級保存選項”，如下圖，可以看出編碼為：Unicode（UTF-8帶簽名）
第二：找到aspx存放路徑，用系統(tǒng)自帶的文本編輯器打開，然后“文件”->"另存為"，如下圖，可以看出編碼為UTF-8
很多時候我們有些疑問，我們經(jīng)常在aspx頁面的<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />強制把carset改為gb2312
然后我們在“文件”->“高級保存選項”，可以看出編碼為：GB2312（如果你前面把carset改為gb2312，vs會自動在高級保存選項中進行綁定改變）,然后編譯運行后，右擊html“查看源”發(fā)現(xiàn)<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />沒有變化，這時候一切正常
下面以IE為例：我們以為此時 “右擊瀏覽器”->“編碼” 看到的是 瀏覽器會選中簡體中文（GB2312）,但是事實上，你看到的還是選中的Unicode（UTF-8） (再勾選了‘自動選擇’前提下)
現(xiàn)象已經(jīng)很明顯，但是需要驗證瀏覽器為何會這樣，F(xiàn)12調(diào)試瀏覽器（如下圖），我們發(fā)現(xiàn)content-type竟然是“text/html；charset=utf-8”！
這個現(xiàn)象至少說了兩個問題點：
1、asp.net機制至少在某個地方改變了response的ContentEncoding，導致雖然html頁面代碼上看到的設置<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />并沒有生效
2、瀏覽器再自動選擇編碼方式的時候不會優(yōu)先根據(jù)html源碼中的所展示的<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />代碼來決定選擇什么編碼方式，很明顯，以上的現(xiàn)象證明瀏覽器是優(yōu)先根據(jù)“響應標頭-response header”中的鍵為“Content-Type”的值來自動選擇判斷，導致html中的所看到的<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />形同虛設。
以上兩個問題點很快得到論證：
問題1、在任意新建一個測試頁面，在第一個“}”處設置斷點,然后命中斷點后再“即時窗口”中寫入“Response.ContentEncoding.EncodingName”，按enter執(zhí)行，輸出什么？沒錯："Unicode (UTF-8)"
protected void Page_Load(object sender, EventArgs e)
{
}
如果了解asp.net生命機制的朋友知道，在執(zhí)行到Page_Load之前已經(jīng)執(zhí)行了很多潛在的初始化事件，類似：Page_Init，LoadViewState， LoadPostData等等，可以想象一定是在某個地方系統(tǒng)為響應頁面指定修改了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，那么瀏覽器表現(xiàn)如何呢？
這正是我們想看到的，我相信很多朋友有過中文亂碼的情況，我先不說具體亂碼的解決方案，但是至少搜索發(fā)現(xiàn)很多解決方案是在web.config下添加如下節(jié)點，即把網(wǎng)站內(nèi)所有網(wǎng)頁的請求編碼和響應編碼都改為utf-8
<system.web>
<globalization requestEncoding="utf-8" responseEncoding="utf-8" />
</system.web>
其實，上面案例其實只是單個頁面的修改response Encoding為gb2312，我們也可以在web.config中添加<globalization requestEncoding="gb2312" responseEncoding="gb2312" />，即整個網(wǎng)站有效
問題2、瀏覽器編碼方式是根據(jù)“響應標頭-response header”中的鍵為“Content-Type”的值來自動選擇判斷，而不會簡單的根據(jù)你在html中看到的標簽值<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />來判定，雖然這個標簽一般情況下會寫入header，但是有時候會被暗中修改掉，導致html中看到的和調(diào)試捕捉到的Content-Type不一致的情況
當然在老版本的ie中，有時候出現(xiàn)的頁面全部為空白，右擊ie瀏覽器編碼發(fā)現(xiàn)沒有勾選“自動選擇”的情況下會出現(xiàn)這種白屏現(xiàn)象，那不是本文討論的范圍，但是簡單的說下原因（拷貝）：老版本的ie瀏覽器解析網(wǎng)頁編碼時以HTML內(nèi)的標簽優(yōu)先，而后才是HTTP header內(nèi)的訊息，而mozilla系列的瀏覽器則剛剛相反，由于UTF-8為3個字節(jié)表示一個漢字，而普通的GB2312或BIG5是兩個。頁面輸出時，由于上述原因，使瀏覽器解析、輸 出<title$amp;>amp;$lt;/title>的內(nèi)容時，如果在</title>前有奇數(shù)個全角字符時，IE把UTF-8當作兩 個字節(jié)解析時出現(xiàn)半個漢字的情況，這時該半個漢字會和</title>的<結(jié)合成一個亂碼字，導致IE無法讀 完<title>部分，使整個頁面為空百輸出。而這個時候如果察看源文件的話，會發(fā)現(xiàn)實際上整個葉面全部已經(jīng)輸出了
解決方法：將<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />放在<title>測試標題</title>之前（好像現(xiàn)在新建網(wǎng)頁默認都在title之前）
asp.net URL參數(shù)編碼
幾乎所有的朋友都會遇到中文情況下亂碼的問題，其原因到底是為何？
我先不說亂碼問題，先說get和post的區(qū)別，幾乎沒有人不知道
我們在新建asp.net頁面時，是很少去對form進行修改的，即保持默認的<form id="form1" runat="server">，可是編譯運行后查看代碼發(fā)現(xiàn)變成<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在請求正文中有如下圖內(nèi)容
情況2（get）：
瀏覽器選擇編碼 ： utf-8
編譯前的aspx ： <form id="form1" runat="server" method="get">
運行后的html ： <form id="form1" action="Default2.aspx" method="get">
點擊服務器按鈕(按鈕文本：阿道夫)：F12在請求正文中有如下圖內(nèi)容
其實，情況1和情況2的對比，并不是我今天想說的意圖，但是我還是要稍微順帶說下：
1、我們可以看到get方式的提交，參數(shù)僅僅是拼接在url后面，然后直接向web服務器請求，所以我們圖中“請求標頭-request header”中就可以看到參數(shù)的值，而post可以從圖中看到，在“請求標頭”中并看不到值，而在“請求正文”中看到值，說明post提交時值是包裝在請求的body中，發(fā)送給服務器，然后向服務器請求數(shù)據(jù)
2、在asp.net中，圖中可以看到不管是get還是post，提交形式不一樣，內(nèi)容確是一樣的，本文僅為測試，所以內(nèi)容相對較少，但是看起來也非常的長了，如果用get提交方式，這就帶來隱患，瀏覽器到底支持多長的uri，web服務器到底支持多長的uri，反正是有限制的（具體長度見：http://www.cnblogs.com/henryhappier/archive/2010/10/09/1846554.html），不僅僅是長度，數(shù)據(jù)量也是有限制，get數(shù)據(jù)量較小，不能大于2KB。post傳送的數(shù)據(jù)量較大，一般被默認為不受限制。但理論上，web服務器載體例如iis應該會有限制，比如IIS5的post最大傳輸量為100kb等
3、安全性，get更加容易暴露參數(shù)，而且會被保存在瀏覽器的歷史記錄中，但是對于稍微專業(yè)點的人來說，post請求傳送的數(shù)據(jù)也是可以被捕捉到的
4、緩存和seo優(yōu)化等就不提了
5、編碼問題?。。。ㄟ@邊上面說這么多，就是為了最后一個“編碼問題”）
我將著重講解編碼問題：
在Form元素的語法中，EncType表明提交數(shù)據(jù)的格式
用 Enctype 屬性指定將數(shù)據(jù)回發(fā)到服務器時瀏覽器使用的編碼類型。
一般是下面幾種類型：
application/x-www-form-urlencoded： 窗體數(shù)據(jù)被編碼為名稱/值對。這是標準的編碼格式。
multipart/form-data： 窗體數(shù)據(jù)被編碼為一條消息，頁上的每個控件對應消息中的一個部分。
text/plain： 窗體數(shù)據(jù)以純文本形式進行編碼，其中不含任何控件或格式字符。
假設此時使用get提交form方式：
瀏覽器則會用x-www-form-urlencoded的數(shù)據(jù)格式，雖然在F12瀏覽器調(diào)試或者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”是“阿道夫”三個漢字編碼后的，究竟這個編碼方式到底是什么？又是如何經(jīng)常引起亂碼問題的呢？
首先：get只能向服務器發(fā)送ASCII字符，這是W3C組織規(guī)定的，所以任何參數(shù)最后都要以ASCII碼的形式傳遞，例如“Button2=%E9%98%BF%E9%81%93%E5%A4%AB”都是ASCII碼中的英文字符和符號等字符，沒有任何中文字符，其次編碼方式是根據(jù)當前網(wǎng)頁采用選擇的編碼來編碼，例如asp.net網(wǎng)頁使用的是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瀏覽器調(diào)試時，get提交的url的最后部分一定不再是“%E9%98%BF%E9%81%93%E5%A4%AB”，
調(diào)試后發(fā)現(xiàn)是：“%B0%A2%B5%C0%B7%F2”
那么用BitConverter.ToString(System.Text.Encoding.Default.GetBytes("阿道夫"))生成的值呢？答案是：B0-A2-B5-C0-B7-F2
這一切證明了url參數(shù)編碼方式是根據(jù)當前網(wǎng)頁采用選擇的編碼來編碼
然后我將在服務端接受參數(shù)，這邊有兩種情況
情況1、ok，我再次以get方式提交form，并是以utf-8編碼（默認），此時，我在服務端通過Request.QueryString["Button2"]，我將得到“阿道夫”，一切正常
情況2、ok，我繼續(xù)以get方式提交form，并是以gb2312編碼（如何設置上文講過），此時，我在服務端通過Request.QueryString["Button2"]，我將得到“??????”，正如我愿
為何一開始正常，后面會出現(xiàn)亂碼，我這邊做幾個假設：
假設1、對于情況1 的Request.QueryString["Button2"]沒有出現(xiàn)亂碼，我是否可以猜測微軟Request.QueryString內(nèi)部自帶有解碼的操作？并且在這種情況下該操作是utf-8的解碼方式
假設2、對于情況2 的Request.QueryString["Button2"]出現(xiàn)亂碼,我是否可以猜測是因為微軟Request.QueryString內(nèi)部自帶有解碼的操作，并按照utf-8解碼方式 解碼我用gb2312編碼的字符，這種不對稱的解碼肯定是錯誤的
如何驗證我的結(jié)論？路過秋天 的這篇文章寫的很詳細，我總結(jié)下大概就是：
反編譯Request.QueryString屬性，你會發(fā)現(xiàn)有這么如下代碼：最后深入到代碼關鍵點：this._queryString.FillFromEncodedBytes(queryStringBytes, this.QueryStringEncoding);從FillFromEncodedBytes方法中可以看出調(diào)用HttpUtility.UrlDecode(bytes, num2, num3 - num2, encoding)的解碼方法，我們現(xiàn)在知道Request.QueryString內(nèi)部實現(xiàn)是調(diào)用了HttpUtility.UrlDecode解碼的方法，那么關鍵點就在HttpUtility.UrlDecode方法的第三個參數(shù)encoding到底是哪種解碼方式
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 else13 {14 if (!string.IsNullOrEmpty(this.QueryStringText))15 {16 this._queryString.FillFromString(this.QueryStringText, true, this.QueryStringEncoding);17 }18 }19 }
下面是FillFromEncodedBytes方法實現(xiàn)：
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 else20 {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 else36 {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解碼的關鍵，我們發(fā)現(xiàn)系統(tǒng)默認會先取globalization配置節(jié)點的編碼方式，如果取不到，則默認為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 set23 {24 this._encoding = value;25 this._flags.Set(32);26 }27 }
得出結(jié)論：
在method為get的提交方式中，如果在web.config中不配置任何globalization相關節(jié)點，那么Request.QueryString屬性獲取uri參數(shù)時會自動用utf-8解碼，如果此時你的頁面是采用gb2312編碼，那么cs端獲取必定會是亂碼
解決方法（form提交method為get）：
方法1、配置globalization節(jié)點，例如<globalization requestEncoding="gb2312" responseEncoding="gb2312" fileEncoding="gb2312" culture="zh-CN"/>
那么get提交的uri附加的參數(shù)會采用gb2312編碼，cs服務端Request.QueryString就會根據(jù)globalization配置的requestEncoding值gb2312進行內(nèi)部的HttpUtility.UrlDecode
方法2、不配置globalization任何節(jié)點，在html端對將要拼接到uri后面的中文參數(shù)進行encodeURIComponent或者encodeURI編碼處理，因為encodeURIComponent或者encodeURI就是utf-8的編碼方法（永遠不會變），然后再cs服務端Request.QueryString接收后，再用 HttpUtility.UrlDecode("", Encoding.Default)進行解碼（或者用Server.UrlDecode（）解碼，效果一樣，Server.UrlDecode為使用當前操作系統(tǒng)的編碼解碼方式），如下：
假設form method=get，當前環(huán)境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內(nèi)部有utf-8解碼操作，但是對于全是英文和符號等屬于assic碼的字符不會做任何解碼操作（utf-8包含assic）
string param2 = HttpUtility.UrlDecode(param1, Encoding.UTF8);//再針對性的用Encoding.UTF8對在腳本端用encodeURIComponent（編碼方式為：utf-8）編碼的param1進行對應解碼，一切都安靜了。值為“阿道夫”
如果理解了編碼解碼的機制，那么如果僅僅是在cs服務端編碼傳遞帶有中文參數(shù)的url到另一個頁面，也需要注意對應的編碼解碼問題，比如A頁面的按鈕點擊后跳轉(zhuǎn)到B頁面，我舉四種情況，大家判斷哪種情況下在B頁面接收時會有亂碼出現(xiàn)
備注： HttpUtility.UrlDecode(param1)在沒有第二個參數(shù)的情況下默認和HttpUtility.UrlDecode(param1, Encoding.UTF8)等效，除非你強制指定第二個參數(shù)比如：HttpUtility.UrlDecode(param1, Encoding.Default)
第一種：沒有配置任何globalization節(jié)點（正確）
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節(jié)點<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節(jié)點（正確）
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節(jié)點<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被大行其道的現(xiàn)在，$.ajax{}、$.post()、$.get()等函數(shù)使用時更是應該注意編碼解碼的問題，大致注意如下：
如果你的頁面使用的是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";
寫成以下形式，可以在大多數(shù)情況避免亂碼：
$.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" ，F(xiàn)12調(diào)試，發(fā)現(xiàn)Content-Type的值是：application/x-www-form-urlencoded，這也是我上面提到過的Form元素的EncType屬性：表明提交數(shù)據(jù)的格式
一般Enctype 屬性指定將數(shù)據(jù)回發(fā)到服務器時瀏覽器使用的編碼類型。
application/x-www-form-urlencoded： 窗體數(shù)據(jù)被編碼為名稱/值對。這是標準的編碼格式。
multipart/form-data： 窗體數(shù)據(jù)被編碼為一條消息，頁上的每個控件對應消息中的一個部分。
text/plain： 窗體數(shù)據(jù)以純文本形式進行編碼，其中不含任何控件或格式字符
那也就是說，假如我使用post方式提交，Enctype為application/x-www-form-urlencoded，那么那些需要提交服務器的值依然會被編碼，只不過這次不是拼接在uri后面，而是存放在body里面，那么這樣依然在不小心的情況下會帶來上面描述的亂碼問題，當然如果你是post提交，（或者你在asp.net頁面不操作form任何屬性，保持默認）那么在cs服務端請不要再用Request.QueryString獲取值了，這是獲取不到的，應該用Request.Form[""]，請盡量少用Request[""]或者Request.Params[""]，這兩個將加大你的遍歷搜索你需要參數(shù)值的范圍，Request可以訪問的有QueryString、Form、Cookies 或 ServerVariables這4個集合的數(shù)據(jù)，get請求用Request.QueryString，post用Request.Form，而Request[""]是依次訪問這4個集合，找到就返回結(jié)果，而Request.Params[""]是在訪問時，先將4個集合的數(shù)據(jù)合并到一個新集合(集合不存在時創(chuàng)建)再去查找，效率可想而知
我現(xiàn)在手動將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吧
推薦的網(wǎng)址：
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
