Wudi's Blog: PHP

文件最优分配算法

Sun, 25 Jun 2006 09:50:07 GMT

这个功能是 WUSN 2 中的，三月份就写好了，现在把它整理出来，以便参考。

算法本身很简单，但经过实际使用，发现分配结果还是很理想的。

<?php
$size_container = 713031680; // 680MB
$size_toosmall = 8388608; // 8MB
$discs = array();
$items_overflow = array();
$items_toosmall = array();
$items = array(
array('id' => ID 1,
'size' => Size 1),
array('id' => ID 2,
'size' => Size 2),
...
array('id' => ID n,
'size' => Size n)
);
usort($items, 'sort_by_size_desc');
foreach ($items as $key => $item) {
if ($item['size'] > $size_container) {
$items_overflow[] = $item;
unset($items[$key]);
} elseif ($item['size'] < $size_toosmall) {
$items_toosmall[] = $item;
unset($items[$key]);
}
}
while (count($items)) {
reset($items);
$key = key($items);
$item = current($items);
$disc_ids = array($item['id']);
$disc_size = $item['size'];
unset($items[$key]);
foreach ($items as $key => $item) {
if (($disc_size+$item['size']) <= $size_container) {
$disc_ids[] = $item['id'];
$disc_size += $item['size'];
unset($items[$key]);
}
}
$discs[] = array('ids' => $disc_ids, 'size' => $disc_size);
}
echo '<pre>';
print_r($discs);
print_r($items_overflow);
print_r($items_toosmall);
echo '</pre>';
function sort_by_size_desc($a, $b) {
return ($a['size'] < $b['size']) ? 1 : -1;
}
?>

PHP 5.1.4 气死我了

Sat, 20 May 2006 04:18:51 GMT

前一段时间我的 Files 中有一些应用程序产生了异常，比如 Media Player 中某些音乐的歌词加载不正常，Highlighter 中看不到文件内容。我一直以为这是网络问题引起的，比如主机名解析错误，或者是被安装了间谍软件，就朝着这个方向查找问题，但一直没找到问题。

今天经过一阵忙活，最后发现这个问题居然是 PHP 5.1.4 引起的，降低到 5.1.2 版后一切正常。

PS，5 月 1 日 PHP Group 就发布了 5.1.3 版，没过几天又发布了 5.1.4 版来修正 5.1.3 版中的一个紧要的错误，后来不知哪天又说上次 PEAR 的 phar 文件没有打包进去，又更新了一次。

Miranda IM Database Reader 项目地址

Sat, 08 Apr 2006 13:26:43 GMT

SourceForge.net:

http://sourceforge.net/projects/mimdbreader/

PHP Classes:

http://www.phpclasses.org/browse/package/3010.html

Miranda IM Database Reader 已提交

Fri, 31 Mar 2006 12:19:57 GMT

MIM DB Reader 是一个可以读取 Miranda IM 数据库的 PHP 类。因此你可以获得联系人设置、聊天记录等有用的信息。

----

这次除了 PHP Classes，还提交到了 SourceForge.net。

sf.net 的应该能先批下来，PHP Classes 的可能需要较长的时间才能批完。

系统各组件简介

Thu, 23 Mar 2006 13:44:46 GMT

Commons

Commons 是系统的中心，实现一些多个程序都会用到的功能，也起到一定的沟通作用。

现在 Commons 的功能较少。仅含有通用文件访问和相关资源查询及处理。

Contacts

Contacts 用于管理联系人信息。其中的所有联系人的姓名都会被用做相关资源里的关键词。

联系人的所有信息均用序列化的关联数组存储，因此信息组织比较自由。

Contacts 支持联系人照片存储，照片的数据存储在 Files 中。

导入程序手机导出的联系人时，处理联系人的照片。导出程序则支持多种格式，完全按照自己的习惯导出，例如为手机导出的联系人的名称可以选择使用“职务，姓名”的格式。

另外，带有生日的联系人的 ID 及生日会提供给 Events，供生日提醒使用。

Events

Events 用于记录各种事件。包括已发生的，将要发生的，固定时间发生的，可能会发生的。

已发生事件主要作回顾用，也可为未来发生的事作一些参考。

将要发生的事件用来作日程安排。

固定时间发生的事件用来作提醒，比如提醒某人哪天过生日。

可能会发生的事件，则是自己的一些猜测，待日期到后看猜测是否准确，纯属消遣。

Files

