vim文件编码及乱码处理

在 Vim 中， 有四个与编码有关的选项， 它们是： fileencodings 、 fileencoding 、 encoding 和 termencoding 。 在实际使用中， 任何一个选项出现错误， 都会导致出现乱码。 因此， 每一个 Vim 用户都应该明确这四个选项的含义。 下面， 我们详细介绍一下这四个选项的含义和作用。

1 encoding

encoding 是 Vim 内部使用的字符编码方式。 当我们设置了 encoding 之后， Vim 内部所有的 buffer、 寄存器、 脚本中的字符串等， 全都使用这个编码。 Vim 在工作的时候， 如果编码方式与它的内部编码不一致， 它会先把编码转换成内部编码。 如果工作用的编码中含有无法转换为内部编码的字符， 在这些字符就会丢失。 因此，在选择 Vim 的内部编码的时候， 一定要使用一种表现能力足够强的编码， 以免影响正常工作。

由于 encoding 选项涉及到 Vim 中所有字符的内部表示， 因此只能在 Vim 启动的时候设置一次。 在 Vim 工作过程中修改 encoding 会造成非常多的问题。 如果没有特别的理由， 请始终将 encoding 设置为 utf-8 。 为了避免在非 UTF-8 的系统如 Windows 下， 菜单和系统提示出现乱码， 可同时做这几项设置：

set   encoding =utf-8
set   langmenu =zh_CN.UTF-8
language  message zh_CN . UTF - 8

2 termencoding

termencoding 是 Vim 用于屏幕显示的编码， 在显示的时候， Vim 会把内部编码转换为屏幕编码， 再用于输出。 内部编码中含有无法转换为屏幕编码的字符时， 该字符会变成问号， 但不会影响对它的编辑操作。 如果 termencoding 没有设置， 则直接使用 encoding 不进行转换。

举个例子， 当你在 Windows 下通过 telnet 登录 Linux 工作站时， 由于 Windows 的 telnet 是 GBK 编码的， 而 Linux 下使用 UTF-8 编码， 你在 telnet 下的 Vim 中就会乱码。 此时有两种消除乱码的方式： 一是把 Vim 的 encoding 改为 gbk ， 另一种方法是保持 encoding 为 utf-8 ， 把 termencoding 改为 gbk ， 让 Vim 在显示的时候转码。 显然， 使用前一种方法时， 如果遇到编辑的文件中含有 GBK 无法表示的字符时， 这些字符就会丢失。 但如果使用后一种方法， 虽然由于终端所限， 这些字符无法显示， 但在编辑过程中这些字符是不会丢失的。

对于图形界面下的 GVim， 它的显示不依赖 TERM， 因此 termencoding 对于它没有意义。 在 GTK2 下的 GVim 中， termencoding 永远是 utf-8 ， 并且不能修改。 而 Windows 下的 GVim 则忽略 termencoding 的存在。

3 fileencoding

当 Vim 从磁盘上读取文件的时候， 会对文件的编码进行探测。 如果文件的编码方式和 Vim 的内部编码方式不同， Vim 就会对编码进行转换。 转换完毕后， Vim 会将 fileencoding 选项设置为文件的编码。 当 Vim 存盘的时候， 如果 encoding 和 fileencoding 不一样， Vim 就会进行编码转换。 因此， 通过打开文件后设置 fileencoding ， 我们可以将文件由一种编码转换为另一种编码。 但是， 由前面的介绍可以看出， fileencoding 是在打开文件的时候， 由 Vim 进行探测后自动设置的。 因此， 如果出现乱码， 我们无法通过在打开文件后重新设置 fileencoding 来纠正乱码。

4 fileencodings

编码的自动识别是通过设置 fileencodings 实现的， 注意是复数形式。 fileencodings 是一个用逗号分隔的列表， 列表中的每一项是一种编码的名称。 当我们打开文件的时候， VIM 按顺序使用 fileencodings 中的编码进行尝试解码， 如果成功的话， 就使用该编码方式进行解码， 并将 fileencoding 设置为这个值， 如果失败的话， 就继续试验下一个编码。

因此， 我们在设置 fileencodings 的时候， 一定要把要求严格的、 当文件不是这个编码的时候更容易出现解码失败的编码方式放在前面， 把宽松的编码方式放在后面。

例如， latin1 是一种非常宽松的编码方式， 任何一种编码方式得到的文本， 用 latin1 进行解码， 都不会发生解码失败 —— 当然， 解码得到的结果自然也就是理所当然的“乱码”。 因此， 如果你把 latin1 放到了 fileencodings 的第一位的话， 打开任何中文文件都是乱码也就是理所当然的了。

以下是滇狐推荐的一个 fileencodings 设置：

set   fileencodings =ucs-bom , utf-8 , cp936 , gb18030 , big5 , euc-jp , euc-kr , latin1

其中， ucs-bom 是一种非常严格的编码， 非该编码的文件几乎没有可能被误判为 ucs-bom， 因此放在第一位。

utf-8 也相当严格， 除了很短的文件外 (例如许多人津津乐道的 GBK 编码的“联通”被误判为 UTF-8 编码的经典错误)， 现实生活中一般文件是几乎不可能被误判的， 因此放在第二位。

接下来是 cp936 和 gb18030， 这两种编码相对宽松， 如果放前面的话， 会出现大量误判， 所以就让它们靠后一些。 cp936 的编码空间比 gb18030 小， 所以把 cp936 放在 gb18030 前面。

至于 big5、euc-jp 和 euc-kr， 它们的严格程度和 cp936 差不多， 把它们放在后面， 在编辑这些编码的文件的时候必然出现大量误判， 但这是 Vim 内置编码探测机制没有办法解决的事。 由于中国用户很少有机会编辑这些编码的文件， 因此我们还是决定把 cp936 和 gb18030 前提以保证这些编码的识别。

最后就是 latin1 了。 它是一种极其宽松的编码， 以至于我们不得不把它放在最后一位。 不过可惜的是， 当你碰到一个真的 latin1 编码的文件时， 绝大部分情况下， 它没有机会 fall-back 到 latin1， 往往在前面的编码中就被误判了。 不过， 正如前面所说的， 中国用户没有太多机会接触这样的文件。

如果编码被误判了， 解码后的结果就无法被人类识别， 于是我们就说， 这个文件乱码了。 此时， 如果你知道这个文件的正确编码的话， 可以在打开文件的时候使用 ++enc=encoding 的方式来打开文件， 如：

:e ++enc=utf-8 myfile.txt

5 fencview

根据前面的介绍， 我们知道， 通过 Vim 内置的编码识别机制， 识别率是很低的， 尤其是对于简体中文 (GBK/GB18030)、 繁体中文 (Big5)、 日文 (euc-jp) 和韩文 (euc-kr) 之间的识别。 而对于普通用户而言， 肉眼看出一个文件的编码方式也是很不现实的事情。 因此， 滇狐强烈推荐水木社区的 mbbill 开发的 fencview 插件。 该插件使用词频统计的方式识别编码， 正确率非常高。 点击 这里 下载

 

 

 

[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的值，是最理想的一种情况。