vim乱码的一些问题

从很久之前的工作日记中摘下来的,忘了又是从哪里偷过来的了

没有写出转自哪里.原作者请见谅

VIM编码规则及解决中文输出乱码详解

1 四个环境变量 (最好设置在.vimrc中):
    enc(encoding)                    vim内部所用编码方式.  内部数据表示,缓冲, 临时文档等所用编码方式.  最好设置为UTF-8, 可以无损转换为其他任何编码方式.
    fenc(fileencoding)              vim保存文件时所用编码方式
    fencs(fileencodings)          vim打开文件时, 探测编码所用编码方式集, 逐一探测.
    tenc(terminalencoding)     vim输出到终端的编码方式, 只有是终端显示支持的编码方式集才  能正常显示.
 
2 四个环境变量默认值:
     enc—-与系统当前locale相同，所以编辑文件的时候要考虑当前locale，否则要设置的东西就比较多了。
     fenc—-vim打开文件时根据fencs设置自动辨认其编码，辨认的结果就是fileencoding的值。为空则保存文件时采用encoding的编码，如果没有修改encoding，那值就是系统当前locale了。
     fencs--与系统当前locale相同.
     tenc—-默认空值，也就是输出到终端不进行编码转换, 默认值为encoding。


 3 四个环境变量设置规则:
    set   enc=utf-8   内部编码固定为utf-8最佳.
    set fencs=utf-8,gb2312,gbk,cp936,gb18030   打开文件识别顺序, 优先识别utf-8和中文.
    fenc 最好不用设置, 就根据打开文件的编码格式保存为宜, 如果有特殊必要设置为 gb2312
    set tenc=gb2312   根据自己终端类型字符集设置, 我的是支持中文的终端.


4 相关系统变量及说明
      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。


     4 用vim探测文档编码
      1 编辑.vimrc, 设置fencs环境变量,  对于可能的编码方式设置在 fencs中,  vimrc取消fenc的任何设置
      如   set fencs=utf-8,gb2312,gbk,cp936,gb18030  
       2 vim打开文档, 如果正常打开, vim输出界面左下角没显示[converted], 或者即使有显示[converted], 文档也能正常打开,            则执行 set fenc命令查看最终文档以什么编码格式打开
       如  命令:  set fenc 
             结果: fileencoding=euc-cn




1.2 中文支持
Vim 支持世界上的主要语言，当然也包括中文。如果你用 Vim 编辑中文，而中文不能正确显示，那有两种可能性：一是使用的 Vim 不完整，不含多字节语言支持（multi_byte 特性）；二是某个配置出了问题。
说到多语言支持，最基本的概念有两个：一是文件的语言编码，而是环境的内部编码。在较老的操作系统中，不管 Linux 还是 Windows，这两个编码都是一样的，也就意味着，一次只能处理一种编码的文件：要么只能处理西文编码（Latin1，即 ISO-8859-1 [5]），要么只能处理中文编码（GB2312 [2]）。而在新的操作系统中，这两者可以是不一样的。在 Linux 上，常见的情况是环境的内部编码使用 UTF-8 [6]，而 UTF-8 可以同任何一种语言编码作无损转换，这就保证了系统的多语言处理能力。Vim 这方面秉承了 Unix/Linux 的传统，在内部编码使 UTF-8 的时候，可以同时处理不同意语言编码的文件。
以下列出了和语言编码的相关的设置：
环境变量 LANG（使用的语言）；
环境变量 LC_CTYPE（使用的内部编码）；
Vim 选项 encoding（Vim 的内部编码）；
Vim 选项 termencoding（Vim 在与屏幕/键盘交互时使用的编码）；
Vim 选项 fileencoding（Vim 当前编辑的文件在存储时的编码）；
Vim 选项 fileencodings（Vim 打开文件时的尝试使用的编码）；
Vim 选项 ambiwidth（对“不明宽度”字符的处理方式；Vim 6.1.455 后引入）。
如果你的环境只需要处理简体中文的话，那么，最简单的方式就是所有的设定全部使用简体中文。只需要：设定 LANG=zh_CN.GB2312，不设定 LC_CTYPE（默认跟 LANG 一样），不设定与编码相关的 Vim 选项（默认由 LANG 和 LC_CTYPE 决定），也无需设定 Vim 选项 ambiwidth。也就是说，我们把语言设定为中国（CN）使用的中文（zh），编码为 GB2312（注意：Vim 内部并不识别国标 GB18030 [3]，所以此处只能设 GB2312；参看下面关于 UTF-8 的讨论）。
不过，如果按照目前 Linux 下的惯例，内部编码一律使用 UTF-8 的话，会有一些额外的好处，其中之一就是在这种情况下 Vim 支持同时编辑多种不同编码的文件，如简体中文和繁体中文（参见图 2）；另外，此时 Vim 也可以通过编码转换支持 GBK [4] 和 GB18030了。这样，众多关于语言编码的 Vim 选项就有了用武之地了。下面进一步说明一下这些选项和推荐设定（如果适用的话）：ssss


ncoding=utf-8：不管文件的编码如何，不管如何显示和输入，Vim 内部使用的编码是 UTF-8；这是国际化支持的基础。
termencoding：取决于实际的终端或 X Window 的设定。举例来说，如果选择语言简体中文登录到 X Window，或者正在使用 CXTERM [10] 的话，那么该选项应被设为 GB2312；如果使用缺省的语言（LANG=en_US.UTF-8）登录到 X Window，或者使用 PuTTY [11] 远程访问 Linux 机器、并且设定里的字符编码（配置中 Window-Translation）设为 UTF-8 的话，该选项就应该设为 utf-8。从 Windows 下使用 PuTTY 远程连接 Linux 的请特别注意，测试表明，仅在使用 UTF-8 的情况下，PuTTY 才能可靠地支持中文的显示和输入（显示字体必须设成中文字体）。
fileencoding：文件载入时，该选项被置为 Vim 认定的文件编码，因此，存储时文件的编码不会改变。此处和下面 fileencodings 可使用的编码为 libiconv 支持的所有几百种编码（如果编译时包含了 iconv 特性的话），与中文相关的有 gb2312、gbk、gb18030、hz-gb-2312、iso-2022-cn、big5、cp936、cp950 等。如果创建新文件，你又不希望使用 UTF-8 作为文件编码时，那么，你可能需要手工设定该选项，如“:set fileencoding=gb2312”。需要注意的一点是，使用“set”来设定该选项的话会改变以后新建文件的缺省编码，而使用“setlocal”的话则只影响当前文件（参考“:help setlocal”）。
fileencodings=ucs-bom,utf-8,chinese：Vim 会首先判断文件的开头是否是一个 Unicode [7] 的 BOM（byte order mark）字符 [8]，是的话则把文件的其余内容解释成相应的 Unicode 序列；否的话再试图把文件内容解释成 UTF-8 的序列；再失败的话，则把文件解释为简体中文（chinese 是一个跨平台的简体中文字符集的别名，Linux 下相当于 gb2312 和 euc-cn；此处也可以根据需要以 gb2312、gbk 或 gb18030 等编码替代）。需要注意的是，该顺序不能颠倒，并且在后面再添加其它编码如 big5、latin1 也是没有意义的，因为 Vim 不能识别 8 比特编码中的错误，因此这些编码后列的编码永远不会被用到。
ambiwidth=double：把所有的“不明宽度”字符 [9]——指的是在 Unicode 字符集中某些同时在东西方语言中使用的字符，如省略号、破折号、书名号和全角引号，在西方文字中通常字符宽度等同于普通 ASCII 字符，而在东方文字中通常字符宽度等同于两倍的普通 ASCII 字符，因而其宽度“不明”——的宽度置为双倍字符宽度（中文字符宽度）。此数值只在 encoding 设为 utf-8 或某一 Unicode 编码时才有效。需要额外注意的是，如果你通过终端使用 Vim 的话，需要令终端也将这些字符显示为双宽度。比如，XTERM [12] 的情况下应该使用选项“-cjk”，即使用命令“uxterm -cjk”来启动使用双宽度显示这些字符的 Unicode X 终端；使用 PuTTY 远程连接的话则应在配置的 Window-Translation 中选中“Treat CJK ambiguous characters as wide”（参见图 3）。






折腾了老半天,我才发现,
有几点要注意的,
因为我之前编译vim时没有 --enable-multibyte


所以我
./configure --enable-multibyte --enable-cscope --with-features=huge
make
sudo make install


之后,要用
which vi
which vim


再手动把一些连接给替换掉....
当然,  用以打开的终端也需要把字符集设成 GB18080才行,这样我还是不用装中文字体.....




当然啦,.vimrc也要修改一下

修改你的.vimrc文件，让其支持 gb2312就行，会自动识别的。 

结合实际的时候, 发现

 set   enc=utf-8   "内部编码固定为utf-8最佳.

会在win7中导致乱码...

对于win7中的unicode打开乱码的问题,可以在

set fencs 加入

ucs-bom

就可以了