在編程中，大多數(shù)程序員都離不開編碼問題: 系統(tǒng)的默認(rèn)區(qū)域和語言設(shè)置，代碼文件的編碼，以及代碼中字符串的編碼。

編碼簡述以及Windows默認(rèn)配置

一提到編碼大家最熟悉的莫過于ASCII(American Standard Code for Information Interchange), 其采用7個bit表示128個字符，包含了常見的英文字符、數(shù)字，控制字符等。但是ASCII不包含中文，日文等文字的編碼，便出現(xiàn)了針對中文的編碼GB2312,GBK等編碼，針對日文的Shift_JIS編碼，他們都兼容ASCII編碼，微軟]稱為ANSI(American National Standards Institute)編碼。但是有個問題，就是各個編碼之間不兼容，比如我們都知道一個字符的編碼說到底都是二進(jìn)制表示，那么0xB182?在GB2312中編碼為偙，但是在Shift_JIS編碼中為こ。說到這里讀者是不是會有兩個問題:

1. 上述的編碼并不涵蓋世界上所有語言的字符。于是這個時候出現(xiàn)了Unicode編碼方案，而對應(yīng)的編碼方式主要有UTF-8,?UTF-16,?UTF-32.

2. 上述例子中編碼值0xB182在GB2312和Shift_JIS編碼方式中有不同的字符表示。這對于對于程序員來說處理起來不是很友好了，比如0xB182這個字符保存的文本，在你的操作系統(tǒng)中用notepad打開會顯示什么字符呢？這個時候你也許會發(fā)現(xiàn)，怎么在不同人的機(jī)器上會顯示不同的字符樣式呢？

比如在我的系統(tǒng)上顯示的字符為偙:

同一個文件在另一個Windows系統(tǒng)上打開可能顯示字符こ:

然后同一個文件在另一個Windows系統(tǒng)上也可能顯示亂碼。

Notepad在解析的時候，是根據(jù)當(dāng)前的Windows的默認(rèn)配置的區(qū)域有關(guān)系，在控制面板\時鐘和區(qū)域->區(qū)域->管理->更改系統(tǒng)區(qū)域設(shè)置?(修改后會提示重啟生效)

這個配置關(guān)聯(lián)著一個相應(yīng)的Code Page, 這個就表明使用的編碼方式。比如我本機(jī)配置的是中文(簡體，中國)，那么通過命令行chcp得到代碼頁為936，通過微軟的MSDN可以查詢到為GB2312(ANSI/OEM Simplified Chinese (PRC, Singapore); Chinese Simplified (GB2312))。

根據(jù)我當(dāng)前的配置Code Page為936，那邊便在GB2312相應(yīng)字符集中找到對應(yīng)的字符偙進(jìn)行顯示啦。
如果Code Page為932(ANSI/OEM Japanese; Japanese (Shift-JIS))，那邊便從Shift-JIS相應(yīng)的字符相應(yīng)的字符集中找到字符こ進(jìn)行顯示。
如果Code Page為437?(OEM United States), 把每個字節(jié)當(dāng)成一個單獨(dú)的字符為?±亂碼樣式。

一個單元測試

有一定編碼經(jīng)驗(yàn)的同學(xué)一定聽說過URL Encoding，在RFC1738中規(guī)定URL中的除了字母和數(shù)字[0-9a-zA-Z]，特殊符號$-_. !*'(),以及一些保留字可以不做編碼，對于其他的字符需要對其進(jìn)行編碼，比如漢字程序員對應(yīng)三個字對應(yīng)的UTF-8編碼為E7A88B,E5BA8F和E59198(字節(jié)按照從低到高排序)， 其對應(yīng)的UTF-8的URL Encoding(Percent-Encoding)的編碼為程序員。URL Encoding不是本章節(jié)的重點(diǎn)，本章節(jié)的重點(diǎn)在于通過一個單元測試用例，來看一看Visual Studio中字符串的編碼(本文基于Visual Studio 2015)。那么先上一個基于gtest的測試用例，測試用主要測試了原型為std::string UrlEncoding(const std::string