摘要：前后端交互過(guò)程中涉及的編碼首先，瀏覽器的設(shè)置里有設(shè)置編碼格式，一般設(shè)置為。按照設(shè)置的順序檢查檢測(cè)文件的編碼。

最近在寫(xiě)PHP，本身對(duì)PHP不太熟練。然后遇到編碼這個(gè)問(wèn)題，困擾了大半天，索性，系統(tǒng)探索解決一番。

Browser cilent: 首先，瀏覽器的設(shè)置里有設(shè)置編碼格式，一般設(shè)置為UTF-8。

AJAX request: AJAX異步請(qǐng)求的過(guò)程中可以設(shè)置編碼，contentType:"application/x-www-form-urlencoded; charset=utf-8"

PHP cilent: PHP通過(guò)$_POST這個(gè)全局變量接收前端POST過(guò)來(lái)的數(shù)據(jù)，編碼格式為AJAX在請(qǐng)求頭中設(shè)置的charset=utf-8,PHP操作的過(guò)程中可以通過(guò)iconv函數(shù)庫(kù)自行轉(zhuǎn)碼,例如iconv("UTF-8","GB2312//IGNORE",$data)

connection: 在PHP與數(shù)據(jù)庫(kù)連接的過(guò)程中可以設(shè)置connection過(guò)程中使用的編碼格式，例如CodeIgniter框架可以在數(shù)據(jù)庫(kù)配置文件database.php中，設(shè)置"char_set" => "latin1"

databases: 數(shù)據(jù)會(huì)先把數(shù)據(jù)從php客戶(hù)端的編碼轉(zhuǎn)為轉(zhuǎn)為connection中設(shè)置的編碼，再以字節(jié)流的形式傳輸并插入數(shù)據(jù)庫(kù)。

常用的編碼分為

UTF-8 萬(wàn)國(guó)碼，就是它是一種變長(zhǎng)的編碼方式

latin1 又稱(chēng)“西歐語(yǔ)言”，是mysql數(shù)據(jù)庫(kù)默認(rèn)設(shè)置。為單字節(jié)編碼

gb2312 一共收錄了7445個(gè)字符，包括6763個(gè)漢字和682個(gè)其它符號(hào)。

GBK 漢字內(nèi)碼擴(kuò)展規(guī)范,支持繁體與簡(jiǎn)體和許多符號(hào)

走上國(guó)際化就靠它了。現(xiàn)在推薦使用UTF-8，這樣外國(guó)人打開(kāi)我們的網(wǎng)站的時(shí)候不需要轉(zhuǎn)碼，直接就能使用。
不多說(shuō)了，大家都認(rèn)識(shí)。

看一下他的編碼特質(zhì)
UTF-8的設(shè)計(jì)有以下的多字符組序列的特質(zhì)

單字節(jié)字符的最高有效比特永遠(yuǎn)為0。

多字節(jié)序列中的首個(gè)字符組的幾個(gè)最高有效比特決定了序列的長(zhǎng)度。最高有效位為110的是2字節(jié)序列，而1110的是三字節(jié)序列，如此類(lèi)推。

多字節(jié)序列中其余的字節(jié)中的首兩個(gè)最高有效比特為10。

UTF-8的這些特質(zhì)，保證了一個(gè)字符的字節(jié)序列不會(huì)包含在另一個(gè)字符的字節(jié)序列中。這確保了以字節(jié)為基礎(chǔ)的部分字符串比對(duì)（sub-string match）
方法可以適用于在文字中搜索字或詞。有些比較舊的可變長(zhǎng)度8位編碼（如Shift JIS）沒(méi)有這個(gè)特質(zhì)，故字符串比對(duì)的算法變得相當(dāng)復(fù)雜。雖然這增加了UTF-8
編碼的字符串的信息冗余，但是利多于弊。另外，數(shù)據(jù)壓縮并非Unicode的目的，所以不可混為一談。即使在發(fā)送過(guò)程中有部分字節(jié)因錯(cuò)誤或干擾而完全丟失，
還是有可能在下一個(gè)字符的起點(diǎn)重新同步，令受損范圍受到限制。

另一方面，由于其字節(jié)序列設(shè)計(jì)，如果一個(gè)疑似為字符串的序列被驗(yàn)證為UTF-8編碼，那么我們可以有把握地說(shuō)它是UTF-8字符串。一段兩字節(jié)隨機(jī)序列碰巧為合法的UTF-8而非ASCII的概率為32分1。對(duì)于三字節(jié)序列的概率為256分1，對(duì)更長(zhǎng)的序列的概率就更低了。

latin1編碼是單字節(jié)編碼，向下兼容ASCII，其編碼范圍是0x00-0xFF，0x00-0x7F之間完全和ASCII一致，0x80-0x9F之間是控制字符，0xA0-0xFF之間是文字符號(hào)。