Files 用于管理文件。它支持虚拟目录（即直接访问 Web 服务器的磁盘）。

照片，文档，音乐，代码等文件均放置其中。各种应用程序可妥善管理。

例如针对照片有在线注释程序，针对音乐有支持歌词同步的播放器。

Resources

Resources 用于查找与处理网络资源。现在可从一些门户网站查找电影、电视及音乐的更新信息。

这样就可以不用关心电影、音乐的相关消息，让程序去发现。自己要做的只是选择对这个资源的处理方式。

Search

Search 用于搜索本地硬盘内的文件，以及系统中的各种信息。

WUSN

WUSN 用于编号与管理资源。

写一下我的系统的构成

Thu, 23 Mar 2006 13:27:32 GMT

写一下我的系统的构成，也方便自己看。

整个系统的主旨是 记录与享受 (Record & Enjoy)。包含如下组件：

Commons —— 系统中心

Contacts —— 联系人管理

Events —— 事件记录

Files —— 文件管理

Resources —— 网络资源查找与处理

Search —— 信息搜索

WUSN —— 资源编号与管理

以及如下 PHP Class：

Fast Chinese Word Segmentation —— 快速中文分词，用于 Search，目的是避免一些交叉歧异

Gender Guesser —— 性别猜测，用于 Contacts，目的是导入联系人信息时自动补充性别信息

Specified Strings Picker —— 指定字符串提取，用于 Commons，目的是提取文本中的名人姓名

又有一段时间没写了

Thu, 09 Feb 2006 04:30:23 GMT

对近来遇到的问题做一下总结：

设计 passport 时，发现在 Firefox 下提交的 hmac_sha1() 过的数据都是错误的。最后发现是由于属性书写不规范，img 标签中的 src 属性没有值，即“<img src width=...”。为 src 属性加上值后一切正常。
如果设置的 Cookie 的存活期很短，需要特别注意一下。因为设置 Cookie 的头是由服务器发出的，到期时间是由服务器时间加上存活期得到的。如果客户端的时钟比服务器端走的快，而存活期又很短，Cookie 可能会直接过期。
动态加载 CSS 文件可以使用 styleSheet 对象的 addImport 方法。
动态加载 JS 文件可以通过向 HEAD 中添加 defer 属性值为 true 的 script 对象。(See Also)

用 PHP 写离线浏览程序

Wed, 25 Jan 2006 07:18:33 GMT

借助 XMLHTTP，我们可以很快速地制作一个离线浏览程序。步骤如下：

1. 发送请求，服务器端下载网页代码，生成 MHT 文件的头部信息和首网页的数据并写入文件。解析出所有图片及链接文件的 URL，返回给客户端。

2. 客户端收到 URL 列表后，建立 N 个 XMLHTTP 对象，并依顺序发送请求，补充网页中包含的文件的内容。

3. 所有 URL 处理完毕后，MHT 文件中的数据也已添加完整，离线浏览用的文件就生成了。

总结

Sun, 22 Jan 2006 09:00:36 GMT

对编写 Files 的过程中遇到的问题，总结与记录一下：

尽量不要搞特殊。文件名中不能含有 * ? | : " 等字符的常规最好还是要遵守，即使现在不会引起错误。
目录最好单建一个表存储，有利于操作。若只在文件信息的表中记录路径，空文件夹会带来很多问题，通常会使问题变得很复杂。

文件系统函数库和目录函数库仿真类基本完成

Thu, 19 Jan 2006 13:37:11 GMT

现在支持 basename, copy, dirname, file_exists, file_get_contents, file_put_contents, filemtime, filesize, filetype, is_dir, is_file, is_writable, mkdir, rename, rmdir, unlink, opendir, readdir, closedir, scandir 这些函数。函数的参数及返回值与 PHP 内置的函数基本相同。

数据库部分共使用 4 个表: cache, file_index, file_storage, path_index。其中 cache 表存储缓存，加速列表的速度；file_index 表存储文件索引，包含文件所在文件夹的ID、文件大小、最后修改时间等信息；path_index 表存储文件夹的信息。对于比较小的文件，程序默认将其保存在数据库中，加快读取速度；比较大的文件则保存在磁盘上。均使用 MD5 HASH 值作为标识符。

Gender Guesser 已发布

Fri, 11 Nov 2005 23:52:29 GMT

Gender Guesser:

http://www.phpclasses.org/browse/package/2701.html

我在 PHP Classes 发布的所有 Class:

http://www.phpclasses.org/browse/author/168501.html

