标签 Unix 下的文章

Review Board中文支持

Review Board安装成功至今已半月有余,这期间我一直在试用它,虽欣喜于其提供的强大的功能,但还是有若干使用中的问题一直让我头痛不已,同时也阻碍了在部门推广该工具的进程。

首当其冲的就是对中文的支持问题。按照默认的步骤安装和配置后,
输入和保存英文均没有问题,但是一旦输入中文,保存后页面显示的都是乱码,甚至某些时候在保存中文数据时Review Board还提示错误。我的
Ubuntu的locale是"zh_CN.UTF-8",输入法输入后的中文内码应该是UTF-8。Review Board本身按理来说其内核也应该是
内置支持的UTF-8编码的,问题出在哪呢?答案是MySQL。

在命令行模式进入MySQL,敲入status命令:
Server characterset:    latin1
Db     characterset:    latin1
Client characterset:    latin1
Conn.  characterset:    latin1


们看到MySQL当前的四大字符集默认都是latin1,而创建reviewboard数据库时使用的语句又没有指定编码,这样一来
reviewboard数据库和其中表的编码应该都是按照MySQL默认字符集编码(即latin1)创建的,这应该就是中文乱码的根源吧。

修改MySQL默认字符集的方法很简单,先停止MySQL Server(sudo /etc/init.d/mysql
stop),之后打开/etc/mysql/my.cnf,分别在[client]和[mysqld]两个section下,增加一个key-value
pair: default-character-set = utf8,保存后退出。启动MySQL(sudo /etc/init.d/mysql
start),用status命令查看,你会看到所有characterset都已经变成了utf-8:
Server characterset:    utf8
Db     characterset:    utf8
Client characterset:    utf8
Conn.  characterset:    utf8

但是这个设置对已经创建完的reviewboard数据库和相关表不会起作用。由于对MySQL不甚熟悉,所以没有尝试去转数据库和表的编码,而是尝试重新创建一套库。这次在创建库的时候为了以防万一,我加上了显式的字符集编码要求。

mysql> create database reviewboard_utf8 default charset utf8 collate utf8_general_ci;
mysql>
grant all on reviewboard_utf8.* to 'reviewboard'@'localhost';  /*
前一个reviewboard_utf8是新建的数据库的名字,后一个reviewboard则是之前创建的访问数据库的用户名 */
Query OK, 0 rows affected (0.00 sec)
mysql> exit

数据库reviewboard_utf8默认是utf8编码,则系统默认其中创建的表也都是utf8编码。下面的问题就是如何将ReviewBoard与新库reviewboard_utf8连接起来的问题了。以下步骤供参考:
1、sudo vi /var/www/reviewboard/conf/settings_local.py,修改其中的DATABASE_NAME为reviewboard_utf8;
2、sudo rb-site upgrade /var/www/reviewboard,这个步骤中rb-site会在新库reviewboard_utf8中重新创建ReviewBoard需要的各个表
3、重启apache2 server,sudo /etc/init.d/apache2 restart


你再次打开ReviewBoard的首页面时,你会发现一切从头开始了。上面的"换库"操作中,rb-site只是创建了新表,表里并未有任何数据,这与
首次安装ReviewBoard时rb-site帮你创建了一个超级用户是不同的。所以我们这里需要手动做这件事。首先通过页面Register一个帐
户,比如就叫做admin吧。创建后用admin帐户登入,你会发现页面右上方的缺少了'Admin'这个链接选项,你无法通过'admin'用户对
ReviewBoard进行设置,也无法设置用户的权限。这里就需要在数据库中作些手脚了:

mysql> use reviewboard_utf8;
mysql> update auth_user set is_staff = 1 where username = 'admin';

这里is_staff的值决定该用户是否有权限对ReviewBoard站点进行设置。你再刷新一下页面,就会发现右上方出现了一个‘Admin'的链接了。做了上面的工作后,我们尝试在各个页面输入中文并保存,这次中文保存和显示都变得正常了。

在使用ReviewBoard过程中的第二个"问题"其实严格来说是我们自己的问题。我们已有的代码都是在Unix
GBK环境下开发的,所有源代码文件都是以GBK编码格式存储的。这样一来一旦你提交了这些源文件的diff,在ReviewBoard中'View
Diff'时看到的中文全是乱码,更严重的是某些时候ReviewBoard显示的代码差异的位置与真实代码修改的位置不符。比如我在第1000行
增加了一行: i += 1; 提交diff后,ReviewBoard显示的第1000行根本不是i +=
1这行代码,而是之前的若干行甚至是十几行、几十行。我怀疑是我们源代码文件的GBK编码导致ReviewBoard判断出现了错误。我尝试将源码重新以
UTF-8格式保存了一下,并重复上面的修改,提交diff,这回ReviewBoard的View
Diff则完全正确,源码文件中的中文注释显示的也很正常。

再有一点就是Review Board的Mail通知设置问题,公司采用SSL
加密mail,ReviewBoard仅支持TSL,在网上查了一下这两个协议应该是可以兼容的,但是设置后就是无法将mail发送出去。突然想起来公司
似乎还发布了一个数字证书 for mail
client端使用,也许可能是这个原因导致Review Board无法发送Mail,还待继续研究^_^。

也谈VIM字符集编码设置

安装完中文语言包支持后,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编码。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats