Onway

1，字符(Character)是各種文字和符號(hào)的總稱，包括各國(guó)家文字、標(biāo)點(diǎn)符號(hào)、圖形符號(hào)、數(shù)字等。

2，字符集(Character set)是多個(gè)字符的集合。

3，字符編碼是一套將字符集中的字符轉(zhuǎn)換為計(jì)算機(jī)中可以接受的數(shù)值的編碼系統(tǒng)。

起源與50年代后期，在1967年定案，被國(guó)際化標(biāo)準(zhǔn)組織(ISO)定為國(guó)際標(biāo)準(zhǔn)，稱為ISO 646標(biāo)準(zhǔn)。

EASCII各種字符集&字符編碼

EASCII（Extended ASCII，延伸美國(guó)標(biāo)準(zhǔn)信息交換碼）是將ASCII碼由7位擴(kuò)充為8位而成。EASCII的內(nèi)碼是由0到255共有256個(gè)字符組成。EASCII碼比ASCII碼擴(kuò)充出來的符號(hào)包括表格符號(hào)、計(jì)算符號(hào)、希臘字母和特殊的拉丁符號(hào)。

ISO 8859，全稱ISO/IEC 8859，是國(guó)際標(biāo)準(zhǔn)化組織（ISO）及國(guó)際電工委員會(huì)（IEC）聯(lián)合制定的一系列8位字符集的標(biāo)準(zhǔn)，現(xiàn)時(shí)定義了15個(gè)字符集。

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) - 泰語，從泰國(guó)的 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欠缺的芬蘭語字母和大寫法語重音字母，以及歐元（€）符號(hào)。

ISO/IEC 8859-16 (Latin-10) - 東南歐語言。主要供羅馬尼亞語使用，并加入歐元符號(hào)。

由于英語沒有任何重音字母（不計(jì)外來詞），故可使用以上十五個(gè)字集中的任何一個(gè)來表示。

此系列中沒有-12號(hào)的原因是，此計(jì)劃原本要設(shè)計(jì)成一個(gè)包含塞爾特語族字符集的“Latin-7”，但后來塞爾特語族變成了ISO 8859-14 / Latin-8。亦有一說謂-12號(hào)本來是預(yù)留給印度天城體梵文的，但后來卻擱置了。

計(jì)算機(jī)發(fā)明之處及后面很長(zhǎng)一段時(shí)間，只用應(yīng)用于美國(guó)及西方一些發(fā)達(dá)國(guó)家，ASCII能夠很好滿足用戶的需求。但是當(dāng)天朝也有了計(jì)算機(jī)之后，為了顯示中文，必須設(shè)計(jì)一套編碼規(guī)則用于將漢字轉(zhuǎn)換為計(jì)算機(jī)可以接受的數(shù)字系統(tǒng)的數(shù)。

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

上述編碼規(guī)則就是GB2312。GB2312或GB2312-80是中國(guó)國(guó)家標(biāo)準(zhǔn)簡(jiǎn)體中文字符集，全稱《信息交換用漢字編碼字符集·基本集》，又稱GB0，由中國(guó)國(guó)家標(biāo)準(zhǔn)總局發(fā)布，1981年5月1日實(shí)施。GB2312編碼通行于中國(guó)大陸；新加坡等地也采用此編碼。中國(guó)大陸幾乎所有的中文系統(tǒng)和國(guó)際化的軟件都支持GB2312。GB2312的出現(xiàn)，基本滿足了漢字的計(jì)算機(jī)處理需要，它所收錄的漢字已經(jīng)覆蓋中國(guó)大陸99.75%的使用頻率。對(duì)于人名、古漢語等方面出現(xiàn)的罕用字，GB2312不能處理，這導(dǎo)致了后來GBK及GB 18030漢字字符集的出現(xiàn)。

