因?yàn)殡娔X是windows 7系統(tǒng)，開發(fā)環(huán)境又在linux，經(jīng)常在linux碰到亂碼問題，很是痛苦，于是決定好好了解編碼的來龍氣脈，并分享個(gè)各位，免得出現(xiàn)亂碼時(shí)不知所措。

是否存在文件編碼

在講解字符編碼之前，我們需先明確文件本身沒有編碼一說，只有文字才有編碼的概念，我們通常說某個(gè)文件是什么編碼，通常是指文件里字符的編碼。

vim為什么會(huì)出現(xiàn)亂碼

我在linux下一般使用vim進(jìn)行文件編輯，發(fā)現(xiàn)經(jīng)常會(huì)碰到亂碼的情況，那么為什么會(huì)出現(xiàn)亂碼呢？ 首先我們了解下vim編碼方面的基礎(chǔ)知識(shí)，關(guān)于編碼方面vim存在3個(gè)變量：

1.encoding: Vim 內(nèi)部使用的字符編碼方式，包括 Vim 的 buffer (緩沖區(qū))、菜單文本、消息文本等。默認(rèn)是根據(jù)你的locale選擇.用戶手冊(cè)上建議只在 .vimrc 中改變它的值，事實(shí)上似乎也只有在.vimrc 中改變它的值才有意義。你可以用另外一種編碼來編輯和保存文件，如你的vim的encoding為utf-8,所編輯的文件采用cp936編碼,vim會(huì)自動(dòng)將讀入的文件轉(zhuǎn)成utf-8(vim的能讀懂的方式），而當(dāng)你寫入文件時(shí),又會(huì)自動(dòng)轉(zhuǎn)回成cp936（文件的保存編碼).

2.fileencoding: Vim 中當(dāng)前編輯的文件的字符編碼方式，Vim 保存文件時(shí)也會(huì)將文件保存為這種字符編碼方式 (不管是否新文件都如此)。

3.termencoding: Vim 所工作的終端 (或者 Windows 的 Console 窗口) 的字符編碼方式。如果vim所在的term與vim編碼相同，則無需設(shè)置。如其不然，你可以用vim的termencoding選項(xiàng)將自動(dòng)轉(zhuǎn)換成term的編碼.

當(dāng)這三個(gè)變量的編碼出現(xiàn)問題時(shí)就會(huì)出現(xiàn)亂碼:

1.encoding不是utf-8編碼：如果encoding不是utf-8編碼，其他字符可能無法轉(zhuǎn)為 Encoding的指定編碼。如：如果encoding是gbk編碼，而文件內(nèi)容采用big5編碼的，其就無法轉(zhuǎn)換為gbk編碼。

2.fileencoding不對(duì)：Fileencoding編碼是vim的讀取文件內(nèi)容時(shí)使用的編碼，如果其編碼與文件字符編碼不同，必然會(huì)出現(xiàn)亂碼。Fileencoding編碼一般由vim自動(dòng)檢測，可以使用fileencodings設(shè)置，Vim自動(dòng)探測fileencoding的順序列表。不過vim有時(shí)候會(huì)檢測錯(cuò)誤，就會(huì)出現(xiàn)亂碼了。

3.termencoding編碼不對(duì)：我們登錄服務(wù)器一般采用遠(yuǎn)程登錄，這就涉及終端編碼問題，我經(jīng)常碰到因?yàn)榻K端編碼不對(duì)導(dǎo)致亂碼的。如：SecureCRT設(shè)置為utf-8編碼，而vim的termencoding卻為gbk，就出現(xiàn)亂碼了。

字符編碼介紹

說了那么多，到底字符編碼是什么玩意呢？

字符(Character)是文字與符號(hào)的總稱，包括文字、圖形符號(hào)、數(shù)學(xué)符號(hào)等，一組抽象字符的集合就是字符集(Charset)。 字符集常常和一種具體的語言文字對(duì)應(yīng)起來，該文字中的所有字符或者大部分常用字符就構(gòu)成了該文字的字符集，比如英文字符集，漢字字符集。 計(jì)算機(jī)要處理各種字符，就需要將字符和二進(jìn)制內(nèi)碼對(duì)應(yīng)起來，這種對(duì)應(yīng)關(guān)系就是字符編碼(Encoding)。 制定編碼首先要確定字符集，并將字符集內(nèi)的字符排序，然后和二進(jìn)制數(shù)字對(duì)應(yīng)起來。根據(jù)字符集內(nèi)字符的多少，會(huì)確定用幾個(gè)字節(jié)來編碼。

