cat jjgod >> log

• 原文: Packaging Issues with AppTapp
• 作者: Jay Freeman (saurik)
• 译者: Jjgod Jiang

Debian 的 APT，Gentoo 的 Portage，FreeBSD 的 Ports……它们内部运作的方式往往迥异，有的在服务器上存储着按少量标准配置编译好的二进制程序，有的则将代码下载到本地再按需编译，但它们最终都能归结到一两个简单的命令，不会比一句 install bash 这样简单的操作更复杂。

在 iPhone 上包管理工具的时令之选是 AppTapp Installer。这款由 NullRiver 开发的 Installer 给 iPhone 开发社群提供了一套简单的程序 (该程序可在 jailbreakme.com 这样的系统上轻易自举)，它可由普通用户访问，进行即时的应用程序安装维护。任何人都可以通过它来分发自己的软件，只要配置好自己的软件仓库，并将其 URL 告知用户，他们就能以此作为“source”来安装你们的软件。考虑到 iPhone 这个 Apple 设备文档匮乏又 (对开放的软件安装) 深怀敌意，Installer 能做到这样可不容易，非常值得称赞。

然而，对于软件打包者而言，AppTapp 却显得很是繁琐。它的开发者选择了 Objective-C 属性列表 (property list) 来存储所有的软件包元数据，其中包括要在安装时执行的命令——不过通常执行的是 shell 脚本。这通常导致配置文件看起来不够完美。一个用十句脚本代码就能表达的配置往往要好几页的 XML 才能描述。

<array>
  <string>If</string>

  <array>
    <array>
      <string>InstalledPackage</string>
      <string>com.saurik.Cydia</string>
    </array>
  </array>

  <array>
    <array>
      <string>IfNot</string>
      <array>
        <array>
          <string>Confirm</string>
          <string>Performing... continue?</string>
          <string>Yes</string>
          <string>No</string>
        </array>
...

这本身未必就很糟糕，但 AppTapp 的开发者们并未花时间给可以使用的脚本命令定下一套规范的列表，虽然这样的命令偶尔也会在新版本发布时提及，但却时而无效或者用途难辨。我总是不得不坐下找个字串表编辑器来分析它的二进制代码，以提取出那些可能作为命令的字串。

就算格式不成问题了，其表达的语义本身也还是个问题。Installer 的包管理方式是非常简化的，但随着几个大型的软件来源仓库的需求把它推得不停往上加新功能，却没有停下来好好看看周围现有的软件包管理项目，也没有寻求外界的帮助来改进他们的代码。考虑到以往的包管理系统早已花了大量时间在这方面的代码实现和理论研究上，这样从头做起实在不是一件好事。

进阶问题

对包管理系统的许多工作与思考一开始看起来似乎并不那么好理解，尤其考虑到有如此多的竞争者，就更不好理解了：既然人人都能做包管理，它又怎么会是一件困难的事呢？但其实许多有挑战性的问题都有待这些包管理系统提供解决方案。这里就是刚接触这个领域的开发者一些常见的缺漏：

• 包依赖关系 - 在我安装一个 blog 程序前，会先需要一个 web 服务器。所以现在我需要的只是“一个” web 服务器，却没指定具体要哪个。另一种情况则是我明确指定就要 Apache 的 2.1 版本，不要其他的。
• 冲突软件与替代软件 - 我安装了两个 vi 的克隆版本，但只有其中之一可以占用 /bin/vi 这个路径，所以应该是“较好”的那个替换品获得这个关键的路径，但仍允许另一个在别处存在。否则的就只能删除其一了。
• 多来源仓库 - 有时同一个软件包的多个版本会出现在不同的来源中，而我要的是最新的那个。更棘手的情况是，必须允许用户指定安装来自某处的某个特定版本。
• 版本标定 - 就算 1.7 版本从纯数字角度上要比 13 版本老，事实上却未必如此：很多老软件都可能会小幅修改它的起始版本号，甚至完全从头算起也有可能。
• 守护进程与初始化脚本 - 安装一个用来同步时间的守护程序很可能需要启动该守护，这个过程应被视为安装了一个系统特性，而不仅仅是一个二进制程序。
• 废弃与替代 - 一套发行可能需要判断 Firefox 是否应该替代所有已安装的 Mozilla，又或者以前独立提供的 libffi 现在是不是已经被 gcc 包含了这样的情况。

