网页正文提取算法研究[非正则]

互联网的页面展现形式相当丰富,但是如果按页面结构特征来分类,却不外乎以下几种类型:首页(包括栏目首页),列表页,内容页,评论页。 (1) **首页: **网站的首页, 一般含有多个栏目、图片、动画,以及若干文章标题链接。如: 网易首页。 (2) 列表页: 信息以列表的方式给出, 一般以表格的形式列出若干个条目, 经常含有分页功能。例如: 某论坛版面的文章标题列表。 (3) 内容页: 指含有正文内容的底层网页, 一般只含有不超过一篇的文章内容, 无评论或评论较少。如: 各类网站的含有具体某篇文章的底层网页。 (4) **评论页: **除了含有正文, 正文后面还跟有若干个评论,以论坛为代表。 在这几种类型之中,信息含量最大的当数内容页,它是我们平常摄取信息的主要来源。由于内容页的重要性,不同的Web站点为了加强内容页的展示,都会加入一些与内容相关或无关的信息块,如导航,广告等。虽然这些信息块在一定程度上有助于我们的延伸阅读,但很多情况下,我们只需要获取正文信息就可以了,其他信息块反倒成了一种干扰。如何从一个内容页面中,正确提取出正文信息,就成了一个研究课题。 在详述之前,先说一下正文提取的意义。以笔者的经历看来,应用包括但不限于以下几个方面。 (1) **采集,搜索。**信息采集很常见,互联网上超过30%的内容都是从其他Web站点采集而来。现在的采集系统或工具,大多是基于页面的正则来进行信息采集的,这样的优点是,对于需要采集的信息精确度很高,但是缺点也是很明显的,由于是基于页面的Html源码来采集,一旦源站点改版或调整,导致页面的Html源码改变,所有正则将全部作废。而正文提取技术,不是以Html源码格式为依据,所以Html源码的改变相对来说影响不大。 (2) **门户文章发布。**很多门户站点,并没有专门的记者团队,大部分文章都靠编辑在网上复制粘贴。如果能在发布界面加个功能,只需要输入网址,即可正确导入正文内容,并自动处理图片,想必是个不错的用户体验。 (3)**Wap浏览器。**Wap浏览由于受到流量及手机屏幕的限制,现在的Wap页面大部分以特出文字信息为主,但也不排除会有一些干扰信息块出现。作为用户,希望能只显示正文信息,特别是对于新闻及小说等页面。Wap浏览器如果可以将正文内容自动提取出来,应该是个不错功能。Android系统的迷人浏览器有个阅读模式,算是在这方面的一个探索。 正文提取技术的算法很多,本文是基于多特征的一种算法研究,根据信息块的特征进行判定。内容页又称为主题页,主题内容通常可以分解层次为: ①标题; ②发布时间; ③内容正文; ④相关文章或延伸性阅读。除了“内容正文”为必须元素外,其他几个元素都不一定会在内容页出现。根据对大量不同网页观察,各个元素的位置及表现形式虽无固定的标准,但是大部分却满足一定的特征。 一.标题块 分块节点:td,div,h,span 一般位于Head/Title的位置 当前单元含有<h1>-<h3>,<b>,<i>,<strong>等标签 样式,一般class包含title,head等字符 文字长度,一般大于3个字符,小于35个字符 二.发表时间块 分块节点:td,div, span 文字长度,一般小于50个字符 包含日期格式(2010-08-09)的字符串 包含以下关键字:来源,发表 三.主题块 分块节点:td,div HTML网页中有一些特殊标签,通常只出现在网页主题块中,如<P> <BR>等。因此,主题块中往往包含着特殊标签。 主题块内容含有较多的句子,因此具有较多逗号、句号等标点符号(>5)。 若从信息量角度考虑,主题块一般是含有较多文字信息。 主题块的 标签密度=1000*标签数/文字数 应在小于一个范围。 主题块的 文本密度=len(文本)/len(HTML代码) 较大 不应该包含 “上一篇”,“下一篇” 包含以下字符串的内容块,判定为包含版权信息,需减权:“ICP备04000001号”,“版权所有”,“Copyright” 主题块序号在标题块之下 主题块序号在发表时间块之下 主题块序号在相关链接块之上 四.相关链接块 分块节点:td,div 文字应为“相关链接”、“相关新闻”、“相关报道”等敏感词,且连接比例很高。 链接数小于20 实现: 根据以上信息块特征,采用特征提权算法,C#(3.5)编程实现,命名为QD正文提取组件。经测试,对Html格式规范的以文字为主的内容页,正确提取率在85%以上,各大门户的新闻页面在95%以上。 ...

November 11, 2010 · 1 min · 96 words · jabin

大规模网站架构

以下并非所有都经过本人实践,部分为根据资料的假想所得,切勿贯彻本本主义。 网站架构目标 高可用性(High Availability) 可伸缩性(Scalability) 高性能(High Performance) 原则 尽量避免分布式,此为分布式第一原则 避免分布式事务 系统异构 架构与语言无关 系统可以多个平台并存(分层,模块化) 数据库 数据库读写分离 直接在程序中实现,或封装为ORM MySQL Proxy 数据库纵横切分 水平切分 根据自定义策略,如hash(N)%n(按hash分),查找表 在水平分库时,应优先考虑从属关系,以降低查询的复杂度。如用户A和用户A所发表的文章应分在同一数据库中。 如有用到user_id,则应该在公共库中创建一个路由表,表字段主要有:user_id,user_name,DB_Name。如没有用到user_id,而是根据user_name判断及查询用户的关系,则可省略路由表,根据某种算法进行DB定位,此时应考虑以后增加节点时,DB定位是否会发生变化的情况。 为避免分表时自增id发生重复的情况,可选择以下的几个方法: 1.在公共库创建一个空表,专门用于id分发。 2.利用递增值,如DB1的递增值为2,DB2的递增值为3,DB3的递增值为5… 3.利用初始值,id长度一般为11位,每个DB取9位(最多100个DB),如DB1的起始值为100000000,DB2的起始值为200000000,DB3的起始值为300000000… – 在系统设计时就考虑数据库切分的话,应先在一台服务器创建多个数据库节点,当负载达到一定程度时,再将节点迁移至其他服务器上,这样可以减少数据迁移的工作量。每次增加数据库节点,原则上应为已有节点的倍数,而不是一台台的增加。 垂直切分 按功能分(论坛,博客) 表分区 非关系数据库(NoSQL) 高性能 Redis Memcached 海量存储 MongoDB 负载均衡 DNS负载均衡 反向代理负载均衡 负载均衡软件 nginx HAProxy apache httpd LVS(网络第四层工作) F5(硬件,四层/七层) 高可用性 使用双机热备 故障时切换至备份机 工具(Linux-HA) heartbeat 缓存 按功能分 数据缓存 页面缓存 页面片段缓存 静态化 浏览器缓存 按存储介质分 本地缓存 分布式缓存 memcached 反向代理缓存 squid 巨无霸 Varnish 静态资源分离 img,js,css使用单独的服务器处理请求 图片服务器的域名不同 多台机器保存相同的图片(img3,img2子域名) 同一页面不同图片随机生成不同的子域名进行负载均衡 FAQ A.一些大网站,图片服务器为什么都用另外一个域名? 比如yahoo.com 图片服务器用了yimg.com 的域名? ...

December 16, 2009 · 1 min · 107 words · jabin