GBK：由于GB 2312-80只收錄6763個(gè)漢字，有不少漢字，如部分在GB 2312-80推出以后才簡(jiǎn)化的漢字（如"啰"），部分人名用字（如中國(guó)前總理朱镕基的"镕"字），臺(tái)灣及香港使用的繁體字，日語及朝鮮語漢字等，并未有收錄在內(nèi)。于是廠商微軟利用GB 2312-80未使用的編碼空間，收錄GB 13000.1-93全部字符制定了GBK編碼。根據(jù)微軟資料，GBK是對(duì)GB2312-80的擴(kuò)展，也就是CP936字碼表 (Code Page 936)的擴(kuò)展（之前CP936和GB 2312-80一模一樣），最早實(shí)現(xiàn)于Windows 95簡(jiǎn)體中文版。雖然GBK收錄GB 13000.1-93的全部字符，但編碼方式并不相同。GBK自身并非國(guó)家標(biāo)準(zhǔn)，只是曾由國(guó)家技術(shù)監(jiān)督局標(biāo)準(zhǔn)化司、電子工業(yè)部科技與質(zhì)量監(jiān)督司公布為"技術(shù)規(guī)范指導(dǎo)性文件"。原始GB13000一直未被業(yè)界采用，后續(xù)國(guó)家標(biāo)準(zhǔn)GB18030技術(shù)上兼容GBK而非GB13000。

GB 18030，全稱：國(guó)家標(biāo)準(zhǔn)GB 18030-2005《信息技術(shù) 中文編碼字符集》，是中華人民共和國(guó)現(xiàn)時(shí)最新的內(nèi)碼字集，是GB 18030-2000《信息技術(shù) 信息交換用漢字編碼字符集 基本集的擴(kuò)充》的修訂版。與GB 2312-1980完全兼容，與GBK基本兼容，支持GB 13000及Unicode的全部統(tǒng)一漢字，共收錄漢字70244個(gè)。GB 18030主要有以下特點(diǎn)：

與UTF-8相同，采用多字節(jié)編碼，每個(gè)字可以由1個(gè)、2個(gè)或4個(gè)字節(jié)組成。

編碼空間龐大，最多可定義161萬個(gè)字符。

支持中國(guó)國(guó)內(nèi)少數(shù)民族的文字，不需要?jiǎng)佑迷熳謪^(qū)。

漢字收錄范圍包含繁體漢字以及日韓漢字

本規(guī)格的初版是中華人民共和國(guó)信息產(chǎn)業(yè)部電子工業(yè)標(biāo)準(zhǔn)化研究所起草，由國(guó)家質(zhì)量技術(shù)監(jiān)督局于2000年3月17日發(fā)布。現(xiàn)行版本為國(guó)家質(zhì)量監(jiān)督檢驗(yàn)總局和中國(guó)國(guó)家標(biāo)準(zhǔn)化管理委員會(huì)于2005年11月8日發(fā)布，2006年5月1日實(shí)施。此規(guī)格為在中國(guó)境內(nèi)所有軟件產(chǎn)品支持的強(qiáng)制規(guī)格。

Big5，又稱為大五碼或五大碼，是使用繁體中文（正體中文）社區(qū)中最常用的電腦漢字字符集標(biāo)準(zhǔn)，共收錄13,060個(gè)漢字。中文碼分為內(nèi)碼及交換碼兩類，Big5屬中文內(nèi)碼，知名的中文交換碼有CCCII、CNS11643。Big5雖普及于臺(tái)灣、香港與澳門等繁體中文通行區(qū)，但長(zhǎng)期以來并非當(dāng)?shù)氐膰?guó)家標(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)中，取得了較正式的地位。這個(gè)最新版本被稱為Big5-2003。

Big5碼是一套雙字節(jié)字符集，使用了雙八碼存儲(chǔ)方法，以兩個(gè)字節(jié)來安放一個(gè)字。第一個(gè)字節(jié)稱為"高位字節(jié)"，第二個(gè)字節(jié)稱為"低位字節(jié)"。"高位字節(jié)"使用了0x81-0xFE，"低位字節(jié)"使用了0x40-0x7E，及0xA1-0xFE。

歷史上存在兩個(gè)獨(dú)立的嘗試創(chuàng)立單一字符集的組織，即國(guó)際標(biāo)準(zhǔn)化組織（ISO）和多語言軟件制造商組成的統(tǒng)一碼聯(lián)盟。前者開發(fā)的 ISO/IEC 10646 項(xiàng)目，后者開發(fā)的統(tǒng)一碼（unicode）項(xiàng)目。因此最初制定了不同的標(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格式，然后再翻譯回原編碼，你不會(huì)丟失任何信息。

UCS包含了已知語言的所有字符。除了拉丁語、希臘語、斯拉夫語、希伯來語、阿拉伯語、亞美尼亞語、格魯吉亞語，還包括中文、日文、韓文這樣的象形文字，UCS還包括大量的圖形、印刷、數(shù)學(xué)、科學(xué)符號(hào)。

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)一碼、萬國(guó)碼、單一碼、標(biāo)準(zhǔn)萬國(guó)碼）是業(yè)界的一種標(biāo)準(zhǔn)，它可以使電腦得以體現(xiàn)世界上數(shù)十種文字的系統(tǒng)。Unicode 是基于通用字符集（Universal Character Set）的標(biāo)準(zhǔn)來發(fā)展，并且同時(shí)也以書本的形式對(duì)外發(fā)表。

