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

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

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

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

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

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

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

常用的編碼分為

UTF-8 萬國碼，就是它是一種變長的編碼方式

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

gb2312 一共收錄了7445個字符，包括6763個漢字和682個其它符號。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

mysql的latin1 支持中文

UTF-8維基百科

VIM 文件編碼識別與亂碼處理

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