搞垂直搜索(好吧,我承认我说得有点太高雅:搞网页采集)时,一般分这样两步:

现在首先要解决的搞到列表页。拿到列表页时,有的同志很认真,就顺着那个下一页又一次地地抓取所有列表页面。其实不是特别必要。比如,bj.58.com的租房信息列表页,分了10000多页,光遍历这些列表页就需要好久。 hyer的处理方式是,把取到列表面的最大页面数做为一个任务,单独拿出来由一个专有模块去执行。逻辑是这样的: 首页你需要人工分析出列表面的URL的特征。58的那个很简单,一下子就能出来: http://bj.58.com/zufang/pn%d/ %d是分页数。 其次我们要找的时,找出一个字串,在页面数过大(就是一直翻下一页,发现没有下一页可以翻的那个识别串)。这里58的页面估计是用.net的控件拖的,所以就是访问一个不存在的分页,比如第10万页,他也有下一页的链的妆可以翻。这时我们取的是列表项里的一个字符串: “onmouseout=”this.style.background=’#F7F9FE” [顺便说一下,58的前端设计同学,这样写javascript不太好呀。]. 接下来,我们需要一页页地翻。(您要有疑问了,咦,说白了您也还是一页页地翻啊!) NO! 我们是用二分法的思维来试!首先我们一次跳2048页,从第一页,依次试了1,2048,4097等页. page: 1  is not max page page: 2049  is not max page page: 4097  is not max page page: 6145  is not max page page: 8193  is not max page page: 10241  is not max page page number  12289  too big.. 然后发现12289页无法找到这个特征字串。现在我们知道,这个最大页码至少是10241了。接下来,我们一次跳过512个页码,分别访问10753,11265..页。 如此类推,一直到每次跳过1页时,就能很精确地找到最大页码了。好了,接下来我们的任务管理器就根据这个最大页码,决定启动多少个fake browser来要假装用户去读这1w多个列表页了。 未完,待续。