《X档案》和《老友记》剧本CHM

在box.net上申请了一个账号，将《X档案》和《老友记》剧本CHM传了上去。

http://public.box.net/bamanzi

这个账号本来是为了上传ScrapBook中保存的文摘才申请的——我在ScrapBook的网站上看见了ScrapBox.net这个扩展的扩展。

网页速度有点慢，但上传、下载还不是太差。

以后一些非技术的东西或者体积比较大点的东西就传到这里吧。技术方面的东西还是在 http://bamanzi.inlsd.org 上

pidgin: 让MSN支持发送自定义表情的补丁(附win32版本)

在Planet Debian TW上看见的Jesse提供了一个pidgin补丁版本(Debian sid), 其中MSN协议可以发送自定义表情图标了(原来只能接收)，补丁来自http://developer.pidgin.im/ticket/1187。

向他询问了一下之后，我编译了一个win32版本:
http://bamanzi.inlsd.org/gnuwin32/pi...-win32.tar.bz2

需要先安装官方的2.3.1

先在主窗口"工具- Smiley"里面配置自定义表情，然后(目前好像得先重启pidgin)就可以在MSN的聊天窗口里使用这些表情了。

pidgin飞信插件的win32版本

感谢gradetwo昨天放出了pidgin上飞信插件的源代码，俺今晚有空，编译了一个win32版本。

pidgin-fetion-0.96-win32.tar.bz2
(可用于pidgin-2.3.1，解压后将libfetion.dll放到x:\Program Files\Pidgin\plugins\下，重启pidgin即可)

代码只需要做一点小修改: fetion-0.96-win32.patch

编译方法:

1. 先按pidgin网站的win32版本编译 说明编译pidgin. 注意以下几点:
1. 并不一定需要安装cygwin，cygwin安装起来比较麻烦。其实可以从tcl网站下载一个msys + mingw就可以了；
2. 主要w32api版本要在3.9以上。老版本在编译pidgin\win32\gtkdocklet-win32.c时会报告BITMAPV5HEADER没有定义；
3. 如果没有安装perl和tcl，不一定要按网站上说的那样去下载安装，直接修改libpurple\\plugins\Makefile.mingw和pidgin\plugins\Makefile.mingw，注释掉相关行就行了
2. 在libpurple下解压fetion-0.96的源代码（即存在pidgin-2.3.1/libpurple/fetion目录)
3. 打上补丁fetion-0.96-win32.patch
4. 执行make -f Makefile.mingw，编译得到libfetion.dll
   

多媒体和即时通讯方面的几个新玩意

这几天发现了多媒体和即时通讯（这两类也算网民们用电脑最普遍的用途吧）方面的几个新玩意:

网络电视GMLive (图，开发团队blog，使用说明)

目前支持MMS, sopcast, nslive等几种流媒体，UI还比较简单

网络视频nslive (LinuxToy上的介绍，图， 作者的Blog, 安装方法说明)

上面提到过的一种流媒体。支持可用性上做的不太好，那个安装说明也够难找的。

Flash Player 9.0 (Debian包)

新版本支持Linux下的全屏了（并且支持硬件缩放hardware scaling）

Audacious

喜欢Winamp/XMMS的可以用这个了( XMMS -> BMP -> Audacious，功能界面都差不多，都可以用winamp的skin；BMPx和XMMS2却是另外一条路了）。至于功能方面，id3 tag的乱码还是避免不了的，除非自己改代码；另外我现在看重网络音频的支持了（比如电台或者last.fm），很多时候懒得自己去下载mp3文件。

飞信的pigdin插件 (可以放到$HOME/.purple/plugins/或者/usr/lib/purple-2)

当然是第三方开发的。目前有基本功能：对聊或者发短信。最近几天作者gradetwo改 进很频繁，代码还没有放出来。我已经迫不及待要编译win32版本了：在Windows上时如果MSN、QQ、Google Talk、飞信、V网伴侣这些都打开，机器都没法玩了。也不知道现在这些软件怎么搞的，为了界面漂亮一点点，都要拼图片来做，搞得这些软件好用内存相当严 重。还是用pidgin一统天下好。

MusicTracker

A Pidgin 'now playing' plugin to advertise the songs you are listening to in your status message.

MSN客户端KMess发布1.5正式版本

经过两个pre版本后，KMess终于发布了1.5正式版本，主要解决了文件传输过慢问题，新增了对用户自定义表情图片(emoticons)的发送支持。

做了一次系统升级

节前在Debian Package of the Day上看到debfoster的介绍，说是比deborphan可以更进一步清理系统不必要的包，就拉下来玩玩，没想到用它删了一些包之后，使用GNOME时系统老是僵死，除了鼠标箭头，其它啥反应没有（包括Ctl-Alt-Backspace)，只能按电源键。