因?yàn)?b>latin1編碼范圍使用了單字節(jié)內(nèi)的所有空間，在支持latin1的系統(tǒng)中傳輸和存儲(chǔ)其他任何編碼的字節(jié)流都不會(huì)被拋棄。換言之，把其他任何編碼的字節(jié)流當(dāng)作latin1編碼看待都沒(méi)有問(wèn)題。
這是個(gè)很重要的特性，MySQL數(shù)據(jù)庫(kù)默認(rèn)編碼是Latin1就是利用了這個(gè)特性，latin1編碼是一個(gè)8位的容器。

把一個(gè)gbk編碼的串寫(xiě)入latin1的表，不會(huì)有任何問(wèn)題，保存的是原封不動(dòng)的字節(jié)流，從表中讀取已寫(xiě)入的串也不會(huì)有任何問(wèn)題，且讀出的字節(jié)流就和當(dāng)初寫(xiě)入的完全一致。

讀取出來(lái)以后，如果在終端下，就會(huì)理解成locale類(lèi)型（如果locale系gbk，當(dāng)時(shí)寫(xiě)入的gbk中文串可正常回顯）讀取出來(lái)以后，如果要寫(xiě)入文件，則文件編碼方式即當(dāng)時(shí)寫(xiě)入的字節(jié)流編碼，如gbk寫(xiě)入的，讀出存入文件后，文件編碼也是gbk！
但是如果混著寫(xiě)（utf-8 + gbk),那編輯器就犯蒙了，就可能會(huì)顯示會(huì)有亂碼。

當(dāng)然，基于可維護(hù)的角度，還是統(tǒng)一為UTF-8編碼格式，以免出現(xiàn)亂碼。

因?yàn)闅v史原因，很多網(wǎng)頁(yè)和數(shù)據(jù)庫(kù)依然使用這個(gè)編碼格式
應(yīng)該逐步升級(jí)為UTF-8。

每個(gè)文件都設(shè)置了其編碼的格式,大部分推薦使用UTF-8。

一個(gè)文本文件，vim打開(kāi)的時(shí)候按某種編碼A打開(kāi)，轉(zhuǎn)換成某種編碼B，然后保存的時(shí)候轉(zhuǎn)換成另一種編碼C，其他文本編輯器類(lèi)似，可能沒(méi)有vim這么可以設(shè)置和自動(dòng)完成。
編碼B：對(duì)于整個(gè)文件沒(méi)有影響，只是事關(guān)顯示的，就是vim與操作系統(tǒng)交互時(shí)候使用的編碼。

編碼A：使用 set fileencodings=ucs-bom,utf-8,gbk,cp936,latin-1設(shè)置。vim 按照設(shè)置的順序檢查檢測(cè)文件的編碼。因?yàn)槟承┚幋a里不存在某些二進(jìn)制序列的組合，所以如果檢測(cè)到就認(rèn)為不是這種編碼，檢查下一種編碼，否則就認(rèn)為是這一種。因?yàn)閘atin-1可以出現(xiàn)任何二進(jìn)制序列的組合，所以如果放到第一個(gè)，那么將永遠(yuǎn)以latin-1顯示。

在一般的二進(jìn)制文件里是不存在字符編碼的標(biāo)記的。但是Unicode里面有個(gè)特殊叫做零寬度空格（FEFF）而FFFE是不存在的編碼，所以在Unicode的標(biāo)準(zhǔn)里可以人為的在開(kāi)始加入這個(gè)字符（這個(gè)字符在任何字體下都是沒(méi)有寬度的，在中文字符里面沒(méi)有任何的效果跟沒(méi)有一樣，是為了照顧東南亞某些語(yǔ)言的顯示而設(shè)置的）。這樣就便于文本編輯器檢查字符和字節(jié)順序，但是在代碼里include這種文件經(jīng)常會(huì)出問(wèn)題（這可是個(gè)大坑，編譯器會(huì)認(rèn)為這是一個(gè)非法字符，可是你又看不到）。

編碼B：set fileencoding=utf-8，保存時(shí)候使用的編碼，保存的時(shí)候自動(dòng)轉(zhuǎn)換為另一種編碼。但是如果一開(kāi)始打開(kāi)的時(shí)候就識(shí)別錯(cuò)了編碼，再轉(zhuǎn)換的時(shí)候一個(gè)不存在的字符也是不會(huì)完轉(zhuǎn)換的。

mysql的latin1 支持中文

UTF-8維基百科

VIM 文件編碼識(shí)別與亂碼處理

WilsonLiu"s blog首發(fā)地址：http://blog.wilsonliu.cn