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

目前部门还没有采用Pair Programming那种时时刻刻都在review代码的工作方式，代码Review多采用走查方式，即代码写完后召开一个Code Review的Meeting，集中时间和经验丰富的人力对重点代码进行筛查，这种方式的代码Review有利，但也有弊。其弊端在于低效和覆盖面小。做一次走查需要N多人参与若干个小时，而在这段时间里不是每个参与者都能极其高效的参与到走查中的，实践证明只有少数几个人能真正在一次代码走查会议上起到关键的作用。另外走查一次能覆盖的代码范围又较小，一些看似不重要却很可能带来BUG的代码在走查会上很容易被遗漏。

Code Review工具对代码走查是一种很好的补充。目前比较流行的开源Code Review工具有Review Board、CodeStriker等。对于ReviewBoard，我关注已久。在其还在rc阶段我就曾经尝试安装过，不过无论是在Windows和Unix下都以失败告终。开源工具的安装的确有些让人头痛，一堆互相依赖的软件包，版本稍有差异就很可能导致安装运行失败。而且失败的原因还很难得知。

Review Board今年终于Release了，目前最新版是1.0.3，其官方推荐在Linux和Windows上安装。我选择了Ubuntu 9.04。Ubuntu的包管理工具apt最大的好处就是能自动帮你分析开源包的依赖关系并自动下载安装依赖包。恰巧在CSDN的一个博客上发现一篇'ReviewBoard on Ubuntu 9.04 Server'的安装步骤，我就按照文章中的步骤超级顺利的完成了Review Board的安装，这里我也将其步骤贴出来，并做一些简单注释（有些地方略有不同）：

