vim在windows下中文乱码解决方案

vim 在 windows 下中文乱码解决方案篇一：linux 下 vim 中文乱码的解决方法linux 下 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 放到最后面。 ? fermencoding Vim 所工作的终端(或者 Windows 的 Console 窗口)的字符编码方式。如果 vim 所在的 term 与 vim 编码相同，则无需设置。如其不然，你可以用 vim 的 termencoding 选项将自动转换成 term 的编码.这个选项对 GUI 模式 Vim(GVim)无效，而对 Console 模式的Vim 而言就是 Windows 控制台的代码页，并且通常我们不需要改变它。现在来看看 Vim 的多字符编码方式支持是如何工作的： 1. 启动 Vim，根据.vimrc 文件中设置的 encoding的值来设置 buffer、菜单文本、消息文 的字符编码方式。 2. 读取需要编辑的文件，根据 fileencodings 中列出的字符编码方式逐一探测该文件编码 方式。并设置 fileencoding 为探测到的，看起来是正确的字符编码方式。 3. 对比 fileencoding 和 encoding 的值，若不同则调用 iconv 将文件内容转换为 encoding 所描述的字符编码方式，并且把转换后的内容放到为此文件开辟的 buffer 里，此时我们就可以开始编辑这个文件了。注意，完成这一步动作需要调用外部的 ，你需要保证这个文件存在于$VIMRUNTIME 或者其他列在 PATH 环境变量中的目录里。 4. 编辑完成后保存文件时，再次对比 fileencoding和 encoding 的值。若不同，再次调用 iconv 将即将保存的 buffer 中的文本转换为fileencoding 所描述的字符编码方式，并保存到指定的文件中。同样，这需要调用由于 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 来将此文件存成不同的编码。 由于 Unicode 能够包含几乎所有的语言的字符，而且 Unicode 的 UTF-8 编码方式又是非常具有性价比的编码方式 (空间消耗比 UCS-2 小)，因此建议 encoding 的值设置为 utf-8。这么做的另一个理由是 encoding 设置为 utf-8 时，Vim 自动探测文件的编码方式会更准确 (或许这个理由才是主要的 ;) 。我们在中文 Windows 里编辑的文件，为了兼顾与其他软件的兼容性，文件编码还是设置为 GB2312/GBK 比较合适，因此 fileencoding 建议设置为 chinese (chinese 是个别名，在 Unix 里表示 gb2312，在 Windows 里表示 cp936，也就是 GBK 的代码页)。 比如我的/.vimrc 文件设置如下： set fileencodings=utf-8,ucs-bom,gb18030,gbk,gb2312,cp936 set termencoding=utf-8 set encoding=utf-8 所以我的 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_或者 zh_，你的 enc 要对应的设为 gb18030 或者 utf-8(或者 gbk 之类的)。最后再来说一下新建空文件的默认编码。看文档好像说会采用 fencs 里面的第一个编码作为新建文件的默认编码。但是这里有一个问题，就是 fencs 的顺序跟解码成功率有很大关系，根据我的经验 utf-8 在前比 gb18030 在前成功率要高一些，那么如果我新建文件默认想让它是gb18030 编码怎么 办？一个方法是每次新建文件后都:set fenc=gb18030 一下，不过我发现在 vimrc 里面设置fenc=gb18030 也能达到这个效果。 篇二：LINUX 本编辑器 VIM 显示 UTF-8 文档乱码的解决方法在 Linux 系统操作中，Vim 是文本编辑器，在使用Vim 的时候，居然显示 utf-8 文档乱码，遇到这种情况要如何解决呢?下面小编就给大家介绍下 Linux 如何解决 Vim 显示 utf-8 文档乱码问题，一起来看看吧。 1.相关基础知识介绍 在 Vim 中，有四个与编码有关的选项，它们是：fileencodings、fileencoding、encoding 和termencoding。在实际使用中，任何一个选项出现错误，都会导致出现乱码。因此，每一个 Vim 用户都应该明确这四个选项的含义。下面，我们详细介绍一下这四个选项的含义和作用。 (1)encoding encoding 是 Vim 内部使用的字符编码方式。当我们设置了 encoding 之后，Vim 内部所有的 buffer、寄存器、脚本中的字符串等，全都使用这个编码。Vim 在工作的时候，如果编码方式与它的内部编码不一致，它会先把编码转换成内部编码。如果工作用的编码中含有无法转换为内部编码的字符，在这些字符就会丢失。因此，在选择 Vim 的内部编码的时候，一定要使用一种表现能力足够强的编码，以免影响正常工作。 由于 encoding 选项涉及到 Vim 中所有字符的内部表示，因此只能在 Vim 启动的时候设置一次。在 Vim 工作过程中修改 encoding 会造成非常多的问题。用户手册上建议只在 .vimrc 中改变它的值，事实上似乎也只有在 .vimrc 中改变它的值才有意义。如果没有特别的理由，请始终将 encoding 设置为 utf-8。为了避免在非 UTF-8 的系统如 Windows 下，菜单和系统提示出现乱码，可同时做这几项设置： set encoding=utf-8 set langmenu=zh_ language message zh_ (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 来纠正乱码。 简而言之，fileencoding 是 Vim 中当前编辑的文件的字符编码方式，Vim 保存文件时也会将文件保存为这种字符编码方式 (不管是否新文件都如此)。 (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，往往在前面的编码中就被误判了。不过，正如前面所说的，中国用户没有太多机会接触这样的文件。 如果编码被误判了，解码后的结果就无法被人类识别，于是我们就说，这个文件乱码了