更改vim编码

在Linux下咱们常常会遇到编码不一致致使显示乱码的问题,其实Vim给咱们提供了至关强大的编码转换命令,包括文档编码和显示编码. 



        在Vim中输入:set fenc=编码  便可将文档的编码转换为相应的编码格式,这是只须要保存文档,文档的编码就变了. 



        若是在Vim中输入:set enc=编码  便可改变Vim的显示编码,这是就能够看到文档中的乱码了,不过这是即便对文档作了修改并保存,文档仍旧以以前的文档编码保存. 



        其实使用中咱们常常用到的编码有:gbk utf-8 big5 cp936.若是须要转换其余编码能够本身变动. 

set fenc=utf-8 

set enc=gb2312 

此文讲解的是vim编辑多字节编码文档（中文）所要了解的一些基础知识，注意其没有涉及gvim，纯指字符终端下的vim。 
vim编码方面的基础知识： 
1，存在3个变量： 
encoding—-该选项使用于缓冲的文本(你正在编辑的文件)，寄存器，Vim 脚本文件等等。你能够把 ‘encoding’ 选项看成是对 Vim 内部运行机制的设定。 
fileencoding—-该选项是vim写入文件时采用的编码类型。 
termencoding—-该选项表明输出到客户终端（Term）采用的编码类型。 
2，此3个变量的默认值： 
encoding—-与系统当前locale相同，因此编辑文件的时候要考虑当前locale，不然要设置的东西就比较多了。 
fileencoding—-vim打开文件时自动辨认其编码，fileencoding就为辨认的值。为空则保存文件时采用encoding的编码，如 果没有修改encoding，那值就是系统当前locale了。 
termencoding—-默认空值，也就是输出到终端不进行编码转换。 
因而可知，编辑不一样编码文件须要注意的地方不只仅是这3个变量，还有系统当前locale和、文件自己编码以及自动编码识别、客 户运行vim的终端所使用的编码类型3个关键点，这3个关键点影响着3个变量的设定。 
若是有人问：为何我用vim打开中文文档的时候出现乱码？ 
答案是不肯定的，缘由上面已经讲了，不搞清楚这3个关键点和这3个变量的设定值，出现乱码是正常的，却是不出现乱码那反却是凑巧的。 
再来看一下常见状况下这三个关键点的值以及在这种状况下这3个变量的值： 
1，locale—-目前大部分Linux系统已经将utf-8做为默认locale了，不过也有可能不是，例若有些系统使用中文locale zh_CN.GB18030。在locale为utf-8的状况下，启动vim后encoding将会设置为utf-8，这是兼容性最好的方式，由于内部处理使用utf-8的话，不管外部存储编码为什么均可以进行完好损转换。locale决定了vim内部处理数据的编码，也就是encoding。 
2，文件的编码以及自动编码识别—-这方面牵扯到各类编码的规则，就不一一细讲了。但须要明白的是，文件编码类型并非保存在文件内的，也就是说没有任何 
描述性的字段来记录文档是何种编码类型的。所以咱们在编辑文档的时候，要么必须知道这文档保存时是以什么编码保存的，要么经过另外的一些手段来判定编码类 
型，这另外的手段，就是经过某些编码的码表特征来判定，例如每一个字符占用的字节数，每一个字符的ascii值是否都大于某个字段来判定这个文件属于何种编码。这种方式vim也使用了，这就是vim的自动编码识别机制了。但这种机制因为编码各式各样，不可能每种编码都有显著的特征来辨别，因此是不可能 
100%准确的。对于咱们GB2312编码，因为其中文是使用了2个acsii值高于127的字符组成汉字字符的，所以不可能把gb2312编码的文件与latin1编码区分开来，所以自动识别编码的机制对于gb2312是不成功的，它只会将文件辨识为latin1编码。此问题一样出如今gbk，big5等。所以咱们在编辑此类文档时，须要手工设定encoding和fileencoding。若是文档编码为utf-8时，通常vim都能自动识别正确的编码。 
3，客户运行vim的终端所使用的编码类型—-同第二条同样，这也是一个比较难以判定的关键点。第二个关键点决定着从文件读取内容和写入内容到文件 
时使用的编码，而此关键点则决定vim输出内容到终端时使用的编码，若是此编码类型和终端认为它收到的数据的编码类型不一样，则又会产生乱码问题。在linux本地X环境下，通常终端都认为其接收的数据的编码类型和系统locale类型相符，所以不需关心此方面是否存在问题。但若是牵涉到远程终端，例如ssh登陆服务器，则问题就有可能出现了。例如从1台locale为GB2310的系统（称做客户机）ssh到locale为utf-8的系统（称做服务器）并开启vim编辑文档，在不加任何改动的状况下，服务器返回的数据为utf-8的，但客户机认为服务器返回的数据是gb2312的，按照gb2312来解释数据，则确定就是乱码了，这时就须要设置termencoding为gb2312来解决这个问题。此问题更多出如今咱们的windows desktop机远程ssh登陆服务器的状况下，这里牵扯到不一样系统的编码转换问题。因此又与windows自己以及ssh客户端有很大相关性。在 
windows下存在两种编码类型的软件，一种是自己就为unicode编码方式编写的软件，一种是ansi软件，也就是程序处理数据直接采用字节流，不关心编码。前一种程序能够在任何语言的windows上正确显示多国语言，然后一种则编写在何种语言的系统上则只能在何种语言的系统上显示正确的文字。对于这两种类型的程序，咱们须要区别对待。以ssh客户端为例，咱们使用的putty是unicode软件，而secure CRT则是ansi 
软件。对于前者，咱们要正确处理中文，只要保证vim输出到终端的编码为utf-8便可，就是termencoding=utf-8。但对于后者，一方面咱们要确认咱们的windows系统默认代码页为cp936（中文windows默认值），另外一方面要确认vim设置的termencoding=cp936。 
最后来看看处理中文文档最典型的几种状况和设置方式： 
1，系统locale是utf-8（不少linux系统默认的locale形式），编辑的文档是GB2312或GBK形式的（Windows记事本默认保存形式，大部分编辑器也默认保存为这个形式，因此最多见），终端类型utf-8（也就是假定客户端是putty类的unicode软件）则vim打开文档后，encoding=utf-8（locale决定的）， fileencoding=latin1 （ 自动编码判断机制不许致使 的），termencoding=空（默认无需转换term编码），显示文件为乱码。 
解决方案1：首先要修正fileencoding为cp936或者euc-cn（两者同样的，只不过叫法不一样），注意修正的方法不是:set fileencoding=cp936，这只是将文件保存为cp936，正确的方法是从新以cp936的编码方式加载文件为:edit++enc=cp936，能够简写为:e ++enc=cp936。 
解决方案2：临时改变vim运行的locale环境，方法是以LANG=zh_CN vim abc.txt的方式来启动vim，则此时encoding=euc-cn（locale决定的），fileencoding=空（此locale下文件编码自动判别功能不启用，因此fileencoding为文件自己编码方式不变，也就是euc-cn），termencoding=空（默认值，为空则等于encoding）此时仍是乱码的，由于咱们的ssh终端认为接受的数据为utf-8，但vim发送数据为euc-cn，因此仍是不对。此时再用命令:set termencoding=utf-8将终端数据输出为utf-8，则显示正常。 
2，状况与1基本相同，只是使用的ssh软件为secure CRT类ansi类软件。 
vim打开文档后，encoding=utf-8（locale决定的），fileencoding=latin1（自动编码判断机制不许致使 的），termencoding=空（默认无需转换term编码），显示文件为乱码。 
解决方案1：首先要保证运行secure CRT的windows机器的默认代码页为CP936，这一点中文windows已是默认设置了。其余的与上面方案1相同，只是要增长一步，:set termencoding=cp936 
解决方案2：与上面方案2相似，不过最后一步修改termencoding省略便可，在此状况下须要的修改最少，只要以locale为zh_CN开启vim，则encoding=euc-cn，fileencoding和termencoding都为空即为encoding的值，是最理想的一种状况。 
可见理解这3个关键点和3个参数的意义，对于编码问题有很大助力，之后就能够为所欲为的处理文档了，同时不只仅是应用于vim，在其余须要编码转换的环境 里，均可以应用相似的思路来处理问题解决问题。 
最后推荐一款功能强大的windows下的ssh客户端—-xshell，它具备相似secure CRT同样的多tab 
的ssh窗口的能力，但最为方便的是这款工具还有改变Term编码的功能，这样咱们就能够不用频繁调整termencoding，只需在ssh软件里切换编码便可，这是我用过的最为方便的ssh工具。它是商业软件，但非注册用户使用没有任何限制，只是30天试用期超出后会每次启动都提示注册，对于功能没有丝毫影响