VIM字符集编码设置
(2012-09-27 21:29:45)
标签:
it
分类: Linux
安装完中文语言包支持后,Ubuntu的默认locale是zh_CN.UTF-8(即简体中文语言环境,字符集内码UTF-8)。这与我们日常开发环境中Unix设定的环境有所区别,我们日常使用的环境一般为zh_CN.GBK或zh。我们的源代码文件的字符编码也都是GBK的编码,直接在Ubuntu下用默认设置的VIM打开后,中文的注释会显示乱码。如果你直接编辑这个文件并提交,那么其他在Unix下开发的同事Checkout这份源码后打开也将显示乱码(你新增的中文内容会是乱码)。
解决这个问题至少有两种方法:一种是为Ubuntu新增加一个zh_CN.GBK的locale的支持,内码使用GBK;另外一种就是通过设置VIM,在不变换Ubuntu所支持的locale(内码依旧是UTF-8)的情况下支持对GBK内码文件的读写。
第一种方法简单说一下,总共分四步走:
第一步:sudo vi /var/lib/locales/supported.d/local,该文件原始状态只有一行记录:zh_CN.UTF-8 UTF-8;为了增加zh_CN.GBK的locale,我们在这个文件尾添加一行:zh_CN.GBK GBK,保存退出。
第二步:执行:sudo locale-gen,生成zh_CN.GBK对应的locale
第三步:编辑:/etc/environment,在文件尾添加如下内容:
LANGUAGE="zh_CN:zh:en_US:en"
LANG=zh_CN.GBK
LC_CTYLE=zh_CN.GBK
LC_ALL="zh_CN.GBK"
第四步:重启Ubuntu系统。重启后用VIM再打开以前GBK编码的源代码文件,就不再会有乱码了,而且默认情况下编辑文件采用的依然是GBK编码。不会影响他人在其他平台上读写文件。
第二种方法是本文重点要谈的内容。即在zh_CN.UTF-8的环境下保证正确读写GBK编码的文件。问题主要集中在:如何读出并正确显示已有的特定字符编码的文件和如何按照特定字符编码写新文件。
这里有两个数据文件:data1和data2,内容都是“祝祖国六十年生日快乐”,但是data1采用UTF-8编码,而data2采用GBK编码,可以用od -x查看文件实际存储数据是不同的。
od -x data1
0000000 a5e7 e79d 96a5 9be5 e5bd ad85 8de5 e581
0000020 b4b9 94e7 e69f a597 bfe5 e4ab 90b9 000a
0000037
od -x data2
0000000 a3d7 e6d7 fab9 f9c1 aeca eac4 fac9 d5c8
0000020 ecbf d6c0 000a
0000025
在终端UTF-8编码,LC_ALL=zh_CN.UTF-8,VIM默认配置的前提下,尝试用VIM分别打开data1和data2,发现data1正常显示,data2显示乱码;为什么呢?这里VIM当打开一个已存在的文件时会有一系列的处理过程:
用VIM打开一个已存在的文件时,VIM首先要查看fileencodings(或fencs)这个option。fileencodings是一 系列字符编码格式的列表,例如:set fileencodings=GBK,UTF-8,gb18030,ucs-bom,cp936。这个option仅在打开一个已存在的文件时起作用。如 果你没有在.vimrc中显式set这个option,那fileencodings的默认值是'ucs-bom,UTF- 8,default,latin1',其中default的值是用户环境的默认编码格式。
当你打开一个已存在的文件时,VIM会用fileencodings值列表中的编码格式逐一去探测该文件的编码方式,直到两者匹配一致。探测成功 后,VIM会用匹配到的编码格式去设置此文件session的fileencoding选项值。fileencoding选项指示该session的 VIM BUFFER里的数据写入文件或从文件读出时文件中的数据的编码格式。同样该session中VIM BUFFER中数据的编码格式则由另外一个选项指示,那就是encoding option。这里有多个"encoding-like"字样的options,极易混淆。但实际上真正对VIM文件操作时数据显示和保存起作用的只有两 个选项:fileencoding和encoding。而fileencodings只是在打开已有文件时用来探测并设置fileencoding字段的 一个外围option。VIM的编码转换也是围绕fileencoding和encoding这两个options展开的。无论读写文件,当某个VIM session中fileencoding和encoding的值不一致时,VIM就会自动做编码转换。例如:当读取一个文件时,session的 fileencoding为UTF-8,而encoding为GBK时,VIM将文件中的数据读出来后会自动做一个UTF-8到GBK的转换,并将转换后 的数据存储在VIM针对该session的BUFFER里;同样当创建一个新文件时,如果该session的vim BUFFER中数据的编码格式(encoding指示)和fileencoding指示的文件编码格式不一致时,save file时,VIM会自动将BUFFER中的数据按照fileencoding指示的编码格式进行一次转换后再存入新文件中。
每个option都有三种状态:显式设置、空(encoding除外)和默认值。其中显式设置是指在.vimrc或在session中利用set指 令对选项进行赋值设置;空:比较特殊,表示该选项的值为empty;默认值则是未通过set在.vimrc或在session对选项进行赋值的状态。
fileencodings为空时,即在.vimrc中set fileencodings="";VIM将无法进行文件编码探测,将直接根据fileenoding和encoding的值来确定文件编码和 BUFFER编码以及是否需要自动做编码转换;当fileencodings不为空,但探测文件编码均告失败时,VIM会将该session的 fileencoding置为空,之后将根据encoding的值来设置文件编码和VIM BUFFER编码。
fileencoding的默认值就是空(""),打开已有文件时通过fileencodings来设置其值,新建文件时如果fileencoding为默认值或空,那么encoding将决定一切。其显式设置的值只有在新建文件的session中才会其作用。
encoding是核心,是VIM session中BUFFER数据的编码,也可以理解为VIM核心的内码;VIM会根据它与fileencoding、termencoding(term的编码格式)的不同由VIM做自动转码。encoding默认值为$LANG。
下面用一些例子来说明一下VIM的行为模式,测试环境Ubuntu 9.04, LANG=zh_CN.UTF-8, data1和data2如上所述。
(1) 三个Option均采用默认值,没有在.vimrc下显式设置
此 时在vim session未建立之前,fileencodings的默认值为“ucs-bom,UTF- 8,default,latin1”,fileencoding为空,encoding=UTF-8($LANG).打开data1,VIM通过 fileencodings做探测,顺利匹配到UTF-8的编码格式,将fileencoding设置为UTF-8,此时encoding也为UTF- 8,两者一致,VIM不做编码转换,屏幕正确显示“祝祖国六十年生日快乐”。打开data2,VIM通过fileencodings做探测,未能匹配到 GBK的编码,将fileencoding置为空,encoding发挥作用,VIM不做任何编码转换,将GBK编码的数据以UTF-8格式显示,屏幕显 示乱码。
(2) fileencodings显式被设置为"UTF-8,GBK",其他option采用默认值
此时在vim session未建立之前,fileencodings的值为“UTF-8,GBK”,fileencoding为空,encoding=UTF- 8($LANG).打开data1,VIM通过fileencodings做探测,顺利匹配到UTF-8的编码格式,将fileencoding设置为 UTF-8,此时encoding也为UTF-8,两者一致,VIM不做编码转换,屏幕正确显示“祝祖国六十年生日快乐”。打开data2,VIM通过 fileencodings做探测,顺利匹配到GBK的编码,将fileencoding置为GBK,此时encoding为UTF-8,两者不一 致,VIM做自动编码转换,将GBK编码的数据转换为UTF-8格式后放入BUFFER并显示,屏幕正确显示“祝祖国六十年生日快乐”,VIM在状态条提 示“已转换”。
(3) fileencoding显式设置为"GBK",encoding显式设置为“UTF-8”或采用默认值
新建一个文件data3, 输入:“祝祖国六十年生日快乐”,保存,此时fileencoding和encoding值不一致,VIM做自动编码转换,将BUFFER中的UTF-8 编码的数据转换为GBK编码后存储到文件中,VIM状态栏提示“已转换”。退出VIM。od -x data3,输出的是GBK编码。
转载自:
http://bigwhite.blogbus.com/logs/47259473.html

发表回复