• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            Onway

            我是一只菜菜菜菜鳥...
            posts - 61, comments - 56, trackbacks - 0, articles - 34

            個人整理:字符編碼

            Posted on 2011-12-04 14:39 Onway 閱讀(1612) 評論(1)  編輯 收藏 引用 所屬分類: 使用說明
            第一 概念:
            1,字符(Character)是各種文字和符號的總稱,包括各國家文字、標(biāo)點符號、圖形符號、數(shù)字等。
            2,字符集(Character set)是多個字符的集合。
            3,字符編碼是一套將字符集中的字符轉(zhuǎn)換為計算機中可以接受的數(shù)值的編碼系統(tǒng)。
            第二 ASCII字符集&字符編碼
            起源與50年代后期,在1967年定案,被國際化標(biāo)準(zhǔn)組織(ISO)定為國際標(biāo)準(zhǔn),稱為ISO 646標(biāo)準(zhǔn)。
            EASCII各種字符集&字符編碼
            EASCII(Extended ASCII,延伸美國標(biāo)準(zhǔn)信息交換碼)是將ASCII碼由7位擴充為8位而成。EASCII的內(nèi)碼是由0到255共有256個字符組成。EASCII碼比ASCII碼擴充出來的符號包括表格符號、計算符號、希臘字母和特殊的拉丁符號。
            ISO 8859,全稱ISO/IEC 8859,是國際標(biāo)準(zhǔn)化組織(ISO)及國際電工委員會(IEC)聯(lián)合制定的一系列8位字符集的標(biāo)準(zhǔn),現(xiàn)時定義了15個字符集。
            ISO/IEC 8859-1 (Latin-1) - 西歐語言
            ISO/IEC 8859-2 (Latin-2) - 中歐語言
            ISO/IEC 8859-3 (Latin-3) - 南歐語言。世界語也可用此字符集顯示。
            ISO/IEC 8859-4 (Latin-4) - 北歐語言
            ISO/IEC 8859-5 (Cyrillic) - 斯拉夫語言
            ISO/IEC 8859-6 (Arabic) - 阿拉伯語
            ISO/IEC 8859-7 (Greek) - 希臘語
            ISO/IEC 8859-8 (Hebrew) - 希伯來語(視覺順序)
            ISO 8859-8-I - 希伯來語(邏輯順序)
            ISO/IEC 8859-9(Latin-5 或 Turkish)- 它把Latin-1的冰島語字母換走,加入土耳其語字母。
            ISO/IEC 8859-10(Latin-6 或 Nordic)- 北日耳曼語支,用來代替Latin-4。
            ISO/IEC 8859-11 (Thai) - 泰語,從泰國的 TIS620 標(biāo)準(zhǔn)字集演化而來。
            ISO/IEC 8859-13(Latin-7 或 Baltic Rim)- 波羅的語族
            ISO/IEC 8859-14(Latin-8 或 Celtic)- 凱爾特語族
            ISO/IEC 8859-15 (Latin-9) - 西歐語言,加入Latin-1欠缺的芬蘭語字母和大寫法語重音字母,以及歐元(€)符號。
            ISO/IEC 8859-16 (Latin-10) - 東南歐語言。主要供羅馬尼亞語使用,并加入歐元符號。
            由于英語沒有任何重音字母(不計外來詞),故可使用以上十五個字集中的任何一個來表示。
            此系列中沒有-12號的原因是,此計劃原本要設(shè)計成一個包含塞爾特語族字符集的“Latin-7”,但后來塞爾特語族變成了ISO 8859-14 / Latin-8。亦有一說謂-12號本來是預(yù)留給印度天城體梵文的,但后來卻擱置了。
            第三 GBXXXX字符集&編碼
            計算機發(fā)明之處及后面很長一段時間,只用應(yīng)用于美國及西方一些發(fā)達國家,ASCII能夠很好滿足用戶的需求。但是當(dāng)天朝也有了計算機之后,為了顯示中文,必須設(shè)計一套編碼規(guī)則用于將漢字轉(zhuǎn)換為計算機可以接受的數(shù)字系統(tǒng)的數(shù)。
            天朝專家把那些127號之后的奇異符號們(即EASCII)取消掉,規(guī)定:一個小于127的字符的意義與原來相同,但兩個大于127的字符連在一起時,就表示一個漢字,前面的一個字節(jié)(稱之為高字節(jié))從0xA1用到 0xF7,后面一個字節(jié)(低字節(jié))從0xA1到0xFE,這樣就可以組合出大約7000多個簡體漢字了。在這些編碼里,還把數(shù)學(xué)符號、羅馬希臘的 字母、日文的假名們都編進去了,連在ASCII里本來就有的數(shù)字、標(biāo)點、字母都統(tǒng)統(tǒng)重新編了兩個字節(jié)長的編碼,這就是常說的"全角"字符,而原來在127號以下的那些就叫"半角"字符了。
            上述編碼規(guī)則就是GB2312。GB2312或GB2312-80是中國國家標(biāo)準(zhǔn)簡體中文字符集,全稱《信息交換用漢字編碼字符集·基本集》,又稱GB0,由中國國家標(biāo)準(zhǔn)總局發(fā)布,1981年5月1日實施。GB2312編碼通行于中國大陸;新加坡等地也采用此編碼。中國大陸幾乎所有的中文系統(tǒng)和國際化的軟件都支持GB2312。GB2312的出現(xiàn),基本滿足了漢字的計算機處理需要,它所收錄的漢字已經(jīng)覆蓋中國大陸99.75%的使用頻率。對于人名、古漢語等方面出現(xiàn)的罕用字,GB2312不能處理,這導(dǎo)致了后來GBK及GB 18030漢字字符集的出現(xiàn)。
            GBK:由于GB 2312-80只收錄6763個漢字,有不少漢字,如部分在GB 2312-80推出以后才簡化的漢字(如"啰"),部分人名用字(如中國前總理朱镕基的"镕"字),臺灣及香港使用的繁體字,日語及朝鮮語漢字等,并未有收錄在內(nèi)。于是廠商微軟利用GB 2312-80未使用的編碼空間,收錄GB 13000.1-93全部字符制定了GBK編碼。根據(jù)微軟資料,GBK是對GB2312-80的擴展,也就是CP936字碼表 (Code Page 936)的擴展(之前CP936和GB 2312-80一模一樣),最早實現(xiàn)于Windows 95簡體中文版。雖然GBK收錄GB 13000.1-93的全部字符,但編碼方式并不相同。GBK自身并非國家標(biāo)準(zhǔn),只是曾由國家技術(shù)監(jiān)督局標(biāo)準(zhǔn)化司、電子工業(yè)部科技與質(zhì)量監(jiān)督司公布為"技術(shù)規(guī)范指導(dǎo)性文件"。原始GB13000一直未被業(yè)界采用,后續(xù)國家標(biāo)準(zhǔn)GB18030技術(shù)上兼容GBK而非GB13000。
            GB 18030,全稱:國家標(biāo)準(zhǔn)GB 18030-2005《信息技術(shù) 中文編碼字符集》,是中華人民共和國現(xiàn)時最新的內(nèi)碼字集,是GB 18030-2000《信息技術(shù) 信息交換用漢字編碼字符集 基本集的擴充》的修訂版。與GB 2312-1980完全兼容,與GBK基本兼容,支持GB 13000及Unicode的全部統(tǒng)一漢字,共收錄漢字70244個。GB 18030主要有以下特點:
            與UTF-8相同,采用多字節(jié)編碼,每個字可以由1個、2個或4個字節(jié)組成。
            編碼空間龐大,最多可定義161萬個字符。
            支持中國國內(nèi)少數(shù)民族的文字,不需要動用造字區(qū)。
            漢字收錄范圍包含繁體漢字以及日韓漢字
            本規(guī)格的初版是中華人民共和國信息產(chǎn)業(yè)部電子工業(yè)標(biāo)準(zhǔn)化研究所起草,由國家質(zhì)量技術(shù)監(jiān)督局于2000年3月17日發(fā)布。現(xiàn)行版本為國家質(zhì)量監(jiān)督檢驗總局和中國國家標(biāo)準(zhǔn)化管理委員會于2005年11月8日發(fā)布,2006年5月1日實施。此規(guī)格為在中國境內(nèi)所有軟件產(chǎn)品支持的強制規(guī)格。
            第四 BIG5字符集&編碼
            Big5,又稱為大五碼或五大碼,是使用繁體中文(正體中文)社區(qū)中最常用的電腦漢字字符集標(biāo)準(zhǔn),共收錄13,060個漢字。中文碼分為內(nèi)碼及交換碼兩類,Big5屬中文內(nèi)碼,知名的中文交換碼有CCCII、CNS11643。Big5雖普及于臺灣、香港與澳門等繁體中文通行區(qū),但長期以來并非當(dāng)?shù)氐膰覙?biāo)準(zhǔn),而只是業(yè)界標(biāo)準(zhǔn)。倚天中文系統(tǒng)、Windows等主要系統(tǒng)的字符集都是以Big5為基準(zhǔn),但廠商又各自增加不同的造字與造字區(qū),派生成多種不同版本。2003年,Big5被收錄到CNS11643中文標(biāo)準(zhǔn)交換碼的附錄當(dāng)中,取得了較正式的地位。這個最新版本被稱為Big5-2003。
            Big5碼是一套雙字節(jié)字符集,使用了雙八碼存儲方法,以兩個字節(jié)來安放一個字。第一個字節(jié)稱為"高位字節(jié)",第二個字節(jié)稱為"低位字節(jié)"。"高位字節(jié)"使用了0x81-0xFE,"低位字節(jié)"使用了0x40-0x7E,及0xA1-0xFE。
            第五 UCS&UNICODE字符集
            歷史上存在兩個獨立的嘗試創(chuàng)立單一字符集的組織,即國際標(biāo)準(zhǔn)化組織(ISO)和多語言軟件制造商組成的統(tǒng)一碼聯(lián)盟。前者開發(fā)的 ISO/IEC 10646 項目,后者開發(fā)的統(tǒng)一碼(unicode)項目。因此最初制定了不同的標(biāo)準(zhǔn)。
            UCS:
            通用字符集(Universal Character Set,UCS)是由ISO制定的ISO 10646(或稱ISO/IEC 10646)標(biāo)準(zhǔn)所定義的32位(高位恒為0)的標(biāo)準(zhǔn)字符集。
            通用字符集是包括了所有其他字符的字符集。它保證了與其他字符集的雙向兼容,即,如果你將任何文本字符串翻譯到UCS格式,然后再翻譯回原編碼,你不會丟失任何信息。
            UCS包含了已知語言的所有字符。除了拉丁語、希臘語、斯拉夫語、希伯來語、阿拉伯語、亞美尼亞語、格魯吉亞語,還包括中文、日文、韓文這樣的象形文字,UCS還包括大量的圖形、印刷、數(shù)學(xué)、科學(xué)符號。
            ISO/IEC 10646-1標(biāo)準(zhǔn)第一次發(fā)表于1993年,現(xiàn)在的公開版本是ISO/IEC 10646-1:2000。ISO/IEC 10646-2在2001年發(fā)表。
            UNICODE:
            Unicode(統(tǒng)一碼、萬國碼、單一碼、標(biāo)準(zhǔn)萬國碼)是業(yè)界的一種標(biāo)準(zhǔn),它可以使電腦得以體現(xiàn)世界上數(shù)十種文字的系統(tǒng)。Unicode 是基于通用字符集(Universal Character Set)的標(biāo)準(zhǔn)來發(fā)展,并且同時也以書本的形式對外發(fā)表。
            1991年前后,兩個項目的參與者都認識到,世界不需要兩個不兼容的字符集。于是,它們開始合并雙方的工作成果,并為創(chuàng)立一個單一編碼表而協(xié)同工作。從Unicode 2.0開始,Unicode采用了與ISO 10646-1相同的字庫和字碼;ISO也承諾,ISO 10646將不會替超出U+10FFFF的UCS-4編碼賦值,以使得兩者保持一致。
            統(tǒng)一碼聯(lián)盟公布的Unicode標(biāo)準(zhǔn)包含了ISO/IEC 10646-1實現(xiàn)級別3的基本多文種平面。在兩個標(biāo)準(zhǔn)里,所有的字符都在相同的位置并且有相同的名字。
            第六 UTF-x編碼
            UTF為UCS / Unicode Transformation Format“Unicode轉(zhuǎn)換格式”的縮寫。
            (可以這樣理解:Unicode是字符集,UTF-32/ UTF-16/ UTF-8是三種字符編碼方案。)
            UTF-8:
            UTF-8(8-bit Unicode Transformation Format)是一種針對Unicode的可變長度字符編碼(定長碼),也是一種前綴碼。
            UTF-16:
            UTF-16是Unicode的其中一個使用方式。
            在基本多語言平面內(nèi)定義的符號((Basic Multilingual Plane, BMP),或稱第零平面(Plane 0)),使用2個字節(jié)表示,在此之外的字符(其他平面內(nèi)的字符),則使用4個字節(jié)表示。
            UTF-16與UCS-2的關(guān)系:
            UTF-16可看成是UCS-2的父集。在沒有輔助平面字符Mapping of Unicode character planes(surrogate code points)前,UTF-16與UCS-2所指的是同一的意思。但當(dāng)引入輔助平面字符后,就稱為UTF-16了。現(xiàn)在若有軟件聲稱自己支援UCS-2編碼,那其實是暗指它不能支援在UTF-16中超過2bytes的字集。對于小于0x10000的UCS碼,UTF-16編碼就等于UCS碼。
            UTF-32:
            UTF-32 (或 UCS-4)是一種將Unicode字符編碼的協(xié)定,對每一個Unicode碼位使用恰好32位元。
            UTF-32與UCS-4的關(guān)系:
            原本ISO 10646標(biāo)準(zhǔn)定義了一個32位元的編碼形式,稱作UCS-4,使用通用字符集(UCS)的每一個字符,會在0到十六進制的7FFFFFFF這樣的字碼空間中,被表示成一個的32位元的碼值。
            UCS-4足以用來表示所有的Unicode的字碼空間,其最大的碼位為十六進制的10FFFF,所以其空間約有百萬個碼位。有些人認為保留如此大的字碼空間卻只為了對應(yīng)這很小的碼集是浪費的所以一個新的編碼UTF-32被提出來了。UTF-32 是一個 UCS-4 的子集,使用32-位元的碼值,只在0到10FFFF的字碼空間。
            UTF-32 原本是 UCS-4 的子集,但JTC1/SC2/WG2聲明,所有未來對字符的指定都將會限制在BMP及其14個補充平面,并移除先前在 E0 到 FF 平面的 60 到 7F 群的私用空間。
            于是就現(xiàn)狀而言,除了 UTF-32 標(biāo)準(zhǔn)包含額外的 Unicode 意涵,UCS-4 和 UTF-32 大體是相同的。
            第七 補充:
            Unicode的編碼方式與ISO 10646的通用字符集(Universal Character Set,UCS)概念相對應(yīng),目前實際應(yīng)用的Unicode版本對應(yīng)于UCS-2,使用16位的編碼空間。也就是每個字符占用2個字節(jié)。這樣理論上一共最多可以表示216即65536個字符。基本滿足各種語言的使用。實際上當(dāng)前版本的Unicode尚未填充滿這16位編碼,保留了大量空間作為特殊使用或?qū)頂U展。
            上述16位Unicode字符構(gòu)成基本多文種平面(Basic Multilingual Plane,簡稱BMP)。最新(但未實際廣泛使用)的Unicode版本定義了16個輔助平面,兩者合起來至少需要占據(jù)21位的編碼空間,比3字節(jié)略少。但事實上輔助平面字符仍然占用4字節(jié)編碼空間,與UCS-4保持一致。未來版本會擴充到ISO 10646-1實現(xiàn)級別3(參考中文維基百科,通用字符集),即涵蓋UCS-4的所有字符。UCS-4是一個更大的尚未填充完全的31位字符集,加上恒為0的首位,共需占據(jù)32位,即4字節(jié)。理論上最多能表示231個字符,完全可以涵蓋一切語言所用的符號。
            BMP字符的Unicode編碼表示為U+hhhh,其中每個h 代表一個十六進制數(shù)位。與UCS-2編碼完全相同。
            基本多文種平面及輔助平面參考維基百科。
            內(nèi)碼和code page
            目前Windows的內(nèi)核已經(jīng)支持Unicode字符集,這樣在內(nèi)核上可以支持全世界所有的語言文字(不是說目前使用的是16位編碼嗎?)。但是由于現(xiàn)有的大量程序和文檔都采用了某種特定語言的編碼,例如GBK,Windows不可能不支持現(xiàn)有的編碼,而全部改用Unicode。Windows使用代碼頁(code page)來適應(yīng)各個國家和地區(qū)。
            內(nèi)碼是指操作系統(tǒng)內(nèi)部的字符編碼。早期操作系統(tǒng)的內(nèi)碼是與語言相關(guān)的。現(xiàn)在的Windows在系統(tǒng)內(nèi)部支持Unicode,然后用代碼頁適應(yīng)各種語言,“內(nèi)碼”的概念就比較模糊了。微軟一般將缺省代碼頁指定的編碼說成是內(nèi)碼。
            Windows中有缺省代碼頁的概念,即缺省用什么編碼來解釋字符。
            Windows的內(nèi)碼是Unicode,它在技術(shù)上可以同時支持多個代碼頁。只要文件能說明自己使用什么編碼,用戶又安裝了對應(yīng)的代碼頁,Windows就能正確顯示,例如在HTML文件中就可以指定charset。
            問題:如果目前使用的unicode版本是16位編碼的,即對應(yīng)UCS-2,那么就是說沒有使用輔助平面,那樣的話使用UTF-16編碼有什么意思呢?直接使用UCS-2不就得了嗎?
            第八 關(guān)于linux和windows的CR, LF, CR/LF 回車 換行問題
            在文本處理中, CR, LF, CR/LF是不同操作系統(tǒng)上使用的換行符. 
            Dos和windows: 采用回車+換行CR/LF表示下一行. 
            UNIX/Linux  : 采用換行符LF表示下一行. 
            MAC OS      : 采用回車符CR表示下一行. 
            CR用符號'\r'表示, 十進制ASCII代碼是13, 十六進制代碼為0x0D; 
            LF用符號'\n'表示, 十進制ASCII代碼是10, 十六制為0x0A. 
            所以Windows平臺上換行在文本文件中是使用 0d 0a 兩個字節(jié)表示, 而UNIX和蘋果平臺上換行則是使用0a或0d一個字節(jié)表示. 
            一般操作系統(tǒng)上的運行庫會自動決定文本文件的換行格式. 如一個程序在windows上運行就生成CR/LF換行格式的文本文件,而在Linux上運行就生成LF格式換行的文本文件。 
            在一個平臺上使用另一種換行符的文件文件可能會帶來意想不到的問題, 特別是在編輯程序代碼時,有時候代碼在編輯器中顯示正常, 但在編輯時卻會因為換行符問題而出錯。 
            很多文本/代碼編輯器帶有換行符轉(zhuǎn)換功能, 使用這個功能可以將文本文件中的換行符在不同格式單互換。在不同平臺間使用FTP軟件傳送文件時, 在ascii文本模式傳輸模式下, 一些FTP客戶端程序會自動對換行格式進行轉(zhuǎn)換。經(jīng)過這種傳輸?shù)奈募止?jié)數(shù)可能會發(fā)生變化。如果你不想ftp修改原文件, 可以使用bin模式(二進制模式)傳輸文本。
            第九 linux區(qū)域設(shè)置locale:
            Locale是根據(jù)計算機用戶所使用的語言,所在國家或者地區(qū),以及當(dāng)?shù)氐奈幕瘋鹘y(tǒng)所定義的一個軟件運行時的語言環(huán)境。  
            這個用戶環(huán)境可以按照所涉及到的文化傳統(tǒng)的各個方面分成幾個大類,通常包括用戶所使用的語言符號及其分類(LC_CTYPE),數(shù)字 (LC_NUMERIC),比較和排序習(xí)慣(LC_COLLATE),時間顯示格式(LC_TIME),貨幣單位(LC_MONETARY),信息主要是提示信息,錯誤信息, 狀態(tài)信息, 標(biāo)題, 標(biāo)簽, 按鈕和菜單等(LC_MESSAGES),姓名書寫方式(LC_NAME),地址書寫方式(LC_ADDRESS),電話號碼書寫方式 (LC_TELEPHONE),度量衡表達方式(LC_MEASUREMENT),默認紙張尺寸大小(LC_PAPER)和locale對自身包含信息的概述(LC_IDENTIFICATION)。
            設(shè)定locale就是設(shè)定12大類的locale分類屬性,即 12個LC_*。除了這12個變量可以設(shè)定以外,為了簡便起見,還有兩個變量:LC_ALL和LANG。它們之間有一個優(yōu)先級的關(guān)系: LC_ALL>LC_*>LANG 可以這么說,LC_ALL是最上級設(shè)定或者強制設(shè)定,而LANG是默認設(shè)定值。 1、如果你設(shè)定了LC_ALL=zh_CN.UTF-8,那么不管LC_*和LANG設(shè)定成什么值,它們都會被強制服從LC_ALL的設(shè)定,成為 zh_CN.UTF-8。 2、假如你設(shè)定了LANG=zh_CN.UTF-8,而其他的LC_*=en_US.UTF-8,并且沒有設(shè)定LC_ALL的話,那么系統(tǒng)的locale設(shè)定以LC_*=en_US.UTF-8。 3、假如你設(shè)定了LANG=zh_CN.UTF-8,而其他的LC_*,和LC_ALL均未設(shè)定的話,系統(tǒng)會將LC_*設(shè)定成默認值,也就是LANG的值 zh_CN.UTF-8 。 4、假如你設(shè)定了LANG=zh_CN.UTF-8,而其他的LC_CTYPE=en_US.UTF-8,其他的LC_*,和LC_ALL均未設(shè)定的話,那么系統(tǒng)的locale設(shè)定將是:LC_CTYPE=en_US.UTF-8,其余的 LC_COLLATE,LC_MESSAGES等等均會采用默認值,也就是LANG的值,也就是LC_COLLATE=LC_MESSAGES=……= LC_PAPER=LANG=zh_CN.UTF-8。
            所以,locale是這樣設(shè)定的: 1、如果你需要一個純中文的系統(tǒng)的話,設(shè)定LC_ALL= zh_CN.XXXX,或者LANG= zh_CN.XXXX都可以,當(dāng)然你可以兩個都設(shè)定,但正如上面所講,LC_ALL的值將覆蓋所有其他的locale設(shè)定,不要作無用功。 2、如果你只想要一個可以輸入中文的環(huán)境,而保持菜單、標(biāo)題,系統(tǒng)信息等等為英文界面,那么只需要設(shè)定LC_CTYPE=zh_CN.XXXX,LANG= en_US.XXXX就可以了。這樣LC_CTYPE=zh_CN.XXXX,而LC_COLLATE=LC_MESSAGES=……= LC_PAPER=LANG=en_US.XXXX。 3、假如你高興的話,可以把12個LC_*一一設(shè)定成你需要的值,打造一個古靈精怪的系統(tǒng): LC_CTYPE=zh_CN.GBK/GBK(使用中文編碼內(nèi)碼GBK字符集); LC_NUMERIC=en_GB.ISO-8859-1(使用大不列顛的數(shù)字系統(tǒng)) LC_MEASUREMEN= de_DE@euro.ISO -8859-15(德國的度量衡使用ISO-8859-15字符集) 羅馬的地址書寫方式,美國的紙張設(shè)定……。估計沒人這么干吧。 4、假如你什么也不做的話,也就是LC_ALL,LANG和LC_*均不指定特定值的話,系統(tǒng)將采用POSIX作為lcoale,也就是C locale。
            相關(guān)目錄文件及命令:
            /usr/share/i18n/
            /usr/lib/locale/
            /etc/default/locale
            locale
            locale-gen
            localedef
            第十 Ubuntu解決gedit打開windows記事本.txt文件亂碼的方法
            在ubuntu下打開.TXT文件,中文顯示為亂碼,在這找到了解決的辦法:
            終端輸入gconf-editor調(diào)出gconf-edit
            PS:輸入gconf-editor即可,前面不需要加Sudo
            依次點開
            apps->gedit-2->preferences->encodings 中的auto-detected
            在雙擊彈出對話框中加入GB18030,GBK,GB2312就可以了
            這里最好把GBK,GB2312,GB18030調(diào)到其他字符編碼的前面去
            第十一 vim編碼設(shè)置
            Vim有四個跟字符編碼方式有關(guān)的選項,encoding、fileencoding、fileencodings、termencoding(這些選項設(shè)置請參考Vim文檔中encoding-names章節(jié)),它們的意義如下:
            encoding
            encoding是Vim內(nèi)部使用的字符編碼方式,包括Vim的buffer(緩沖區(qū))、菜單文本、消息文本等。默認是根據(jù)你的locale選擇。VIM用戶手冊上建議只在.vimrc中改變它的值,事實上似乎也只有在.vimrc中改變它的值才有意義。你可以用另外一種編碼來編輯和保存文件,如你的vim的encoding為utf-8,所編輯的文件采用cp936編碼,vim會自動將讀入的文件轉(zhuǎn)成utf-8(vim的能讀懂的方式),而當(dāng)你寫入文件時,又會自動轉(zhuǎn)回成cp936(文件的保存編碼)。
            fileencoding
            Vim中當(dāng)前編輯的文件的字符編碼方式,Vim保存文件時也會將文件保存為這種字符編碼方式(不管是否新文件都如此)。
            fileencodings
            Vim自動探測fileencoding的順序列表,啟動時會按照它所列出的字符編碼方式逐一探測即將打開的文件的字符編碼方式,并且將 fileencoding 設(shè)置為最終探測到的字符編碼方式。因此最好將Unicode 編碼方式放到這個列表的最前面,將拉丁語系編碼方式 latin1放到最后面。
            termencoding
            Vim所工作的終端(或者 Windows的Console窗口)的字符編碼方式。如果vim所在的term與vim編碼相同,則無需設(shè)置。如其不然,你可以用vim的termencoding選項將自動轉(zhuǎn)換成term的編碼.這個選項對GUI模式Vim(GVim)無效,而對Console模式的Vim而言就是Windows控制臺的代碼頁,并且通常我們不需要改變它。
            現(xiàn)在來看看Vim的多字符編碼方式支持是如何工作的:
            啟動Vim,根據(jù).vimrc文件中設(shè)置的encoding的值來設(shè)置buffer、菜單文本、消息文的字符編碼方式。
            讀取需要編輯的文件,根據(jù)fileencodings中列出的字符編碼方式逐一探測該文件編碼方式。并設(shè)置fileencoding為探測到的,看起來是正確的字符編碼方式。
            對比fileencoding和encoding的值,若不同則調(diào)用iconv將文件內(nèi)容轉(zhuǎn)換為encoding所描述的字符編碼方式,并且把轉(zhuǎn)換后的內(nèi)容放到為此文件開辟的 buffer 里,此時我們就可以開始編輯這個文件了。注意,完成這一步動作需要調(diào)用外部的 iconv.dll,你需要保證這個文件存在于$VIMRUNTIME或者其他列在PATH環(huán)境變量中的目錄里。
            編輯完成后保存文件時,再次對比fileencoding和encoding的值。若不同,再次調(diào)用iconv將即將保存的buffer中的文本轉(zhuǎn)換為fileencoding所描述的字符編碼方式,并保存到指定的文件中。同樣,這需要調(diào)用iconv.dll由于Unicode能夠包含幾乎所有的語言的字符,而且Unicode的UTF-8編碼方式又是非常具有性價比的編碼方式 (空間消耗比 UCS-2 小),因此建議encoding的值設(shè)置為utf-8。這么做的另一個理由是encoding設(shè)置為 utf-8 時,Vim 自動探測文件的編碼方式會更準(zhǔn)確 (或許這個理由才是主要的 ;)。我們在中文Windows里編輯的文件,為了兼顧與其他軟件的兼容性,文件編碼還是設(shè)置為GB2312/GBK比較合適,因此fileencoding建議設(shè)置為chinese(chinese是個別名,在Unix里表示gb2312,在Windows里表示cp936,也就是GBK的代碼頁)。
            當(dāng)vim在utf-8的local下打開gbk文件時,顯示的是亂碼,可以在~/.vimrc文件中加入如下代碼來解決:
            set fencs=utf-8,gbk
            這一行的作用是告訴vim,打開一個文件時,嘗試utf8,gbk兩種編碼,vim只需要掃描文件的前一段,就可以根據(jù)文件里面的數(shù)據(jù)判斷出文件是否用的是utf8或者gbk編碼。如果不指定這一行,則vim只會用當(dāng)前編碼 (locale)來打開文件,因為locale是UTF-8,而文件是gbk,所以打開是亂碼。
            一般vim打開中文文件時出現(xiàn)亂碼時可以用下面的方法來解決:
            set fileencoding=gb18030 set fileencodings=utf-8,gb18030,utf-16,big5
            這樣設(shè)置的原因說明如下:vim里面的編碼主要跟三個參數(shù)有關(guān):enc(encoding), fenc(fileencoding)和fencs(fileencodings)。其中fenc是當(dāng)前文件的編碼,也就是說,一個在vim里面已經(jīng)正確顯示了的文件(前提是你的系統(tǒng)環(huán)境跟你的enc設(shè)置匹配),你可以通過改變 fenc后再w來將此文件存成不同的編碼。比如說,我:set fenc=utf-8然后:w就把文件存成utf-8的了,:set fenc=gb18030再:w就把文件存成gb18030的了。這個值對于打開文件的時候是否能夠正確地解碼沒有任何關(guān)系。fencs就是用來在打開文件的時候進行解碼的猜測列表。文件編碼沒有百分百正確的判斷方法,所以vim只能猜測文件編碼。比如我的vimrc里面這個的設(shè)置是:
            set fileencodings=utf-8,gb18030,utf-16,big5
            所以我的vim每打開一個文件,先嘗試用utf-8進行解碼,如果用utf-8解碼到了一半出錯(所謂出錯的意思是某個地方無法用utf-8正確地 解碼),那么就從頭來用gb18030重新嘗試解碼,如果gb18030又出錯(注意gb18030并不是像utf-8似的規(guī)則編碼,所以所謂的出錯只是 說某個編碼沒有對應(yīng)的有意義的字,比如0),就嘗試用utf-16,仍然出錯就嘗試用big5。這一趟下來,如果中間的某次解碼從頭到尾都沒有出錯,那么 vim就認為這個文件是這個編碼的,不會再進行后面的嘗試了。這個時候,fenc的值就會被設(shè)為vim最后采用的編碼值,可以用:set fenc?來查看具體是什么。
            當(dāng)然這個也是有可能出錯的,比如你的文件是gb18030編碼的,但是實際上只有一兩個字符是中文,那么有可能他們正好也能被utf-8解碼,那么這個文件就會被誤認為是utf-8的導(dǎo)致錯誤解碼。
            至于enc,其作用基本只是顯示。不管最后的文件是什么編碼的,vim都會將其轉(zhuǎn)換為當(dāng)前系統(tǒng)編碼來進行處理,這樣才能在當(dāng)前系統(tǒng)里面正確地顯示出 來,因此enc就是干這個的。在windows下面,enc默認是cp936,這也就是中文windows的默認編碼,所以enc是不需要改的。在 linux下,隨著你的系統(tǒng)locale可能設(shè)為zh_CN.gb18030或者zh_CN.utf-8,你的enc要對應(yīng)的設(shè)為gb18030或者 utf-8(或者gbk之類的)。
            最后再來說一下新建空文件的默認編碼。看文檔好像說會采用fencs里面的第一個編碼作為新建文件的默認編碼。但是這里有一個問題,就是fencs 的順序跟解碼成功率有很大關(guān)系,根據(jù)我的經(jīng)驗utf-8在前比gb18030在前成功率要高一些,那么如果我新建文件默認想讓它是gb18030編碼怎么辦?一個方法是每次新建文件后都:set fenc=gb18030一下,不過我發(fā)現(xiàn)在vimrc里面設(shè)置fenc=gb18030也能達到這個效果。
            第十二 內(nèi)容轉(zhuǎn)載引用自:
            字符集: http://baike.baidu.com/view/51987.htm
            字符編碼:http://www.cnblogs.com/skynet/archive/2011/05/03/2035105.html
            ASCII: http://baike.baidu.com/view/15482.htm
            EASCII:http://zh.wikipedia.org/wiki/EASCII
            http://zh.wikipedia.org/wiki/ISO/IEC_8859
            GBxxxx系列,BIG5:
            http://www.cnblogs.com/skynet/archive/2011/05/03/2035105.html
            UCS&UNICODE:http://zh.wikipedia.org/wiki/通用字符集
            http://zh.wikipedia.org/wiki/Unicode
            UTF-x系列:http://zh.wikipedia.org/wiki/UTF-8
            http://zh.wikipedia.org/wiki/UCS-2
            http://zh.wikipedia.org/wiki/UCS-4
            內(nèi)碼與code page:http://blog.csdn.net/rokia/archive/2006/05/21/747302.aspx
            換行問題:http://www.cnblogs.com/lihong/archive/2011/02/19/1958349.html
            代碼頁,內(nèi)碼:http://hi.baidu.com/bhoold/blog/item/5736058bb13b11d8fd1f1099.html
            http://hi.baidu.com/bluewindbell/blog/item/bc17a5311cc013ad5edf0eb3.html
            locale設(shè)定:http://zy19810808.blog.163.com/blog/static/1188006200941703922620/
            gedit設(shè)置:http://headzxx.blog.163.com/blog/static/702015852009108101644849/
            vim編碼設(shè)置:http://www.cnblogs.com/hopeworld/archive/2011/04/20/2022331.html

            Feedback

            # re: 個人整理:字符編碼  回復(fù)  更多評論   

            2011-12-04 14:42 by Onway
            怎么那些空行不見了啊?
            久久国产高清字幕中文| 亚洲国产精品狼友中文久久久| 久久人妻AV中文字幕| 奇米影视7777久久精品| 国产Av激情久久无码天堂| AA级片免费看视频久久| 一本色道久久综合狠狠躁| 久久综合九色综合精品| 久久午夜福利无码1000合集| 国内精品伊人久久久久av一坑 | 日日噜噜夜夜狠狠久久丁香五月| 久久精品国产亚洲综合色| 国产精品一区二区久久精品涩爱| 久久99精品久久久久久hb无码| 久久99精品国产99久久6| 久久精品无码专区免费东京热 | 久久亚洲中文字幕精品有坂深雪| 91精品婷婷国产综合久久| 亚洲国产美女精品久久久久∴| 久久精品国产一区二区| 久久精品嫩草影院| 久久99精品久久久久久hb无码 | 久久精品视频一| 国产午夜电影久久| 国产精品久久影院| 色偷偷偷久久伊人大杳蕉| 噜噜噜色噜噜噜久久| 久久国产高清一区二区三区| 国产国产成人精品久久| 久久AV高潮AV无码AV| 亚洲人成网站999久久久综合| 九九久久精品无码专区| 91精品免费久久久久久久久| 久久91亚洲人成电影网站| 久久se精品一区精品二区| 香蕉久久一区二区不卡无毒影院 | 久久综合九色综合网站| 四虎国产精品成人免费久久| 国产精品成人久久久| 亚洲国产另类久久久精品小说| 精品熟女少妇AV免费久久|