根据姓名判断性别

Sat, 22 Oct 2005 15:51:58 GMT

今天从网上收集了 5000 个姓名的性别信息，做了一个程序来根据姓名判断性别。

经过测试，准确率还不错，和人类识别的效果基本相同。过两天有时间发布到 phpclasses.org 上去。

使用 AJAX 的同时令浏览器的后退按钮生效

Tue, 04 Oct 2005 01:46:37 GMT

在 WUSN 中，我使用 JavaScript 的数组来记录每次请求结果，来实现前进、后退功能。

后来看到 GMail 利用的是浏览器的前进、后退按钮，觉得还是这样操作更自然些。于是利用 Firefox 的 DOM 查看器试图分析 GMail 的机制。无奈其 JavaScript 代码都已进行了降低可读性的处理，而且结构复杂，没有找到它的实现方法。

最后，还是自己想了一个方法来解决，不知是否合适。如果您有更好的方法，欢迎提出来。

以下是我的实现方法：

在主页面的底部增加（注意蓝色部分）：

<div id="obj_act" style="position:absolute;left:-200px;top:-200px;visibility:hidden;" onClick="if(this.innerText=='R'){action_refresh();}else if(this.innerText=='L'){window.location.reload();}else if(this.innerText.substr(0, 8)=='REQUEST:'){request_get(this.innerText.substr(8));}"></div>
<div style="position:absolute;left:-200px;top:-200px;visibility:hidden;"><iframe id="obj_his" width="1" height="1"></iframe></div>

每次请求时，改变 obj_his 的 src 属性：

function request(uri) {
document.all.obj_his.src = "history.php?uri=" + encodeURIComponent(uri);
}

history.php 收到请求后，输出：

......
function act() {
parent.document.all.obj_act.innerText="REQUEST:<?php echo addslashes($_GET['uri']); ?>";
parent.document.all.obj_act.click();
}
......
<body onLoad="act();">
......

这样，主页面的 obj_act 的 innerText 属性的值就变为了“REQUEST:......”，在触发其 click 事件后将执行 request_get("...")，这样便达到了发送请求的目的。

点击浏览器的后退、前进按钮时，操作的其实是 obj_his，而每个 obj_his 中都含有控制主页面请求 URI 的代码。这样就利用了浏览器的前进、后退按钮。

PS，你可能会注意到我是通过 document.all 这个 IE Only 的对象来获得对象的，按照标准应该使用 getElementById()。但是 Contacts 程序本身包含了很多 Web 页对话框，这决定了现阶段这个程序只能在 IE 下使用。

Contacts 初步完成

Mon, 03 Oct 2005 14:44:57 GMT

经过十天，特别是这两天的努力，Contacts 已经初步完成了。别名、重名（消歧异）、排序等问题都已解决，而且联系人信息很灵活，可以随意增减、调序。

用序列化的对象存储电话号码等序列数据

Mon, 26 Sep 2005 09:22:12 GMT

昨晚背书时突然想到，可以用 serialize() 函数序列化一个存储电话号码的数组对象，将返回的字符串存到数据库中来存储电话号码。这样比另建一个表并通过外键联系高效，程序也容易处理。

另外，用序列化的对象存储信息，也容易扩展。比如某一个联系人需要添加某一个特殊的信息，只要简单地在数组中增加一项就行了，否则可能需要再添加额外的字段。

