文字编码
?
編碼一直是讓新手頭疼的問題，特別是 GBK、GB2312、UTF-8 這三個比較常見的網頁編碼的區別，更是讓許多新手暈頭轉向，怎么解釋也解釋不清楚。但是編碼又是那么重要，特別在網頁這一塊。如果你打出來的不是亂碼，而網頁中出現了亂碼，絕大部分原因就出在了編碼上了。此外除了亂碼之外，還會出現一些其他問題（例如：IE6 的 CSS 加載問題）等等。潛行者m?寫出本文的目的，就是要徹底解釋清楚這個編碼問題！如果你遇到了類似的問題，那就要仔細的看看這篇文章。
ANSI、GBK、GB2312、UTF-8、GB18030和 UNICODE
這幾個編碼關鍵詞是比較常見的，雖然我把我們放在了一起說，但并不意味這這幾個東西是平級的關系。本部分的內容，引用自網絡略有修改，不知原文出處，故無法署名。
很久很久以前，有一群人，他們決定用8個可以開合的晶體管來組合成不同的狀態，以表示世界上的萬物，他們把這稱為”字節”。再后來，他們又做了一些可以處理這些字節的機器，機器開動了，可以用字節來組合出很多狀態，狀態開始變來變去，他們就把這機器稱為”計算機”。
開始計算機只在美國用。八位的字節一共可以組合出256(2的8次方)種不同的狀態。他們把其中的編號從0開始的32種狀態分別規定了特殊的用途，一但終端、打印機遇上約定好的這些字節被傳過來時，就要做一些約定的動作。遇上 00×10, 終端就換行，遇上0×07, 終端就向人們嘟嘟叫，例好遇上0x1b, 打印機就打印反白的字，或者終端就用彩色顯示字母。他們看到這樣很好，于是就把這些0×20以下的字節狀態稱為”控制碼”。
他們又把所有的空格、標點符號、數字、大小寫字母分別用連續的字節狀態表示，一直編到了第127號，這樣計算機就可以用不同字節來存儲英語的文字 了。大家看到這樣，都感覺很好，于是大家都把這個方案叫做?ANSI?的”Ascii”編碼（American Standard Code for Information Interchange，美國信息互換標準代碼）。當時世界上所有的計算機都用同樣的ASCII方案來保存英文文字。
后來計算機發展越來越廣泛，世界各國為了可以在計算機保存他們的文字，他們決定采用127號之后的空位來表示這些新的字母、符號，還加入了很多畫表格時需要用下到的橫線、豎線、交叉等形狀，一直把序號編到了 最后一個狀態255。從128到255這一頁的字符集被稱”擴展字符集”。但是原有的編號方法，已經再也放不下更多的編碼。
等中國人們得到計算機時，已經沒有可以利用的字節狀態來表示漢字，況且有6000多個常用漢字需要保存呢。于是國人就自主研發，把那些127號之后的奇異符號們直接取消掉。規定：一個小于127的字符的意義與原來相同，但兩個大于127的字符連在一起時，就表示一個漢字，前面的一個字節（他稱之為高字節）從0xA1用到 0xF7，后面一個字節（低字節）從0xA1到0xFE，這樣我們就可以組合出大約7000多個簡體漢字了。在這些編碼里，我們還把數學符號、羅馬希臘的字母、日文的假名們都編進去了，連在 ASCII 里本來就有的數字、標點、字母都統統重新編了兩個字節長的編碼，這就是常說的”全角”字符，而原來在127號以下的那些就叫”半角”字符了。
中國人民看到這樣很不錯，于是就把這種漢字方案叫做 “GB2312″。GB2312?是對?ASCII?的中文擴展。
但是中國的漢字太多了，后來還是不夠用，于是干脆不再要求低字節一定是127號之后的內碼，只要第一個字節是大于127就固定表示這是一個漢字的開始，不管后面跟的是不是 擴展字符集里的內容。結果擴展之后的編碼方案被稱為?GBK?標準，GBK 包括了 GB2312 的所有內容，同時又增加了近20000個新的漢字（包括繁體字）和符號。后來少數民族也要用電腦了，于是我們再擴展，又加了幾千個新的少數民族的字，GBK?擴成了?GB18030。從此之后，中華民族的文化就可以在計算機時代中傳承了。
因為當時各個國家都像中國這樣搞出一套自己的編碼標準，結果互相之間誰也不懂誰的編碼，誰也不支持別人的編碼。當時的中國人想讓電腦顯示漢字，就必須裝上一個”漢字系統”，專門用來處理漢字的顯示、輸入的問題，裝錯了字符系統，顯示就會亂了套。這怎么辦？就在這時，一個叫?ISO?（國際標誰化組織）的國際組織決定著手解決這個問題。他們采用的方法很簡單：廢了所有的地區性編碼方案，重新搞一個包括了地球上所有文化、所有字母和符號的編碼！他們打算叫它”Universal Multiple-Octet Coded Character Set”，簡稱 UCS, 俗稱 “UNICODE”。
UNICODE 開始制訂時，計算機的存儲器容量極大地發展了，空間再也不成為問題了。于是 ISO 就直接規定必須用兩個字節，也就是16位來統一表示所有的字符，對于 ascii 里的那些”半角”字符，UNICODE 包持其原編碼不變，只是將其長度由原來的8位擴展為16位，而其他文化和語言的字符則全部重新統一編碼。由于”半角”英文符號只需要用到低8位，所以其高 8位永遠是0，因此這種大氣的方案在保存英文文本時會多浪費一倍的空間。
但是，UNICODE 在制訂時沒有考慮與任何一種現有的編碼方案保持兼容，這使得 GBK 與UNICODE 在漢字的內碼編排上完全是不一樣的，沒有一種簡單的算術方法可以把文本內容從UNICODE編碼和另一種編碼進行轉換，這種轉換必須通過查表來進行。UNICODE 是用兩個字節來表示為一個字符，他總共可以組合出65535不同的字符，這大概已經可以覆蓋世界上所有文化的符號。
UNICODE 來到時，一起到來的還有計算機網絡的興起，UNICODE 如何在網絡上傳輸也是一個必須考慮的問題，于是面向傳輸的眾多 UTF（UCS Transfer Format）標準出現了，顧名思義，UTF8?就是每次8個位傳輸數據，而?UTF16?就是每次16個位，只不過為了傳輸時的可靠性，從UNICODE到 UTF時并不是直接的對應，而是要過一些算法和規則來轉換。
還有一個ANSI編碼，參考?https://blog.csdn.net/imxiangzi/article/details/77370160
看完這些，相信你對于這幾個編碼關系等，了解的比較清楚了吧。我再來簡單的總結一下：
- 中國人民通過對 ASCII 編碼的中文擴充改造，產生了 GB2312 編碼，可以表示6000多個常用漢字。
- 漢字實在是太多了，包括繁體和各種字符，于是產生了 GBK 編碼，它包括了 GB2312 中的編碼，同時擴充了很多。
- 中國是個多民族國家，各個民族幾乎都有自己獨立的語言系統，為了表示那些字符，繼續把 GBK 編碼擴充為 GB18030 編碼。
- 每個國家都像中國一樣，把自己的語言編碼，于是出現了各種各樣的編碼，如果你不安裝相應的編碼，就無法解釋相應編碼想表達的內容。
- 終于，有個叫 ISO 的組織看不下去了。他們一起創造了一種編碼 UNICODE ，這種編碼非常大，大到可以容納世界上任何一個文字和標志。所以只要電腦上有 UNICODE 這種編碼系統，無論是全球哪種文字，只需要保存文件的時候，保存成 UNICODE 編碼就可以被其他電腦正常解釋。
- UNICODE 在網絡傳輸中，出現了兩個標準 UTF-8 和 UTF-16，分別每次傳輸 8個位和 16個位。
于是就會有人產生疑問，UTF-8 既然能保存那么多文字、符號，為什么國內還有這么多使用 GBK 等編碼的人？因為 UTF-8 等編碼體積比較大，占電腦空間比較多，如果面向的使用人群絕大部分都是中國人，用 GBK 等編碼也可以。但是目前的電腦來看，硬盤都是白菜價，電腦性能也已經足夠無視這點性能的消耗了。所以推薦所有的網頁使用統一編碼：UTF-8。
關于記事本無法單獨保存“聯通”的問題
當你新建一個 文本文檔 之后，在里面輸入 “聯通” 兩個字，然后保存。當你再次打開的時候，原來輸入的 “聯通” 會變成兩個亂碼。
?
這個問題就是因為 GB2312 編碼與 UTF8 編碼產生了編碼沖撞造成的。從網上引來一段從UNICODE到UTF8的轉換規則：
UTF-8
0000 – 007F
0xxxxxxx
0080 – 07FF
110xxxxx 10xxxxxx
0800 – FFFF
1110xxxx 10xxxxxx 10xxxxxx
例如”漢”字的Unicode編碼是6C49。6C49在0800-FFFF之間，所以要用3字節模板：1110xxxx 10xxxxxx 10xxxxxx。將6C49寫成二進制是：0110 1100 0100 1001，將這個比特流按三字節模板的分段方法分為0110 110001 001001，依次代替模板中的x，得到：1110-0110 10-110001 10-001001，即E6 B1 89，這就是其UTF8的編碼。
而當你新建一個文本文件時，記事本的編碼默認是ANSI, 如果你在ANSI的編碼輸入漢字，那么他實際就是GB系列的編碼方式，在這種編碼下，”聯通”的內碼是：
c1 1100 0001
aa 1010 1010
cd 1100 1101
a8 1010 1000
注意到了嗎？第一二個字節、第三四個字節的起始部分的都是”110″和”10″，正好與UTF8規則里的兩字節模板是一致的，于是再次打開記事本 時，記事本就誤認為這是一個UTF8編碼的文件，讓我們把第一個字節的110和第二個字節的10去掉，我們就得到了”00001 101010″，再把各位對齊，補上前導的0，就得到了”0000 0000 0110 1010″，不好意思，這是UNICODE的006A，也就是小寫的字母”j”，而之后的兩字節用UTF8解碼之后是0368，這個字符什么也不是。這就 是只有”聯通”兩個字的文件沒有辦法在記事本里正常顯示的原因。
由這個問題，可以發散出很多問題。比較常見的一個問題就是：我已經把文件保存成了 XX 編碼，為什么每次打開，還是原來的 YY 編碼？！原因就在于此，你雖然保存成了 XX 編碼，但是系統識別的時候，卻誤識別為了 YY 編碼，所以還是顯示為 YY 編碼。為了避免這個問題，微軟公司弄出了一個叫?BOM?頭的東西。
關于文件 BOM 頭的問題
當使用類似 WINDOWS 自帶的記事本等軟件，在保存一個以UTF-8編碼的文件時，會在文件開始的地方插入三個不可見的字符（0xEF 0xBB 0xBF，即BOM）。它是一串隱藏的字符，用于讓記事本等編輯器識別這個文件是否以UTF-8編碼。這樣就可以避免這個問題了。對于一般的文件，這樣并不會產生什么麻煩。
這樣做，也有弊處，尤其體現在網頁中。PHP并不會忽略BOM，所以在讀取、包含或者引用這些文件時，會把BOM作為該文件開頭正文 的一部分。根據嵌入式語言的特點，這串字符將被直接執行（顯示）出來。由此造成即使頁面的 top padding 設置為0，也無法讓整個網頁緊貼瀏覽器頂部，因為在html一開頭有這3個字符。如果你在網頁中，發現了由未知的空白等，很有可能就是由于文件有 BOM 頭造成的。遇到這種問題，把文件保存的時候，不要帶有 BOM 頭！
如何查看和修改某文檔的編碼
1，直接使用記事本查看和修改。我們可以用記事本打開文件，然后點擊左上角的 “文件” =》“另存為”，這時候就會彈出一個保存的窗口。在下面選擇好編碼之后，點擊保存就可以了。
?
但是這種方式的選擇余地非常小，通常用來快速查看文件是什么編碼。我更推薦使用下面的方法。
2，使用其他文本編輯器（例如：notepad ++）來查看修改。幾乎所有的成熟的文本編輯器（例如：Dreamweaver、Emeditor等），都可以快速查看或修改文件編碼。這一點尤其體現在 notepad++ 上面。
打開一個文件之后，會在右下角顯示當前文件的編碼。
?
點擊上面菜單欄中的 “encoding” 即可把當前文檔轉換成其他編碼
?
IE6 的加載 CSS 文件 BUG
當 HTML 文件的編碼 與想要加載 CSS 的文件不一致的時候，IE6 將無法讀取 CSS 文件，即 HTML 文件沒有樣式。就本人的觀察，這個問題從未在其他瀏覽器中出現過，只在 IE6 中出現過。只需要把 CSS 文件，保存成 HTML 文件的編碼即可。
對于vc2010，在unicode編碼環境下:
1._T
是一個宏，在unicode環境下，_T被替換為L，而L表示被修飾的字符串為unicode字符串；在多字節環境下_T則為空
比如unicode環境下，_T("AB")表示為L"AB"；
2.
MFC預定義的其他幾個宏
? ? ? ??
? ? ? ? wchar_t//unsigned short
?? ??? ?CHAR //char
?? ??? ?WCHAR // wchar_t
?? ??? ?TCHAR //WCHAR 或 CHAR
?? ?
?? ??? ?//指針類型的宏
?? ??? ?LPSTR //CHAR*
?? ??? ?LPWSTR //WCHAR*
?? ??? ?LPTSTR //TCHAR* ，即 WCHAR* 或 CHAR*
?? ??? ?LPCTSTR //TCHAR* ，即 const WCHAR* 或 const CHAR*
3.CString
CString是一個宏，在unicode環境下被替換為CStringW，所以定義變量的時候，字符串字面量需要加_T來表示是寬字符，類似CString wstr= _T("AB")
如果不想加_T，則需要特別指定用CStringA ，比如 CStringA awstr= "AB";
4.std::string
而std::string是一個類型，不是宏。所以，需要根據實際情況直接用std::string和std::wstring。不管在unicode環境或gb2312環境下，std::string都是表示多字節編碼，std::wstring都是表示寬字節編碼
綜上，
如果想在unicode環境下和多字節環境下都能正常編譯，對于CString的處理需要注意下，因為CString 是一個宏，所以需要對CString的字符串字面量需要也用一個宏_T來修飾，即等號的左邊要么都用T系列的宏，要么都不用
如下
CString s1= _T("AB")//等號兩邊都用宏，unicode和多字節環境下都能編譯通過
CStringA s1= "AB"//等號兩邊都不用宏，unicode和多字節環境下都能編譯通過
CStringW s1= L"AB"//等號兩邊都不用宏，unicode和多字節環境下都能編譯通過
而對于std::string和std::wstring需要如下處理
std::string s1 = "ab"
std::wstring s1 = L"ab"//不要用std::wstring s1 = _T("ab"),在多字節下編譯不過
對于char和wchar,則需要如下處理
?? ?CHAR *p1 = "AB";//
?? ?WCHAR *p2 = L"AB";
?? ?TCHAR *p3 = _T("AB");//兩邊都是用T系列的宏，會自動根據系統編碼類型替換為unicode類型或多字節類型
不管在unicode編碼環境還是多字節編碼環境下，
CStringA 就是gb2312的編碼，CStringW就是用unicode編碼
std::string 就是gb2312的編碼，std::wstring就是用unicode編碼
而CString需要根據編碼環境來確定是gb2312還是unicode編碼
參考文獻
http://www.qianxingzhem.com/post-1499.html
https://www.cnblogs.com/ccjt/p/4320244.html
總結
- 上一篇： 六十分之一——首记
- 下一篇： css hover变成手_css鼠标样式