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