林健的BLOG

　　既然今天是世界电信和信息社会日，那我就来谈一些通信相关的话题。
　　上周末 @lonepig 同学送我了一个基于 RTL2832U+e4000 解决方案的 DVB-T+DAB+FM 电视棒。这是他最近发现的一件神器，也是近几个月来国内外一些 HAM 热衷研究的小玩意。这个电视棒神在哪里呢？原来是一位 Linux 驱动开发者 Antti Palosaari 在分析 RTL2832U 芯片时，发现这款原本只公开了 DVB-T 等接收功能的芯片其实可以输出原始的 I/Q 采样，且接收频段较宽（64-1700MHz），因而可以用做 SDR（软件无线电）接收机。由于 RTL2832U 相关产品廉价且易购（十多美元或几十人民币，eBay 和淘宝上很多），这引起了一些 SDR 爱好者的关注（如[1][2]），很快有人为之开发了 Linux 或 Windows 下的驱动和接口程序（如[3][4]），以便通过诸如 GNU Radio 之类的 SDR 软件对其进行编程使用。
　　我在前人研究基础上，照猫画虎地把这套基于 RTL2832U + GNU Radio 的 SDR 搭了起来，成功地接收了 FM 广播和 U/V 手台的信号。另外简单测试了 GNU Radio 中一些名称看得懂的模块——发现本科时学的那些老三论忘得差不多了。在 Windows 下，使用解调功能现成、界面友好的 HDSDR 进行接收相对简单一些，但可定制性也比能够灵活编程的 GNU Radio 差一些。

　　这只是最初步的用法。国外一些 SDR 发烧友已经开发了针对这个芯片的扩频模块，使之可以接收短波。时间和精力有限，我就先不实验这些了，静观老外折腾。
　　看过了新鲜，别忘了这个电视棒的原本功能——看电视。之前我不是测试过 CMMB 和 DAB/DMB 制式的数字无线电视吗？有了这个电视棒，又可以测试欧洲标准 DVB 制式了。北广传媒集团在 794MHz 上发送 4 套 DVB 电视节目，分别是公交、地铁、城市（楼宇）移动电视和转播的 CCTV-1。由于应用场合的差异，其分辨率是 768x576，大于面向掌上终端的 CMMB 和 DAB/DMB；延时在亚秒级到秒级，也优于 CMMB 和 DAB/DMB。电视棒附带的 Windows 客户端 BlazeVideo HDTV 还是比较好用的，只是其 DAB 模块貌似只能解码 DAB 音频，不能解码 DMB 视频。我亦测试了 RTL2832U 的 Linux 驱动，并使用 VLC 实时解码播放，效果也不错。不过我工位附近的 DVB 信号明显比 CMMB 和 DAB/DMB 信号差，只有在室外或窗口附近才能看到稳定的视频。当然，这有可能是因为天线的差异。

　　最后说一句实验体会，这也是 @lonepig 同学想说的：要有好天线呀！

