• UnicodeChecker

  

  Mac OS X 下完美的 Unicode 字符查看工具，可以根据 UTF-16 编码 (10 进制、10 进制)、UTF-8 编码来查找，或者直接复制粘贴字符进去，可以选择不同的字体查看该字符对应的字形，包含完整的 Unicode 字符属性数据库，可以自动下载安装 Unihan 数据库。几乎是每次开发和调试问题的必备。Linux 下有 gucharmap 实现类似的功能，但要弱很多。

• ttx

  将 TrueType/OpenType 文件按照指定的表 dump 成 XML 格式，或者反过来，所以既可以查看也可以修改。非常方便分析 OpenType 的 GPOS/GSUB 特性查找表。这是一个命令行工具。更简单一点的 TTF/OTF 分析命令行工具还有 lcdftypetools 里的 otfinfo，可以直接列出字体的特性，但没有细节显示。

• FontForge

  

  大部分 TTX 的功能也都可以用 FontForge 实现，虽然界面是基于 Xlib 的相对老旧，但它的功能实在是强大，不过我一般也就用来编辑字体的 name table 和 OpenType feature。

• hb-view

  harfbuzz-ng 提供的工具，可以用指定的字体、指定的 OpenType 特性，将 HarfBuzz 排版好的内容以 FreeType 渲染出来，方便对比测试特性字符串的布局正确性。当然，通常我还会用常见的浏览器、文本编辑器等来比较，尤其现在 Firefox 和 IE10 TestDrive 支持 OpenType 特性指定了，测试起来就更方便。

• fc-list, fc-match

  fontconfig 提供的工具，主要用来分析 Linux 下的字体匹配，在阅读它的用户文档之后，善用 -v 和 -a 参数，可以直接获得不少字体的信息。

• Pixie

  

  Xcode 自带的屏幕放大镜，用来分析 subpixel antialiasing 非常给力。别的平台下当然也有类似的工具，比如我在 Linux 下用 KDE 的 kmag。

• The Font Game, Kerning Game 和 letter shaping game

  三个制作非常精良的字体相关小游戏，第一个是 iOS 上的字体辨识，后两个则是体验对间距形状把握的 HTML5 在线游戏，适合在开发之余放松一下大脑

随着硬盘上收集的电影多了起来，怎么管理它们就成了问题，我之前采用的方法很简单：先把电影下载到内置的硬盘上，然后把看过之后觉得值得保留的那些，或者还没来得及看，但内置硬盘空间不够的时候，转移到外置硬盘 (一般是大容量的仓库盘) 上。一般这样的仓库盘就直接在根目录下分个 Movies 目录，然后所有的电影每个占一个目录，全部按它们原来的名字移动到这个 Movies 下面。类似这样：

$ cd /Volumes/Foo/Movies
$ ls
Apocalypto.2006.720p.BluRay.x264-ESiR
Gake.no.ue.no.Ponyo.2008.BluRay.720p.DTSES.3Audio.x264-CHD
Lock.Stock.and.Two.Smoking.Barrels.1998.720p.BluRay.x264-CYBERMEN
Mission.Impossible.1996.720p.BluRay.DD.x264-ESiR
Surrogates.2009.720p.BluRay.x264.DTS-WiKi
...

而自从 XBMC 被移植到 Mac 上以来，就开始关注这个软件内置的多媒体管理功能，毕竟大部分多媒体文件不是从 iTunes Store 上买的，所以 FrontRow 并不那么合用，而这个软件从功能全面和界面美观的程度上看都合适。不过之前一直都在用 Plex 这个 fork 版本，因为 Plex 确实对 Mac 相关的一些细节处理的比较好点，但也只把它当作一个单纯的媒体播放器来用，并没有用到它的库管理功能。主要是因为 XBMC / Plex 要求的命名方式是“标题 (年份)”这样的类 imdb 方式，而我又想保留原有的目录名 (方便找字幕什么的)，所以一直没有实施。

更新：发现 XBMC 还能根据目录下放置的 nfo 文件中的 imdb 地址来查找，而且这样更精确，所以假如你每个目录都保存了 nfo 文件，可以不必修改目录的命名。

最近想到的取巧做法是，对每个这样的电影目录，都在本地目录建立一个符合 XBMC 命名规范符号链接，然后让 XBMC 对这个本地目录进行索引。于是写了这么一个脚本 试了一下，果然很方便，效果如图：