1991年前后，兩個(gè)項(xiàng)目的參與者都認(rèn)識(shí)到，世界不需要兩個(gè)不兼容的字符集。于是，它們開始合并雙方的工作成果，并為創(chuàng)立一個(gè)單一編碼表而協(xié)同工作。從Unicode 2.0開始，Unicode采用了與ISO 10646-1相同的字庫(kù)和字碼；ISO也承諾，ISO 10646將不會(huì)替超出U+10FFFF的UCS-4編碼賦值，以使得兩者保持一致。

統(tǒng)一碼聯(lián)盟公布的Unicode標(biāo)準(zhǔn)包含了ISO/IEC 10646-1實(shí)現(xiàn)級(jí)別3的基本多文種平面。在兩個(gè)標(biāo)準(zhǔn)里，所有的字符都在相同的位置并且有相同的名字。

UTF為UCS / Unicode Transformation Format“Unicode轉(zhuǎn)換格式”的縮寫。

（可以這樣理解：Unicode是字符集，UTF-32/ UTF-16/ UTF-8是三種字符編碼方案。）

UTF-8：

UTF-8（8-bit Unicode Transformation Format）是一種針對(duì)Unicode的可變長(zhǎng)度字符編碼（定長(zhǎng)碼），也是一種前綴碼。

UTF-16：

UTF-16是Unicode的其中一個(gè)使用方式。

在基本多語言平面內(nèi)定義的符號(hào)（（Basic Multilingual Plane, BMP），或稱第零平面（Plane 0）），使用2個(gè)字節(jié)表示，在此之外的字符（其他平面內(nèi)的字符），則使用4個(gè)字節(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了?，F(xiàn)在若有軟件聲稱自己支援UCS-2編碼，那其實(shí)是暗指它不能支援在UTF-16中超過2bytes的字集。對(duì)于小于0x10000的UCS碼，UTF-16編碼就等于UCS碼。

UTF-32：

UTF-32 (或 UCS-4)是一種將Unicode字符編碼的協(xié)定，對(duì)每一個(gè)Unicode碼位使用恰好32位元。

UTF-32與UCS-4的關(guān)系：

原本ISO 10646標(biāo)準(zhǔn)定義了一個(gè)32位元的編碼形式，稱作UCS-4，使用通用字符集（UCS）的每一個(gè)字符，會(huì)在0到十六進(jìn)制的7FFFFFFF這樣的字碼空間中，被表示成一個(gè)的32位元的碼值。

UCS-4足以用來表示所有的Unicode的字碼空間，其最大的碼位為十六進(jìn)制的10FFFF，所以其空間約有百萬個(gè)碼位。有些人認(rèn)為保留如此大的字碼空間卻只為了對(duì)應(yīng)這很小的碼集是浪費(fèi)的所以一個(gè)新的編碼UTF-32被提出來了。UTF-32 是一個(gè) UCS-4 的子集，使用32-位元的碼值，只在0到10FFFF的字碼空間。

UTF-32 原本是 UCS-4 的子集，但JTC1/SC2/WG2聲明，所有未來對(duì)字符的指定都將會(huì)限制在BMP及其14個(gè)補(bǔ)充平面，并移除先前在 E0 到 FF 平面的 60 到 7F 群的私用空間。

于是就現(xiàn)狀而言，除了 UTF-32 標(biāo)準(zhǔn)包含額外的 Unicode 意涵，UCS-4 和 UTF-32 大體是相同的。

Unicode的編碼方式與ISO 10646的通用字符集（Universal Character Set，UCS）概念相對(duì)應(yīng)，目前實(shí)際應(yīng)用的Unicode版本對(duì)應(yīng)于UCS-2，使用16位的編碼空間。也就是每個(gè)字符占用2個(gè)字節(jié)。這樣理論上一共最多可以表示216即65536個(gè)字符。基本滿足各種語言的使用。實(shí)際上當(dāng)前版本的Unicode尚未填充滿這16位編碼，保留了大量空間作為特殊使用或?qū)頂U(kuò)展。

