Tony Bai

一个Solaris x86平台64位编译的问题

Thu, 05 Nov 2009 13:20:23 +0800

上午在做一个Solaris 10 on x86代码移植测试过程中，发现一个Gcc编译问题，这里记录下来以作备忘。

我们的代码在一台安装了Solaris 10 for x86平台的机器A上进行64位编译(gcc -m64)时报错，错误信息如下：
"xx.c:1: sorry, unimplemented: 64-bit mode not compiled in"。

而奇怪的是在另外一台同为Solaris 10 for x86的机器B（与上面的机器A硬件配置相同）上则顺利编译通过。最初猜测可能是因为系统设置或环境变量设置不同导致的问题，经过对比检查后发现以上设置都一致，最后将问题定位在Gcc编译器版本上了。

机器A上使用的是Gcc 3.4.6 for Solaris 10 on x86版本；而可以通过编译的那台机器B上使用的是Gcc 3.4.3 (csl-sol210-3_4-branch+sol_rpath) for Solaris 10 x86版本。尝试在机器A上使用Gcc 3.4.3进行编译，错误未再出现，看来的确是Gcc编译器版本问题。

遂到Sunfreeware网站上一查究竟。在Gcc 3.4.6 for Solaris 10 on x86的软件说明中，有这样一段话：
“If you need to do 64-bit compiles, you should use the gcc-3.4.3 that comes with Solaris 10 in /usr/sfw/bin.”

而Gcc 3.4.6 for Solaris 10 on sparc的版本说明中，则明确表示：“When needed and the source code supports it, this C compiler can create 64-bit executables via the -m64 flag as well as the usual 32-bit ones.”

注：以上提到的Solaris软件均来自于Sunfreeware站点。

随机文章：

使用iconv做内码转换 2009-10-31

也谈VIM字符集编码设置 2009-09-28

Solaris 10安装二三事 2009-09-10

Bash文件描述符重定向符号的另类理解 2009-09-08

Cmockery支持mock输出参数 2009-08-26

博客大巴，你的个人传媒早班车

收藏到：Del.icio.us

使用iconv做内码转换

Sat, 31 Oct 2009 15:08:45 +0800

前不久某南方省份的客户反馈说我们的产品对某些生僻字(如“赟”)的转码支持的不好，终端收到后无法显示这个字。

经分析，发现类似“赟”这样的字在GB2312编码标准中并未收录，要想支持这样的生僻字的内码转换需要产品支持目前最新的中文编码标准GB18030。而我们的产品在诞生到现在就一直只支持GB2312，这就是导致这一问题的直接原因。

产品以前的代码库中内码转换的接口都是自己实现的，仅支持GB2312和UCS-2(即UNICODE16)之间的内码互转，如果要扩展就要更换码表。与其耗费力气找码表还不如挖掘一下开源世界最常用的内码转换工具iconv呢。iconv既提供了命令行转换工具(iconv)，也提供一系列函数库接口供开发人员在代码里调用。很多知名的开源软件包(如vim等)都依赖iconv包。而iconv也几乎遍布所有unix和linux平台，iconv提供的转码支持也基本涵盖了世界范围内绝大多数主流字符集，其中支持的中文字符集就包括GBK, CP936, GB18030, BIG5等主流内码标准。

iconv的函数接口很简单，我迫不及待的想写一个例子测试一下了（不料，就在写下的这个简单的例子里我犯下了一个低级错误^_^)。

下面例子代码目的是将"赟"从UTF-8编码转换为GB18030编码（环境：GCC 3.4.6 on Solaris 10 for X86）。
#include <iconv.h>