这里简单介绍一下步骤，供有兴趣的朋友参考：

1. 推荐使用最新的 XBMC 9.11 版本，Plex 最新的 0.8.5 版本这方面支持得不好；

2. 图中使用的是 Rapier 这个 skin，需要单独下载，推荐使用；(下载后将解压得到的目录移动到 ~/Library/Application Support/XBMC/skin 目录下，然后在 XBMC 的 Settings -> Skin 中选择 Rapier)

3. 下载前面提到的这个 makelib.py 脚本，使用方法如下：

   $ chmod +x makelib.py
   $ ./makelib.py /Volumes/Megatron/Movies ~/Movies
   Apocalypto.2006.720p.BluRay.x264-ESiR -> '/Users/jjgod/Movies/Apocalypto (2006)'
   Gake.no.ue.no.Ponyo.2008.BluRay.720p.DTSES.3Audio.x264-CHD -> '/Users/jjgod/Movies/Gake no ue no Ponyo (2008)'
   Mission.Impossible.1996.720p.BluRay.DD.x264-ESiR -> '/Users/jjgod/Movies/Mission Impossible (1996)'
   Surrogates.2009.720p.BluRay.x264.DTS-WiKi -> '/Users/jjgod/Movies/Surrogates (2009)'
   The.Cove.2009.LIMITED.DVDRip.XviD-AMIABLE -> '/Users/jjgod/Movies/The Cove (2009)'
   ...
   

   这么做的效果是扫描 /Volumes/Megatron/Movies 目录下所有匹配的目录，在自己的主目录下的 Movies 目录中建立对应的符号链接。

   需要注意的是，这个脚本会要求所有内容都是目录，而且命名都是 Movie.Title.Year.*.*.*.-Group 的格式，中间一段可以任意，但必须包含年份和小组后缀，如果你手头存的目录名称不规范，必须先修改为这种格式，有的来源目录名称就不包含年份，这时可以根据 themoviedb.org 或者 imdb.com 提供的年份来自行添加。如果要求不那么规范，可以修改脚本来忽略小组。另外还要注意的是，Director’s Cut, DC, Unrated, Limited 这样的词必须放到年份后面，要么自己改改脚本，过滤掉它们也行。

4. 打开 XBMC，进入 Videos 部分，选择 Add Source，用 Browse 选择这个 ~/Movies 目录，在 Set Content 中，选择用 themoviedb.org 作为内容来源，选上 Use folder names for lookup，如图：

   

5. 然后 XBMC 就会开始索引所有创建好符号链接的目录，如果能在 themoviedb.org 上找到对应记录，就会自动下载。这个时候你切换到 XBMC 的 Movies 部分，就能看到如前面截图一样的效果了。选择其中任何一个，按回车就会开始播放。按 c 键或者用 Apple Remote 的 menu 按钮则可以打开上下文菜单，这里可以编辑选定项目的信息、删除特定项目 (如果导入的内容不对)、设置已经看过的标志等等。注意在 XBMC 扫描的时候不要断开存储实际内容的硬盘，否则 XBMC 会认为本地存的是无效的链接而直接跳过。如果出现个别电影名称不规范导致找不到对应记录的，可以在更名后按 c 选择重新扫描。

6. 如果你下载了新的内容，可以再次以同样的参数运行前面提到的脚本，这个脚本会跳过已经添加的内容。另外，还可以在 XBMC 的 Settings -> Videos -> Library 部分选上 Update Library on Startup，这样每次启动 XBMC 的时候就会自动扫描你添加为库的目录，检查是否有新的内容了。

这两种方式各自有各自的优点和缺陷：

MacPorts 基于源代码的管理优点是非常灵活，更新很快 (很多时候更新只需要修改一下 Portfile 里的版本号和压缩包校验码就可以)，用户要订制安装也可以简单的通过修改 Portfile 实现，而且很多开源软件的安装配置会有多种模式 (典型的大都通过 configure 步骤配置)，在 MacPorts 中可以方便地通过 variants 参数指定，而不必像二进制分发那样，在远程服务器上编译的时候就定死了。而 MacPorts 的问题是，它希望自己安装的每套软件，所有的依赖都在它自己这个系统内 (一般就是你的 /opt/local) 解决，就算 Mac OS X 系统原生自带了满足依赖的库，它也坚决不用，这样就给你的系统增加了许多冗余，也客观增加了管理上的难度，典型的情况是：你的系统里装了两套 Python，该怎么管理外部安装的 Python 模块？比如通过 easy_install 或 setup.py 安装的，往往很难记住到底装到哪里了。

