第一 概念：
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