Ubuntu 9.10版本在10月29日发布，虽然没有太多吸引我的地方，但是看了网上很多关于Ubuntu 9.10的文章后，心里面还是痒痒的，终于在上周五我用午间休息时间完成了Ubuntu 9.10版本的安装。

光盘是让同事帮我下载并刻录的，安装过程和以前没什么两样，由于本本中已经有了9.04版本，直接插入光盘升级安装就可以了。大约40分钟后，安装完毕，重启进入Ubuntu 9.10。首先感受到的变化就是Ubuntu的启动和登录界面了，黑白鲜明的反色对比的登录界面显得更科幻，启动速度较快，比起我的Windows要快上太多。

由于导入了9.04的用户数据，所以省去了很多工作。但是更新源、安装中文语言支持是必不可少的。这些工作都结束后突然觉得这个9.10安装后屏幕上的中英文字体看起来都很别扭，不舒服；使用9.04版本时我也使用的是默认字体，但是却没有这么别扭的感觉，遂尝试更换字体。在桌面右键“更改桌面背景”->"字体"中看到当前使用的字体都是"WenQuanYi Bitmap Song"，然后到网上查了一下，发现用文泉驿微米黑的人不少，我也下载了一份(sudo apt-get install ttf-wqy-microhei)并配置了系统字体以及Firefox的字体，果然界面顿显漂亮多了，以后也就是它了:)。

以往每每安装Ubuntu后都要自行安装中文输入法软件，但这次不用，Ubuntu 9.10默认自带了一款称为IBus的输入法框架。之所以称为框架是因为它不仅仅支持中文，还支持世界上其他重要的语言。Ctrl+Space键唤起IBus，尝试在文档中输入中文，发现这个IBus输入法怎么好似十多年前的全拼输入法呢？只能一个字一个字的输入，没有智能联想和光标跟随提示，不能进行词输入和长句输入，太落伍了。但是为什么网上很多人还声称有了IBus就可以不用以前的SCIM和fcitx了呢？难道我还没有挖掘出IBus真正强大的功能所在？经Google的帮忙，我终于明白了原因：原来Ubuntu 9.10默认启动的IBus的中文输入法都不怎么好用，你需要自己重新在IBus设置中添加。选择“系统”->“首选项”->"IBus设置",打开"IBus首先项"对话框，选择“输入法”标签，在“选择输入法”下拉框中找到“汉语”，在"汉语"后面的可选择输入法中选择"拼PinYin"，这才是我们需要的中文输入法。另外默认的IBus的光标跟随提示框是竖向的，你也可以在IBus设置中修改之，改为于Windows下输入法一致的“横向”提示。

Ubuntu 9.10还提供了"软件中心"对系统中的软件进行更好的管理，不过我目前还是习惯使用apt工具。Ubuntu One是9.10提供的Ubuntu云存储的一个客户端，不过不知为何我的机器上的Ubuntu One一启动就报错，另外通过Web页面访问的Ubuntu One目前还很慢，这是我在公司和家里测试的结果。

其他的，还待使用中继续挖掘。

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

经分析，发现类似“赟”这样的字在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

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)，并让你的代码链接静态库。

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