上述16位Unicode字符構(gòu)成基本多文種平面（Basic Multilingual Plane，簡(jiǎn)稱BMP）。最新（但未實(shí)際廣泛使用）的Unicode版本定義了16個(gè)輔助平面，兩者合起來至少需要占據(jù)21位的編碼空間，比3字節(jié)略少。但事實(shí)上輔助平面字符仍然占用4字節(jié)編碼空間，與UCS-4保持一致。未來版本會(huì)擴(kuò)充到ISO 10646-1實(shí)現(xiàn)級(jí)別3（參考中文維基百科，通用字符集），即涵蓋UCS-4的所有字符。UCS-4是一個(gè)更大的尚未填充完全的31位字符集，加上恒為0的首位，共需占據(jù)32位，即4字節(jié)。理論上最多能表示231個(gè)字符，完全可以涵蓋一切語言所用的符號(hào)。

BMP字符的Unicode編碼表示為U+hhhh，其中每個(gè)h 代表一個(gè)十六進(jìn)制數(shù)位。與UCS-2編碼完全相同。

基本多文種平面及輔助平面參考維基百科。

內(nèi)碼和code page

目前Windows的內(nèi)核已經(jīng)支持Unicode字符集，這樣在內(nèi)核上可以支持全世界所有的語言文字（不是說目前使用的是16位編碼嗎？）。但是由于現(xiàn)有的大量程序和文檔都采用了某種特定語言的編碼，例如GBK，Windows不可能不支持現(xiàn)有的編碼，而全部改用Unicode。Windows使用代碼頁(yè)(code page)來適應(yīng)各個(gè)國(guó)家和地區(qū)。

內(nèi)碼是指操作系統(tǒng)內(nèi)部的字符編碼。早期操作系統(tǒng)的內(nèi)碼是與語言相關(guān)的?，F(xiàn)在的Windows在系統(tǒng)內(nèi)部支持Unicode，然后用代碼頁(yè)適應(yīng)各種語言，“內(nèi)碼”的概念就比較模糊了。微軟一般將缺省代碼頁(yè)指定的編碼說成是內(nèi)碼。

Windows中有缺省代碼頁(yè)的概念，即缺省用什么編碼來解釋字符。

Windows的內(nèi)碼是Unicode，它在技術(shù)上可以同時(shí)支持多個(gè)代碼頁(yè)。只要文件能說明自己使用什么編碼，用戶又安裝了對(duì)應(yīng)的代碼頁(yè)，Windows就能正確顯示，例如在HTML文件中就可以指定charset。

問題：如果目前使用的unicode版本是16位編碼的，即對(duì)應(yīng)UCS-2，那么就是說沒有使用輔助平面，那樣的話使用UTF-16編碼有什么意思呢？直接使用UCS-2不就得了嗎？

在文本處理中, CR, LF, CR/LF是不同操作系統(tǒng)上使用的換行符. 

Dos和windows： 采用回車+換行CR/LF表示下一行. 

UNIX/Linux  ： 采用換行符LF表示下一行. 

MAC OS      ： 采用回車符CR表示下一行. 

CR用符號(hào)'\r'表示, 十進(jìn)制ASCII代碼是13, 十六進(jìn)制代碼為0x0D; 

LF用符號(hào)'\n'表示, 十進(jìn)制ASCII代碼是10, 十六制為0x0A. 

所以Windows平臺(tái)上換行在文本文件中是使用 0d 0a 兩個(gè)字節(jié)表示, 而UNIX和蘋果平臺(tái)上換行則是使用0a或0d一個(gè)字節(jié)表示. 

一般操作系統(tǒng)上的運(yùn)行庫(kù)會(huì)自動(dòng)決定文本文件的換行格式. 如一個(gè)程序在windows上運(yùn)行就生成CR/LF換行格式的文本文件，而在Linux上運(yùn)行就生成LF格式換行的文本文件。 