字符集和編碼的區(qū)別：

字符集字符的集合，不一定適合計(jì)算機(jī)存儲(chǔ)、網(wǎng)絡(luò)傳送、處理，有時(shí)須經(jīng)編碼(encode)后才能應(yīng)用。如Unicode字符集可依不同需要以UTF-8、UTF-16、UTF-32等方式編碼。

字符編碼的發(fā)展

字符編碼大概分為三個(gè)發(fā)展階段。

ASCII編碼：ASCII（American Standard Code for Information Interchange，美國信息互換標(biāo)準(zhǔn)代碼）是基于拉丁字母的一套電腦編碼系統(tǒng)。 因?yàn)橛?jì)算機(jī)起源于美國，為表示英文字符，他們制定了ASCII編碼，ASCII編碼使用7位二進(jìn)制來表示字符，高位用來做奇偶校驗(yàn)，0×20以下的字節(jié)狀態(tài)稱為”控制碼”，同時(shí)包括標(biāo)點(diǎn)符號(hào)、數(shù)字等，當(dāng)時(shí)人們覺得已經(jīng)夠用了。

多種編碼并存：但隨著計(jì)算機(jī)的廣泛應(yīng)用，別的國家也開始使用計(jì)算機(jī)，但是很多國家用的不是英文，他們的字母里有許多是ASCII里沒有的，為了可以在計(jì)算機(jī)保存他們的文字，他們決定采用127號(hào)之后的空位來表示這些新的字母、符號(hào)，還加入了很多畫表格時(shí)需要用下到的橫線、豎線、交叉等形狀，一直把序號(hào)編到了最后一個(gè)狀態(tài)255。從128到255這一頁的字符集被稱”擴(kuò)展字符集”。最優(yōu)秀的擴(kuò)展方案是ISO 8859-1，通常稱之為Latin-1，Latin-1包括了足夠的附加字符集來寫基本的西歐語言。

后來其他國家也開始使用計(jì)算機(jī)，為了表達(dá)自己國家的文字，不同的國家和地區(qū)制定了不同的標(biāo)準(zhǔn)，產(chǎn)生了GB2312,BIG5,JIS等各自的編碼標(biāo)準(zhǔn)。通常使用0×80~xFF范圍的2個(gè)字節(jié)來表示1個(gè)字符。比如：漢字 ‘中' 在中文操作系統(tǒng)中，使用 [0xD6,0xD0]這兩個(gè)字節(jié)存儲(chǔ)。 這些使用2個(gè)字節(jié)來代表一個(gè)字符的延伸編碼方式，稱為 ANSI 編碼。

在簡體中文系統(tǒng)下，ANSI 編碼代表 GB2312 編碼，在日文操作系統(tǒng)下，ANSI 編碼代表 JIS 編碼。 不同 ANSI 編碼之間互不兼容，當(dāng)信息在國際間交流時(shí)，無法將屬于兩種語言的文字，存儲(chǔ)在同一段 ANSI 編碼的文本中。

Unicode編碼 由于不同國家的ANSI編碼互不兼容，為了使國際間信息交流更加方便，國際組織制定了UNICODE字符集，為各種語言中的每一個(gè)字符設(shè)定了統(tǒng)一并且唯一的數(shù)字編號(hào)，以滿足跨語言、跨平臺(tái)進(jìn)行文本轉(zhuǎn)換、處理的要求。 UNICODE開始制訂時(shí)，計(jì)算機(jī)的存儲(chǔ)器容量極大地發(fā)展了，空間再也不成為問題了。于是ISO就直接規(guī)定必須用兩個(gè)字節(jié)，也就是16位來統(tǒng)一表示所有的字符，對(duì)于ascii里的那些“半角”字符，UNICODE保持其原編碼不變，只是將其長度由原來的8位擴(kuò)展為16位，而其他文化和語言的字符則全部重新統(tǒng)一編碼。由于”半角”英文符號(hào)只需要用到低8位，所以其高8位永遠(yuǎn)是0，因此這種大氣的方案在保存英文文本時(shí)會(huì)多浪費(fèi)一倍的空間。