经年以来，每个主流的包管理系统提供者都不得不消化这些问题，并提供解决方案，其中有的就比其他的更为成功。这些经验往往是在维护一个系统发行版中慢慢学得的，再一点点被加入到他们的包管理工具中去：包管理要解决的问题的复杂程度甚至可以作为一个发行版的年轮。所以 Debian 和 FreeBSD，这两个都从 1993 年开始的项目，自称其方案最被广泛认可和使用也不算虚言了：他们发展的时间最长嘛。

即便如此，我们还是能发现新的包管理工具在不断出现：没什么解决方案是完美的，人人都有自己的观点。这并非总是坏事。比如 Gentoo 创制 Portage 时，他们将过往的全部经验运用到了这个困难的环境下，并在很大程度上成功了：以允许按各自机器定制软件包编译的方式，在发行版市场分得了一杯羹。

但 Portage 大概就是 Gentoo 所做的全部工作了：如果你把这个发行版分解一下就会发现他们大部分的时间都花在了一个革命性的包管理工具上，而不是花在诸如改进每个支持的软件包对怪异编译器的支持、或是集中式配置工具、又或者是一切理想发行版所需要的东西上面。

通常有这么一个建议不错：当你开创一个新的公司或新的发行版时，应该只选择在少量几件 (最好是一件) 事情上与竞争者有区别，并把这几件事情做好。要把每件事情都做好恰是通往平庸之路，这样你永远也没时间做完其中任何一件。

尽管肯定说得简单了点，但看看每个稍著名一点的发行版和其他有何不同就能体会得到：Gentoo 之于部署，Ubuntu 之于集成，OpenBSD 之于安全，RedHat 之于支持，Slackware 之于简单，而 SuSE 之于配置。

有人可能会这么问：NullRiver 想通过 Installer 达到何种目标？考虑到这是一个封闭源代码的产品，来自一个主要目的并非这个应用的公司，我们只能认为这个公司只会在 Installer 上面花很少的时间。(把那些经常蹦到你面前的要求捐赠的链接，和最近数月毫无有价值更新这两个事实综合起来，更能证明这一点。)

我大概可以确定，他们关注的是用少量允许的时间开发一个小的 (因而也是容易自举的) 软件部署机制，提供标准 iPhone 程序的图形界面 (正如我在前面提到的，在那个 Apple 提供的库对大家几乎是一个迷的情况下，能写出这样的程序真是值得赞叹的)，他们已经有效地达到了这一目的。

由于重点在此，Installer 之所以完全忽略前述那些包管理的复杂情形也就可以理解了。此外，因为开发的时间有限，实现本身也缺乏处理边界情况的能力 (比如磁盘空间不足时)。对简单的情形下 (安装到一个较新的设备上并有比较充足的空间) 安装简单的软件包 (来自单一来源并作为单一 iPhone 应用程序的一部分提供) 它做得不差不离：一旦情形稍变，它就会出问题。这样，我觉得参与打包的社群他们的目标正在改变，尤其是在这 Apple 官方 SDK 马上就要发布的时候。我们的软件正变得越来越大、功能越来越多、也越来越多地相互依赖。与其作出完全独立的二进制程序，我们发现大部分人都越来越愿意自己的工作能与现成的库整合，这些库提供的功能从多媒体编码显示一直到网络协议的实现。

为 Installer 打包

我让 Installer 做的第一件事情就不算简单: 我想把 Java 和一系列它依赖的库及例子程序移植到 iPhone 上 (过几天等我写好关于这个成功移植的文章)。这需要安装较多的内容 (大概 30MB)，应该切分为数个独立的软件包，以便人们各取所需，来执行自己想要的程序。