而 Fink 虽然不会这么自作主张地添加依赖，最大的问题是更新不够及时，这也是缺乏维护人手导致的。二进制安装的缺点在上面也提到了：不便定制。

所以 Homebrew 的出现，也许不是很及时，但在现在仍然是很必要的，它有这么一些优点：

1. 尽可能的利用你的系统里自带的库，包括 zlib, OpenSSL, Python 等等，只要 Mac OS X 自带了，它就不会另装一份。

2. 定制简单，通过用 Ruby 写的 Homebrew formula 来定制，甚至可以灵活的跟踪直接来自版本管理库的最新软件

3. 用 Git 管理和同步自身

4. 直接装在 /usr/local 下，这样可以少定义很多各种 PATH 环境变量

其中第一点尤为重要。好的，下面简单介绍一下 Homebrew 的安装，以及它是如何工作的。

安装

首先，Homebrew 的原则是“No sudo”，也就是说，既然 Mac OS X (client 版本) 绝大部分情况下都是归你这个有管理员权限的用户，为什么在自己的 /usr/local 下安装程序还需要 sudo 呢？所以，首先：

sudo chown -R `whoami` /usr/local

然后可以正式开始安装，我推荐的安装方式是先用 git-osx-installer 装上 git，然后用 git 安装：

cd /usr/local
git init
git remote add origin git://github.com/mxcl/homebrew.git
git pull origin master

这么做的实际作用是把你的 /usr/local 目录变成了一个本地 git 仓库，只不过这个仓库只跟踪跟 Homebrew 相关的更新，并不影响任何其他软件的安装。

这样安装会在 /usr/local 下创建 Library 这个目录，然后在 /usr/local/bin 中加入 brew 这个 ruby 脚本。

使用

安装完毕，下面就可以试试了：

brew search

这个命令用来搜索所有可以通过 homebrew 安装的软件，不带任何参数的时候就是列出所有的。可以看到数量已经不少了。

下面就是选择安装，比如我想安装 unrar：

$ brew search rar
gnu-scientific-library     unrar

$ brew install unrar
Warning: It appears you have Macports or Fink installed
Although, unlikely, this can break builds or cause obscure runtime issues.
If you experience problems try uninstalling these tools.
/usr/local/Library/Formula/unrar.rb:3: warning: already initialized constant ALL_CPP
==> Downloading http://www.rarlab.com/rar/unrarsrc-3.9.4.tar.gz
######################################################################## 100.0%
==> g++ -O4 -march=core2 -mmmx -msse3 -w -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE all.cpp -o unrar
/usr/local/Cellar/unrar/3.9.4: 3 files, 320K, built in 13 seconds

可以看到，unrar 被安装到了 /usr/local/Cellar/unrar/3.9.4 这个目录下，但这样我们访问起来显然很不方便，所以 Homebrew 会在 /usr/local/bin 下面创建到 unrar 程序的符号链接，如果安装的是库之类的，也会对应在 /usr/local/lib 这样的目录下创建符号链接。所以这是一套类似 GoboLinux 的软件管理方式。

安装后就可以用 list 命令列出：

$ brew list
pkg-config  unrar

更新

如果用了一段时间，需要更新同步上游的 Formula，可以简单地：

$ brew update
From git://github.com/mxcl/homebrew
 * branch            master     -> FETCH_HEAD
Updated Homebrew from 60600885 to 60600885.
No formulae were updated.

Homebrew 会通过 git 完成同步。

总结起来，Homebrew 是一套很有新意的软件包管理工具，虽然它的更新及时程度还有待考验，但至少在目前还是比较令我满意的解决方案。

Wii 现在大家一般都软解后用 USB Loader，这个一般无非是把下载下来的游戏镜像文件复制到移动硬盘里的 WBFS 文件系统中，在 Mac 下，WBFS for MacOS X 是最方便的工具。偶尔需要提取 Wii 游戏光盘镜像时，wiiscrubber-ng 是个不太完全的移植，我略作了一点修改。