　　近日我在反思一些系统设计问题，本想重读一遍《Unix 编程艺术》，后来在书店不经意发现了一本刚刚出版的《Linux/Unix 设计思想》（Linux and the Unix Philosophy），于是借来，趁五一假期通读了一遍。有关设计思想的问题，我想改日再谈。而作为一名图灵译者，这里简单讨论一下这本书的一些翻译细节。
　　总体而言，我认为这本书的翻译质量上乘，译者漆犇把握了原书轻松诙谐的基调，使用流畅的语言和灵活的词汇较为准确地传达了原书思想。我之所以关注这本书的翻译细节，是由于译者在多处使用引号强调一些大约为“移译”（参见《GEB-EGB》中文版前言）的语句。
　　我赞成其中多数译法。例如第 3.4.4 节“关公战秦琼”（apples-to-oranges）、第 4.2.2 节“一招鲜，吃遍天”（one size fits all），使用中国俗语或谚语取代对应西方惯用语，语义不变，行文自然。如果直译，读者反而会不知所云。
　　但有的译法可能就不太贴切了。第 7.10 节“自盘古开天以来”（since the dawn of time）这个译法虽符合上下文语境，且是中文惯用说法，但从本书的“致谢”以及其他章节中的暗示来看，作者可能是一位基督徒，因此以中国民间传说翻译这个短语就些突兀了。我觉得可译为偏基督教文化的“自创世以来”，或者更加文化中立的“自从有了这个世界”。
　　译者还有意使用了若干时兴的网络流行语，例如第 3.6.1 节“自封的‘砖家’”（experts by self-proclamation）、第 5.2 节“羡慕嫉妒恨”（jealous）和第 9.1 节“膝盖中箭”（with his foot shot off）。我对这些译法持保留态度。的确，原书是近年来的作品，作者也常常使用口语化的说法进行调侃。但网络流行语毕竟还没有像成语、谚语那样沉淀到中文文化中，其时效性特征决定了这两年看上去很“潮”的话，过两年再去读就会觉得有些奇怪。像 Linux/Unix 设计思想这个主题，再过若干年去读也不会过时，所以还是应该斟酌一下表达。
　　另外，我对第 11 章末尾的“白客”（good guys）这个译法不是很理解。如果要我来翻译，我可能将其译为俗气但容易理解的“好人”（同时将前面用来注释“malicious hacker”的“bad guys”译为“坏人”）。而看到译文中“白客”一词，我有两个联想，一是和恶意黑客相对的白帽黑客，二是郑渊洁的小说《白客》——这两个概念都不能很好地对应原文所谓的 good guys。因此我也想知道译者是如何考虑的。
　　最后说说这本书标题的翻译。国内翻译作品，出于语言习惯差异和市场营销需要，对书的译名进行修改和创新实属普遍。本书将“philosophy”译为“设计思想”我没有异议，但对“and”的处理就有点不忠于原书了。原书名中，通过冠词“the”可以判断，“and”连接的是“Linux”和“the Unix Philosophy”两个概念。从引言中可知，“这本书是 The Unix Philosophy 的修订稿”，“在 Linux 语境下阐明（Unix 哲学的）这些准则”。将本书组织结构与《The Unix Philosophy》对比，也可以体会出作者的写作手法和内容侧重。而中文版译名这样处理，貌似是将 Linux 和 Unix 平等对待了。我对此有些敏感，可能因为我属于作者所说的那类强调 Linux 与 Unix 特性差异的人。当然，想用简明扼要中文译好这个书名是有点不容易，译者和编辑肯定也没少费脑筋。从引言来看，我估计作者基本能够接受这个中文译名，但要让 Richard Stallman 看到了，我猜他很可能是要较真的。
　　上面仅仅是些个人观点，请译者和编辑指证。无论如何，《Linux/Unix 设计思想》是一本优秀的译作，推荐惆怅中的 *nix 技术人员阅读。

　　前文所说的这个问题，理应在 Extmail 服务端解决，然而我向 Extmail 开发者发信，尚未得到回复。尔后委托 Jeoygin 同学修改代码，却得知 Extmail 在这块的设计逻辑有些混乱，并不是改一两行代码就能搞掂的，有一些纠结的逻辑必须重构。考虑到这是实验室的生产环境，加之受影响的只有我等另类用户，就不在服务器上折腾了。
　　退而求其次，在客户端解决吧。要么让 Claws Mail 在解析邮件时忽略非标准的头部，要么在收到邮件之后将其修改正确再解析。Claws Mail 的功能丰富，但遍历各个功能，没有发现能够直接解决这类问题的选项。虽然可以通过 Action 或 Run command 机制调用外部脚本修改邮件文件，但实验发现总有一些小问题：或是需要额外的鼠标操作，或是不能及时刷新。于是决定发挥主观能动性，自己写个 Claws Mail 插件。我仿照官方提供的插件示例，实现了一个 ExtMailHeaderFixer。思路很简单，添加一个处理接收到的邮件的钩子函数，当收到 Extmail 发来的带有 multipart 和 base64 头的邮件时，将 Content-Transfer-Encoding: base64 修改为 X-ExtMail-Header-Encoding: base64 即可。之所以不在解析时处理，而要修改邮件，是因为实验发现 Claws Mail 确实可以解析符合 Content-Transfer-Encoding: base64 语义的 multipart 邮件（即将 multipart 整体进行 base64 编码），不仅如此，Claws Mail 还能解析不同格式多级内联的邮件，我不想失去这个挺酷的特性。之所以不删除 Content-Transfer-Encoding: base64 这一行，或者把 base64 修改成合法的 8bit，而把这一行修改成对客户端无影响的 MIME 扩展字段，是便于必要时快速恢复邮件原样。这个方案也有缺点，即相关的钩子函数只对 POP3 邮件有效，对 IMAP 邮件无效，Claws Mail 这样设计可能与两个协议的语义差别（接收或同步）有关。在我目前的使用场景中，这个问题不大。
　　在 32 位 Ubuntu 12.04＋Claws Mail 3.8.0 和 64 位 Debian wheezy＋Claws Mail 3.8.0 下测试通过。把代码释放出来，放在 sf.net（万古不化……），按传染性要求以 GPLv3 授权，方便遇到相同问题的朋友使用：http://sourceforge.net/projects/extmailhf/。

