問題：
前段時間，在系統中做了一個類似于友情鏈接的功能塊，一直運行良好，直到有一天加了類似于以下的鏈接地址：http://www.****.com/user.aspx?id=水天，就出現大問題了：
１、從ＩＥ地址欄中直接輸入這個地址，訪問沒錯；
?。?、做一個靜態頁，其中包括這個超鏈接，點擊訪問也沒錯；
?。?、就是把這個鏈接添加到這個功能塊中，點擊訪問那邊接收到的是亂碼。
一開始，被這個問題也搞得頭大，在google了一把后，總算是把問題給搞清楚了，其實只要這個鏈接地址不經過任何編碼傳遞是不會有問題的。但就是加到了這個功能塊后，再點擊，雖然這個時候在ＩＥ地址欄里顯示的還是"http://www.****.com/user.aspx?id=水天"，但真正傳遞過去的參數"水天"其實已經經過類似于Server.UrlEncode的操作了，當然默認是utf-8編碼，正是由于這個原因，如果對方系統不進行相應的解碼，直接操作該參數，就產生了以上的錯誤。
解決方法：
網上有很多解決之道，最常見的莫過于以下幾點：
?。?、在web.config里配制<globalization requestEncoding="gb2312" responseEncoding="gb2312" />，這個方法確實可行，但我想很多人不想用這種方法來解決，把整個項目的請求和回應都定為gb2312，我覺得不是一個好辦法，有點本末倒置了，畢竟這會導致很多其它問題的出現。
２、把要包含該鏈接的aspx文檔，修改其charset屬性為gb2312。這個方法到也可以接受，不過對于該文中的問題還不是最好的方法，因為該功能塊是可以動態添加到任何頁面的，難道要去修改所有的頁面？想想還是不太合適。
３、直接用Server.UrlEncode和Server.Decode進行加碼和解碼操作，這種方法對于發送方和接收方都在一個項目中是可行的，現在的問題是，我們要隨意去訪問別人的系統，所以只能棄用此方法了。
?。?、采用HttpUtility.UrlEncode(query, System.Text.Encoding.GetEncoding("GB2312"));對鏈接中的參數值進行gb2312的編碼，這種方法，對方不用進行任何解碼操作，直接接收參數則不會出現亂碼。
一般提到最多的也就上面４種方法，其它的也跟這些大同小異。仔細分析后，覺得還是第４種方法最適合解決當前問題，把中文參數進行如４中的操作。但又出現另外一個問題，由于這是一個用戶可以自由輸入鏈接地址的功能，所以首先要做的就是得先分析這些鏈接ＵＲＬ，解析出參數，再對這些參數進行４中操作，然后再合拼成原來的ＵＲＬ地址。
幸虧，ＵＲＬ參數解析Ｃ#已經有類庫的支持，不用再去寫那些復雜的正則表達式來匹配了。這里我也不詳細說了，直接貼出原碼：
復制代碼代碼如下:
public static string InitChineseUrl(string chineseUrl)
{
Uri url = new Uri(chineseUrl);
System.Collections.Specialized.NameValueCollection nv = System.Web.HttpUtility.ParseQueryString(url.Query, System.Text.Encoding.GetEncoding("utf-8"));
string query = "";
for (int i = 0; i < nv.Count; i++)
{
if (query.Trim() == string.Empty)
{
query = "?" + nv.Keys[i] + "=" + HttpUtility.UrlEncode(nv[i], System.Text.Encoding.GetEncoding("GB2312"));
}
else
{
query += "&" + nv.Keys[i] + "=" + HttpUtility.UrlEncode(nv[i], System.Text.Encoding.GetEncoding("GB2312"));
}
}
string u = chineseUrl.Split('?')[0] + query;
return u;
}
這里我是把所有的參數都進行gb2312編碼操作了，反正參數如果是英文或者是數字，經過這些操作后還是不變的。
