Programming
更新: 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 的，每次我要用到这些 [...]
虽然我认为花 $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] [...]
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
更新: 刚刚设立了一个 [...]
在使用 Safari 的时候，我们会注意到一个很常见的乱码问题，如下图:
这是在打开 http://att.newsmth.net/att.php?p.719.214628.536.png 这样的图片链接时，Safari 错误的判断了这个图片文件的文件名造成的。而为什么会有这样的错误判断呢？
其实 Safari 使用的是 Cocoa 框架 [URL Loading](http://developer.apple.com/documentation/ Cocoa/Conceptual/URLLoadingSystem/URLLoadingSystem.html) 架构中的 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 [...]
© jjgod / blog. Powered by WordPress using the DePo Skinny Theme.