一开始我非常天真地开始了尝试，以为 Installer “当然”会支持我在其他包管理方案里看到过的功能，结果发现它其实不支持时我还很是惊讶。

第一个问题是缺乏依赖关系支持。Installer 中唯一类似的特性是查询某个软件包是否已被安装，如果没有的话只能停止安装 (这会导致用户只能非常困惑地寻找正确的依赖包安装顺序) 或仅显示一条警告 (这样漫不经心的用户就有可能忽略安装某个重要的软件包)。

每天我都会收到来自用户的消息，说我的软件不能正常工作，这类报告我查起来通常的结果都是一两个必须的软件包没装上。有时要向用户证明他们其实是因为缺少了某个包挺困难，不过他们总归会发现并装上，然后我的软件一般都能正常工作了。

开发社群也在逐渐变大。随着越来越多的开发者的加入 (以及越来越多来源库的加入)，还应该在改进更新库元数据的时间上下功夫，争取找出更有效的措施。我想人人都体会过在刷新软件源列表时那种慢得痛苦的感觉，而 Ste (负责打包最多也是最受欢迎的一个打包者之一) 也曾因为 Installer 的同时连接数受限而遇到过一些严重的问题。

符号链接

还存在一些其他的实现问题。我们要打包的内容类型变得越来越复杂：比如符号链接就很常见。但 Installer 基本不支持这个。对我而言情况是我希望打包的许多库都有这个需求，当安装动态库时，通常的习惯时将含版本号的库文件放置在 /usr/lib 中，然后以符号链接的方式来提供备用的名称，以供不挑剔版本的应用程序使用，这些备用的名称里通常不含完整的版本字符串，但都会链接到一个真实的库上。我要打包很多都是这样的库，每个至少都包含一个符号链接。

现在符号链接在现代的 InfoZip 文件中存储是没什么问题了，也能被 Installer 标准的安装方式 (CopyPath) 所解压……除非目标位置已经有了一个同名的符号链接，这样安装就会因无法覆盖而失败。虽然仅这一个算不得大问题，但考虑到 Installer 标准的卸载方法 (RemovePath) 不支持符号链接，重新安装显然就会失败了。

好吧，符号链接显然不应该用 CopyPath 来处理，考虑到 Installer 是声称支持一个叫做 LinkPath 的特性 (在它的 “Featured” 网站写了，你一打开这个程序就能看到)。可是这个函数是用 linkPath:toPath:handler: 来实现的，问题在于 iPhone 里压根没这个函数，导致你一用 Installer 立即就崩溃了。所以显然他们从来没测试过这个功能。

最后的办法是尝试用 Exec (它允许执行任意的外部程序) 来调用 /bin/ln，这倒是有效，但要假定 BSD Subsystem 已经安装了。然而因为解析 Exec 命令的机制有问题，它根本不支持包含空格的文件名 (用引号包含或者转义字符都无效)。

我能找到的唯一一个通用的办法是提供一个独立的 shell 脚本来执行 /bin/ln，这样我就能任意做命令行参数的转义了。尽管如此，我还是遇到了问题：在 iPhone 新的 firmware 1.1.3 版本上 (Installer 以 mobile 用户运行，setuid 为 root)，Installer 只能以 effective root 身份 (而不是 real root) 来执行 Exec 命令，这导致许多程序 (比如 bash) 都没有足够的权限，因为我需要在自己的 shell 脚本中用到许多 bash 专有的特性，我只好另外配一个有 setuid 的 ln 版本。

当然，这些不过是实现上的顾虑，也可能被修正，但考虑到我去年 11 月就寄去的关于符号链接处理的 bug 报告至今未有回音，我想这些问题仍然值得关注。

总结性评论

我所要做的本不该这么困难，是的，就算我忽略了一些更简单的选择，但要运用一个完全没有文档的包分发格式，而这个格式只有不到一年历史却已经不怎么维护了，这本身很成问题。

