在日常編寫代碼過程中，常常會碰到亂碼問題，一個典型的情況是瀏覽網頁，如果網站開發者缺少經驗，就會帶來這種令人頭疼的問題。要了解亂碼的症結，我們就得從字符集和字符編碼說起，先來看看它們到底是什么：
1：字符集：是一個系統支持的所有抽象字符的集合。字符是各種文字和符號的總稱，包括各國家文字、標點符號、圖形符號、數字等。
2：字符編碼：是一套法則，最常規的理解就是：讓程序根據這個法則對應到相應的字符集中將byte[]存取為string。
現在，我們要來看看這些東西在 .NET 中對應的是什么。
一：字符集和字符編碼
如果想得到全部的字符集，則使用 System.Text.Encoding.GetEncodings() 方法，以下代碼用於列出.Net支持的全部字符集：
foreach (var item in Encoding.GetEncodings())
{
Console.WriteLine(item.Name);
}
字符串在進行如網絡傳輸等場景時，要先轉為 byte[] 。但是，首先，不同的字符編碼規則，所轉換生成的byte[]是不一樣的。所以，再將byte[]轉換回string的時候，要依據原先的字符編碼規則。有如下幾種情況能導致“亂碼”的產生：
1：string to byte[] 和 byte[] to string，使用了不同的字符編碼規則；
2：byte[] to string 的 時候，當前宿主環境沒有對應的字符集；
示例：
string originalString = "Hello Test, 測試!";
byte[] utf8Bytes = Encoding.UTF8.GetBytes(originalString);
string utf8String = Encoding.UTF8.GetString(utf8Bytes);
string errorString = Encoding.ASCII.GetString(utf8Bytes);
觀察Encoding類，實際上象上面UTF8這樣的屬性，只有幾個，這些是最常用的字符集，要獲取其它，如gb2312這樣的字符集，則需要象如下這樣來獲得：
byte[] gbBytes = Encoding.GetEncoding("gb2312").GetBytes(originalString);
string utf8String = Encoding.GetEncoding("gb2312").GetString(gbBytes);
二：典型應用場景之 HttpWebResponse
很多人都作過頁面抓取功能， HttpWebResponse 就會比較熟悉，當然如果不嫌麻煩，也可以用 Socket 實現，但是同時要解析很多屬性以及處理象重定向之類的諸多問題。
2.1 http header 和http content是什么？
瀏覽一個網頁，使用很多工具，或者使用.Net中的某些類進行抓取，都給我們結構化為 Http 頭和正文這樣的信息，其實，當我們發送一個請求，服務器返回給我們的是一串 byte[]，我們完全可以自己去從這串 byte[] 解析出 http header 和 http content，它們之間其實僅僅非常簡單的以兩個 /r/n/ 分割開而已，歷史上有著名的CRLF攻擊，CR就是\r，LF就是\n，就利用的是這個規則。
2.2 我們如何察看http header，http content？
其實很簡單，既然這些都是 byte[] ，所以，我們只要知道這段 byte[] 正確的字符編碼規則，就能得到我們所需要看到的 html （html就是字符串而已）。使用 HttpWebResponse 這個類，就能請求一個 url ，該類自動為我們解析出了 httpheader ，有意思的是，它沒有給我們解析出 content ，所以，我們需要自己完成正文的byte[] to string。
2.3 http content to string的具體做法
好的，實際上，httpheader 中已經告訴了我們一些字符集編碼相關的信息，我們可能感興趣，以及會混淆的這些http頭如下：
Content-Type：WEB 服務器告訴瀏覽器自己響應的對象的類型和字符集。例如：Content-Type: text/html; charset='gb2312' ；
Content-Encoding：WEB 服務器表明自己使用了什么壓縮方法（gzip，deflate）壓縮響應中的對象。例如：Content-Encoding：gzip 。這里我要多說一點，這個 Content-Encoding 的 Http header 會令人混淆，極度容易讓人理解成是字符集或字符編碼信息；
那么,這些 Http 頭在HttpWebResponse 中是怎么代表的呢?
HttpWebResponse.Content-Type對應的是Http頭的Content-Type比如"text/html;"后的那個Charset，實際是和HttpWebResponse.Charaterset是一致的。但是如果前者無，則后者
一般會指定一個默認的HttpWebResponse.Charaterset，默認為"iso-8859-1"。
HttpWebResponse.ContentEncoding 代表的是 http頭中 Content-Encoding，與此類似的，還有一個http頭，為Transfer-Encoding。注意，很惡心的一點是HttpResponse.ContentEncoding跟HttpWebResponse.ContentEncoding代表的不是一個東西，它和HttpResponse.Charaterset在MSDN上是一致的解釋。
根據上面的說法，似乎下面的代碼就能得到http content的字符編碼規則：
return Encoding.GetEncoding(
string.IsNullOrEmpty(HttpWebResponse.Charaterset) ?
"iso-8859-1" : HttpWebResponse.Charaterset
但是，這里有一個很重要的但是，如果你嘗試從Http頭或者HttpWebResponse所給我的這些字符編碼信息或屬性去解碼正文content的話，很可能馬上就會迎來一個大大的挫折。我們很可能會發現以下幾個可悲的事實：
1：http頭的Content-Type中沒有charset信息；
2：HttpWebResponse.Charaterset是空的；
3：http頭的Content-Type和HttpWebResponse.Charaterset是不一致的；
4：http頭的Content-Type和HttpWebResponse.Charaterset是一致的，但是解碼還是錯的；
5：嘗試用"iso-8859-1"解碼也是錯的。
2.4 為什么還是有亂碼問題？BOM能解決一切？
之所以碰到以上問題，其實僅僅是因為，服務器給我們傳回來的是byte[]，而任何程序員在寫服務器端WEB程序的時候，都有可能有意或無意的轉碼出不規范的byte[]來。所以，如果我們嘗試從http頭的Content-Type和HttpWebResponse.Charaterset想要得到編碼規則，我們就敗了，我們敗在了有標准，但是沒人嚴格去執行標准。
有一些頗具迷惑性的API試圖在告訴我們，使用我你就能得到該流正確的Encoding了，比如，StreamReader.CurrentEncoding，我們可以把HttpWebResponse的GetResponse中讀取到
byte[]，放置到MemoryStream中，然后利用如下代碼：
StreamReader sr = new StreamReader(memoryStream, true)
return sr.CurrentEncoding;
似乎就可以得到Encoding了，其實非也，注意StreamReader構造器的第二個參數，為detectEncodingFromByteOrderMarks。ByteOrderMarks是什么呢？解釋如下：
BOM（byte-order mark），即字節順序標記，它是插入到以UTF-8、UTF16或UTF-32編碼Unicode文件開頭的特殊標記，用來識別Unicode文件的編 碼類型。對於UTF-8來說，BOM並不是必須的，因為BOM用來標記多字節編碼文件的編碼類型和字節順序（big-endian或little- endian）。
這表明了什么呢？表明了如果你的字節流未含有BOM，或者即便包含了BOM，但是字節流不是unicode-based的Encoding，則依舊不能得到正確的Encoding，具體我們也可以看StreamReader的源碼來得到驗證。這個萬惡的CurrentEncoding屬性並沒有告訴你它的前提條件。
2.5 關於本例的一點補充
以上字節流的編碼解碼，很多地方用了Response做例子，但是，以上解碼針對的是非壓縮的Response，如果服務器已經對http流進行了壓縮（其壓縮格式在Content-Encoding中指明了），我們就得先解壓縮，再解碼Response流，然后再解碼正文。考慮到本文的主題，特意剪裁了對於 Response 流的解壓過程。
2.6 關於正確解碼的嘗試
有很多人嘗試從byte[]本身去解析和判斷編碼規則的API，如：codeproject上也有相關的文章，但是可悲的事實是：並沒有一種完美的方法來自動判斷byte[]的編碼規則。還記得我們的瀏覽器（如IE）的編碼設置中的“自動選擇”嗎，其實這個自動選擇的錯誤率還是蠻高的。所以，對於字節流的生成者，如BS程序開發者，可以通過規范輸出：聲明charset和編碼規范的方式，這樣才能讓解析者（如瀏覽器）解析的時候盡可能的少出現亂碼。