在一個(gè)平臺(tái)上使用另一種換行符的文件文件可能會(huì)帶來意想不到的問題, 特別是在編輯程序代碼時(shí)，有時(shí)候代碼在編輯器中顯示正常, 但在編輯時(shí)卻會(huì)因?yàn)閾Q行符問題而出錯(cuò)。 

很多文本/代碼編輯器帶有換行符轉(zhuǎn)換功能, 使用這個(gè)功能可以將文本文件中的換行符在不同格式單互換。在不同平臺(tái)間使用FTP軟件傳送文件時(shí), 在ascii文本模式傳輸模式下, 一些FTP客戶端程序會(huì)自動(dòng)對(duì)換行格式進(jìn)行轉(zhuǎn)換。經(jīng)過這種傳輸?shù)奈募止?jié)數(shù)可能會(huì)發(fā)生變化。如果你不想ftp修改原文件, 可以使用bin模式(二進(jìn)制模式)傳輸文本。

Locale是根據(jù)計(jì)算機(jī)用戶所使用的語言，所在國(guó)家或者地區(qū)，以及當(dāng)?shù)氐奈幕瘋鹘y(tǒng)所定義的一個(gè)軟件運(yùn)行時(shí)的語言環(huán)境。  

這個(gè)用戶環(huán)境可以按照所涉及到的文化傳統(tǒng)的各個(gè)方面分成幾個(gè)大類，通常包括用戶所使用的語言符號(hào)及其分類(LC_CTYPE)，數(shù)字 (LC_NUMERIC)，比較和排序習(xí)慣(LC_COLLATE)，時(shí)間顯示格式(LC_TIME)，貨幣單位(LC_MONETARY)，信息主要是提示信息,錯(cuò)誤信息, 狀態(tài)信息, 標(biāo)題, 標(biāo)簽, 按鈕和菜單等(LC_MESSAGES)，姓名書寫方式(LC_NAME)，地址書寫方式(LC_ADDRESS)，電話號(hào)碼書寫方式 (LC_TELEPHONE)，度量衡表達(dá)方式(LC_MEASUREMENT)，默認(rèn)紙張尺寸大小(LC_PAPER)和locale對(duì)自身包含信息的概述(LC_IDENTIFICATION)。

設(shè)定locale就是設(shè)定12大類的locale分類屬性，即 12個(gè)LC_*。除了這12個(gè)變量可以設(shè)定以外，為了簡(jiǎn)便起見，還有兩個(gè)變量：LC_ALL和LANG。它們之間有一個(gè)優(yōu)先級(jí)的關(guān)系： LC_ALL>LC_*>LANG 可以這么說，LC_ALL是最上級(jí)設(shè)定或者強(qiáng)制設(shè)定，而LANG是默認(rèn)設(shè)定值。 1、如果你設(shè)定了LC_ALL＝zh_CN.UTF-8，那么不管LC_*和LANG設(shè)定成什么值，它們都會(huì)被強(qiáng)制服從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)會(huì)將LC_*設(shè)定成默認(rèn)值，也就是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等等均會(huì)采用默認(rèn)值，也就是LANG的值，也就是LC_COLLATE＝LC_MESSAGES＝……＝ LC_PAPER＝LANG＝zh_CN.UTF-8。

