“Server.UrlDecode(Server.UrlEncode("北京")) == “北京””，先用UrlEncode編碼然后用UrlDecode解碼，這條語句永遠為true嗎？答案是否定的，結果可能與很多人預想的不大一樣。本文主要分析這一問題出現的原理，研究下Server.UrlEncode()，Server.UrlDecode()，Request["xxx"]三個函數與編碼方式的關系。
1. 問題出現的情景
網站采用了GB2312編碼，在Web.config中添加如下配置。
<system.web> <globalization requestEncoding="GB2312" responseEncoding="GB2312"/> </system.web>
測試頁面EncodeServerTest.aspx.cs代碼。
PRotected void Page_Load(object sender, EventArgs e) { string s = Server.UrlDecode(Server.UrlEncode("北京")); bool isEqual = s == "北京"; }
測試頁面EncodeServerTest.aspx代碼。
<html xmlns="http://www.w3.org/1999/xhtml"><head runat="server"> <title>頁面編碼測試(服務器端)</title> <script type="text/javascript" src="Scripts/jquery-2.1.1.min.js"></script></head><body> <form id="form1" runat="server"> <div> <input type="button" name="btnAjaxPost" value="AJax提交" onclick="Ajax()" /> <div id="divMessage" style="color: red"></div> </div> </form> <script type="text/Javascript"> function Ajax() { $.ajax({ type: "POST", url: "EncodeServerTest.aspx", data: {name:"name"}, success: function (data) { $("#divMessage").html(data); } }); } </script></body></html>View Code
運行頁面，首次執行時，編碼解碼方式都為GB2312，isEuqal=true；點擊頁面的button，通過ajax再次請求頁面，編碼方式仍為GB2312，但解碼方式變成了UTF-8，于是s值成了亂碼，isEqual=false。下面兩個圖分別為兩次執行的結果：
實際項目遇到問題的場景比這復雜，但也是因為UrlEncode編碼和UrlDecode解碼方式不一致造成的，本系列的第三篇會有實際項目場景的說明。要解釋這一現象，必須了解UrlEncode()和UrlDecode()的實現。
2. Server.UrlEncode()函數
反編譯UrlEncode()函數，實現如下：
public string UrlEncode(string s) { Encoding e = (this._context != null) ? this._context.Response.ContentEncoding : Encoding.UTF8; return HttpUtility.UrlEncode(s, e); }從源碼可以看出，有上下文時用的是Response.ContentEncoding，沒有上下文時默認用UTF-8編碼。關鍵是Response.ContentEncoding的實現，繼續反編譯ContentEncoding的實現：
public Encoding ContentEncoding { get { if (this._encoding == null) { GlobalizationSection globalization = RuntimeConfig.GetLKGConfig(this._context).Globalization; if (globalization != null) { this._encoding = globalization.ResponseEncoding; } if (this._encoding == null) { this._encoding = Encoding.Default; } } return this._encoding; } }結論：UrlEncode()函數，優先從取配置文件的Globalization結點獲取，如果配置文件沒有的話用Encoding.Default，最后默認用Encoding.UTF8。
3. Server.UrlDecode()函數
反編譯UrlEncode()函數，實現如下：
public string UrlDecode(string s) { Encoding e = (this._context != null) ? this._context.Request.ContentEncoding : Encoding.UTF8; return HttpUtility.UrlDecode(s, e); }從源碼可以看出，有上下文時用的是Request.ContentEncoding，沒有上下文時默認用UTF-8編碼。關鍵是Request.ContentEncoding的實現，繼續反編譯ContentEncoding的實現：
public Encoding ContentEncoding { get { if (!this._flags[0x20] || (this._encoding == null)) { 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; this._encoding = globalization.RequestEncoding; } this._flags.Set(0x20); } return this._encoding; } set { this._encoding = value; this._flags.Set(0x20); } }從源碼可以看出，Request.ContentEncoding先通過函數GetEncodingFromHeaders()獲取，如果獲取不到，則從配置文件獲取，接下來看GetEncodingFromHeaders()的實現：
private Encoding GetEncodingFromHeaders() { if ((this.UserAgent != null) && CultureInfo.InvariantCulture.CompareInfo.IsPrefix(this.UserAgent, "UP")) { string str = this.Headers["x-up-devcap-post-charset"]; if (!string.IsNullOrEmpty(str)) { try { return Encoding.GetEncoding(str); } catch { } } } if (!this._wr.HasEntityBody()) { return null; } string contentType = this.ContentType; if (contentType == null) { return null; } string attributeFromHeader = GetAttributeFromHeader(contentType, "charset"); if (attributeFromHeader == null) { return null; } Encoding encoding = null; try { encoding = Encoding.GetEncoding(attributeFromHeader); } catch { } return encoding; }View Code從GetEncodingFromHeaders()的源碼可以看出，先從HTTP請求頭（x-up-devcap-post-charset或者charset）獲取編碼信息，如果編碼合法的話則采用HTTP請求頭指定的編碼方式解碼。
結論：UrlDecode()函數，優先從HTTP請求頭（x-up-devcap-post-charset或者charset）獲取編碼，如果沒指定的話從取配置文件的Globalization結點獲取，最后默認Encoding.UTF8。
通過對UrlEncode()和UrlDecode()源碼的分析，可以看出兩者在確定編碼上并不一致，UrlDecode()和HTTP請求的頭有關，而通過Fiddler對比EncodeServerTest.aspx頁面的兩次請求，發現通過Ajax方式的請求，請求頭正好多了“Content-Type:application/x-www-form-urlencoded; charset=UTF-8”一句，文章開始的問題得以解釋。
補充：獲取Response.ContentEncoding和Request.ContentEncoding時，還有一個重要的函數”GlobalizationSection globalization = RuntimeConfig.GetLKGConfig(this._context).Globalization“，網上關于這個函數的資料很少，反編譯后代碼也很復雜，看的云里霧里，下面摘錄一部分代碼，從總可以猜測這個函數的功能：根據配置文件的繼承關系，取配置文件中Globalization結點的Request和Response編碼方式，如果沒取到的話默認取UTF-8編碼，個人感覺獲取Request.ContentEncoding時的分支Encoding.Default賦值應該不會被執行。
internal static RuntimeConfig GetLKGConfig(HttpContext context) { RuntimeConfig lKGRuntimeConfig = null; bool flag = false; try {
新聞熱點
疑難解答
