采集是永恒的话题。

但我更愿意这种行为进化为“自动化信息整理”（这儿用“整理”而非“处理”）。

当前国内主流的有多种“小蜜蜂”及“火车头”，共同特点是“一切取决于采集规则”，这两个平台的在线论坛由此火爆，而康盛创想推出的X-Space原生即包含简单采集功能（有个特色小附加功能是自动判定和析出网页主体内容）。

1. 非采集器，但要求高微操能力
当前，我正着手构建一个大信息量的站点(zhonghuayixue.net)，网站主要是整理医学类的资源如医学图片、视频及软件、电子书、词条及论文。初步计划是先灌装和有效标记十万条左右数据，后期再进行程序及性能优化，逐步WEB2.0。

这些资源形式各有不同，信息源分散，大信息量的站点不多，更新亦不频繁。我考查了包括上面提及的几个采集器，不得不承认制作团队花费了大量的时间让信息整理变得简单，但恐怕仍然无法胜任我的要求——单独为不同站点编写不同采集规则，从性能及时间成本上均不划算，并且，采集器无法对付光怪陆离的防采手段，更重要的是，性能问题也很大。

我的实际解决方案是，整站下载软件OE＋文本编辑Editplus＋以vbs编写的wscript宿主脚本。首先下载指定站点（这个大概一分钟能指定一个下载项目，只需提前找到所有目标对象即可），Wscript再找出不同项目的不同规则，为不同项目形成不同的vbs文件（这个复杂一些，约需十五分钟），按模板分析所有既有页面文件，一般十五分钟至三十分钟可处理一个站点。一两周下来，大约积累了十万张医学图片。

后来考虑，恐怕这个完善一下就是一个基于脚本宿主技术的采集器:-），但比那些采集器缺的东西多了太多。

另外，同样需要注意性能问题——Wscript在处理正则表达式时，规则编写过于随便会导致每个信息页面的处理时间超过30秒！照此，若以四核的PC，一天也才能搞定三四千条记录。

但，这确实对终合技能要求过高，因此，普通编辑人员恐怕无法达到这样的速度要求——我在试图请一个朋友帮忙时，回应是：kolidon同学，这种高强度的活儿做得快我很羡慕，但一点都不高科技——无奈，话题又回到采集器应用上的问题上来。

2. 思路简单，但核心问题在于文本比较

自动对下载下来的文件进行比较，以发现相似之处，结合人工点击鼠标决选，或者会是一个比较不错的思路。

1) 支持命令行比较的开源软件winmerge进入视线。这儿是中文介绍。
2) 另一个开源文本比较器,TextDiff，在这儿http://www.angusj.com/delphi/textdiff.html (我一直在用的)
3) 冬blog，http://www.cnblogs.com/yuandong/archive/2006/12/18/596109.html
4) clariones：文本比较算法剖析（1）-如何确定最大匹配率

核心算法与图论有关，这个我需要进一步研究，但目前来讲，直接采用开源组件以获得不同的行即可。

那么，接下来：
1) 源文件尽可能多的换行；（遇标签换行即可）
2) 按行比较并找出最大匹配（尽可能多的文件扫描）；
3) 换行后的文本恢复到原始状态显示（只需记住在何处添加了换行符即可），但高亮不同部分（不同次数越多，颜色越深），用户点选鼠标，将自定标签拖到高亮位置以确认选定（每标签被拖至位置后可填写进一步参数）；
4) 系统根据参数生成规则文件。

目前是思路，实际操作估计比这个稍复杂一些。

2009年7月update：拿到了一套2004年左右的基于java的商用采集产品，似乎也努力想要实现多路源比较找出模板的功能，可惜不太成功。若有时间，kolidon将反编译之以研究其类库结构并找出其自动模板生成不成功的原因。