所以，locale是這樣設(shè)定的： 1、如果你需要一個(gè)純中文的系統(tǒng)的話，設(shè)定LC_ALL= zh_CN.XXXX，或者LANG= zh_CN.XXXX都可以，當(dāng)然你可以兩個(gè)都設(shè)定，但正如上面所講，LC_ALL的值將覆蓋所有其他的locale設(shè)定，不要作無用功。 2、如果你只想要一個(gè)可以輸入中文的環(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個(gè)LC_*一一設(shè)定成你需要的值，打造一個(gè)古靈精怪的系統(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(德國(guó)的度量衡使用ISO-8859-15字符集) 羅馬的地址書寫方式，美國(guó)的紙張?jiān)O(shè)定……。估計(jì)沒人這么干吧。 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下打開.TXT文件，中文顯示為亂碼，在這找到了解決的辦法：

終端輸入gconf-editor調(diào)出gconf-edit

PS：輸入gconf-editor即可，前面不需要加Sudo

依次點(diǎn)開

apps->gedit-2->preferences－＞encodings 中的auto-detected

在雙擊彈出對(duì)話框中加入GB18030，GBK，GB2312就可以了

這里最好把GBK,GB2312,GB18030調(diào)到其他字符編碼的前面去

Vim有四個(gè)跟字符編碼方式有關(guān)的選項(xiàng)，encoding、fileencoding、fileencodings、termencoding(這些選項(xiàng)設(shè)置請(qǐng)參考Vim文檔中encoding-names章節(jié))，它們的意義如下:

encoding

encoding是Vim內(nèi)部使用的字符編碼方式，包括Vim的buffer(緩沖區(qū))、菜單文本、消息文本等。默認(rèn)是根據(jù)你的locale選擇。VIM用戶手冊(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（文件的保存編碼)。

fileencoding

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

fileencodings

Vim自動(dòng)探測(cè)fileencoding的順序列表，啟動(dòng)時(shí)會(huì)按照它所列出的字符編碼方式逐一探測(cè)即將打開的文件的字符編碼方式，并且將 fileencoding 設(shè)置為最終探測(cè)到的字符編碼方式。因此最好將Unicode 編碼方式放到這個(gè)列表的最前面，將拉丁語系編碼方式 latin1放到最后面。

termencoding

Vim所工作的終端(或者 Windows的Console窗口)的字符編碼方式。如果vim所在的term與vim編碼相同，則無需設(shè)置。如其不然，你可以用vim的termencoding選項(xiàng)將自動(dòng)轉(zhuǎn)換成term的編碼.這個(gè)選項(xiàng)對(duì)GUI模式Vim(GVim)無效，而對(duì)Console模式的Vim而言就是Windows控制臺(tái)的代碼頁(yè)，并且通常我們不需要改變它。

現(xiàn)在來看看Vim的多字符編碼方式支持是如何工作的：

啟動(dòng)Vim，根據(jù).vimrc文件中設(shè)置的encoding的值來設(shè)置buffer、菜單文本、消息文的字符編碼方式。

讀取需要編輯的文件，根據(jù)fileencodings中列出的字符編碼方式逐一探測(cè)該文件編碼方式。并設(shè)置fileencoding為探測(cè)到的，看起來是正確的字符編碼方式。

對(duì)比fileencoding和encoding的值，若不同則調(diào)用iconv將文件內(nèi)容轉(zhuǎn)換為encoding所描述的字符編碼方式，并且把轉(zhuǎn)換后的內(nèi)容放到為此文件開辟的 buffer 里，此時(shí)我們就可以開始編輯這個(gè)文件了。注意，完成這一步動(dòng)作需要調(diào)用外部的 iconv.dll，你需要保證這個(gè)文件存在于$VIMRUNTIME或者其他列在PATH環(huán)境變量中的目錄里。

編輯完成后保存文件時(shí)，再次對(duì)比fileencoding和encoding的值。若不同，再次調(diào)用iconv將即將保存的buffer中的文本轉(zhuǎn)換為fileencoding所描述的字符編碼方式，并保存到指定的文件中。同樣，這需要調(diào)用iconv.dll由于Unicode能夠包含幾乎所有的語言的字符，而且Unicode的UTF-8編碼方式又是非常具有性價(jià)比的編碼方式 (空間消耗比 UCS-2 小)，因此建議encoding的值設(shè)置為utf-8。這么做的另一個(gè)理由是encoding設(shè)置為 utf-8 時(shí)，Vim 自動(dòng)探測(cè)文件的編碼方式會(huì)更準(zhǔn)確 (或許這個(gè)理由才是主要的 ;)。我們?cè)谥形腤indows里編輯的文件，為了兼顧與其他軟件的兼容性，文件編碼還是設(shè)置為GB2312/GBK比較合適，因此fileencoding建議設(shè)置為chinese(chinese是個(gè)別名，在Unix里表示gb2312，在Windows里表示cp936，也就是GBK的代碼頁(yè))。

當(dāng)vim在utf-8的local下打開gbk文件時(shí)，顯示的是亂碼，可以在~/.vimrc文件中加入如下代碼來解決：

set fencs=utf-8,gbk

這一行的作用是告訴vim，打開一個(gè)文件時(shí)，嘗試utf8,gbk兩種編碼，vim只需要掃描文件的前一段，就可以根據(jù)文件里面的數(shù)據(jù)判斷出文件是否用的是utf8或者gbk編碼。如果不指定這一行，則vim只會(huì)用當(dāng)前編碼 (locale)來打開文件，因?yàn)閘ocale是UTF-8，而文件是gbk，所以打開是亂碼。