但是UNICODE來到時(shí)，一起到來的還有計(jì)算機(jī)網(wǎng)絡(luò)的興起，UNICODE如何在網(wǎng)絡(luò)上傳輸也是一個(gè)必須考慮的問題，于是面向傳輸?shù)谋奤TF（UCS Transfer Format）標(biāo)準(zhǔn)出現(xiàn)了，顧名思義，UTF8就是每次8個(gè)位傳輸數(shù)據(jù)，而UTF16就是每次16個(gè)位，只不過為了傳輸時(shí)的可靠性，從UNICODE到UTF時(shí)并不是直接的對(duì)應(yīng)，而是要過一些算法和規(guī)則來轉(zhuǎn)換。

學(xué)過計(jì)算機(jī)網(wǎng)絡(luò)的童鞋都知道，在網(wǎng)絡(luò)里傳遞信息時(shí)有一個(gè)很重要的問題，就是對(duì)于數(shù)據(jù)高低位的解讀方式，一些計(jì)算機(jī)是采用低位先發(fā)送的方法，例如我們PC機(jī)采用的INTEL架構(gòu)；而另一些是采用高位先發(fā)送的方式。在網(wǎng)絡(luò)中交換數(shù)據(jù)時(shí)，為了核對(duì)雙方對(duì)于高低位的認(rèn)識(shí)是否是一致的，采用了一種很簡便的方法，就是在文本流的開始時(shí)向?qū)Ψ桨l(fā)送一個(gè)標(biāo)志符——如果之后的文本是高位先發(fā)送，那就發(fā)送”FEFF”，反之，則發(fā)送”FFFE”。(IP/TCP協(xié)議規(guī)定網(wǎng)絡(luò)字節(jié)序使用大端法)
因?yàn)閁TF-8編碼兼容之前的ASCII編碼,而且有利于傳輸，其得到了非常廣泛的應(yīng)用。

從UNICODE到UTF8的轉(zhuǎn)換規(guī)則：

漢字ANSI編碼發(fā)展

GB2312：為了表示漢字，我們國家首先發(fā)明了GB2312 編碼，GB2312 編碼規(guī)定一個(gè)小于127的字符的意義與原來相同，但兩個(gè)大于127的字符連在一起時(shí)，就表示一個(gè)漢字，前面的一個(gè)字節(jié)（他稱之為高字節(jié)）從0xA1用到0xF7，后面一個(gè)字節(jié)（低字節(jié)）從0xA1到0xFE，這樣我們就可以組合出大約7000多個(gè)簡體漢字了。在這些編碼里，我們還把數(shù)學(xué)符號(hào)、羅馬希臘的字母、日文的假名們都編進(jìn)去了，連在 ASCII 里本來就有的數(shù)字、標(biāo)點(diǎn)、字母都統(tǒng)統(tǒng)重新編了兩個(gè)字節(jié)長的編碼，這就是常說的”全角”字符，而原來在127號(hào)以下的那些就叫”半角”字符了。

GBK 后來發(fā)現(xiàn)很多偏僻字和少數(shù)名族的語言還是沒辦法編碼進(jìn)來，為了表示這些字符，于是干脆不再要求低字節(jié)一定是127號(hào)之后的內(nèi)碼，只要第一個(gè)字節(jié)是大于127就固定表示這是一個(gè)漢字的開始，不管后面跟的是不是擴(kuò)展字符集里的內(nèi)容。結(jié)果擴(kuò)展之后的編碼方案被稱為 GBK 標(biāo)準(zhǔn)，GBK包括了GB2312的所有內(nèi)容，同時(shí)又增加了近20000個(gè)新的漢字（包括繁體字）和符號(hào)。

GB18030 后來少數(shù)民族也要用電腦了，于是我們?cè)贁U(kuò)展，又加了幾千個(gè)新的少數(shù)民族的字，GBK擴(kuò)成了GB18030。從此之后，中華民族的文化就可以在計(jì)算機(jī)時(shí)代中傳承了。