对我来说，这正是 Telesphoreo 和 APT 最重要的目的之一：运用开放源代码、人人可以获得、经过长期考验的产品来解决问题，而不是从头专为 iPhone 写一个这样的软件。如果你在使用 APT 时弄坏了什么，令人安慰的是有成千上万有其经验的人帮助你修正，有邮件列表、bug 跟踪系统可以关注，还有成百上千介绍了 APT 使用方法的网站可以参考。所以，在 Unix 的世界中，你永远不会孤单。

相信熟悉 Web 设计的朋友已经了解，这本书是一本关于 JavaScript 的较有深度的书籍，中文版是由贤安 (realazy) 和我一起翻译的，中文译名是《精通 JavaScript》。

原书的价值，对于熟悉的朋友应该毋庸置疑，我们两人在翻译时也颇费了一番功夫，大致分工是我主要负责和语言特性相关的，贤安主要负责和 Web 应用相关的 (包括与 CSS 的配合)，如果有任何意见建议，欢迎致信 projsch@gmail.com，我们会将所有的更正与改进放在勘误页面上。

更新: gitmo 已经过期了，Sergey Yanovich 更新了 git repo 上的说明，现在应该用这个 client.sh 来更新。

今天实在是受不了 CVS 了：在 mozilla 这么大的树上用 cvs diff 简直是自虐，于是找来 mozilla cvs trunk 的 git mirror 来 clone，上次 clone 过一次发现缺东西不能编译，因为 mozilla cvs 树里有些东西是作为 external item 放在别的地方的，比如 nsprpub，但 git mirror (和 hg mirror) 都没有镜像这些。

因为看 mozilla.dev.platform 上有人贴了一个 gitmo 的脚本还方便，以为不会出问题的，结果还是出问题了。

为什么呢？因为 git 的 mirror 是用那个 repository 的几个 branch 来存这些 external items 的，每次我要用到这些 external items 来编译的时候，就把 checkout -b 一个 本地的 branch 出来，remote 的一个 branch 给 merge 进来，然后编译，问题是这些个 remote branch 的镜像更新似乎不如 CVS 上的勤，结果跟主干上的代码就不一致了。

虽然归根结地还是 mozilla 土鳖：CVS 这种原始社会的玩意早该淘汰了，但经验之谈是：除非对 Mozilla 的代码树结构以及它的编译系统很熟悉，否则如果自己要编译 Firefox 还是直接从 CVS 上取最省事，出问题的概率最小。

哦，顺便说一句，最近解决了一个 Firefox 3 在 Mac OS X 10.5 上的一个比较严重的 bug，涉及中文字体的载入和顺序，patch 已经进入主干，最新的 nightly build 中也已经包含，不妨试试。

虽然我认为花 $99 获得一个发布免费软件的权利是很荒谬的事情，不过假如我收到 $99 的话，我会将它用到 iPhone Developer Program，下面是一些开发的计划：

• 一个真正高效、可靠、方便的电子书阅读软件，至少达到 PSP 上的 eReader 的效果
• weDict 的替代品，因为 weDict 的代码是在是糟糕得恐怖
• 改进现有基于 libpurple 库的 IM 软件的在中文支持
• 其他中文相关的项目

而且我可以很肯定的说，如果是我发起的项目，会完全开源并免费，如果是我参与开发/发布的软件，只会是免费的。

所以，如果你希望见到这些软件的出现，欢迎点击下面任一按钮捐赠

目前收到: $114。感谢: Glider, bluevisor, fancyrabbit。

更新: TextEdit/UCD 的代码现在可以在 http://gitorious.org/projects/textedit-ucd/ 找到。

TextEdit/UCD 的第 5 个版本发布了，TextEdit/UCD 开发的目标是尽可能解决所有 TextEdit 固有的中文处理问题，但并不改变 TextEdit 原有的轻量小巧。