int main() {
        char    in[8];
        char    out[255];

        memset(in, 0, sizeof(in));
        memset(out, 0, sizeof(out));

        in[0]   = 0xe8; /* "赟"的UTF-8编码: E8B59F */
        in[1]   = 0xb5;
        in[2]   = 0x9f;

        size_t inlen = strlen(in);
        size_t outlen = sizeof(out);

        iconv_t cd;
        cd = iconv_open("gb18030","utf-8"); /* from utf-8->gb18030 */
        if (cd < 0) {
                printf("iconv_open failed!\n");
                return -1;
        }

        if (iconv(cd, &in, &inlen, &out, &outlen) < 0) {
                printf("iconv failed!\n");
                iconv_close(cd);
                return -1;
        }

    printf("out = %s\n", out);
    iconv_close(cd);
    return 0;
}
以上代码通过iconv_open获取一个转换描述符，这个描述符包含了转换信息（如从UTF-8转换到GB18030），然后调用iconv接口对传入的字符串进行转换，转换后的结果存储在OUT缓冲区中。

编译执行执行上面代码：
gcc -g testiconv.c -liconv
testiconv.c: In function `main':
testiconv.c:26: warning: passing arg 2 of `libiconv' from incompatible pointer type
testiconv.c:26: warning: passing arg 4 of `libiconv' from incompatible pointer type

./a.out
段错误 (core dumped)

为什么会dump core呢？回顾一下编译时的Warning信息，再对比一下iconv接口的原型：
size_t iconv (iconv_t cd, const char* * inbuf, size_t * inbytesleft,
              char* * outbuf, size_t * outbytesleft);
似乎没什么问题，但又仔细分析了一下Core的栈上信息，发现了一个低级失误：
问题就出在iconv的第二个和第四个参数上，我在栈上分配了数据in和out，并简单的将&in和&out作为参数传给了iconv。iconv要得是char **类型的参数。看起来&in和&out类型也是char **，但实则不然，这也是C语言的一个陷阱。以in为例，in本身就是栈上那个数组的首地址，&in的含义与in相同，同样是数组的首地址，所以&in = in，也就是说实际上传给iconv的是一个char*而不是char**，iconv在内部对一个char*执行*操作，并以为这是一个地址，显然会导致内存错误。

修改一下代码：
    char    *p_in    = in;
    char    *p_out    = out;
    if (iconv(cd, &p_in, &inlen, &p_out, &outlen) < 0) {
                printf("iconv failed!\n");
                iconv_close(cd);
                return -1;
    }
p_in变量在栈上分配，其本身的地址是&p_in，其值指向in这个数组的首地址，这样将&p_in传给iconv就万无一失了。
再编译执行，我们就得到了正确结果：
out = 赟

unix上有很多iconv实现，由于版本不同可能支持的字符集范围不同，所以为了保证代码行为一致，你可下载最新iconv包，并生成静态库(./configure --enable-static=yes)，并让你的代码链接静态库。

午饭时从电视中得知：中国航天之父钱学森今天上午在北京离世。钱老可谓是中国科学家的楷模，对钱老的离世感到甚为惋惜。这里也道一句：“钱老，一路走好！”

随机文章：

一个Solaris x86平台64位编译的问题 2009-11-05

也谈VIM字符集编码设置 2009-09-28

Solaris 10安装二三事 2009-09-10

Bash文件描述符重定向符号的另类理解 2009-09-08

Cmockery支持mock输出参数 2009-08-26

博客大巴，你的个人传媒早班车

收藏到：Del.icio.us

说书单2009.10.28

Wed, 28 Oct 2009 23:03:22 +0800

十月以来，自已通过网购或换购还真收了不少书，这里说说：

国内关于伟大领袖毛主席的传记实在让我无法提起兴致，但哈佛大学教授Ross Terrill的《毛泽东传》我早在其出版时就关注过，它可以让我弄清楚毛主席在一个西方人眼中的事实形象。昨天偶然发现该书在卓越网的卖价居然比其他网店（诸如当当网）便宜近十元，这个“便宜”怎能不捡^_^，遂在昨天下了订单。今天再一看卓越的定价居然涨到了35.8元，涨了仅5元，不过还是比其他网店要便宜。

说到传记，就不能不提到最近卖的很火一本传记书-前Google中国区负责人李开复的新书《世界因你不同李开复自传》。以前读过李开复的《做最好的自己》，感觉很不错，所以这次也这本新书列入了购物车中。同时我也的确想通过李开复的书或多或少的去了解一下像微软、Google这样的大公司的一些运作“内幕"^_^。

今天在中国移动积分商场看到一套丛书套装《世界艺术瑰宝》很是动心，遂让同事先帮忙用2170积分换购下来（我的积分还差100多）。丛书共六册，均为全彩印刷，主要留作日后陶冶艺术情操、提升品位、家庭教育和旅游规划之用。

“灵修”二字我也是第一次遇到，十月初网购的一本名为《新世界灵性的觉醒》就是此类书籍。书的作者在西方很有名，同时也是一个怪人。书还没开始看（还未做好心理准备^_^），初略翻阅了一下，觉得有些难度，或多或少的会折腾一下你的大脑神经的。

《怪诞心理学》和《思维风暴》与“新世界”一书一起到手，前者是为了尝试了解一些大众心理学的内容，花了两个等晚点航班的时间段就翻阅完了；后者则纯粹为了让自己的大脑保持活跃的。

现在已是深秋近初冬季节，在暖气未供给之前，北方的屋内也都是冷冷的、湿湿的。捂在暖暖的被窝儿中看书那是何等的快哉。捧在我手中的这本《世界是平的》自从07年从书刊批发市场买回后只看了一半，现在正以每天一章的速度阅读着，估计这周就能欣赏完这部三年前的名作了。如果再不快看，里面的一些观点可能就要过时了^_^。

随机文章：

网上淘二手书 2009-04-21

在卓越网买书 2008-03-04

第一次网上买书 2007-11-15

读'代码修改艺术'，可观其大略 2007-11-09

'Write Great Code'书中的一处错误 2006-12-26

博客大巴，你的个人传媒早班车

收藏到：Del.icio.us

榕城走一回

Sat, 24 Oct 2009 13:58:11 +0800

应客户之邀，本周一到福州做业务需求调研，周三返回沈阳。

以前从未去过榕城福州，领导下达调研任务时已是上周五。时间比较仓促，而且要求周一上午务必到达福州，因为客户方领导都较忙，也只有在周一才有机会见到客户领导。

安抚了LP后，周日下午我背上本子，带了几件随身衣物，就匆忙赶往机场。从沈阳出发到福州的航班都是有经停的，而且多是厦航、川航这样的小航空公司。为了能多陪LP一会儿，我选择了起飞较晚的航班，计划晚上22点到达福州。但是人算不如天算，航班晚点，周一凌晨1点才抵达福州长乐机场。在机场等飞机那是何等的煎熬，还好我随身带了一本《怪诞心理学》可以帮我打发时间。

此时的北方已进入深秋，夜晚温度近零度，但榕城却仍旧是一片温暖和煦，下飞机时机场地面温度依然有20多摄氏度。福州长乐机场距离市区较远，估计是我到过的城市里机场离市区最远的了。乘机场大巴用了将近一个多小时才到达终点（阿波罗大酒店）。打车到达闽江饭店Checkin时已是凌晨2点半了。走进房间后竟全无睡意，但想到白天还要到客户那开会，还是强迫自己入睡。

早上七点醒来，头有些痛，显然这短暂的睡眠还不能缓解我身体的疲劳。酒店提供早餐，早餐品种还算丰富，就是味道清淡了些，让我这个习惯了浓重口味的北方人有些不适^_^。和当地办事处的同事约好时间，上午做内部讨论，下午再去见客户。上午9点走出酒店，第一次清晰的看到榕城的闹市景象。和大多数省会城市一样，高楼大厦，繁忙喧嚣。瞥了一眼马路上的情况，看得出福州堵车也很严重^_^。既然福州号称榕城，那自然少不了榕树，我是不认识榕树的，但是猜也猜得出，大街两旁矗立的那些枝叶繁茂、树冠巨大的树肯定就是榕树了。

和北方相比，这里简直就是夏天，大街上男女老幼均是半袖裙子打扮，我也“入乡随俗”，脱去了厚重的外套，穿上了半袖衬衫。公司的办事处离酒店很近，走路也就5分钟，工作内容这里就不多说了。中午办事处领导在港式茶餐厅请客，这也算是入榕城后的第一顿饭了，遗憾的是少了些许本地菜的特色。席间听同事谈福州的房价，才知道福州房价要比沈阳高出一倍多，均价估计要上万，这在国内省会级城市里也算是排在前列的了。

下午见客户，途中路过闽江，江不宽，但却不失忙碌，闽江两旁码头林立，闽江中央船只往复。很想驻足欣赏，但无奈有公务在身^_^。

从客户那开完会出来已是华灯初上。同事带我去了一家当地特色的饭店吃了一顿牛排，这个牛排不是西餐中的那种烤牛肉，而是原生的牛排骨，一碗鲜美的汤中泡着两块包裹着厚实牛肉的牛排骨。以前从未这么吃过牛肉，这还是第一次，据同事介绍这家店里的牛肉是正宗的当地“达道牛肉”，肉质的确很嫩。

我有一个喜好，就是每到一地必到当地的博物馆，但是这次估计是真的没有时间了，因为周二有很多资料要准备，索性就在酒店里闷了一天。晚上出来随意到了一家小店吃了一口，然后在酒店附近转了转。福州的街道环境卫生一般，马路上街道旁可见随意丢弃的废物，很多国内城市（包括沈阳）也是这个样子。福州的电动自行车很多，起码比沈阳要多，每到饭点儿，在各家饭店门口你会看到一排排的电动车。福州的物价倒是不低，在超市里逛了逛发现无论是菜价还是水果价格都不在沈阳之下，甚至一些南方水果的价格也不低。

周三上午到客户现场与客户再次开会，就周一会上的一些问题和需求做应答。下午一点坐大巴赶往机场，三点的厦行航班居然又晚点了近一个小时。更可气的是经停南京时由于航空管制，竟坐在飞机上等了近一个多小时。回到家里已经是晚上10点多了。一进门，LP正坐在沙发上等我吃晚饭呢，那时那刻，心里美滋滋的。这两天发现自己的脸摸起来很顺滑儿，估计用福州的水的功劳，福州的水水质较软。

之前一直认为福州是个内陆临江城市，但是今天看了Google地图才发现原来福州机场东测就是大海。这次榕城行真是太匆忙了，甚至没有留下一张照片，下次有机会有时间一定细致“挖掘”一下福州。

有些像流水帐^_^。

随机文章：

成都行记 2009-07-02

走进九寨 2009-06-24

离开太原 2008-10-31

游永祚寺和迎泽公园 2008-10-26

太原晋祠游记 2008-10-25

博客大巴，你的个人传媒早班车

收藏到：Del.icio.us

ReviewBoard中文支持

Mon, 05 Oct 2009 10:04:17 +0800

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

首当其冲的就是对中文的支持问题。按照默认的步骤安装和配置后，输入和保存英文均没有问题，但是一旦输入中文，保存后页面显示的都是乱码，甚至某些时候在保存中文数据时ReviewBoard还提示错误。我的 Ubuntu的locale是"zh_CN.UTF-8"，输入法输入后的中文内码应该是UTF-8。ReviewBoard本身按理来说其内核也应该是内置支持的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则完全正确，源码文件中的中文注释显示的也很正常。

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

随机文章：

Firefox变身Vim 2009-09-20

ReviewBoard安装和配置札记 2009-09-19

发掘Trac 2009-03-18

“扶正”Bash Shell 2009-02-27

CSCOPE使用中问题小解 2009-02-23

博客大巴，你的个人传媒早班车

收藏到：Del.icio.us

这个十一没回家

Fri, 02 Oct 2009 23:21:30 +0800

以往每逢重要节假日，我一般都会回到老家看望父母和亲戚朋友。不过这个十一因工作和其他一些原因，我决定不回家了。八天长假确也不短，事先也做了一些计划和准备。

这个十一是祖国六十周年的生日，国家将举行盛大的庆典，所以十月一日这天我和LP选择在家里守在电视旁，看庆典、看阅兵、看游行。自从1999年第一次看国庆庆典以来，一晃已是十年，不禁感叹一下时光荏苒、岁月如梭啊。中国已经有了多次组织大型庆典活动的经验了，本次六十周年庆典组织的也很井井有条。细数一下庆典中让我格外激动和感动的场景：当五星红旗冉冉升起、全体高唱国歌的时候；当国旗护卫队第一个通过天安门前的时候；当阅兵空中梯队飞临广场上空的时候；当毛主席和邓小平的声音再次响彻天安门广场的时候；当5000名少年儿童放飞手中气球、呼喊跳跃地奔向天安门城楼的时候。当然庆典也不是没有瑕疵的，如果非要鸡蛋里挑骨头的话，那我觉得CCTV导播的镜头切换技术显然还不够成熟，还有待提高啊。

十月二日也就是今天是个好天气，沈城秋高气爽，温度适中。我和LP本来的计划是这样的：先到辽宁省博物馆看展览，再到市府广场休闲，下午陪LP到长安寺，最后进电影院看"建国大业"。

大约10点钟到了辽博正门，发现这里排了近50米的长队，节日里市民到博物馆游览的热情如此之高是我们始料不及的，无奈我们也只能放弃今天游省博的计划了。旁边的市府广场倒是一派热闹的景象。放眼望去，家长带孩子来这里休闲的居多，广场上熙熙攘攘、欢笑声此起彼伏。我也拿起相机将这里和谐的景象收录了下来，这里展示一部分出来：

广场五星红旗主题景观

"我也要放风筝"

"宝贝，抬头看镜头"

到长安寺纯属LP意愿，这里就不细说了。出寺后，我们直奔电影院。以前我是很少去电影院看国产影片的，近一两年来有所改观，但与国外影片相比，国产影片始终无法激起我到电影院观影的热情。这次是LP非要看"建国大业"。这部国庆六十周年献礼影片在公映前是做足了宣传，其实这部影片的献礼性质+百位三地明星的出镜就足以吸引广大老百姓的眼球了。两个多小时下来，有两点主要感受：一是影片中将领袖演绎的更接近普通人；二是影片的确尊重历史的真实展现和还原，这点从政治协商会议上毛主席讲话那段就可以看出来，那组镜头中唐国强的表演就是在真实还原当年毛主席的讲话神态和肢体语言。总体来说，如果有条件的话，还是推荐在十一期间到影院去看看这部片子的，就算是对那段历史的重温了，也缅怀一下那些为新中国建立做出巨大贡献的革命志士们。

随机文章：

“找回”自己的密码 2009-09-23

瞬时“失忆”，密码忘记 2009-09-22

手机做MODEM实现无线上网 2009-08-30

天儿太热了！ 2009-08-12

体检·SSH·Safari4 2009-07-17

博客大巴，你的个人传媒早班车

收藏到：Del.icio.us

也谈VIM字符集编码设置

Mon, 28 Sep 2009 10:24:14 +0800

安装完中文语言包支持后，Ubuntu的默认locale是zh_CN.UTF-8(即简体中文语言环境，字符集内码UTF-8)。这与我们日常开发环境中Unix设定的环境有所区别，我们日常使用的环境一般为zh_CN.GBK或zh。我们的源代码文件的字符编码也都是GBK的编码，直接在Ubuntu下用默认设置的VIM打开后，中文的注释会显示乱码。如果你直接编辑这个文件并提交，那么其他在Unix下开发的同事Checkout这份源码后打开也将显示乱码（你新增的中文内容会是乱码）。

解决这个问题至少有两种方法：一种是为Ubuntu新增加一个zh_CN.GBK的locale的支持；另外一种就是通过设置VIM，在不变换Ubuntu所支持的locale的情况下支持对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编码。

随机文章：

一个Solaris x86平台64位编译的问题 2009-11-05

使用iconv做内码转换 2009-10-31

Solaris 10安装二三事 2009-09-10

Bash文件描述符重定向符号的另类理解 2009-09-08

Cmockery支持mock输出参数 2009-08-26

博客大巴，你的个人传媒早班车

收藏到：Del.icio.us

“找回”自己的密码

Wed, 23 Sep 2009 22:15:04 +0800

继续昨天的情况道来。话说昨天因瞬时“失忆”，导致将公司办公账户的密码忘记了。这给工作带来的不便是我没有想到的。今天一上班就询问秘书密码重置的进度，得到的回复是已经发给公司HR并催促多次了。但是直到近中午也未曾收到密码重置的通知，耐不住性子的我终于决定亲自跟踪这件事，电话直接打到HR部门负责此事的专员那，结果无人接听，一连多次，估计是那个同事不在Office。遂直接拨打公司IT服务部门的电话，说明了情况，这个部门的态度倒是很好，帮我查了一下，并告知我昨天没有收到HR那边的邮件，并答应我，一旦收到邮件就会马上处理的。

放下电话又想了想，觉得我不能就这么等下去，应该尝试一下找回自己的密码。虽然昨天瞬时“失忆”，但是自己的密码组成规则还是记得的。公司的密码起码的要求包括长度、大小写字母和特殊符号。记得当时我只是想换一下大写字母的位置，只是事后忘记了调整了哪两个字母。午饭过后，决定花一定时间尝试去“找回”自己的密码，工具吗，用Ruby+Watir。用Watir来操作IE，用穷举的方法来尝试各种密码组合，直到能正确登录的密码就是我想要的。Watir好久没有用了，而且也没有现成的包，还得重新安装，Ubuntu上安装Watir总是提示已存在的文件的gem格式不符，无奈回到Windows上安装。先用C代码生成了所有可能的密码组合，写到一个文件中，每行一个密码。然后在网上找到了Watir使用的例子，参考之完成了自己的脚本：打开公司内外首页，用文件中的密码逐一尝试，如果登录成功，则脚本执行结束。

一杯咖啡功夫，脚本执行完了，不过出乎意料的是没有一个密码是正确的，这让我大为疑惑。30分钟后，Ubuntu上的iptux闪动，秘书将重置后的密码发了过来，我再一想估计是在我尝试“破解”之前IT服务部门的同事就已经将密码重置了，所以我穷举的那些密码也就都不正确了。

现在我最想知道的就是到底我昨天更改后的密码是什么^_^。

随机文章：

这个十一没回家 2009-10-02

瞬时“失忆”，密码忘记 2009-09-22

手机做MODEM实现无线上网 2009-08-30

天儿太热了！ 2009-08-12

体检·SSH·Safari4 2009-07-17

博客大巴，你的个人传媒早班车

收藏到：Del.icio.us

瞬时“失忆”，密码忘记

Tue, 22 Sep 2009 21:45:27 +0800

密码这东西在信息化的今天真是很重要，估计大家一张口就能说出5个以上使用密码的地方：登录网银、上淘宝、上亚马逊购书、写博客、登录Gmail等等。平时在公司，我的mail就是我的ID，公司所有内部网络服务都需要使用这个ID登录，甚至包括内部无线网络也是如此，所以在公司办公，内部mail账户和密码很重要。

公司为了加强信息安全管理，要求每位员工的密码都要符合SOX规范，而且要每隔若干个月就要对密码做一次修改，更有甚者公司内网首页居然做了强制密码修改的校验，如果你超出规定时间没有修改密码，那么当你登录公司内网时就必须修改密码，否则就无法登入。

今天就因为这个让我“损失”大了。符合SOX规范的密码较长也比较难记，所以大家也都总偷懒，很少去改密码。今天为了到内网去下载一个文档，不得不被强制修改密码。修改密码时有些三心二意了，改完后，突然感觉“瞬时”失忆了似的，刚才的新密码就是想不起来了，试了十几次，仍然无法想起正确的密码。这下可惨了，一分钟后，无线网络断了、outlook和thunderbird相继弹出输入密码对话框、Firefox也弹出了输入代理密码的对话框。无奈只能向秘书“求救”，后被告知重置密码还真不那么简单，先要秘书发mail给人力，人力再发mail给公司网络管理部门，之后如何处理还不得而知了。不过公司的办事效率也真不怎么高，到现在为止我仍然没能恢复我的密码，真是耽误事啊。一天了都没能收到mail，中间有几封重要的客户mail也没能及时回复。

悔啊！

随机文章：

这个十一没回家 2009-10-02

“找回”自己的密码 2009-09-23

手机做MODEM实现无线上网 2009-08-30

天儿太热了！ 2009-08-12

体检·SSH·Safari4 2009-07-17

博客大巴，你的个人传媒早班车

收藏到：Del.icio.us

Firefox变身Vim

Sun, 20 Sep 2009 00:30:32 +0800

在'IDEAL Garden'上看到作者在文章中提到一个名为Vimperator的FireFox插件，该插件功能甚是强大，可以让你以Vim的操作方式来使用Firefox，对于我这个天天都用Vim写代码的人来说，Vimperator可谓有非凡的吸引力，它可以让你的手指留在键盘上。

安装Vimperator这个插件仅需十几秒的时间，重启Firefox后你就可以以Vim的操作方式来尽情操作Firefox了。重启Firefox后，Vimperator会自动打开其Tutorial页面(你也可以通过在命令行输入'help tutorial'打开tutorial页面)。Tutorial页面介绍了Vimperator的大多数基本命令，熟练掌握了这些命令你就可以自由操控Firefox了。

Vimperator默认会隐藏Firefox的菜单栏和工具栏，你可以通过输入'set go+=mTB<CR>'恢复菜单栏和工具栏的显示。

Vimperator与Vim一样，提供常用的normal模式和command-line模式，通过':'或'ESC’可以在两种模式间切换。

打开一个新网页，可以在command-line模式下输入open(或o)，加上url来打开网页。同样你也可以输入o加上你要搜索的关键词，敲击回车后会自动打开默认的搜索引擎搜索该关键字，就和你用Google ToolBar是一样的。当然在command-line模式下输入open这种方式也支持自动补齐功能，输入若干个关键字后，敲击TAB键，会出现一个下拉列表，之后可继续用TAB键在列表中做选择。另外使用tabopen(或t)则是在新标签页中打开你要的网页。

当你在各个Tab间切换时，命令行中显示的是该页面的url地址，如果你想复制这个地址，只需在normal mode下敲击"yy"，该地址就被写入剪贴板了。

在Tab之间切换你大可依然使用ctrl+tab的方式，但是你同样可以在normal模式下通过gt或gT来前后切换标签页。关闭一个标签页你只需要在normal模式下敲入d即可。在当前页面中后退到历史页用ctrl+o，前进到下一页用ctrl+i。

打开页面中的超链接，你大可以继续用mouse点击；但是vimperator也给你提供了一种方法。在normal模式下敲入:f或F，页面上的超链接将被编号，快速输入你要跳转的超链接的编号，即可打开那个超链接。如果超链接较多，你在输入f或F后输入的字符将被用来做匹配，Vimperator会根据匹配到的超链接文字做编号重分配，减少编号个数，便于你精确定位你想打开的链接。

有了好工具，剩下的就是多多练习、熟练掌握并提升效率了。

随机文章：

ReviewBoard中文支持 2009-10-05

ReviewBoard安装和配置札记 2009-09-19

发掘Trac 2009-03-18

“扶正”Bash Shell 2009-02-27

CSCOPE使用中问题小解 2009-02-23

博客大巴，你的个人传媒早班车

收藏到：Del.icio.us