PS2 无非是刻盘，这个用系统自带的 Disk Utility 就可以胜任。

Xbox 360 的刻盘稍微无法一点，因为是双层 DVD，有时需要设置分层点，iBurn360 或者 OSx360 都可以设置分层点进行刻录，其中 OSx360 在刻录新的 Wave 3 游戏时，需要去掉“Require Stealth Verification”选项。

PSP 偶尔需要转换 CSO 和 ISO 格式，Prometeus 是一个很好的工具。

NDSL 没什么可说的，使用了烧录卡后就是往 TF 卡里复制游戏而已。

$ cat dump.sh
#!/usr/bin/env bash
DISK=`hdiutil attach -noverify $1 | awk '/Apple_partition_scheme/ { print $1 }'`
dd if=$DISK of=$2 bs=512 count=`hdiutil pmap $DISK | awk '/WINDOWSSUPPORT/ { print $6 }'`
hdiutil detach $DISK

使用方法:

$ ./dump.sh snowleopard_10a354_userdvd.dmg bc.iso

• 使用手动安装，也就是一个独立的 .app，里面通过 @executable_path/../Frameworks/ 的方式链接所有依赖的第三方库，也就是说，不往系统相关目录里乱放东西。这是 Apple 官方的 Software Delivery Guide 中推荐的安装方式。
• 支持用 Sparkle 这样的自动更新框架，实际上符合上一点的也就自然可以用 Sparkle 完全自动的完成更新。
• 用 .zip 格式分发。为什么不用 .dmg？因为 .dmg 不容易直接解压，挂载速度比 .zip 慢得多，增加拖动的手续，所以我支持这篇 zip vs dmg 的观点。

但是如果遇到特殊的情况呢？比如你写的是一个非得往系统目录 (/Library/...) 安装内容的软件呢？比如我最近参与改进的 SunPinyin 输入法，就必须打包为 Installer 支持的 .pkg 格式安装了，否则很难确保软件被正确的安装。

关于这个打包方式，最重要的一点心得是：千万不要用 Apple 自己提供的 PackageMaker，这恐怕是 Apple 开发的最恐怖的一个开发辅助工具了，因为：

• 它必须用图形界面修改内容
• 它保存的 .pmdoc 格式非常混乱，而且居然喜欢把绝对路径存入文件中
• 不支持 Installer Plugins 扩展

那替代的工具是什么呢？是一个非常棒的第三方工具: Iceberg，它能：

• 打包出 Mac OS X 10.2+ 以上都支持的 .pkg bundle 格式
• 界面比 PackageMaker 友好得多，而且有非常详尽的文档，也很方便调试
• 支持 Installer Plugin

涉及打包、Sparkle 的 appcast 自动生成，Iceberg 的使用等问题，都可以参考 SunPinyin 目前使用的代码。

使用步骤如下：

1. 如果没装过，先安装 SIMBL；

2. 下载 SafariURLFix.zip，解压后，放到 ~/Library/Application Support/SIMBL/Plugins 目录 (如果没这个目录就自己创建)；

3. 在 Terminal 中输入:

   defaults write com.apple.Safari JJURLsToFix -dict newsmth.net GBK

   其中 newsmth.net 为你希望应用修正的网站域名。也可以打开 ~/Library/Preferences/com.apple.Safari.plist 文件自己编辑 JJURLsToFix 这个 Dictionary，自行添加新的，见附图。

4. 重新启动 Safari，尝试下载这样的文件，看看文件名是否被正确纠正了。

如果还有什么问题，欢迎在下面提出。

昨天看到 Apple 版上的一篇文章，便想起来试试 Page ’09 新增的 AppleScript 功能，其实用到的功能在之前的 Pages 版本中应该也有，不过我手头没有更早的版本，所以无法试验了。可以点这里看完整的脚本，其实核心代码非常短：

from appscript import *
pages = app(id="com.apple.iWork.Pages")

for doc in pages.documents():
    words = doc.words()
    i = 0

    for word in words:
        i += 1
        if isch(word[0][0]):
            doc.words[i].font_name.set("SimSun")

这个脚本没有直接用 AppleScript，而是通过第三方提供的 py-appscript 接口来调用 (它的语法比 ScriptingBridge 要友好很多)，作用是，扫描所有 Pages 打开的文档，把所有的汉字的字体设为 SimSun，因为仅仅作为一个示例，所以没有加任何参数。