在开发这个版本中，我发现了一个 Cocoa Text System 的固有问题：还没有下载的朋友可以先打开自己机器上的 TextEdit，输入一个汉字，一个英文字母，如“中a”，这时汉字会以默认的中文字体显示，英文字母会以 Preferences 中设定的 Plain Text 字体 (如 Monaco) 显示，此时按下 cmd-’+’ 增大一号字体，然后再输入一个英文字母，就会发现这个新的英文字母居然改用中文字体显示了？

为什么呢？在 TextEdit 中花了一段时间重载各个类，加上 gdb 分析，结果发现，其实在 Make Text Bigger/Make Text Smaller 时，调用 [NSFontManager modifyFont:]，这个 modifyFont: 方法会将 -changeFont: 这个 action 发送到 responder chain 中，而此时的 NSTextView 收到这个 action 以后，居然会将 [NSFontManager sharedInstance] 的 selectedFont 修改为这个 TextView 的 TextStorage 中第一个字符使用的字体。于是就导致了已选字体的变化。这其实不是我们期望的结果。

然而，由于事实上 NSTextView 的 changeFont 实现可能很复杂，它要逐个分析所有的 run，逐个将这个 run 的字体送到 NSFontManager 中 convertFont 获得新的字体。既然我们无法直接修改这个 changeFont 的代码，就只能用重载的方法，写一个新的 NSTextView 的子类，重载这个函数，在调用基类的 changeFont 之前，先给整个文档的开头加上一个用纯文本字体的新字符，然后在调用完基类 changeFont 之后再把它删除。

这是一个看起来有些 dirty 的方法，不过很有用，也算是“曲线救国”，用欺骗的方式使之有正确的效果。

Chmox 是 Mac OS X 上常用的 chm 阅读软件，它最后一个版本是 2006-10-28 发布的 0.4β，这也是它唯一的一个 Universal Binary 的版本，此后作者就再也没有过更新，因为我和许多 Mac 用户一样，为缺少好用的 chm 所困扰，所以便尝试来对此做一些修正。

主要的更新是参照 ChmSee 的做法修正了一些编码判断的问题，包括目录的编码和显示内容的编码。欢迎对此有兴趣的朋友将 Chmox 无法打开或者打开错误的 chm 发给我 (当然，文件大小尽可能小)，我会尽力修正的。

下面是最近的更新记录 (版本号延续作者原来的定义进行递增):

Chmox 0.4.2

更新:

- 修正某些 chm 文件无法正确载入页面的问题 (faithprice 报告)
- 没有目录时不打开 Drawer
- 提供简单的页内搜索功能

Chmox 0.4.1*

注: 版本号为我按照 http://chmox.sourceforge.net/ 原有版本更新
的，所以这不是官方版本号 (似乎作者本人已经停止维护了)。

更新:

- 更新到 chmlib 0.39
- 修正一些编译警告
- 使用 chm 文件自带的 LCID 信息来判断 CHM 目录的编码，修正在
  解析目录时的一些常见的编码判断错误

下载链接为: Chmox-0.4.2.dmg

更新: 刚刚设立了一个 git 代码仓库，请用 git clone git://gitorious.org/chmox/mainline.git 获取最新代码，访问这里了解项目最新开发进度。

mplayer 是常用的播放软件，其文档对于涉及字幕播放的一些参数不甚详尽，或者留意的人不多，这里对常用选项略作一介绍。

以一个包含了字幕的 mkv 文件为例:

$ mkvinfo ~/Vexille_2077_Nippon_Sakoku.mkv
...
|+ Segment tracks
| + A track
|  + Track number: 1
|  + Track UID: 141444798
|  + Track type: video
|  + Enabled: 1
|  + Default flag: 1
|  + Forced flag: 0
|  + Lacing flag: 0
|  + MinCache: 1
|  + Timecode scale: 1.000000
|  + Max BlockAddition ID: 0
|  + Codec ID: V_MPEG4/ISO/AVC
|  + Codec decode all: 1
|  + CodecPrivate, length 131
|  + Default duration: 41.708ms (23.976 fps for a video track)
|  + Language: jpn
|  + Name: 
|  + Video track
|   + Pixel width: 864
|   + Pixel height: 480
|   + Interlaced: 0
|   + Display width: 864
|   + Display height: 480
| + A track
|  + Track number: 2
|  + Track UID: 3113156519
|  + Track type: audio
|  + Enabled: 1
|  + Default flag: 1
|  + Forced flag: 0
|  + Lacing flag: 1
|  + MinCache: 0
|  + Timecode scale: 1.000000
|  + Max BlockAddition ID: 0
|  + Codec ID: A_AC3
|  + Codec decode all: 1
|  + Default duration: 32.000ms (31.250 fps for a video track)
|  + Language: jpn
|  + Name: 
|  + Audio track
|   + Sampling frequency: 48000.000000
|   + Channels: 6
| + A track
|  + Track number: 3
|  + Track UID: 3841949375
|  + Track type: subtitles
|  + Enabled: 1
|  + Default flag: 1
|  + Forced flag: 0
|  + Lacing flag: 0
|  + MinCache: 0
|  + Timecode scale: 1.000000
|  + Max BlockAddition ID: 0
|  + Codec ID: S_TEXT/ASS
|  + Codec decode all: 1
|  + CodecPrivate, length 903
|  + Language: chi
|  + Name: GB
| + A track
|  + Track number: 4
|  + Track UID: 1264721059
|  + Track type: subtitles
|  + Enabled: 1
|  + Default flag: 0
|  + Forced flag: 0
|  + Lacing flag: 0
|  + MinCache: 0
|  + Timecode scale: 1.000000
|  + Max BlockAddition ID: 0
|  + Codec ID: S_TEXT/ASS
|  + Codec decode all: 1
|  + CodecPrivate, length 891
|  + Language: chi
|  + Name: Big5
|+ EbmlVoid (size: 1024)
|+ Attachments
| + Attached
|  + File name: Font.TTF
|  + Mime type: application/x-truetype-font
|  + File data, size: 2484512
|  + File UID: 577931698
|  + File description: CN-GB
...

这是一个比较典型的情况: 有两个 subtitles track，分别对应简体和繁体的字幕 (从 Name 分别叫 GB 和 Big5 可以看出)，字幕的格式都是 ASS，并自带了一个附件 (Attachment)，这个附件是一个名为 Font.TTF 的字体文件。*

• 注: 顺带说一句，附带有版权的字体文件是非法的。

mplayer 默认的选项并不能让我们很好地播放这个 mkv 文件，所以需要一些配置。在这里，我首先建议编辑你的 ~/.mplayer/config 文件，而不是通过 MPlayer OSX 这样的图形化前端，因为 mplayer 同时支持用配置文件和用命令行选项来选择参数，前者调整起来要方便一些。

对于中文用户，最常见的一个选项是

subcp=gbk

这表示我们显示地指定将所有字幕文件以 GBK 编码处理，对于大部分中文字幕都是适用的。*

• 注: 近来，在 shooter (射手网) 上提供的字幕有些也会以 UTF-16 格式出现，如果你用 GBK 编码无法成功看得到字幕，可以尝试换用 subcp=utf-16 看看。

• 注 2: mplayer 可以用 enca 库来进行自动编码探测，可惜的是这个库并没有对 CJK 相关语系编码的支持，如果有可能，将 Universal Charset Detector 用在此处或许更好。

对于 ASS 格式的字幕，mplayer 有两种渲染方式，一种是忽略所有的格式信息，将它作为纯文本显示，另一种则是启用格式，一般我们希望使用后者，所以可以加上选项:

ass=1

对于自带字体的情况，默认 mplayer 并不解析它们，只有在:

embeddedfonts=1

时才会解析，所以也建议加上这个选项。