我是在Ubuntu 9.04 Desktop上安装的，这个版本默认自带Gcc、Python等软件包。我们只需安装其他工具：(如果你是通过公司代理上外网，别忘了在你的Shell配置文件中设置http_proxy环境变量，格式是：export http_proxy=http://user:passwd@url:port)
1、安装easy_install
sudo apt-get install python-setuptools python-dev;

2、安装apache2和mod_python
sudo apt-get install apache2 libapache2-mod-python
sudo a2enmod python /* 修改apache2的配置，让python mod处于enable状态 */

3、安装mysql
sudo apt-get install mysql-server python-mysqldb libmemcache-dev
sudo easy_install http://gijsbert.org/downloads/cmemcache/cmemcache-0.95.tar.bz2

创建数据库、数据库用户for ReviewBoard(这块要注意数据库的字符集设置，默认是UTF-8，如果你要用其他中文字符编码标准，这里就需要显式指定，查查mysql的Manual吧)
mysql -u root -p  /* 用root用户登录 */
mysql> create database reviewboard;
Query OK, 1 row affected (0.00 sec)
mysql> create user 'reviewboard'@'localhost' identified by 'reviewboard';  /* 前一个reviewboard是访问数据库的用户名，后一个reviewboard是密码 */
Query OK, 0 rows affected (0.00 sec)
mysql> grant all on reviewboard.* to 'reviewboard'@'localhost';  /* 前一个reviewboard是数据库的名字，而后一个reviewboard则是访问数据库的用户名 */
Query OK, 0 rows affected (0.00 sec)
mysql> exit

4、安装subversion （目前大多数公司都用subversion）
sudo apt-get install patch subversion python-svn

5、安装reviewboard
sudo easy_install reviewboard

6、创建你的reviewboard站点
sudo rb-site install /var/www/reviewboard   /* 之后会有一系列类似安装向导的步骤，需要你做出选择，尽量选择默认值吧 */
    · Domain = localhost
    · Root Path = /
    · Media URL = media/
    · Database Type = mysql
    · Database Name = reviewboard
    · Database server = localhost
    · Database username = 'reviewboard'
    · Database password = 'reviewboard'
    · Cache Type = memcache
    · Memcache Server = memcached://localhost:11211/
    · Webserver = apache
    · Python loader = modpython

7、配置站点，启动Apache2
sudo chown -R www-data /var/www/reviewboard/htdocs/media/uploaded /* 让webserver拥有对uploaded目录的修改权限 */
sudo cp /var/www/reviewboard/conf/apache-modpython.conf /etc/apache2/sites-available/reviewboard
sudo a2dissite default
sudo a2ensite reviewboard
sudo /etc/init.d/apache2 restart

在你的浏览器里敲入：http://localhost:80，ReviewBoard的登录界面就会出现在你的面前。

顺利安装完ReviewBoard后，你可以到官网去看Manual，学习如何使用ReviewBoard。简单说ReviewBoard支持两种Review Code的模式，一种是在code没有commit之前提交diff/patch文件进行review，叫做pre-commit review，另外一种则是在code commit之后，由工具自动根据提交的版本号生成diff/patch文件，并形成一条新的Review Request，这种模式也叫post-commit review。

先说pre-commit review模式。生成pre-commit review request有两种方法，第一种就是通过页面手工提交patch/diff文件的方法：首先通过界面设置好你的svn repository，比如：svn://10.1.1.23:3344；然后在你的DashBoard中“New Review Request"，有三个字段需要你填写：
Repository:  /* 选择你刚才配置的repository的id */   
Base Diff Path: /* 如果你checkout出来的proj的svn url是svn://10.1.1.23:3344/trunk/testproj，那么这个字段填的就是/trunk/testproj */
Diff: /* 你生成的diff文件的路径，在Windows上我用TortoiseSVN的creatpatch工具直接生成某个源文件的diff格式文件 */

填好后，提交，这时你就会看到一个处于draft状态的Request，继续编辑它，指定Reviewer，然后Publish这个Request，这样你指定的Reviewer就能看到这个Request了。这块如果你设置了Email通知，Publish过程会有一定延迟，特别是如果你的Email设置出错了，那Publish将一直处于ing状态，你刷新一下页面后，实际上你的Request已经publish结束了。

另外一种提交pre-commit review request的方法是通过一个名为'Post-Review'的python脚本实现的。这个脚本在RBTools工具包中，在使用之前先执行：'sudo easy_install -U RBTools'安装这一脚本。

Post-Review需要知道两类信息，一个是ReviewBoard Server的信息, 一个是你的svn repository的信息，第一种信息我们可以通过编辑~/.reviewboardrc，添加一行REVIEWBOARD_URL="http://localhost:80"。至于svn repository的信息，post-review脚本可自动从你本地checkout出的代码working copy中携带的repository信息中获得，前提你要进入到该working copy所在的目录下去执行post-review。比如：你将svn://10.1.1.23:3344/trunk/testproj checkout到~/proj/testproj下面，那么你就应该先cd ~/proj/testproj后再执行post-review，post-review工具在默认情况下会将当前本地代码uncommitted的changes形成一个review request并提交到reviewboard server。你也可以在post-review后面加上文件名字来指定将特定的文件的changes而不是当前项目目录下所有的uncommitted changes。

下面是我配置和执行Post-review出现的一些问题和解决方法:

首次在testproj下执行'sudo post-review'，出现如下打印日志：

Traceback (most recent call last):
  File "/usr/local/bin/post-review", line 5, in
    pkg_resources.run_script('RBTools==0.2beta1', 'post-review')
  File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 448, in run_script
    self.require(requires)[0].run_script(script_name, ns)
  File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 1166, in run_script
    execfile(script_filename, namespace, namespace)
  File "/usr/local/lib/python2.6/dist-packages/RBTools-0.2beta1-py2.6.egg/EGG-INFO/scripts/post-review", line 2314, in
    main(sys.argv[1:])
  File "/usr/local/lib/python2.6/dist-packages/RBTools-0.2beta1-py2.6.egg/EGG-INFO/scripts/post-review", line 2292, in main
    server.login()
  File "/usr/local/lib/python2.6/dist-packages/RBTools-0.2beta1-py2.6.egg/EGG-INFO/scripts/post-review", line 308, in login
    'password': password,
  File "/usr/local/lib/python2.6/dist-packages/RBTools-0.2beta1-py2.6.egg/EGG-INFO/scripts/post-review", line 570, in api_post
    return self.process_json(self.http_post(path, fields, files))
  File "/usr/local/lib/python2.6/dist-packages/RBTools-0.2beta1-py2.6.egg/EGG-INFO/scripts/post-review", line 481, in process_json
    rsp = simplejson.loads(data)
  File "/usr/local/lib/python2.6/dist-packages/simplejson-2.0.9-py2.6-linux-i686.egg/simplejson/__init__.py", line 307, in loads
    return _default_decoder.decode(s)
  File "/usr/local/lib/python2.6/dist-packages/simplejson-2.0.9-py2.6-linux-i686.egg/simplejson/decoder.py", line 335, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/local/lib/python2.6/dist-packages/simplejson-2.0.9-py2.6-linux-i686.egg/simplejson/decoder.py", line 353, in raw_decode
    raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded

这种错误信息弄得我一头雾水，在Google上找了半天，也没有什么好的办法。在ReviewBoard的issue archive里有人遇到了和我一样的问题，而ReviewBoard的维护人员建议：修改/usr/local/lib/python2.6/dist-packages/RBTools-0.2beta1-py2.6.egg/EGG-INFO/scripts/post-review中的代码(在/usr/local/lib/python2.6/dist-packages下你可能会发现RBTools-0.2beta1-py2.6.egg是个文件而不是目录，不要紧，.egg文件就是一个zip文件，可将其用unzip命令解压后再放到一个名为RBTools-0.2beta1-py2.6.egg的目录中即可，解压后原始RBTools-0.2beta1-py2.6.egg做好更名和备份)，在process_json method开始处加上一行代码：debug(data)。然后在执行post-review时加上–debug选项，观察http post的response数据。

按照网上的建议做了修改：执行sudo post-review –debug，果然有效果，能看到http post后返回的应答内容，居然是公司代理服务器websense的拦截应答。

哇，原来如此，我的.bashrc配置了http_proxy，似乎post-review是向代理发出的http post请求，结果被代理拦截掉了。注释掉.bashrc中的http_proxy变量后，再重复执行post-review命令，这下一切ok了，一个New Review Request成功生成。

第二种模式post-committed review同样是通过post-review工具完成的。命令格式：post-review –revision-range=STARTREV[:STOPREV]。脚本会自动diff两个revision之间的差别并形成review request提交到reviewboard server的。

关于post-review的更多用法，这里不细说了，可阅读官方的Manual。Review Board功能还是很强大的，Review时你可以针对每行代码写Comments，这种Review Code的方式给你足够时间去思考，只要你认真对待，就不会出现盲区、死角，所以新提交的代码就都能被Review到。