一般vim打開中文文件時(shí)出現(xiàn)亂碼時(shí)可以用下面的方法來解決：

set fileencoding=gb18030 set fileencodings=utf-8,gb18030,utf-16,big5

這樣設(shè)置的原因說明如下：vim里面的編碼主要跟三個(gè)參數(shù)有關(guān)：enc(encoding), fenc(fileencoding)和fencs(fileencodings)。其中fenc是當(dāng)前文件的編碼，也就是說，一個(gè)在vim里面已經(jīng)正確顯示了的文件(前提是你的系統(tǒng)環(huán)境跟你的enc設(shè)置匹配)，你可以通過改變 fenc后再w來將此文件存成不同的編碼。比如說，我:set fenc=utf-8然后:w就把文件存成utf-8的了，:set fenc=gb18030再:w就把文件存成gb18030的了。這個(gè)值對(duì)于打開文件的時(shí)候是否能夠正確地解碼沒有任何關(guān)系。fencs就是用來在打開文件的時(shí)候進(jìn)行解碼的猜測(cè)列表。文件編碼沒有百分百正確的判斷方法，所以vim只能猜測(cè)文件編碼。比如我的vimrc里面這個(gè)的設(shè)置是：

set fileencodings=utf-8,gb18030,utf-16,big5

所以我的vim每打開一個(gè)文件，先嘗試用utf-8進(jìn)行解碼，如果用utf-8解碼到了一半出錯(cuò)(所謂出錯(cuò)的意思是某個(gè)地方無法用utf-8正確地 解碼)，那么就從頭來用gb18030重新嘗試解碼，如果gb18030又出錯(cuò)(注意gb18030并不是像utf-8似的規(guī)則編碼，所以所謂的出錯(cuò)只是 說某個(gè)編碼沒有對(duì)應(yīng)的有意義的字，比如0)，就嘗試用utf-16，仍然出錯(cuò)就嘗試用big5。這一趟下來，如果中間的某次解碼從頭到尾都沒有出錯(cuò)，那么 vim就認(rèn)為這個(gè)文件是這個(gè)編碼的，不會(huì)再進(jìn)行后面的嘗試了。這個(gè)時(shí)候，fenc的值就會(huì)被設(shè)為vim最后采用的編碼值，可以用:set fenc?來查看具體是什么。

當(dāng)然這個(gè)也是有可能出錯(cuò)的，比如你的文件是gb18030編碼的，但是實(shí)際上只有一兩個(gè)字符是中文，那么有可能他們正好也能被utf-8解碼，那么這個(gè)文件就會(huì)被誤認(rèn)為是utf-8的導(dǎo)致錯(cuò)誤解碼。

至于enc，其作用基本只是顯示。不管最后的文件是什么編碼的，vim都會(huì)將其轉(zhuǎn)換為當(dāng)前系統(tǒng)編碼來進(jìn)行處理，這樣才能在當(dāng)前系統(tǒng)里面正確地顯示出 來，因此enc就是干這個(gè)的。在windows下面，enc默認(rèn)是cp936，這也就是中文windows的默認(rèn)編碼，所以enc是不需要改的。在 linux下，隨著你的系統(tǒng)locale可能設(shè)為zh_CN.gb18030或者zh_CN.utf-8，你的enc要對(duì)應(yīng)的設(shè)為gb18030或者 utf-8(或者gbk之類的)。

最后再來說一下新建空文件的默認(rèn)編碼?？次臋n好像說會(huì)采用fencs里面的第一個(gè)編碼作為新建文件的默認(rèn)編碼。但是這里有一個(gè)問題，就是fencs 的順序跟解碼成功率有很大關(guān)系，根據(jù)我的經(jīng)驗(yàn)utf-8在前比gb18030在前成功率要高一些，那么如果我新建文件默認(rèn)想讓它是gb18030編碼怎么辦？一個(gè)方法是每次新建文件后都:set fenc=gb18030一下，不過我發(fā)現(xiàn)在vimrc里面設(shè)置fenc=gb18030也能達(dá)到這個(gè)效果。

字符集： 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

代碼頁(yè)，內(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