在播放 mkv 文件时，mplayer 默认并不会选择字幕文件的 track，所以我们需要手动用 -sid 0 或者 -slang chi 参数来选择。(你也可以将这类参数写入配置文件，不过在 mkv 不自带字幕时这样的参数不会有效。)

经过上述的调整，mplayer 已经可以很好地播放 ASS 格式字幕和 mkv 媒体文件了，不过还有一种更常见的字幕格式需要调节，那就是 srt。

srt 字幕常以外置文件的形式提供，放在媒体文件同一个目录下，以同样的前缀为名，后缀一般为 .chs.srt, .gb.srt 这样的形式，所以为了让 mplayer 的外部字幕文件查找能够找到这些文件，我们首先就应该加上下面的选项:

sub-fuzziness=1

这个选项的可选值对应:

0 = 不模糊匹配
1 = 匹配任何包含原媒体文件名的字幕文件，但包含原媒体文件名和 slang 所指定语言的优先级更高
2 = 匹配任何字幕文件

所以当同一个目录下有多个语言的字幕时，你可以用

sub-fuzziness=1
slang=chs

这样的配置来优先选择后缀为 .chs.srt 的那个。

对于 srt 字幕文件，一个有用的功能是字体大小的缩放 (因为 srt 本身没有指定字体大小)，经过试验，对于一般 DVDRip (resolution 在 600×300 左右)，用以下参数较恰当:

subfont-autoscale=2
subfont-text-scale=3.5

对于 720p / 1080p 的 HDRe/Remux，则应该将 subfont-text-scale 进一步缩小到 2.5 左右较好。

欢迎补充更多 mplayer 的使用经验。

在使用 Safari 的时候，我们会注意到一个很常见的乱码问题，如下图:

这是在打开 http://att.newsmth.net/att.php?p.719.214628.536.png 这样的图片链接时，Safari 错误的判断了这个图片文件的文件名造成的。而为什么会有这样的错误判断呢？

其实 Safari 使用的是 Cocoa 框架 URL Loading 架构中的 NSURLResponse 类的 suggestedFilename 方法实现的。

而这个方法，其实就是解析 HTTP 首部中的 Content-Disposition 域里的 filename 部分完成的，比如下面这个首部:

$ curl -I http://att.newsmth.net/att.php?p.719.214628.536.png
HTTP/1.1 200 OK
....
Content-Disposition: inline;filename=ͼƬ_6.png
....

显然这是乱码，可奇怪的是，这和我们在上面的图中看到的乱码又不一样，这是为什么呢？

假如将它作为 GBK 来解码就清楚了:

$ curl -I http://att.newsmth.net/att.php?p.719.214628.536.png | iconv -f gbk -t utf-8
HTTP/1.1 200 OK
....
Content-Disposition: inline;filename=图片_6.png
....

哦，原来是 GBK 编码的“图片_6.png”，可是这个文件名怎么会变成开头图片中那种形式的乱码呢？其实写一段 Cocoa 程序就可以发现:

#import <Foundation/Foundation.h>

int main()
{
    const char *bytes = "图片_6.png";
    NSString *str = [[NSString alloc] initWithCString: bytes
                                             encoding: NSASCIIStringEncoding];
    NSLog(@”str: %@”, str);
    [str release];

    return 0;
}

(用 GBK 编码保存) 这个程序的执行结果就是输出开头那段乱码，原来 NSURLResponse 把 Content-Disposition 中的 filename 当成 ASCII 处理了，怪不得会乱码。

可是也不能怪 NSURLResponse，毕竟服务器没有提供任何编码的信息，而 RFC 2183 中也明确说明，不应该在 filename 中使用任何 ASCII 以外的字符，用了就是后果自负了。

那假如我们要写一个自己的客户端 (或者尝试修正 Safari 的错误行为)，该怎么修正已经被按照 ASCII 错误解码的 NSString 呢？

因为 NSString 本身是按照 UTF-16 编码的，所以如果逐个字符地观察这个错误解码后的 NSString:

int max = [str length];