折腾了几日不见起色，干脆就apt-get dist-upgrade再apt-get upgrade了，反正有近半年没做大面积更新了。这次下载了1000多个包，530多M，可折腾了些时间。

结果如下:

• 当然，系统不死机了;
  
• GNOME升级到了2.20，没留意到什么大的变化，倒是首选项精简了许多。另外lunar-applet不能用了，回头重新编译一下试试;
• totem-gstreamer和totem-xine现在可以同时安装了，依靠Debian alternatives连接到/usr/bin/totem (不过我还是不知道gstreamer版本有什么优点，它好像很多格式都不支持）
  
• 一直在用的小企鹅(fcitx)不好使了，输入条开始可看到，但一开始敲字符就死了。只得切换到scim去;
• 装了个以前在cygwin下试玩过的tilda，感觉用热键呼出比切换到Gnome Terminal方便
  
• 顺便从Debian multimedia (镜像: http://update.inlsd.org/debian-multimedia/ ) 升级了flash-player（可从这里手工下载安装）。现在可以全屏了，爽。但设置界面还是乱码
• pidgin升级到了2.3.1，没见到明显的改进，反而QQ群功能出现问题：名字都显示成"(NULL)"，而且几个"(NULL)"群也区分不开

总而言之，不太爽，不过系统死机的问题倒是解决了。

对字符集和编码的一些错误认识

字符集和编码一直很头疼的一块，最近为了搞培训，研究了一下，发现以前确实有很多不明白甚至是错误的认识:

• ISO-8859-1 .. ISO-8859-16 这些都是西欧各国用的字符集，主要的差别在与128-255之间各自代表的字符不同；
  
• 仍然不明白为啥GB2312, Big5这些就算MBCS，而同样采用多字节编码的Unicode却不算
  
• GBK应该是GB2312的超集，向下兼容GB2312的，记得以前谁跟我说不是，我迷惑了好一阵；
  
• 很 多编辑器说可以支持"Unicode编码"，并且一些软件说"Unicode"就是两字节编码，这都是基于Unicode 4.0之前的认识。在那之前，Unicode跟GB2312这样的名称一样，即是字符集(charset)名称又是编码(encoding)名称， Unicode字符均是两个字节。但从Unicode 4.0开始，它已经不只65536个字符了，Unicode只是一个字符集名称，而UCS-2, UCS-4，UTF-8, UTF-16, UTF-32这些才是编码名称（当然，历史包袱总是存在的）；
• UCS-2与UTF-16是不一样的，UCS-2固定采用两个字节，它不能表达Unicode 4.0之后增补的字符（当然，那些字符很生僻），而UTF-16里面每个字符可能是2或4个字符组成；
• UTF-8
• 从新的理论上而言，UTF-8应该是1-6个字符不等，但目前应该是1-3个字符就可以表达已有的字符了；
• UTF-8的优点
• 如果原有数据大都采用ASCII表达，那么这些数据不用转换
• 如果系统采用ASCII可以表达大多数数据，那么相对UCS-2，UTF-16这些节省空间；
• 编码中字符边界很容易找到：以0开头的字节肯定是ASCII字符，最高位以11开头的字节肯定是字符的开头字节，以10开头的字节肯定是字符的后续字节；
• 容错性强一些，偶尔一两个错误不会影响后面，原因同上（想咱们都碰到过GB2312/Big5的半个汉字问题带来的乱码问题吧)
• 按字节流读取，不用考虑大端(big endian)/小端(little endian)问题
• 字符串中不会出现0x00这样的字节（而UCS-2这些会），这样char *这样的方式表达缓冲区时不太容易导致错误
• UTF-8的缺点
• 对于非ASCII字符，相对以前存储空间增加了，比如非英语的西欧字符集现在都需要两个字节了，而中文等很多都需要三个字节了；
• 计算字符串长度比较麻烦，只能逐个统计；
• 综上，现在很多系统内部处理采用UCS-2，只在存储和数据交换中采用UTF-8
• Java以前内部全部采用Unicode(其实是UCS-2)来处理字符串，但Unicode 4.0以上的那些字符它不能处理。在Java 5.0中加入了一些奇怪的机制来解决这个问题；
• Python也不能同时支持UCS-2和UCS-4，只是可以在编译时挑选(--enable-unicode=ucs2和--enable-unicode=ucs4)，看sys.maxunicode是否大于65535就知道是否是UCS-4了。我看Windows上的预编译版本是UCS-2(python2.5)的，而Linux上是UCS-4(Debian testing, python 2.4)。注意这两种版本在二进制上是不兼容的。

参考文档

• Joel Spolsky: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
• 每一个软件开发人员绝对必须掌握的关于 Unicode 和字符集的最基础的知识(上文的简体翻译，居然木野狐翻译的，好久不见他了)
• 对字符编码与Unicode,ISO 10646,UCS,UTF8,UTF16,GBK,GB2312的理解