使用方法是，先安装 py-appscript，然后打开 Pages，随便输入一段中文和英文混杂的文字，比如刚才的“在50ml的PBS缓冲中加入15mg的HCl使得最终pH为5”这句，一开始加入时因为默认字体是 Helvetica，所以英文字母和数字都用了 Helvetica，汉字则使用了 Helvetica 的默认 Fallback, 也就是 STXihei，如下图所示。

然后运行:

python format-pages.py

这时候切换回 Pages 就能看到效果，如下图所示。

其实这个脚本还可以做很多其他的变化，比如加入界面来选择字体、只是转换当前选中的部分等等等等，至少了解一点 AppleScript 的调用方式就可以尝试，这里不赘述了。

昨天碰巧翻到一个叫 CoreAVC for Linux 的项目，其实应该之前很早就听说过，因为这个项目在去年五月份的时候曾经被 Google Code 停止提供服务，因为“DMCA complaint”，但现在又恢复了，不过可能 patch 更新得不够及时，不一定能够用在 svn HEAD 的 mplayer 上。

CoreAVC for Linux 到底是个怎么样的项目呢？众所周知的是，CoreAVC 是目前公认软解 H.264 效率最高的解码器，在 Windows 平台有提供，价格是 $15 (不过大部分 Windows 用户都用破解版本的)。开发这个解码器的公司还把它移植到了 Palm, Symbian, Windows CE 等平台上，是移动平台中最有名的一个通用播放器，叫 CorePlayer。

从去年二月开始，CorePlayer 被移植到了 Windows 和 Mac OS X 平台上，但官方没有提供给 Mac OS X 平台的 CoreAVC (假如有的话，应该是 Perian, Flip4Mac 那样作为 QuickTime 插件的形式，但不知道这个公司出于什么考虑，并没有像 Windows 平台那样提供)。而 Linux 平台下也没有提供公开销售的版本。所以 CoreAVC for Linux 就是为了能在 Linux 平台下使用这个解码器而产生的。

虽然细节比较复杂，我现在也不大了然，但原理也不难理解，修改 mplayer 的 DirectShow 支持代码，类似调用 RealMedia 的 DirectShow 插件那样来调用 CoreAVC 的 DirectShow 插件。开发者说有两种修改方法：

1. 使用一个外部程序 dshowserver 来提供服务，修改 mplayer 使之能够支持 dshowserver，这种方法能够适用于 x86_64 和 ia32
2. 直接修改 mplayer 的 Win32 dshow 代码使之支持 CoreAVC，只适用于 ia32

作者说第一种是推荐的方法，但不能用于 Windows 和 Mac。而第二种完全没有提到具体步骤，也没见到具体的 patch。

正巧看到 CorePlayer Pro for OS X，虽然没提供试用版本，但好在也不算贵 ($17)，就买了一个试试。下面是一点结论：

1. 最大的问题是音频解码支持很弱，不支持 AC3 解码，不支持 DTS 解码，而且发布之后一年内始终没得到解决，开发者很有点言而无信，一开始在去年二月说“数周内”能解决，到 12 月还没提供，又改说我们可能要依赖平台提供的功能实现 (Windows 下用 DirectShow, Mac 下用 Core Audio)，这也没问题，可这都二月了，还没解决。感觉相比移动平台，这个公司并不怎么注重桌面平台的支持。

2. 界面很土，非要做跨平台的界面，结果用起来非常不方便，更不用说完全不 Mac 化了。

3. 解码 H.264 的效率确实比其他任何 Mac 平台的解码器都要好，手头一个 1080p 的 Fight Club 的 BDRe, 用 Plex 时的 CPU 占用率在 120% ~ 150% 左右，用 CorePlayer 时占用率在 75% ~ 80% 左右。

4. 不支持外挂字幕，而且短期内不打算支持。

总的说来，我觉得他们最大的决策错误就是不提供单独的 CoreAVC，非要自己做播放器，结果给自己带来了过重的开发负担，比如界面、音频编码器这些，如果只提供一个 QuickTime 插件，就压根不需要他们操心了。H.264 的解码效率是好，但也没有好到超过一个数量级的程度，在 Snow Leopard 和新一代 Mac 提供了显卡硬解码支持的背景下，就更难让人看好这个产品的前景了。