PS，这个序列化函数也是前天和 andot 聊天时才知道的，以前一直不知道类似“a:2:{i:1;a:6:{s:15:"set_skin_set_id";……”的字符串是怎么生成的。

新想法

Thu, 22 Sep 2005 09:18:28 GMT

最近又冒出来几个新想法，这样排在队列中的程序就有 Contacts, Commons, Gallery 三个了。

Contacts 就是前几天说的那个联系人管理程序，Commons 是管理共享资源的程序，Gallery 是用来管理图片的。打算 Commons 使用数据库来存储文件，Gallery 的图片直接存在磁盘上。

好像现在有不少好的 Gallery 程序，但是改别人的程序比自己写要累的多，为了以后能根据自己的需要增加功能，决定还是自己写一个。

Contacts

Mon, 19 Sep 2005 16:00:30 GMT

早就想做一个联系人的管理程序了，但一直懒得动手。现在 Events 基本功能都实现了，记录的事件中含有不少的人名，这就需要一个联系人的程序来配合。

新的标记语言

Sat, 17 Sep 2005 15:10:02 GMT

以前使用的 WPL (Wudi Personal Label) 的扩展性不强，每次增加功能都需要添加新的标签，而且在不同程序的连接上有欠缺。

新的标记语言的语法和 MediaWiki 的类似。外部链接使用[url]，内部链接用[[Namespace:...]]，扩展功能使用{{name|...}}。这样增加新的功能时，只要添加相应的名字空间就行了。

Lexicons for Chinese Word Segmentation

Wed, 17 Aug 2005 12:43:01 GMT

Fast Chinese Word Segmentation:

http://pickup.mofile.com/7207178715932947

MP Chinese Word Segmentation:

http://pickup.mofile.com/9789759588639069

MP Chinese Word Segmentation v0.02.0

Thu, 11 Aug 2005 12:12:30 GMT

http://www.phpclasses.org/browse/package/2508.html

最大概率法中文分词，审核后就能看到了

PS，发现如果用相同的词库，最大概率分词法和逆向最大匹配法的分词结果差不多只有不到 1% 的地方不同。

SCWS 改名

Thu, 11 Aug 2005 12:07:30 GMT

Simple Chinese Word Segmentation 改名为 Fast Chinese Word Segmentation

随后发布 Fast Chinese Word Segmentation v0.05.2

开始研究最大概率法分词

Tue, 09 Aug 2005 12:40:54 GMT

现在就是担心速度啊。因为已经发现 Win32 下 Apache + PHP 不能用共享内存函数了。

Articles

Mon, 08 Aug 2005 10:36:45 GMT

上个月月底 Articles 项目就开始了。现在只是简单的列表查看，还没有搜索等功能。通过两个小时的抓取，已有 3 万多篇中学作文。

我打算 Articles 的搜索使用单词索引，这样搜索时能提高速度，结果漏一篇两篇无所谓。

表. 建立索引搜索和直接搜索内容的区别

项目	建立索引搜索	直接搜索内容
搜索速度	非常快	慢
搜索结果	可能有遗漏	无遗漏
对英文区分大小写	通常不能	能
精确匹配标点符号	通常不能	能

SmartTemplate?

Tue, 02 Aug 2005 16:13:47 GMT

今天看到 MeagerAvenger 发表的评论，让我看看 SmartTemplate。

其实几天以前我的模板就换成类似 Savant3 的了。自己写的 2KB 左右的类来驱动，觉得这样自定义方便，速度也快。

关于模板引擎

Wed, 27 Jul 2005 16:28:37 GMT

今天看了这篇文章（Template View）后，打算自己开发一个轻型的模板引擎。模板不编译，直接使用 PHP 语言写，这样运行速度快，而且模板书写灵活。

上面提到的那篇文章中，提到这种类型的模板引擎存在的缺点主要是模板设计者可能不会或不喜欢 PHP 语言，而且这样可能不安全。但我自己非常喜欢 PHP 语言，由于程序全是自用的，模板全是自己写，也不存在安全问题。所以觉得用这种方式写模板挺好。

另外再说一句，其实比起那些模板中复杂的语法，我觉得 PHP 的语法真的是非常简单。如果都是初学，PHP 的语法并不一定比 Smarty, Flexy, TinyButStrong 之类模板引擎的语法难学。

考虑用 Smarty 了

Mon, 25 Jul 2005 15:40:45 GMT

最近在开发搜索引擎时，发现现在用的自己写的 2KB 不到的模板引擎（暂时就称作模板引擎吧）越来越不够用了，很多地方需要在 PHP 脚本中混入 HTML 才能实现。

所以考虑换成 Smarty，虽然效率会低一点，但能使程序代码精简，思路清晰，也值了。

传几个我的搜索引擎的截图

Mon, 25 Jul 2005 14:16:48 GMT

MSN Spaces 对图像的压缩太厉害了，字全是模糊的，所以传到论坛里了。

搜索页面，搜索帮助，搜索结果，图像搜索，Guess 功能

PHP Class: 简单的中文分词

Thu, 21 Jul 2005 13:14:13 GMT

http://www.phpclasses.org/browse/package/2431.html

由于 phpclasses.org 有单个文件最大 300KB 的限制，所以词典分成了 2 部分。

好几天没写代码了

Wed, 20 Jul 2005 01:16:17 GMT

这几天一直在忙活 Miranda IM。先是原有 QQ 协议插件不能使用了，必须重装用新的插件。

后来在写维基百科的条目 Miranda IM 时，从英文维基中看到 Miranda IM 将支持 SQLite 数据库。这下我的搜索引擎中的聊天记录索引部分就可以先放一放了，等支持 SQLite 时再写。

不过也没白忙活，装了 IEView 插件后，虽然内存占用从 12MB 增加到 20MB，但界面的确漂亮了很多啊~~

phpclasses.org 最近效率怎么这么低

Fri, 15 Jul 2005 16:20:21 GMT

我在北京时间 07/12/2005 中午就在 phpclasses.org 发布了我的 Simple Chinese Word Segmentation（链接）。现在都 07/16/2005 了，还没有审核完。

找到中文问题的解决办法了

Wed, 06 Jul 2005 04:55:35 GMT

在 PHPMyAdmin 中修改字段属性，字符集选 latin1，属性选 BINARY。这样字段的 Collation 就是 latin1_bin 了，问题就解决了。

在编制索引的过程中遇到了麻烦

Tue, 05 Jul 2005 14:30:33 GMT

MySQL 默认认为 “土人” == “外人” == “下人”，因此，当其中任意一个插入到词汇表中后，其他两个便无法插入了（`word_text` 有唯一性）。

无论怎么改字符集，都没有作用，插入的数据还会出现乱码。

我的桌面搜索系统

Mon, 04 Jul 2005 11:49:06 GMT

中文分词想做到这样就差不多了，毕竟是自己用。目的就是搜索“土人”不要把“风土人情”相关的内容搜出来就行。

接下来该做英文分词了。也不管动词时态和名词复数等问题了，能分开就行。因为全英文的数据基本都是程序代码。

把中英文分词都做完后，就该考虑如何建立索引了。

第三次修改后中文分词程序的分词速度

Mon, 04 Jul 2005 07:06:48 GMT

程序改动：不使用 PHP 中的 Multi-Byte String 函数，自己判断汉字

分词方法：逆向最大匹配分词法，只对中文字符进行分词

词库大小：73,226 个词

编写语言：PHP

分词速度：

99% 中文 —— 211 KB —— 2s —— 105.50KB/s (+ 92.32KB/s)

45% 中文 —— 2, 100 KB —— 22s —— 95.45KB/s (+ 66.69KB/s)

00% 中文 —— 413 KB —— 6s —— 68.83KB/s (+ 9.83KB/s)

我的中文分词程序现在存在的主要问题

Sat, 02 Jul 2005 11:41:07 GMT

为了避免出现乱码，我的中文分词程序使用了 PHP 中的 Multi-Byte String 函数。先通过 mb_strlen() 函数取得字符串的长度，然后利用 mb_substr() 把每个字符都存到一个数组里，再进行匹配。

这样效率就会降低很多。如果不使用 Multi-Byte String 函数，而是逐个判断每个字符是单字节还是双字节的，效率应该可以提高不少。

待有时间再研究汉字编码吧。

第二次修改后中文分词程序的分词速度

Sat, 02 Jul 2005 04:31:14 GMT

分词方法：逆向最大匹配分词法，只对中文字符进行分词

词库大小：73,226 个词（增加了 29,289 个词，但去除了单字和四字以上的词语）

编写语言：PHP

分词速度：

99% 中文 —— 211 KB —— 16s —— 13.18KB/s (+ 10.08KB/s)

45% 中文 —— 2, 100 KB —— 73s —— 28.76KB/s (+ 23.82KB/s)

00% 中文 —— 413 KB —— 7s —— 59.00KB/s (- 9.83KB/s)

我的中文分词程序的分词速度

Sun, 19 Jun 2005 09:00:22 GMT

分词方法：逆向最大匹配分词法，只对中文字符进行分词

词库大小：43, 937 个词或单字

编写语言：PHP

分词速度：

99% 中文 —— 211 KB —— 68s —— 3.10 KB/s

45% 中文 —— 2, 100 KB —— 425s —— 4.94 KB/s

00% 中文 —— 413 KB —— 6s —— 68.83 KB/s

逆向最大匹配分词法分词结果

Sat, 18 Jun 2005 17:29:26 GMT

刚才又试了一下逆向最大匹配分词法，结果比正向的要好：

今天在中文维基百科搜索 “ 土人 ” ，没有匹配的条目。搜索 “ 风土人情 ” ，找到了徐霞客这一条目，其内容含有 “ ... 业、手工业、交通运输、名胜古迹、风土人情，仍然具有很高的科学和文学价值。 ”

看来中文维基百科使用了中文分词技术，但不知是 zh.wikipedia.org 自己增加的独有功能还是 MediaWiki 中就有的功能。如果 MediaWiki 中就有此技术，那么假期时就可以参考一下它的程序了。

不过话说回来，除了搜索引擎，很少有搜索有中文自动分词技术的，做不成这个功能也无所谓。

后记：在自己机器上装的 MediaWiki 上测试了一下，结果是 — — 不支持中文自动分词。

试着写了一个中文分词程序

Sat, 18 Jun 2005 16:17:18 GMT

可以把上个日志项分成这样：

今天在中文维基百科搜索 “ 土人 ” ，没有匹配的条目。搜索 “ 风土人情 ” ，找到了徐霞客这一条目，其内容含有 “ ...业、手工业、交通运输、名胜古迹、风土人情，仍然具有很高的科学和文学价值。 ”

不过话说回来，除了搜索引擎，很少有搜索有中文自动分词技术的，做不成这个功能也无所谓。

后记：在自己机器上装的 MediaWiki 上测试了一下，结果是 — — 不支持中文自动分词。

由于用的是正向最大匹配分词法，所以效果不是很好。现在用的词库有 43932 个词。将来再改进一下算法吧。

中文维基百科的搜索

Sat, 18 Jun 2005 02:58:49 GMT

今天在中文维基百科搜索“土人”，没有匹配的条目。搜索“风土人情”，找到了徐霞客这一条目，其内容含有“...业、手工业、交通运输、名胜古迹、风土人情，仍然具有很高的科学和文学价值。”

不过话说回来，除了搜索引擎，很少有搜索有中文自动分词技术的，做不成这个功能也无所谓。

后记：在自己机器上装的 MediaWiki 上测试了一下，结果是——不支持中文自动分词。

中文分词技术

Fri, 17 Jun 2005 09:23:28 GMT

刚才搜索了一下“PHP 搜索引擎”，发现了很多搜索方面的难题。

现在中文自动分词技术只有一些专门研究这种技术的公司有，而且很少有公开源代码的，更别说用 PHP 写的了。

我的桌面搜索系统

Wed, 15 Jun 2005 09:49:42 GMT

最近有个计划，就是开发自己的桌面搜索系统。一是不会泄漏自己的信息，二是可以为自己量身定做。

Google 桌面搜索可以处理 QQ, MSN Messenger 及 AOL Instant Messenger 的聊天记录。但是我哪个程序都不用，而是用 Miranda IM 这个即时通讯软件，只要有协议的插件，就能支持。如果我自己开发桌面搜索系统，就可以把它加到索引范围里。

Google 桌面搜索支持的邮件客户端有 Outlook Email, Outlook Express, Netscape Mail 和 Thunderbird。很可惜，我用的是 Google 不支持的 Becky! Internet Mail。

还有，我从去年夏天开始就抛弃 Microsoft Office，转向 OpenOffice.org 了。一是因为 Microsoft Office 很贵；二是因为从 Microsoft Office XP 开始，我感觉 Microsoft Office 越来越臃肿了，界面看着也没有 2000 那么舒服；三是 Microsoft Office 文件的专有格式是不公开的。很可惜，Google 现在还不支持 OpenOffice.org 的专有格式。不过 OpenOffice.org 2.0 里的默认使用的文档格式是 Open Document，将来 Google 很有可能会支持这种开放的、规范的文档格式。

虽然我自己一个人写出来的搜索系统不如 Google 桌面搜索，但是因为用 Google 桌面搜索对我来说在软件支持及自定义方面有种种不便，所以我必须开发适合我自己的搜索系统。

Miranda IM 是开源软件，而且我用 Ultra Edit 看了看它的数据文件，应该能读取它的聊天记录。Becky 的邮件索引文件格式也比较简单。现在已经有了很多 Perl 的模块来解析 OpenOffice.org 的文档，PHP 的我还不太清楚。不过文档格式是开放的，问题就好解决多了。

最后说一下 Torrent 文件的解析。昨天在网上搜，发现了一个为 Discuz! 设计的解析 BT 文件的插件。但是下载下来一看，发现它是用 Zend Encoder 编译过的，就没什么参考价值了。于是又在国外找，发现了一个德国人写的 TorrentParse，用了一下，效果很好，就是感觉解析的稍微有点慢。TorrentParse - PHP 现在的最后更新时间是 2005-01-24。

不过这一切目前还只是计划，需要等到 7 月 3 日考完试以后再做。