BOM介紹

1.BOM的來歷： 為了識(shí)別 Unicode 文件，Microsoft 建議所有的 Unicode 文件應(yīng)該以 ZERO WIDTH NOBREAK SPACE（U+FEFF）字符開頭。這作為一個(gè)“特征符”或“字節(jié)順序標(biāo)記（byte-order mark，BOM）”來識(shí)別文件中使用的編碼和字節(jié)順序。

2.不同的系統(tǒng)對(duì)BOM的支持：因?yàn)橐恍┫到y(tǒng)或程序不支持BOM，因此帶有BOM的Unicode文件有時(shí)會(huì)帶來一些問題。

①JDK1.5以及之前的Reader都不能處理帶有BOM的UTF-8編碼的文件，解析這種格式的xml文件時(shí)，會(huì)拋出異常：Content is not allowed in prolog。
②Linux/UNIX 并沒有使用 BOM，因?yàn)樗鼤?huì)破壞現(xiàn)有的 ASCII 文件的語法約定。
③不同的編輯工具對(duì)BOM的處理也各不相同。使用Windows自帶的記事本將文件保存為UTF-8編碼的時(shí)候，記事本會(huì)自動(dòng)在文件開頭插入BOM（雖然BOM對(duì)UTF-8來說并不是必須的）。而其它很多編輯器用不用BOM是可以選擇的。UTF-8、UTF-16都是如此。

3.BOM與XML：XML解析讀取XML文檔時(shí)，W3C定義了3條規(guī)則：

①如果文檔中有BOM，就定義了文件編碼；
②如果文檔中沒有BOM，就查看XML聲明中的編碼屬性；
③如果上述兩者都沒有，就假定XML文檔采用UTF-8編碼。

決定文本的字符集與編碼

軟件通常有三種途徑來決定文本的字符集和編碼:

1.檢測BOM

對(duì)于Unicode文本最標(biāo)準(zhǔn)的途徑是檢測文本最開頭的幾個(gè)字節(jié)。   

2.用戶選擇： 采取一種比較安全的方式來決定字符集及其編碼，那就是彈出一個(gè)對(duì)話框來請(qǐng)示用戶。

3.采取“猜”的方法： 如果軟件不想麻煩用戶，或者它不方便向用戶請(qǐng)示，那它只能采取自己“猜”的方法，軟件可以根據(jù)整個(gè)文本的特征來猜測它可能屬于哪個(gè)charset，這就很可能不準(zhǔn)了。使用記事本打開那個(gè)“聯(lián)通”文件就屬于這種情況。（把原本屬于ANSI編碼的文件當(dāng)成UTF-8處理。

記事本的幾種編碼介紹

1.ANSI編碼：記事本默認(rèn)保存的編碼格式是：ANSI，即本地操作系統(tǒng)默認(rèn)的內(nèi)碼，簡體中文一般為GB2312。這個(gè)怎么驗(yàn)證呢？用記事本保存后，使用EmEditor、EditPlus和UltraEdit之類的文本編輯器打開。推薦使用EmEditor，打開后，在又下角會(huì)顯示編碼：GB2312。

2.Unicode編碼：用記事本另存為時(shí)，編碼選擇“Unicode”，用EmEditor打開該文件，發(fā)現(xiàn)編碼格式是：UTF-16LE+BOM（有簽名）。用十六進(jìn)制方式查看，發(fā)現(xiàn)開頭兩字節(jié)為：FF FE。這就是BOM。

3.Unicode big endian 用記事本另存為時(shí)，編碼選擇“Unicode”，用EmEditor打開該文件，發(fā)現(xiàn)編碼格式是：UTF-16BE+BOM（有簽名）。用十六進(jìn)制方式查看，發(fā)現(xiàn)開頭兩字節(jié)為：FE FF。這就是BOM。

4.UTF-8 ：用記事本另存為時(shí)，編碼選擇“UTF-8”，用EmEditor打開該文件，發(fā)現(xiàn)編碼格式是：UTF-8（有簽名）。用十六進(jìn)制方式查看，發(fā)現(xiàn)開頭三個(gè)字節(jié)為：EF BB BF。這就是BOM。

最新評(píng)論