　　实验室的邮件系统最近改用了国产开源邮件服务器——Extmail。我在使用过程中发现一个问题：Claws Mail 客户端收到来自 Extmail web 界面发来的带有附件的邮件，内容均为空白，既无正文也无附件。而使用 Foxmail 等其他客户端接收邮件，则正常。经测试，发现问题出在 Extmail web 界面生成的邮件头中的这一行：

　　如果将这一行删除，则 Claws Mail 可以正确显示邮件正文与附件。那么，这是 Extmail 的问题还是 Claws Mail 的问题呢？既然这一问题只出现含有附件的邮件中，就从实现邮件附件的规范——MIME 的 Multipart Content-Type 入手分析。查阅 RFC 1341 相关章节，其中明确说明了 multipart 类型的 Content-Transfer-Encoding 只允许是 7bit、8bit 或 binary，而具体内容（正文和附件）的 Content-Transfer-Encoding 应在各个 part 的头部声明。因此，Extmail 在邮件头部指定“Content-Transfer-Encoding: base64”是不符合 RFC 的。而 Claws Mail 可能对标准的执行过于严格，容错能力不足，因此不能显示不符合规范的 multipart 邮件的正文和附件。
　　我又查看了 Foxmail、Coremail 等 X-Mailer 发来的 multipart 邮件，发现多数 X-Mailer 构造的 multipart 邮件在头部都不指定 Content-Transfer-Encoding，只在下面的各个 part 中分别指定 Content-Transfer-Encoding。作为具有缺省值、可以省略的字段，multipart 邮件头部不指定 Content-Transfer-Encoding 应该是符合 RFC 的，这些邮件在 Claws Mail 中解析正确。
　　因此，这个问题的根源在于 Extmail 未严格遵守 RFC。简单查了一下，构造 multipart 邮件的相关代码位于 libs/Ext/App/Compose.pm 文件，应该比较好修改。不过 Claws Mail 的“死板”也算一个原因，应对中国制造就要学会超强纠错（还记得这个例子吗）。

---

　　Update 2012-04-24: 经 Jeoygin 同学提醒，有关 MIME multipart 的更新标准是 RFC 2046。该 RFC 仍限制 Content-Transfer-Encoding 只能是 7bit、8bit 或 binary。另外，Extmail 修改这个 bug 并不是一行代码就能搞掂的，Compose.pm 里面有一些纠结的逻辑有待重构。

　　我的姓名使用香港政府粤语拼音拼写出来是 Lam Kin。以前从词典上知道，连写成一个词的 Lamkin 是源于英格兰的一个姓氏，今天在 Wikipedia 上乱翻时发现 Lamkin 居然也是一首流传于英美的“谋杀民谣”（Murder ballad）的名字。
　　谋杀民谣？听着是多么纠结的一种艺术形式。网上找不到几篇讨论谋杀民谣的中文内容，只有台湾作家卧斧的这篇《狂暴与温柔，谋杀的情歌》对谋杀民谣进行了相对详细的介绍。参考 Wikipedia 上的说法，谋杀民谣作为欧洲传统民谣的一个流派，源于中世纪的北欧和英伦，并在近代早期开始以大报（broadsheet）形式印刷发行。作为在通信闭塞时代民间传唱的轶闻谈资，其内容或为真实案例演绎，或为虚构的野史神话，其中不免包含讽刺、调侃等不严肃的情绪。例如这首 Lamkin，其主流版本讲述的是辛苦修建城堡的长工 Lamkin 受欺压于无赖拖欠工钱的地主 Wearie，万般无奈之下与地主家的丫鬟合谋杀死地主家丁，继而被地主残酷处死的悲惨故事，反映了黑暗的中世纪尖锐的阶级斗争现实。而其衍生版生却将 Lamkin 描述为游魂野鬼或者地痞流氓，显然体现了地主阶级对无产阶级劳动人民的无礼污蔑。这种创作形式在西方流传至今，经久不衰，当代典型作品是澳大利亚另类摇滚乐队 Nick Cave and the Bad Seeds 1996 年发表的《Murder Ballads》专辑。由此看出可以，东西方文化还是有很大的差异。至少我不知道中国的哪种传统戏曲会如此成系统地戏说命案。
　　回到 Lamkin，在 Google 上搜索一下，以此为姓氏的人物以及以此为名号的机构还真不少。不过这肯定不是特例，这种基于语言音译转写的“同名”现象应该还有很多。想想看，其中能挖掘出什么有趣的应用吗？