VIM 文件编码识别与乱码处理（二）

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

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

因此，我们在设置 ''fileencodings'' 的时候，一定要把要求严格的、当文件不是这个编码的时候更容易出现解码失败的编码方式放在前面，把宽松的编码方式放在后面。
* fileencoding
   当 Vim 从磁盘上读取文件的时候，会对文件的编码进行探测。如果文件的编码方式和 Vim 的内部编码方式不同，Vim 就会对编码进行转换。转换完毕后，Vim 会将 ''fileencoding'' 选项设置为文件的编码。
当 Vim 存盘的时候，如果 ''encoding'' 和 ''fileencoding'' 不一样，Vim 就会进行编码转换。
   因此，通过打开文件后设置 ''fileencoding''，我们可以将文件由一种编码转换为另一种编码。
但是，由前面的介绍可以看出，''fileencoding'' 是在打开文件的时候，由 Vim 进行探测后自动设置的。
因此，如果出现乱码，我们无法通过在打开文件后重新设置 ''fileencoding'' 来纠正乱码。

   编码的自动识别是通过设置 fileencodings 实现的，注意是复数形式。fileencodings 是一个用逗号分隔的列表，列表中的每一项是一种编码的名称。当我们打开文件的时候，VIM 按顺序使用 fileencodings 中的编码进行尝试解码，如果成功的话，就使用该编码方式进行解码，并将 ''fileencoding'' 设置为这个值，如果失败的话，就继续试验下一个编码。
    因此，我们在设置 ''fileencodings'' 的时候，一定要把要求严格的、当文件不是这个编码的时候更容易出现解码失败的编码方式放在前面，把宽松的编码方式放在后面。
    例如，latin1 是一种非常宽松的编码方式，任何一种编码方式得到的文本，用 latin1 进行解码，都不会发生解码失败
当然，解码得到的结果自然也就是理所当然的“乱码”。因此，如果你把 ''latin1'' 放到了 ''fileencodings'' 的第一位的话，打开任何中文文件都是乱码也就是理所当然的了。
以下是滇狐推荐的一个 ''fileencodings'' 设置：

#Code syntax="vim" <<---
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，往往在前面的编码中就被误判了。不过，正如前面所说的，中国用户没有太多机会接触这样的文件。
   如果编码被误判了，解码后的结果就无法被人类识别，于是我们就说，这个文件乱码了。此时，如果你知道这个文件的正确编码的话，可以把 ''fileencodings'' 改成只有这一种编码，阻止任何 fall-back 发生，然后重新打开这个文件。

* fencview

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

PS：本人通过按照文中顺序set fileencodings解决了VIM中的乱码，希望对大家有用，原文出自水木