int i;
for (i = 0; i < max; i++)
{
    unichar ch = [str characterAtIndex: i];
    printf(”%x “, ch);
}

我们可以得到:

cd bc c6 ac 5f 36 2e 70 6e 67

这样一串输出，5f 36 2e 70 6e 67 就是 _6.png，比较好认，前面的 cd bc c6 ac 是什么呢？一查，原来是“图”和“片”这两个字的 GBK 编码。

这就好理解了：NSString 一开始把一段 GBK 编码的字节流逐个字节地按照 8bit-ASCII 处理了，原本 10 个字节对应的是 7 个字符，结果被错误地解码为了 10 个字符，所以我们要把它转换回去，首先是要还原回原来的那段字节流:

int max = [str length];
char *nbytes = malloc(max + 1);

int i;
for (i = 0; i < max; i++)
{
    unichar ch = [str characterAtIndex: i];
    nbytes[i] = (char) ch;
}
nbytes[i] = ‘\0′;

然后再将这段字节流按照正确的编码 (GB18030) 处理:

NSStringEncoding enc = CFStringConvertEncodingToNSStringEncoding(
    kCFStringEncodingGB_18030_2000);

NSLog(@"nstr: %@", [NSString stringWithCString: nbytes
                                      encoding: enc]);

结果果然得到了正确的输出:

2008-02-17 06:09:46.408 test[14095:10b] nstr: 图片_6.png

同样的逻辑可以用在很多类似的乱码情形中。完整的代码可以在这里下载: test-str-encoding.m

Linux System Programming 封面上的图是在一个正在飞行机器上的人。早在莱特兄弟于 1903 年实现他们第一台“重于空气”的可控飞行器以前，世界上的许多人就已经在用简单而精致的机器探寻飞行的奥秘了。在二世纪或三世纪时，就有中国的诸葛亮在孔明灯中飞行的记录，这是第一个热气球。而在六至七世纪，许多中国人尝试将自己绑在大型的风筝上以在空气中飞行。

此外，据说中国还创造了会转动的玩具，它是直升机的早期版本，这个设计可能在莱昂纳多达芬奇对人类飞行进行早期尝试时给予了他灵感，而在 1845 年，他设计了一台扑翼机，一台试图通过展动翅膀载人于空中飞行的机器。尽管他从未将这台机器建造出来，扑翼机的鸟状结构影响了后续几个世纪对飞行器的设计。

绘于本书封面的这台飞行机器要比 James Means 在 1893 的模型飞行器更为精细，多出了螺旋桨。Means 后来给他的飞行器印制了一份使用手册，其中提到“于 Willard 山巅，Crawford 屋畔，觅一良所”来试验这台机器。

不过这类试验通常是很危险的，在十九世纪后期，Otto Lilienthal 建造了一些单翼机、双翼机和滑翔机，他是第一个展示出飞行是在人类可控的范围内的人，也因此获得了“飞行测试之父”的称号：他曾参与超过 2000 次滑翔机飞行，有时单次飞行距离就超过了一千英尺。他在 1896 年死于一次降落事故，在那次事故中他折断了脊椎。

飞行器还被称作机器鸟或飞行船，也偶尔会叫成人造信天翁 (Artificial Albatross) 这样华美的名字。人们对飞行器的热情现在依然高涨，直到今天还有航空爱好者在建造早期的飞行器。

封面图和章节题图来自 Dover Pictorial Archive。封面的字体是 Adobe ITC Garamond。正文字体是 Linotype Birka，标题字体是 Adobe Myriad Condensed，代码字体则是 LucasFont 的 TheSans Mono Condensed。

注：孔明灯的传说里并没有提到诸葛亮借此飞行，当为老外附会。

To make developers’ lives easier, Apple really should make the following 6 frameworks bundled with their OS, it will make application distribution much better.

• Growl
• Sparkle
• Perian
• Universal Charset Detector
• A decent HUD framework (maybe based on HMBlkAppKit)
• A decent Tab control (maybe based on PSMTabBarControl)