java scrapy下的租房信息爬取与数据展示工具的设计与实现

工具的设计与实现

摘 要

时代在发展，技术在进步，互联网改变了全世界，各行各业都在这个互联网时代寻求自身的增长点，人们的日常生活也越来越离不开互联网。以租房为例，线下租房行业持续遭到冲击，越来越多的年轻人选择在互联网上挑选房源。然而网上信息混杂，数据来源众多，如何提升租房用户体验就成了一个值得探讨的问题。本文以此为研究方向，设计并实现了一个基于python开源爬虫框架scrapy的租房信息爬取系统，爬取互联网上多个含有此数据的网站。以城市为区分，将多个站点的数据存入非结构化数据库，再以数据库为连接，开发出一个以python开源web框架Django的基础的租房数据展示系统。与此同时，对爬取到的租房数据进行可视化处理。

关键词：scrapy；Django；非结构化数据库；数据可视化

Design of information acquisition and data display tool for renting houses based on scrapy ABSTRACT The era is developing, technology is progressing, the Internet has changed the whole world. All walks of life are seeking their own growth points in this Internet age, and people’s daily life is becoming more and more inseparable from the Internet.Taking renting as an example, the rental industry has been under constant impact, and more and more young people have chosen to choose housing on the Internet. However, online information is mixed and data sources are numerous. How to improve the user experience of renting has become a problem worth discussing. As a research direction, this paper designs and implements a renting information crawling system based on Python open source crawler framework scrapy, and crawls several web sites on the Internet. With the city as the distinction, the data of multiple sites are stored in the unstructured database, and then the database is used as the connection to develop a renting data display system based on the python open source web framework Django. At the same time, we can visualize the data of rental housing.

Keywords: scrapy;Django;NoSQL DB;Data visualization

目 录

摘 要 I ABSTRACT II 1 绪论 1 1.1 研究背景及需求分析 1 1.2 国内外研究现状 2 1.2.1 爬虫技术概述 2 1.2.2 爬虫设计者面临的问题与反爬虫技术现状 4 1.3 研究目标及研究内容 6 1.4 论文的整体结构 7 1.5 本章小结 7 2 相关理论及技术 8 2.1 robot协议对本设计的影响 8 2.2 爬虫 8 2.2.1 工作原理 8 2.2.2 工作流程 8 2.2.3 抓取策略 9 2.3 python发展现状 9 2.5 scrapy架构 10 2.5.1 scrapy：开源爬虫架构 10 2.6 MongoDB数据库 13 2.6.1 NoSQL数据库介绍 13 2.6.2 MongoDB数据库介绍 13 2.7 python web框架Django 14 2.7.1 Django框架介绍 14 2.7.2 MTV模式 14 2.7.3 ORM模式 14 2.7.4 template模板语言 14 2.7.5 Django工作机制 15 2.8 semantic UI开发框架 15 2.8.1 semantic介绍 15 2.8.2 semantic开发 16 2.9 高德地图API 16 2.10 本章小结 16 3 系统分析与设计 17 3.1 系统分析 17 3.1.1 系统功能 17 3.1.2 爬取对象分析 17 3.1.3 模块设计 18 3.2 数据流 19 3.3 系统总体逻辑层次 20 3.4 本章小结 21 4 爬虫与数据存储、展示的具体实现 22 4.1 爬虫模块 22 4.1.1 环境搭建与前期分析 22 4.1.2 爬虫规则预处理模块 23 4.1.3 数据抓取模块 24 4.1.4 数据存储模块 29 4.1.5 反反爬虫模块 30 4.2 数据库设计 34 4.2.1 数据库环境搭建 34 4.2.2 数据库表设计 35 4.3 数据展示模块 35 4.3.1 django环境搭建 35 4.3.2 前端UI模块 37 4.3.3 网页架构搭建模块 39 4.3.4 前端与数据库连接模块 41 4.3.5 地图展示模块 42 4.4 开启Django服务器 43 4.5 成果展示 43 4.6 本章小结 45 5 系统测试 46 5.1 测试环境及工具 46 5.2 系统功能性测试 46 5.2.1 数据爬取功能测试 46 5.2.2 数据展示测试 49 5.3 系统非功能性测试 49 5.4 本章小结 49 6 总结与展望 50 参考文献 51 致谢 52 附录一 外文文献（原文） 53 附录二 外文文献（译文） 59

1 绪论

1.1 研究背景及需求分析 21世纪以来，互联网真正的走进了千家万户，特别是随着时代的发展、网络技术的更迭，快速方便的网络随处都可接入，世界真正变成了地球村。如今，各行各业都正在受到互联网的影响，席卷全球的“互联网+”迫使几乎所有的传统行业寻找自身新的增长点。比如，传统媒体行业正在经受新媒体的猛烈冲击，微博、微信公众号等充斥在人们的日常生活中，报纸等媒体早已没了往日的风采。4G技术的迅猛发展，给予人们随时随地畅快上网的体验，与此同时，第三届世界互联网大会上，高通公司带来的5G技术原型十分抢眼，5G似乎离我们也不再那么遥远。甚至十分传统的医疗行业，一个个掌上医疗APP不断挑战着这个行业的运转规则。 互联网的高随发展随之带来的就是网络数据在数据规模与数据复杂度上的指数级别的增加。根据全球著名咨询公司IDC（国际数据公司）发布的研究报告，预计到2020年，世界上的数据总量将达到35ZB。[1]17年举办的中国存储行业联盟大会上，《2015-2020全球IP网络流量报告》指出，数据以每年44%的增幅增长，预计2020年每月将产生6ZB数据。[2]现阶段网络环境中，各种类型的数据交错其中，主要包括结构化数据、半结构化数据、非结构化数据，其中非结构化数据已经超过半数，随着传感器、万物互联等技术的发展，非结构化数据的占比将进一步提升。数据规模庞大，数据类型复杂，而数据又对人们的日常生活起着十分重要的作用，如何从这些动态生成、超高时效性的数据中快速准确的找到自己所需要的数据，并将其筛选清洗加以利用，似乎已经成为互联网时代的必修课。在数据的各种应用场景中，房屋租赁是十分重要的一个方面。 房屋租赁市场，与房屋销售市场一同构筑起整个住房供给体系，是房地产行业的一个重要组成部分。2016年6月，国务院提出了《关于加快培育和发展住房租赁市场的若干意见》，2017年10月，党的十九大报告再次明确“房子是用来住的不是用来炒的”。 我国房屋租赁人口基数庞大，约为1.9亿人，其中进城务工人员与大学毕业生是其市场的主力军[3]，租客的年轻化与流动化，导致在互联网上寻找合适的租房成了人们不得不面对的问题。租房因其与互联网的结合，使其相较于传统租房方式有了以下三点优点: 第一，虚拟性。虚拟性是网络环境的一大特点，打破了地域的限制，人们可以在A城市选择B城市的房屋，不过这一特性也为网租房的市场环境带来了一定的挑战，经笔者观察，很多房源发布者要求租客提供诸如“蚂蚁信用积分”等证明其信用的信息。 第二，广泛性。网上的租房信息平台如58同城，往往能够收集到大量的房源信息，并能根据房源的情况，有针对性的对房源进行分类整理，使租客可以根据自己的想法搜索房源信息，从中选出契合自己需求的房源，极大的节省了租客的时间。 第三，即时性。房源发布者可以选择随时发布自己的房源信息，租客也可以随时随地查询房源信息。 电子商务研究中心发布的《2015年中国网络租房调查报告》（后简称为报告）显示，在剔除来自乡村、县城、四线城市及以下的调查样本后，无论是一线城市还是二三线城市，选择租房居住的用户均占据了绝大部分比例，其中北上广深的租房用户超过了77%，省会及二三线城市的租房用户达到了65%[4]（该比例为参与网上调查的被调查者提供的问卷反馈结果，考虑到参与调查的被调查者的人数因素，结果存在一定偏差，但依然真实的反映了我国现在租房用户群体的庞大）。目前国内通过租房来解决居住问题的人数已经超过一亿人，年租金也已经超过1万亿元,互联网的发展给房屋租赁市场注入了新的活力，据报告显示，通过网络寻找房源的比例已超半数，半数以上的房主也倾向于将自己的房源信息发布到网上，可以说互联网为房屋租赁市场提供了发展的沃土。[5; 6]但是，网络中提供房屋租赁信息的网站很多，用户寻找房源时往往由于使用习惯等原因主要在一个平台上寻找，若找不到心仪的房源，又将面临辗转各个房屋租赁信息平台，为用户带来不便。 笔者认为，对生活有实际意义的软件系统才称得上是一个好系统，结合以上背景，本文将以python语言为基础，实现scrapy架构下租房信息爬取与Django架构下的租房数据展示系统，该系统能帮助到实际生活中寻找某城市的出租房的租客，具有实际应用价值。

1.2 国内外研究现状 1.2.1 爬虫技术概述 爬虫是指一段自动的向互联网上某些网页发出请求并接收响应，根据一定规则继续爬取链接或从响应中提取出有价值的信息的一段程序，即爬虫是一段完成特定功能的程序。从原理上讲，任何具有网络通信功能的高级程序设计语言均可设计实现爬虫程序。爬虫与浏览器访问网页，究其原理，都是通过网络协议去请求互联网中的某个特定数据（不一定特指网页数据，音频、图片等数据也是爬取的对象）。不同点在于，其一，爬虫一般只需要运行编写好的爬虫程序即可完成网页请求；其二，浏览器一般运行在客户端，这与爬虫不同。 自上世纪90年代起，爬虫技术就得到了不少计算机工作者的重视，随着技术的发展，爬虫技术已经逐步趋于成熟，并在很多领域发挥巨大作用，尤其是在搜索引擎领域。爬虫为搜索引擎从互联网上下载网页，是搜索引擎技术中十分重要的组成部分[7]。 一个传统的爬虫往往是从一批URL开始的，爬虫先请求这批URL的网页内容，得到正确的应答后，对页面内容进行解析，然后根据预先设计好的规则从网页中找到某些URL加入到请求队列中，或者从网页中定位到所需要的信息，并将信息进行封装保存。循环往复，不断从请求队列中提取URL进行请求，直至请求队列为空或某些其他情况导致爬虫程序终止为止。

python语言在爬虫设计与实现中具有独特的优势。首先，python有scrapy等一些其他的成熟爬虫框架，其中已经考虑到了cookie，并行爬取等众多令人头疼的问题，让程序员大可不必“造轮子”，而是直接可以站在巨人的肩膀上。其次，即便不使用框架，python依然提供了众多成熟的第三方库如request、Beautiful解析库等等，其中也集成了部分反爬取的高级功能，开发起来又快又好。虽然以上功能很多语言都可以完成，但均没有使用python来的简洁舒适，正如python的设计标语“Life is short,you need python”。最后，python对爬取到的数据进行处理十分方便。总之，各种优点造就了现在python在爬虫编写领域的地位，其已经是现在编写爬虫使用最广泛的语言。 1.2.2 爬虫设计者面临的问题与反爬虫技术现状 在互联网时代，爬虫是一个较为普及的技术，很多人做项目、做调查，都离不开大量数据的支撑，编写爬虫似乎成了大家一致的选择。准入门槛低、网上现成的代码使得网络上爬虫横行。[8]然而，爬虫又面临着很多问题，比如爬虫是自动化的访问大量网页，访问速度快，频率高，占用了服务器大量的带宽，如若短时间访问量过于巨大，轻则造成对方服务器反映缓慢，影响到正常用户的访问，重则给予对方服务器类似于Dos攻击的效果，造成宕机。依据某知名企业在网络上举办的技术分享视频上的介绍，其某个页面一分钟的浏览量为1.2万，真实用户仅有500人左右，爬虫流量占比峰值曾达到了98%。其次，网络爬虫还面临着一定的法律风险。现如今，知识产权观念深入人心，网站上的内容作为其公司经济利益与知识产权的载体，理应收到一定的保护[9]。相关法律法规出台的滞后性、适用法律的模糊性以及技术手段的多样性都造成了如今使用爬虫可能面临一定的风险。某些网站本身商业利益来源就是其数据，这类网站会想方设法对爬虫行为进行限制。 反爬虫[10; 11]，顾名思义，是与爬虫技术相对抗的一种技术，具体又指一系列限制网络爬虫行为的技术集合。一般网站从多个方面进行反爬虫： 第一，基于请求头headers。headers是HTTP协议的一部分，是区分人与机器的最简单的方式，浏览器在请求网页时，会带上自身的User-Agent、Cookie等字段，而爬虫进行爬取时，默认是没有这些字段的。如果服务器收到的请求缺失了这几个字段，基本可判定是爬虫程序在对网页进行访问，从而达到对其封禁。这是最基础的反爬虫手段。 第二，IP限制。爬虫与人访问网页最大的区别在于,爬虫一般完成的是短时间内超一般数量的访问，而人对网页的访问一般呈现随机性与线性增长性。基于此，可以完成一种十分高效的反爬手段：IP封锁。如若某个单一IP在短时间内的访问量超出了某个既定的阈值，则可判断此访问行为非人所为，可对其进行封禁。此方式虽然高效且实现简单，但仍有一定的缺陷，其一，仍然有一定的几率将正常访问网页的用户封禁，这种误伤行为将极大的影响自身的服务；其二，随着时代的发展，网上有大量的免费IP代理可以获取，还有众多出售专业爬虫代理IP的网站，获取较为容易。本系统在开发初期，曾遭遇多次严重的IP封禁。

第三，数据异步加载。数据异步加载指的是一次不加载网页的全部内容，原本是为了提高网络访问速度的一种方式，现在在反爬虫领域也大放光彩。爬虫一般爬取到的是html页面信息，而不是异步加载刷新之后的代码，所以网页设计者可以将需要重点保护的数据使用异步加载技术加载到html代码中，这样既不会影响到正常用户的访问，又可以对爬虫进行很好的抵抗。异步加载一般采用JavaScript实现，对爬虫编写者的能力要求较高，此类反爬技术可以挡掉相当部分的网络爬虫。在本系统开发过程中也在某些防护较强的网页遇到了数据异步加载问题，最终采用其他方式绕过了该异步加载，爬取到了想要的数据。 第四，网络流量与日志分析。网络管理员对网络流量数据进行检查，分析日志，从中分析出异常访问，对其加以限制。此方法自动化程度不如前几种反爬技术，但仍是一种现在不可忽视的反爬手段，一些精心编写的爬虫只有采用此种方法才可被发现。 第五，验证码。验证码全称为全自动区分计算机和人类的图灵测试，它2002年产生于美国卡内基梅隆大学，是一种区分当前访问用户是计算机还是人的公共全自动程序。一般来讲，计算机很难通过该图灵测试，所以对异常访问进行重定向至输入验证码页面这种反爬措施十分有效。本系统在开发过程中也曾遇到过验证码问题。

原则上来讲，没有一种最完美反爬的技术可以阻挡爬虫的进攻，商业公司与爬虫编写人员之间的较量有时比拼的并不只是技术，而是代价。如果爬虫编写者应对某网站的反爬措施需要花比反爬者更大的价值，编写者一段时间后也将失去爬取的兴趣；如果反爬人员需要花费更大的时间精力来阻止一个精心设计的爬虫，如若该爬虫对网站的利益影响没有那么大，一般公司的技术人员会选择放弃与之较量，任其爬取。反爬虫是一场矛与盾的较量。对于爬虫编写者来说，如何能找到一些适合当前任务的抓取策略，既避免遭到网站的封禁，又能避免对该网站的稳定性与经济利益造成影响，是个值得继续研究的问题。

1.3 研究目标及研究内容 本系统的研究目标为： 1.对国内外网络爬虫技术与反爬虫技术研究现状、网络协议及协议运行相关技术等背景知识进行了解，对国内网租房市场进行调查了解； 2.研究学习scrapy爬虫架构及非结构化数据库相关技术； 3.分析目标用户人群对房屋租赁信息的业务需求，结合市面上房屋租赁信息平台的特点，设计整个系统的数据流动方式、设计多个框架之间相互协作的业务流程； 4.针对部分网页的反爬取策略，采用反反爬虫技术，完成对房屋租赁网站信息的获取； 5.结合房屋租赁信息的数据特点，对爬取到的房屋租赁数据进行合理的处理，并且利用非关系数据库MongoDB设计实现数据存储，为数据展示提供必要的数据支持； 6.研究学习web框架Django，完成网站搭建，学习semantic UI编写网页界面，使用列表形式或地图形式完成数据展示； 6.对该系统进行功能性与非功能性测试，验证系统的可用性； 7.总结所做的工作，对进一步的研究工作作出展望。 本系统实现了一个房屋租赁信息爬取与数据展示系统。首先通过python开源爬虫框架scrapy对目标房屋租赁信息网站进行爬取，包括58同城、安居客、107间房、我爱我家网、房天下、列表网、58同城移动端等，依据不同网页的不同特性选择不同的爬取策略，编写爬虫代码，过滤并抽取所需出租房源信息，建立以城市为区分的房源信息数据库。数据库部分采用非结构化数据库MongoDB，避免网上信息的非结构性对数据存储的影响。然后采用python开源网站搭建框架Django完成对爬取到的租房信息的web端展示。除此之外，本系统采用高德地图API提供的“坐标拾取器”功能完成位置信息与经纬度之间的转换，并将爬取到的数据可视化展示在地图上，一并展示于前端页面。在爬虫部分，除了对房屋租赁信息的爬取外，还实现了对网上免费代理的爬取、存储、有效性验证与维护。本系统还涉及到的技术有：MongoDB与scrapy框架的集成，MongoDB与Django框架的集成，semantic UI快速html5界面开发等。

1.4 论文的整体结构 本论文共由六章组成，各章节安排如下： 第一章绪论，说明了该系统开发的可行性与现实应用意义，介绍了爬虫技术及反爬虫技术的发展现状，介绍了开发该系统所预期达到的目标及所需做的工作。 第二章对系统中涉及到的相关技术进行了介绍，并说明了相关技术在本系统中的作用。如Robot协议等，其中着重对爬虫架构scrapy、非结构化数据库MongoDB、开源网站框架Django进行了介绍。 第三章为系统分析与设计，本章对所要完成的系统进行了整体分析设计。分析了系统所要实现的功能，设计出总体架构，对其进行细分，分成各个模块，然后对各个模块进行了介绍。 第四章为系统设计实现与成果展示，本章编写代码实现了爬虫，对数据库进行了设计，并完成了数据展示模块。最后对本系统的运行成果进行了展示。 第五章系统测试。本章对整个系统进行测试，包括对测试环境的描述，对系统的功能性测试和非功能性测试。 第六章总结与展望，本章对系统进行总结，并总结了开发过程中的一些所思所想。然后对本系统的进一步研究方向进行了展望。

1.5 本章小结 本章主要是对该系统进行了介绍。首先介绍了研究该问题的背景、可行性及现实意义，接着对国内外相关领域的研究进行了分析。接着根据以上分析引出了本系统的主要研究内容，最后对本篇论文的结构进行了介绍。

2 相关理论及技术

2.1 robot协议对本设计的影响 robot协议的全称是“网络爬虫排除标准”，互联网上的站点通过Robot协议告诉爬虫本站点的哪些页面可以爬取，哪些页面不允许爬取[12]。 robots.txt文件是robot协议的直接体现。如果将网站视作一个旅游景点，robots.txt就是景区管理员在某些路口悬挂的“游客禁入”或“请走这边”的提示牌，爬虫就是来此景点观光的游客。 但是，robot协议并不是法律强制性规定，也没有一份正式的协议，其只是约定俗成的一种协议，或一种行业规范，需要爬取方与被爬取方自觉遵守[13]。目前国内外大部分互联网公司都遵循robot协议，这体现了互联网的一种契约精神。 如若遵循robot协议，本爬虫系统将有部分数据无法爬取到。本系统不是为了某些商业利益而开发，而仅作为学习使用，为了数据获取的完整性，本系统需要禁止遵守robot协议。可在scrapy架构中的setting.py文件中设置。如图2.1所示。

2.2 爬虫 2.2.1 工作原理 爬虫是指一段自动的向互联网上某些网页发出请求并接收响应，根据一定规则继续爬取链接或从响应中提取出有价值的信息的一段程序。爬虫运行过程中涉及到了网络请求、网络解析，其可以运行主要依托于一下几个技术。 URL（Universal Resource Identifier）：通用资源标识符，互联网中每一个资源都由一个唯一的URL所确定，反之根据URL可以定位互联网上的唯一一个资源。 HTTP协议：超文本传输协议，该协议是互联网上应用最为广泛的一种网络协议，HTTP协议提供了一种发布和接收HTML页面的方法，由HTML语言编写的网页代码可由浏览器渲染成结构清晰的页面。 2.2.2 工作流程 一个传统的爬虫往往是从一批URL开始的，爬虫先请求这批URL的网页内容，得到正确的应答后，对页面内容进行解析，然后根据预先设计好的规则从网页中找到某些URL加入到请求队列中，或者从网页中定位到所需要的信息，并将信息进行封装保存。循环往复，不断从请求队列中提取URL进行请求，直至请求队列为空或某些其他情况导致爬虫程序终止为止 2.2.3 抓取策略 爬虫抓取策略大致可分为横向与纵向两种，其又称为广度优先算法与深度优先算法。 横向（广度优先算法）是图的算法中十分重要和基础的[9]，也是很多其他图的算法策略的原型。横向搜索的设计与实现均较为简单，从初始URL出发，搜索距离初始URL最近的URL，加入请求队列并进行搜索。在本系统中，以58同城为例，横向搜索是指从列表第一页开始，一次次的向后翻页，将下一页的URL加入到待爬取的队列。 纵向（深度优先算法）的策略与横向搜索正好相反，其从起始点开始，一层层深入，直至没有更深的节点，再一层层递归返回，直至搜索完所有节点。在本系统中，纵向搜索即指从列表也的某一页，获取所有详情页的URL，将其加入到待爬取队列中等待爬取。由于租房信息网页特性，从一个详情页无法找到另外一个详情页的信息，故此纵向深度为2。 本系统需要完成的是双向爬取，即从列表页第一页开始，一次性爬取到下一页的URL和每一页中详情页的URL，直至爬取完整个网站信息。scrapy架构对各种爬取策略都有所支持，具体内容将在2.5节中介绍。

2.3 python发展现状 python是一种面向对象、语法简洁、规则优美的脚本语言，支持现有的主流操作系统。其应用范围很广[14]，几乎涉及程序设计的所有领域，在爬虫、自然语言处理、深度学习、数据挖掘等方面表现出众。正如python的设计原则所讲，“优雅，简单，明确”，阅读其代码就好似读英语一样，python比任何语言都排斥复杂，在简洁中反而强调严谨（如其近乎苛刻的缩进规则）。python语言本身至提供了一套编程语言最小内核，其余各种丰富的功能均可通过导入第三方库来实现。

2.4 XPath 随着互联网的快速发展，现如今XML已成为各种网络应用中实际上的数据表达标准。若光有XML语言而没有一种能够操作其所描述数据的方法，则毫无用处。[15]必须有某种数据查询语言与之配合，这样XML语言才会有实际作用，才能发挥其特性。XPath，是XML的路径语言，它可以用来确定XML（可扩展标记语言）文档中某个标签或数据的位置，是W3C体系中用于查询XML文档的通用标准，可以将其看做XML的SQL[16]。 XPath是一系列查询规则，通过这些规则来完成对XML文档的树形结构访问。其采用简洁的语法和基于XML文档的逻辑结构十分便于从文档中提取元素。通过XPath规则，我们可以按照某一规则，从任何一篇XML文档的任意位置提取出有价值的数据。 在本系统中，XPath所完成的最关键的任务是数据定位，即从爬取到的网页中依据XPath规则编写定位代码，从中找出我们所需的各种数据。除了XPath这中定位手段外，其他常用的定位手段还包括selector、正则表达式等。scrapy内置支持XPath定位，使用该定位手段我们不用导入其他包即可使用，而且XPath的定位能力也完全可以处理此类情况。

2.5 scrapy架构 2.5.1 scrapy：开源爬虫架构 scrapy开源爬虫框架，由python开发的爬虫框架，具有易于使用、抓取效率高和开发迅速的特点，其用于抓取互联网中的web站点并从网页中提取结构化的数据。scrapy是一个爬虫框架，而且开源，任何人都可以根据需求对其进行修改。[17]本系统采用scrapy框架的原因如下： 1.scrapy基于Twisted框架。[18]Twisted框架（事件驱动型的网络引擎）实际上是一个异步IO的框架。由于它的Twisted特性，scrapy框架内置实现了单机多线程，十分有效的提升了性能。应用此框架，程序的执行流将被外部事件所影响。不过也是由于此特性，scrapy不支持分布式爬虫，如要实现分布式，需要调用其他包。 2.scrapy扩展功能十分强大。在框架中提供了众多内置模块，几乎涵盖爬虫所需处理的所有问题，大部分扩展功能都能在下载中间件或爬虫中间件中实现，开发效率高。 3.scrapy内置了css和XPath两种定位方式对爬取到的网页进行元素定位,其对网页的解析效率十分高。 4.scrapy开发简单。使用scrapy完成一个爬虫系统十分快速高效，且可以集成众多第三方库，配个各个库可以使该框架的性能十分优秀。 5.它内置了不同的爬虫开发基类，使开发者可以根据自己的需求继承不同的基类，完成开发。它十分简单且易于使用，开发者基本只需要编写好爬取规则，即可调动整个框架开始爬取工作。 2.5.2 scrapy框架结构 scrapy框架结构如图2.2。

整个框架由位于中心位置的引擎所控制。引擎是指挥各个部件协同工作的核心，它控制着数据在爬取过程中的流动，并在某些指定事件发生时控制框架。爬取时，首先引擎想调度器索要需要爬取的链接，调度器将请求队列中的一些URL交给引擎，接着引擎将这些URL交由下载器处理，下载器向这些页面发起请求，（在请求过程中可能使用到下载器中间件，其可以通过一些设置，完成对scrapy框架功能的扩展）。下载器得到这些页面的返回后，将其交给引擎，引擎又将其交给Spiders。，在其中，将根据页面的不同返回情况，找到处理其的爬虫代码，对返回数据进行解析与提取。提取到的数据将被交给管道（pipeline），管道将对数据进行打包，最终对其完成数据的持久化，如存入某文件或存入数据库。整个爬取过程依次进行，直至调度器的请求队列中没有需要请求的页面，爬虫框架才会停止运行。 2.5.3 两种继承，两种爬虫模式 在scrapy框架中，每个Spider都需要继承一个由scrapy框架自身提供的爬虫类，不同的类对应了不同的爬取方式，在此主要介绍两个最常用的类。本系统主要使用第一种Spider，只有某个地方使用了第二种类。 第一种为scrapy.Spider。Spider是最简单的spider。开发者编写的每个spider类必须继承自该类。Spider只是一个普通的爬虫，其一般只用来请求特定的start_urls或调用start_requests方法，并根据返回的结果选择不同的 parse方法解析数据。 该类中关键的几个参数有： name，字符串类型，唯一确定了一个爬虫，在开启爬虫时必须使用此名称，故在爬虫系统中，该字段必须保证唯一，name可以说是整个框架中最不能修改的一个字段。 allowed_domains，列表类型，当中间件中的OffsiteMiddleware为开启状态时（默认开启），若URL不在该列表中，该URL将不会被跟进。 start_urls：列表类型，当没有特别指定起始URL时，该列表中的URL将作为起始URL，提供给引擎。后续爬取的URL将从此开始寻找。 start_request()：该方法必须返回一个可迭代的对象，一般使用yield返回。该返回的对象包括了spider用于爬取的第一个request，当爬虫启动且未指定URL时，自动调用该方法，开始请求URL。 parse()：该函数是整个类中最关键的方法，也是爬虫逻辑实现的主要地方。当response没有指定回调函数时（在返回时以callback参数指定），parse方法是scrapy处理获取到的网页数据的默认方法。网页信息将在其中被解析，被处理，并将定位到的数据以生成器的形式返回给pipeline处理。 第二种为CrawlSpider。若需要爬取的网页为一般网页，使用Spider就已足够，但若需要完成对URL的进一步跟进，则需继承该类。该类是爬取全站的利器，可以从起始页面开始不断爬取本站点的数据，如不加限制（如跟进深度限制），将可以爬取整个站点的所有网页。 该类最关键的字段为： rules：其中包括了一个或多个Rule的集合，每个Rule对爬取网站的动作定义了特定表现。 Rule对象包含多个参数，依据各个参数的共同筛选，将筛选出匹配的URL进行进一步跟进。其中重要的参数有：link_extractor，专门负责从页面中提取a标签下的href链接；follow，布尔类型，定义了对爬取到的URL是否需要继续跟进。 使用Spider类时，通过start_request与parse两方法的配合，可以实现对页面的纵向爬取，通过start_urls列表，可以直接依据URL的规律直接指定横向爬取。使用CrawlSpider，可以直接由列表页的第一页开始，依据写好的爬取规则进行横向与纵向的同时爬取。使用第一种方式进行代码编写，逻辑较为简单，便于维护，且可实现所需功能，故本系统大部分采用第一种爬取逻辑。

2.6 MongoDB数据库 2.6.1 NoSQL数据库介绍 互联网上的信息大致可以分为两类，一类是可以由同一结构加以表示的，如电话号码、字母等，另一类信息是我们无法用数字或者同一的结构所表示的，此类数据即可称为非结构化数据，为了应对互联网中越来越多的非结构化数据，非结构化数据库应运而生。简单的说，非结构化数据库就是字段数、字段类型、字段长度均无硬性规定的数据库[19; 20]。 NoSQL，与目前流行的关系型数据库相对，定位为基于非关系型的数据库。与传统结构化查询数据库不同，NoSQL 数据库对于数据格式的要求十分宽松。 如今各个网站都可以通过爬虫轻松的访问和获取数据，但是不同的网站在数据结构的处理上是截然不同的，而且因为网络普及，用户的数量也在急速增加。所以爬虫的数据处理模块如何处理多样复杂的数据格式以及应对大规模的数据量，成为了不可忽视的问题[9]。 NoSQL数据库与一般的关系型数据库相比，优势主要体现在： 1.NoSQL 数据库不拘泥于范式，没有对数据间的结构和关系做出硬性要求。这使得NoSQL 数据库在保存用户信息等错综复杂的信息时具有得天独厚的优势。 2.能支持大数据时代下的数据量。不需要检查数据是否满足关系范式，在面对大规模数据时，NoSQL 数据库有着更好的表现。 3.高度灵活的索引方式[20]。数据库的核心技术之一是数据库的索引技术。由于其有着灵活的数据结构，其中支持的索引方式比传统的关系型数据库要丰富的多，可以满足极其复杂的索引需要。 2.6.2 MongoDB数据库介绍 Mongo DB 是由 C++语言编写的，是一个基于分布式文件存储的开源数据库系统。其是一个介于结构化与非结构化之间的数据库产品，同时也是非关系数据库当中功能最丰富，最像关系数据库的一种数据库。

2.7 python web框架Django 2.7.1 Django框架介绍 python的web框架一般有如下特性：平台性：不一定依赖于数据库，相比关注数据库，更关注于高效构建和运行的稳定。 Django是一个开放源代码的Web应用框架，由Python写成。采用了MTV的软件设计模式（将在2.7.2中介绍），其基于MVC，即模型M，视图V和控制器C。 2.7.2 MTV模式 MVC是大家十分熟悉的软件开发模式，它由三个部分组成:model层,view层,和 controller层。其中： Django也采用MVC模式。但是在Django中，控制器接受用户输入的部分由框架自行处理，所以 Django 里更关注的是Model、Template（模板）和Views，其被称为 MTV模式。 M 代表模式，控制着数据的存取。模式层处理与数据相关的所有事务，比如与数据库的连接、从库中调取数据、数据查询等。 T 代表模板，该层控制着Django的表示界面。其中主要涉及HTML5页面的管理。 V 代表视图，控制整个框架的业务逻辑。本层类似于MVC中的控制器，它是MTV模型的中心。 2.7.3 ORM模式 对象关系映射(ORM），是一种程序设计技术，用于实现面向对象编程语言里不同类型系统的数据之间的转换。从效果上说，它其实是创建了一个“面向对象的”，可在编程语言里使用的–“虚拟对象数据库”[21]。 Django中使用技术，极大的简化了程序员对数据库操作时需要记忆的命令数量，以极简、极语义化的方式完成与数据库之间的联系。 2.7.4 template模板语言 Django的模板是一个简单的文本文件，它可以生成任何文本格式（HTML、XML、CSV等）Django的模版系统并不是简单的将Python嵌入到HTML中。 设计决定了：模版系统主要致力于表达外观。模版的功能包括在使用时会被值替换掉的变量和可以控制模版的逻辑控制标签。 本系统中使用的分页系统为Django内置的分页器系统，其中涉及到了大量的模板语言，除此之外，从数据库中调出数据、HTML5页面的控制也涉及到大量的模板语言控制。这一部分将在详细设计阶段具体解释。 2.7.5 Django工作机制 Django的机构图如图2.3，2.4所示：

2.8 semantic UI开发框架 2.8.1 semantic介绍 Semantic（语义化）作为一款前端框架，帮助开发者使用对人类友好的语义化语言构建优雅而舒适的前端页面。 Semantic开发工具具有如下特点[22]： 简洁的 HTML：Semantic UI中语意和css类被认为是相同的。在semantic.css文件中定义了大量的已经写好的样式，开发者可以像描述一个事物一样，用日常生活中的词汇来描述一个元素，来完成前端页面的语义化开发。 直观明了的 javascript：Semantic提供给开发者易于掌握的js文档，开发者可以其中的部分，来完成自己的个性化开发，也可直接使用本身提供的各项js功能。 semantic 自带简约的可继承系统，以及高级主题变量，可以自由的完成各式各样的设计。只需开发一次UI，就可以在各处部署相同的代码。 配合Django的模板继承系统，可以快速开发出本系统所需要的界面优美的前端界面。 2.8.2 semantic开发 本系统的UI使用semantic开发框架完成开发。在h5网页编写过程中，导入semantic.css及其他js文件后完成语义化UI开发。

2.9 高德地图API “各行各业都在使用高德”。高德开放平台提供市面上所有的地图形式供开发者选择，无论是windows、linux还是Max甚至手机APP，都可以通过高德开放平台提供的API轻松的完成地图的绘制工作。高德地图API对开发人员的支持面很高，平台使用性也很好[23]。本系统将爬取到的租房信息数据中的地址字段作为参数传给高德地图为开发者提供的坐标转换工具“坐标拾取器”的API中，获得该地点的经纬度。在得到所有地点的经纬度后，将其传入高德地图为开发者提供的工作台，在其中生成数据的地图展示，并将其引入到本系统的前端页面中，最终完成数据的可视化展示。

2.10 本章小结 本对系统中涉及到的相关技术进行了介绍，并说明了相关技术在本系统中的应用。如robot协议、semantic UI前端开发、模板语言等。 其中，着重对本系统的几个核心技术进行了介绍，包括爬虫架构scrapy、非结构化数据库MongoDB、开源网站框架Django。

3 系统分析与设计

3.1 系统分析 3.1.1 系统功能 本系统实现了一个房屋租赁信息爬取与数据展示系统,主要功能如下： 1.搭建scrapy框架运行环境、搭建MongoDB运行环境、搭建Django框架运行环境，为系统开发做环境支持； 2.编写爬虫代码，依据不同网页的特性，实现对目标房屋租赁信息网站的爬取，从获取的网页内容中抽取出有价值的信息，对其进行数据清洗、数据封装，并将其存入数据库中； 3.使用Django web框架，完成其与数据库的连接，实现将爬取到的房屋租赁信息在web端展示的功能； 4.采用有效的反爬取手段，避开各个网站对爬虫的封禁。 5.将爬取到的房屋租赁信息中的地理位置信息转化为经纬度，并最终实现数据的可视化展示。 3.1.2 爬取对象分析 本系统实现的爬虫以国内几个知名租房信息网站为爬取目标，如“安居客”，”我爱我家”等网站。这些网站中有大量的租房信息数据，且出租房的信息格式较为固定，数据库设计较为容易。此次将爬取各个网站中租房的基本介绍（大小、楼层）、详情页链接、标题、大小、价格、所处地区、详细介绍、数据来源、房屋朝向、联系方式等内容。表3.1对爬取的目标及目标状况进行分析。 表3.1 爬取对象分析 目标网站 对爬虫的限制 爬取方式 58同城 强 爬取列表页或爬取其反爬手段较弱的移动端网页 安居客 强 爬取列表页 目标网站 对爬虫的限制 爬取方式 我爱我家 弱 爬取详情页 107间房 较强 爬取详情页，设置时间间隔 列表网 弱 爬取详情页 房天下 较强 爬取详情页，设置时间间隔

“58同城”、”安居客”等网站是著名的租房信息网站，其中均有大量出租房信息。选取其作为爬取对象，首先其中的数据足够支撑本系统的需求，其次，通过对页面的分析，如网页结构元素解析，帮助我更加深入的了解了网络协议，使我对爬虫的工作原理和流程有了更深入的了解。表3.1对爬取的目标及目标状况进行分析。 3.1.3 模块设计 系统整体可分为三个部分，爬虫模块、数据库部分、数据展示模块。每个部分又可继续细分。

其中，爬虫模块涉及对网页的请求、对请求到页面的解析、对解析后网页内容中有价值资源的定位、与数据库的连接；数据库部分涉及对数据的存储；数据展示部分主要指将爬取到的租房信息进行列表化或可视化的展示。 其细分的各个子模块的功能介绍如表3.2。 表3.2 子模块功能描述 模块名 介绍 爬虫规则预处理模块 在爬虫代码编写之前，需要对需要爬取的数据格式进行前期规定，避免在爬取过程过爬取目标不清晰

数据抓取模块 爬虫代码的核心部分，涉及对网页的访问，对获取到的页面内容的解析，对页面内容中有价值数据的定位与存储 数据存储模块（爬虫与数据库的连接模块） 爬虫与数据库的连接部分，将完成对数据的清洗，并负责将数据以一定的格式存入数据库中，供后续使用 反爬虫模块 实现对各个网站反爬措施的突破，根据不同的反爬能力实现不同的爬取策略 数据库设计 对爬虫爬取到的数据进行存储、对异常数据进行清洗 前端UI模块 以适当的界面展示爬虫获取的数据 网页架构搭建模块 Django架构搭建网站，一站式完成网站搭建，为页面展示做准备 前端与数据库连接模块 Django架构有自带的默认数据库，需要修改其设置，将网页与爬虫获取到的数据联系起来，连接到MongoDB，完成数据的展示 地图展示模块 高德地图为开发者提供了完善的、优雅的地图展示API，通过调用此API，完成对数据的可视化展示

3.2 数据流 本系统以非结构化数据库MongoDB为轴，划分为两个大块，一块为爬虫，一块为B/S架构前端，其数据流动如图3.3所示。其中各个函数、文件都将在第四章详细介绍。

3.3 系统总体逻辑层次 系统层次采用了基于B/S结构的4层架构，系统自下至上被划分为数据存储层、数据服务层、业务逻辑层、业务表现层。各个数据层之间相互具有独立性，采用不同的交互方式进行交互，完成整个系统的逻辑实现。

3.4 本章小结 本章为系统分析与设计，本章对所要完成的系统进行了整体分析设计。分析了系统所要实现的功能，设计出总体架构，对功能点进行细分，划分出各个模块，然后对各个模块进行了介绍。接着，对系统中数据的数据流进行了分析与绘制。最后，对系统的逻辑层次进行了明确。

4 爬虫与数据存储、展示的具体实现

4.1 爬虫模块 4.1.1 环境搭建与前期分析 anaconda是一个开源的python发行版，现已发行至4.3.0版本，其中默认包含了大量第三方库及其相互依赖的库，完成了多种环境的搭建，其中就包括scrapy的环境。为了避开scrapy复杂的环境配置问题，直接安装已经集成scrapy架构所需要的所有环境的anaconda，完成对scrapy环境的安装。安装完成后，所有所需环境变量已自动配置好，所需的各种python库也已安装成功，可直接开始scrapy项目。安装好的anaconda环境如图4.1所示。

创建scrapy项目需在命令行中进入准备开始项目的目录，运行如下命令： scrapy startproject demo1 创建项目后，文件结构如图4.2所示。

其中各个文件的简要介绍如表4.1。 表4.1 scrapy主要文件介绍 文件名 功能 scrapy.cfg 项目环境配置文件，在不移植程序的情况下，一般不对其进行修改 settings.py 该文件中定义了一些爬虫设置，如中间件开启顺序，爬取时延、是否遵循robot协议、是否开启cookie功能等 items.py 该文件定义了待抓取数据的各个字段 pipelines.py 该文件定义了数据的存储方式，它接收爬取到的数据，并将其存储。可以将其存储为csv或其他格式的文件，也可将其存入某数据库 middlewares.py 中间件，是完成对scrapy框架更多功能扩展的主要文件，在其中可定义随机切换IP的IP代理中间件。该文件是反反爬虫技术的核心 spiders文件夹 该文件夹下存放着最为核心的爬虫代码 4.1.2 观察网页结构（以58同城为例）如图4.3，从其中可以看到在详情页中包括的信息十分全面，基本包含我们所需要的全部信息，即爬取详情页可以获得尽可能多的租房信息。

在item.py文件中写入所需要爬取的字段，对其进行定义，各个字段具体介绍可参见4.2节中中对数据库表的设计。字段定义如图4.4所示。

4.1.3 数据抓取模块 网页抓取时最关键的部分为spider文件夹下的各个爬虫文件，它同样也是整个项目中最核心的部分。本系统实现了对58同城、安居客、我爱我家、107间房、列表网及房天下这几个网站中租房信息的爬取，下面将介绍在不同的反爬策略下，不同网页的爬取方式。内容包括反爬工作做的不错的“58同城”的列表页爬取及移动端爬取思路、对爬虫限制较小的“我爱我家”详情页爬取。完成后的文件架构如图4.5，其名称分别对应各个网站。

首先对“58同城”的列表页URL进行分析，研究发现，第一页的后缀为‘/pn1’，第二页的后缀为‘/pn2’，且无论是通过点击下一页，还是URL直接输入‘/pn71’，都无法访问第71页，说明58同城默认只提供前70页的房屋租赁信息。由于其反爬措施十分严格，短时间内快速访问将导致IP封禁，故本系统只爬取其列表页，该爬取主要为横向爬取，使用继承Spider类的爬虫即可。设计其爬取流程如图4.6。

继承Spider类，并对其关键字进行定义，如图4.7。

name字段为唯一表示此爬虫的字段，开启爬虫时需要用到。 allowed_domains表示在爬取过程中，只会跟进“58.com”的链接，即规定了爬取的范围。 url为网页URL的一部分，用列表解析式加上1至70之间的数字，即可完成对所有页面的访问。列表解析式如下： start_urls = [‘http://ty.58.com/chuzu/pn{}’.format(i) for i in range(1, 71, 1)] 使用python极简的语法完成了1到70页url的生成。 接着，编写最重要的parse函数，如图4.8。

第40行：完成了在item.py中定义的字段类的实例化，此后将使用该实例对象接收数据。 第41至47行：使用XPath对页面元素进行定位，找到其中包含的标题、价格、地理位置等区域。由于无法深入到详情页，所以获取到的数据会不全，部分数据只好使用None代替。 XPath语法规则：‘//’表示在整个页面中搜索，‘/text()’表示获取HTML5中该标签内的文本数据，‘extract()’可将数据提取出来。 第48至56行：将抓取到的数据赋值给item对象，其中item字段必须与item.py文件中编写的字段名完全一致，否则会报错。 第57行：逐条返回该item实例。将数据交给pipeline.py处理。 至此即完成了对58同城列表页的页面信息抓取工作。 为了避开其严格的反爬措施，一个新的爬取思路为爬取其防御稍弱的移动端的网页。实现方式如下：使用chrome浏览器模拟移动端，获取其User-Agent和URL链接，将该User-Agent写在setting.py中，静态设置其为移动端的User-Agent，然后对移动端的页面信息进行分析，定位，爬取移动端的网页。 对“我爱我家”网页的爬取工作如下：首先一样是对其URL进行分析，发现其列表页第三页的后缀为‘n3/’，第五页列表页的后缀为‘n5/’,故分析其列表页URL中n后的数字表示页数。在其网站上可以看到总共的页码数，由此可获得总页数，生成起始URL。由于其反爬措施不那么严格，故选择爬取其详情页，爬取流程设计如图4.9所示。

对所有起始页面的请求如图4.10。

其中所有页面解析后交由parse函数处理。parse函数如图4.11。

第27行：从每一个列表页中定位详情页的URL，将其放入列表link_list中。 第28至30行：生成完整的详情页URL。 第31行：把每一个详情页URL交由parse_item函数处理，在parse_item函数将完成对详情页数据的解析定位。 parse_item函数代码如下： def parse_item(self, response): item = BisheItem() title = (response.xpath(‘//h1[@class=“house-tit”]/text()’).extract())[0].strip().replace(’ ‘,’‘).replace(’\n’,‘’) price = (response.xpath(‘/html/body/div[3]/div[2]/div[2]/div[1]/div[1]/div/p[1]/text()’).extract())[0].strip().replace(’ ‘,’‘).replace(’\n’,‘’) info = str((response.xpath(‘//div[@class=“jlquannei fonthongse”]’).xpath(‘string(.)’)).extract()).strip().replace(’ ‘,’‘).replace(’\n’,‘’).replace(‘[’,‘’).replace(‘]’,‘’).replace(‘\t’,‘’) direction1 = (response.xpath(‘//div[@class=“zushous”]/ul/li[3]/text()’).extract())[0].strip().replace(’ ‘,’‘).replace(’\n’,‘’) direction2 = (response.xpath(‘//div[@class=“zushous”]/ul/li[2]/text()’).extract())[0].strip().replace(’ ‘,’‘).replace(’\n’,‘’) region = (response.xpath(‘//div[@class=“zushous”]/ul/li[1]/a/text()’).extract())[0].strip().replace(’ ‘,’‘).replace(’\n’,‘’) direction = direction1 + ‘’ + direction2 phone = (response.xpath(‘//li[@class=“daikcon fl”]/label/text()’).extract())[0].strip() url = response.url content = str((response.xpath(‘//ul[@class=“fytese”]’).xpath(‘string(.)’)).extract()).strip().replace(’ ‘,’‘).replace(’\n’,‘’).replace(‘[’,‘’).replace(‘]’,‘’) item[‘url’] = url item[‘title’] = title item[‘info’] = info item[‘region’] = region item[‘price’] = price item[‘content’] = content item[‘direction’] = direction item[‘phone’] = phone yield item 其中首先完成item实例化，然后定位出各个数据的位置，顺便对数据进行了简单的清洗，使用.strip().replace()分别为去掉字符串前后的空格与换行、对其中逗号或文字中间的换行符进行替换。再将其存入item实例中，再由item将数据传递至pipeline.py处理。 上述两个例子分别对应了反爬措施强与弱两种情况，其余四个网站的爬取过程与此逻辑相同，只是其中对数据的定位不同，以及不同网页数据展示情况不同，对其清洗程度也不同，在此不再赘述。所有数据都将传入管道，交由pipeline.py处理。 4.1.4 数据存储模块 pipeline所需完成的任务是数据的收集与存储，主要涉及与数据库的连接、接收由各个spider文件传来的item实例、对数据进行数据打包、存入数据库等操作。其模块设计图如图4.12所示。

在pipeline.py文件中导入python与MongoDB链接的第三方库pymongo，然后完成与数据库的连接。如图4.13所示。

此时已连接至‘bishe’库的‘ty’表。 接着在该管道类中定义进行数据封装与存入的函数，如图4.14所示。

第18至31行：对数据进行打包，为插入数据库做准备。在这些网站中，107房间网站有房源的经纬度信息，在对其进行爬取时，取消掉29和30行的注释，即可将经纬度坐标作为字段一并插入数据库中。这体现了非结构化数据库在处理数据上的灵活性。 第32行：将数据插入数据库。 第33行：process_item函数默认返回item。 4.1.5 反反爬虫模块 突破反爬虫的设置主要在中间件中中设置。本系统共进行了四个手段以反反爬虫，包括设置抓取时延、禁用cookie、使用User-Agent池、使用IP代理池，接下来将分别介绍。 设置Download_dalay：对于那些反爬虫力度适中的网站，设置下载时延是一个不错的方法。在中间件文件middleware.py中写入Download_dalay=2，即可完成爬取时延的设置。 禁用cookie：该方法是为了避免网页依据cookie来识别爬虫进行封禁。禁止cookie后，模拟了浏览器的‘无痕浏览’模式，给要爬取的网页以假象，降低被封禁的几率。在setting.py文件中设置COOKIE_ENABLE = FALSE，即可禁用cookie。 使用User-Agent池：可在网上搜索到大量的User-Agent，将其写成列表放入中间件文件中，写自己的中间件函数来继承本身架构中的User-Agent中间件，在其中使用random函数，每次访问随机选择User-Agent池中的一个User-Agent。再在setting.py文件中禁用默认的User-Agent中间件，开启自己写的中间件，实现每次访问自动更换User-Agent。如图4.15所示。

第60至80行：互联网上找到的User-Agent，将其写入列表。 第82和83行：初始化。 第84至87行：实现User-Agent的随机选择，并将此加入到请求时的headers头中。 使用IP代理池：使用IP代理不像使用User-Agent一样，可以在网上找到大量现成的User-Agent以供使用。由于IP的特殊性，网上存在大量出售IP代理的网站。一般这些网站上也会有少量的免费IP代理。为了减少成本，决定写一个爬虫来爬取代理网站，批量化获取免费IP代理。该部分的设计如图4.16所示。

笔者爬取了“西刺代理网”上的免费代理，并将其存入数据库，然后以此使用代理，对同一网页进行访问，若访问失败则在数据库中删除该条数据，实现了对自用代理的维护。然后将数据从数据库中导出，以IP池的形式写入中间件中，实现IP池的使用。爬虫也使用scrapy写成，其逻辑不再赘述。如图4.17为对爬取到的IP进行过滤的代码。

第17行：定义了测试访问的网页。 第18至24行：异常处理，尝试访问测试网页，并设置超时时间为3秒，若超时则认为该代理失效。若超时或访问失败，则输出wrong并删除该条记录，若访问成功，则输出success。 第26至28行：对于爬取到的每一条记录，尝试使用该代理，进行数据清理。 图4.18为在租房信息爬取系统中使用IP池。

第69至224行：列表定义获取到的IP代理 第225至227行：初始化。 第228至231行：在爬虫中设置代理。 图4.19为setting文件中开启自己编写的User-Ageent及IP代理中间件。

第52和53行：开启自己编写的中间件，后面的数字为开启顺序，范围在0至700之间，越小越先开启。 第55和56行：关闭系统默认的中间件。 未使用中间件时的爬虫爬取模式如图4.20所示，直接向网页发起访问请求。

使用中间件后，爬虫想网页发起请求的流程如图4.21。

图4.22为开启中间件后的执行效果。

** **

至此，实现了本系统中的各个反反爬措施。

4.2 数据库设计 4.2.1 数据库环境搭建 MongoDB数据库的安装不再赘述。 pyMongo是Mongodb的python接口开发包，是使用python和Mongodb的推荐方式。 安装pymongo包：命令行输入pip install pymongo，等待下载完成即可。 为了在IDE中可视化的操作mongo，需要下载插件，如图4.23所示。

连接数据库可视化工具，如图4.24所示。

对数据库的操作不在此赘述，爬虫模块已解释或在代码中注释。 4.2.2 数据库表设计 数据库中只存在一种格式的表，即以城市为区分的不同城市租房信息表。该表用来存储从不同网站来源爬取到的同一城市的租房信息数据。由于采用非结构化数据库，每个字段并无确定的格式要求。其在数据库中的字段名及注释见表4.2。 表4.2 数据库表 编号 字段名 备注 1 _id Mongo自动生成，唯一标志某一数据项，无法删除也无法禁止生成 2 url url 3 title 标题 4 info 基本信息如房间大小 5 flag 标志位，可表示房屋信息是否发生该改变、该房屋网站是否已下架等 6 region 地区 7 price 价格 8 source 数据来源，如58同城 9 content 详细内容 10 direction 朝向及楼层信息 11 phone 联系电话 12 lon 经度 13 lat 维度

4.3 数据展示模块 4.3.1 django环境搭建 Django的安装有两种方式，一种为命令行pip安装，另一种为在编译器pycharm中一键式安装。 在命令行中执行以下命令：pip install django即可安装django包。其中pip是python的包管理工具，可在命令行完成包的下载安装、删除、升级。 第二种方法为在pycharm中寻找该包，点击Download，如图4.25所示。

在pycharm中可之间建立Django项目。创建Django项目后自动生成一系列文件，如图4.26所示。

其中主要的文件及介绍见表4.3。 表4.3 Django主要文件介绍 文件名 介绍 static文件夹 该文件夹又分为css、js、images、icon这几个文件夹，其中存放着HTML5页面所需要的各种渲染文件 model.py 模式层，主要负责数据的处理，其中有数据定义函数，该文件同时实现与数据库的连接 views.py 视图层，是整个框架的核心，完成的任务有：面向用户，负责URL的解释与HTML的渲染返回；面向模式层，主要负责向其索要数据，完成数据的填充；面向模板层，主要完成HTML页面的调度 template文件夹 该文件夹中存放着该站点中所有的HTML5文件 urls.py 该文件定义了视图层中的各个函数与URL之间的映射关系，对整个网站架构来说，十分重要 表4.3（续） setting.py 其中包含了对整个框架的设置，主要包括数据库的选择、DEBUG功能的开启与关闭等 manage.py 对Django框架进行操作时需使用此文件。如建立新的项目、创建后台用户、开启Django服务等

4.3.2 前端UI模块 前端UI模块设计如下图4.27。

template为一个文件夹，其中存放html文件，主要负责响应请求后返回的html文件。返回哪个html将在url.py中指定。除html文档之外的其他网页文件如css、image、js等放置于static文件夹中。其结构如图4.28所示。

网页的前端界面由semantic UI架构写成。semantic提供固定的css、js文件，可以让开发者在开发h5界面时通过语义化的方式引入格式，简化开发。而且由于其语义化的特性，对开发人员来说此种开发十分友好。 在semantic UI网站上提供了下载css及js文件的github地址，下载后放置到项目中，并对照网站上的介绍使用，即可快速开发出简洁美观的UI界面。 如图4.29所示，网站上有三部分，分别为效果展示、介绍、示例代码。开发者可根据其示例代码开发自己的网页。只需在class中引入“form”，就会产生如示例中展示的效果。

以下为一段由semantic UI编写的HTML5代码：

Home

English

中文

{% block index_header %} {% endblock %} 在HTML页面的编写中，还应用到了Django中十分神奇的模板语言。以上代码的最后两行，即为模板语言。在其他页面中写入 {% extends 'template.html' %} 即可将template.html文件整个导入，减少了代码的重复书写，十分方便。模板语言共分两种，一种为逻辑部分，格式为{% %}，可有十分语义化的表示方法，如需要多段相同代码时，可以写{% for i in range(1,5) %} {% endfor %}。引入图片或css样式时也需采用此方法。另一种为数据部分，格式为{{ }},其中填入所需补充的数据。 在前端还有一个问题需要解决，那就是分页问题。本系统采用在WEB服务器层分页的方法[24]，再利用Django框架自带的Paginator分页器工具完成分页。分页部分的代码如下：

{% if house_info.has_previous %}

<<< {% endif %}

当前第{{ house_info.number }}页

共有{{ house_info.paginator.num_pages }}页 {% if house_info.has_next %}

>>> {% endif %}

其中house_info为在views.py中定义的实例化分页器。在这段HTML5代码中也大量使用到了模板语言。 4.3.3 网页架构搭建模块 view层类似于控制器，获取到request请求后负责处理请求，与数据库交互获取数据，与template交互获取所需返回的界面，并处理其中的模板语言，通过参数返回内容，完成完整html页面的展示。其模块设计如图4.30。

view.py中的一个处理请求的函数如图4.31所示。

第16行：定义每一页中展示的数据的数量。 第17行：实例化model.py中定义的数据类，由此得到数据库中的数据。 第18行：实例化分页器。 第19行：定义URL中的不同页的写法。 第20行：获得每一页的数据列表 第21至25行：将要加入到HTML页面中的数据以字典的形式打包。 第26行：渲染页面。在收到url.py中的那个与该函数相对应的请求后，调用此函数，返回HTML页面，并加content以填充数据。 在url.py文件中编写url与view.py文件中函数的关系，降其一一绑定，完成由url至HTML页面的连接。 4.3.4 前端与数据库连接模块 Model层主要处理与数据库的操作，包括连接、获取数据等，在其中需要完整定义所连接数据库的各个字段，并完成连接。由于django有原生自带数据库，需要修改设置，使此项目使用MongoDB数据库，获取之前爬虫所获取的数据。点端与数据库连接模块如图4.32所示。

首先在setting.py中修改数据库相关设置并连接，如图4.33所示。

其次，在model.py中完成数据的定义，如图4.34。

第5行：Django框架与数据库的连接。 第6至18行：定义数据字段名与数据类型，其字段名应与数据库中的字段名保持一致。 第20行：连接数据库中的‘ty’表。 4.3.5 地图展示模块 高德地图为开发者提供可良好的地图接口，可以使用简单的js代码完成web项目中地图的创建，也可在其官网导入数据，完成数据可视化，再将可视化结果导入到web页面中。本系统采用第二种方法完成租房数据的可视化展示。使用此API的过程如下。 首先需要在高德地图API官网注册成为开发者，并建立项目，获取自己的key，如图4.35所示。

接着在高德地图为开发者提供的工具中找到“坐标拾取器”API，编写程序调用此API，将位置信息转化为经纬度。如图4.36所示。

第7行：定义传递给服务器的参数。 第8行：高德地图API提供的坐标拾取器的链接。 第9行：向服务器发起请求，并传入参数，接收服务器提供的返回值。 第11行：输出该地理位置的经度和纬度。 以上程序运行的结果如图4.37。

接着，批量将地理位置信息转换为经纬度，并将其保存为csv格式，将其上传至高德地图数据展示工具台，生成数据展示项目，完成数据展示功能。将其链接至Django框架中，即完成了对数据的可视化地图展示。

4.4 开启Django服务器 在命令行中输入命令python manage.py runserver并执行，将开启整个django架构所搭建的网站。如图4.38及4.39所示。此时可访问的页面为提示中的http://127.0.0.1:8000/。

4.5 成果展示 爬虫运行状态图如下图4.40。

从列表页获取详情页URL并进行爬取如图4.41。

数据抓取完成后，打开数据库可视化界面，如图4.42所示。

列表展示页面核心部分如图4.43。

数据可视化成果展示如图4.44。

网页结构展示如图4.45,4.46。

4.6 本章小结 第四章为系统各个模块的具体实现，其中重点分析并设计了各个模块的实现逻辑。本章首先分析了要爬起的各个网页的结构特性，编写代码实现了爬虫模块并将爬取到的数据通过连接模块传递给数据库。接着，对数据库中的表的结构进行了介绍。然后，对于需要完成的数据展示模块，完成了前端UI设计、分页系统设计、数据可视化设计等。最后，对本系统爬取、数据展示的部分成果进行了展示。

5 系统测试

5.1 测试环境及工具 操作系统：win7 家庭版 网络环境：太原理工大学校园网 软件版本环境如表5.1 表5.1 测试环境 软件 版本号 python 3.6.0 Anaconda custom 64bit 4.3.0 Pycharm x64 专业版 2018.1.2 Web strom x64 专业版 2018.1.3 scrapy 1.3.3 MongoDB 3.6 Django 2.0.5 Semantic UI 2.2.4 chrome 56.0.2924.87 高德地图 API 1.4.6（2018.4.18）

5.2 系统功能性测试 5.2.1 数据爬取功能测试 首先，对爬取租房信息的数据量进行测试。人工统计了各个网站太原租房信息的数量，大致情况为：58同城每页约50条记录，共70页，共有3500条可获取数据，安居客每页约为50条记录，总页数为115页，共有5750条可获取数据，我爱我家共有3500条可获取数据，列表网共有879条可获取数据，房天下共有2312条可获取数据，107间房共有799条可获取数据。 通过数据库的统计功能，对source字段进行统计，可得到各个数据来源获取到的数据量，数据量情况如下表5.2。

表5.2 爬取数量统计 网站 应获取数量 实获取数量 收集率 58tc 3500 3250 92.9% anjuke 5750 960 16.7% liebiaowang 879 840 95.6% 5i5j 3500 3442 98.3% fangtianxia 2312 2310 99.9% 107room 799 723 90.5% 总计 16740 11525 68.9% 从以上数据可以看出，除了“安居客”之外，其余各个网站的爬取均正常，达到了超90%的数据获取率，达到了预期的要求。安居客的爬取异常，初步分析为爬取过程中代理失败次数过多，导致大部分页面访问失效，获取不到数据。各个网站未能100%获取的最大原因就是代理失效，导致使用本机IP请求网页，导致出现302错误，网页将爬虫访问的链接重定向至无效页面。 接着，对数据获取的准确性进行测试。在这一部分，将随机从数据库中选取15条记录，分别手工访问其URL，对比爬取到的数据与数据库中的数据，以判断其抓取的准确性。测试用例及测试过程如下表5.3。 表5.3 准确性测试 编号 URL 标题/价格 是否准确 1 https://ty.5i5j.com/zufang/40156969.html 阳光地带高档小区精装三居拎包入住 是 2 https://ty.5i5j.com/zufang/36638185.html 可月付东中环路富力E区公寓豪华一居全家具家电拎包入住 是 3 https://ty.5i5j.com/zufang/38515410.html 平阳南路锦都苑精装三居家具家电齐全可合租员工宿舍 是 4 https://ty.5i5j.com/zufang/37126891.html 南内环街财富大厦对面引黄宿舍可以办公可以住家 是 5 http://m.58.com/ty/zufang/34186084909244x.shtml 可月付迎泽西大街和平南路漫香堤豪装大三居南北通透拎包 是 表5.3（续） 编号 URL 标题/价格 是否准确 6 http://ty.107room.com/r1055520 1300 是 7 http://ty.107room.com/r978799 800 是 8 http://ty.58.com/zufang/34192073358154x.shtml 整租|恒大绿洲两居室家具齐全仅租2100！2100！ 是 9 http://ty.58.com/zufang/34198563159985x.shtml 整租|糖酒大厦宿舍1室1厅1卫 是 10 http://zu.taiyuan.fang.com/chuzu/3_220058499_1.htm 办公长风街千峰南路丽景苑3居随时看房 是 11 http://zu.taiyuan.fang.com/chuzu/3_218975164_1.htm 长风街寇庄西路文华苑好房出租 是 12 http://taiyuan.liebiao.com/zufang/454463524.html 整租,迎泽桥西下元理工大学旁边,文兴苑出租精装主卧文兴苑 是 13 https://ty.zu.anjuke.com/fangyuan/1159390677 小马花园 无*精装修 带独立卫生间 家具家电齐全拎包入住 是 14 https://ty.zu.anjuke.com/fangyuan/1156769355 小井峪 华峪小区 彩虹湾精装三居 全家具家电 拎包月付 是 15 https://ty.zu.anjuke.com/fangyuan/1158578268 月付 低楼层 停车方便小东流 北中环附近 丰颂苑 全家具 是

经过测试发现，随机抽样的爬取正确率为100%，达到预期计划。 图5.1为爬取结束后scrapy提供的日志信息，其中包括爬取成功与失败的数量。

上图表示，在一次爬取过程中，一共请求了3677个页面，其中得到3674个反馈，占到总请求数的99.9%，共请求到了约500万字节的数据。在所有页面中，有3559个网页得到了正确的响应，115个由于网站的反爬策略出现了重定向（302），正确请求的占比达到了96.8%，达到了预期的效果。 5.2.2 数据展示测试 首先进行页面结构与跳转测试。对本站点内的所有页面发送访问请求，检查其返回的页面的结构是否合理，是否与预想效果一致，经测试，各个页面均达到了预期的效果。接着对页面跳转进行测试，点击其中的跳转超链接，均可完成预期的页面跳转。 页码超范围范围如图5.2。

共有231页数据，若URL输入‘?page=231’，页面可正常访问，显示最后一页的数据；若输入‘?page=232’，会出现404页面。若输入‘?p=231’，也将返回404错误提示。URL的页码格式在view层设置，在系统开发过程中将其设置为了‘page’。

5.3 系统非功能性测试 抓取速度测试：在太原理工大学校园网环境下，对我爱我家页面进行爬取，3000条数据约花费6分钟，抓取速度达到每分钟约500页面，基本满足需求。

5.4 本章小结 第五章为系统测试，在该章对系统中的关键环节进行测试。其中首先对测试环境进行了介绍，其次描述了对本系统进行的功能性测试与非功能性测试。

6 总结与展望

本文实现了一个基于scrapy框架的租房信息爬取系统，一个基于Django的数据展示系统，较好的完成了前文分析中提出的各种要求。随着互联网的发展，越来越多的人，特别是年轻人选择在互联网上挑选租房，本系统将互联网上各大租房信息网站的租房信息集中起来，能在一定程度上帮助人们挑选更适合自己的出租房，具有一定的现实意义。 在本系统的开发过程中，研究学习了如何使用scrapy、Django这两大框架，体会到了python语言的“极简至优美”，我接触到了这几个框架的前沿知识，对自己可以站在巨人的肩膀上兴奋不已。我在系统开发过程中，经历了由抓取数据至存储数据再至前端页面展示数据，这样的经历让我收获颇丰。通过这段时间的研究，我越发了解到爬虫已经渗透进了我们生活的方方面面。在这个大数据的时代，数据就是资源，爬虫作为获取数据的一大利器，需要我们更深入的研究与掌握。 代码开发是一个系统工程，从准备数据到前端，每个环节都十分关键，整个过程都需要用心去学习。 本系统有一定的现实意义，但现在看来还较为简陋，距离成熟面向大众，为更多的人提供服务还有一定的差距。我认为，可以在以下几个方向上继续开发，使系统变得更好： 1.单机性能不够强大，可以考虑引入 Redis 开源框架，实现scrapy框架爬虫的分布式爬取，此将极大的提高爬虫的性能； 2.开发基于此数据的搜索引擎； 3.现在的系统仅能爬取较为结构化的数据，仍有部分地方的租房信息是完全没有结构化的，比如豆瓣网的“租房社区”，其中有大量的优质房源但数据较为杂乱，可以给系统中添加自然语言处理模块，实现对此类信息的爬取； 4.该系统将互联网上多个网站的信息整合起来，这个思路可以拓展到其他领域中。

参考文献

[1] 王元卓. 网络大数据_现状与展望[J], 计算机学报,2013,36(6):1125-1138 [2] 2015-2020全球IP网络流量报告[C]. [3] 金朗. 我国住房租赁市场的问题与发展对策[J],宏观经济管理2018.3:80-85 [4] 2015年中国网络租房调查报告[EB/OL].http://www.199it.com/archives/379687.html [5] 张浩. 基于Scrapy的房屋租赁信息搜索系统的设计与实现[D]. 西安电子科技大学, 2017. [6] 梁文超. 网络租房法律规制研究[J], 法制与社会,2018.4(下):80-83 [7] 周立柱. 聚焦爬虫技术研究综述[J], 计算机应用,2005,25(9):1965-1969 [8] 网络爬虫_凶猛来袭[EB/OL].http://www.cnki.com.cn/Article/CJFDTotal-FAYN201 803032.htm [9] 安子建. 基于Scrapy框架的网络爬虫实现与数据抓取分析[D]. 吉林大学, 2017. [10] 陈利婷. 大数据时代的反爬虫技术[J], 电脑与信息技术,2016,24(6):60-61 [11] 刘石磊. 对反爬虫网站的应对策略[J], 电脑知识与技术,2017,13(15):19-23 [12] 张嘉琳. 由Robots协议引发的不正当竞争问题思考_以3百大战为视角[J], 法制与社会,2013.8(中):96-97 [13] 高祖瑞. 互联网竞争关系下的爬虫协议研究[J], 法制与社会,2018.3(上):85-87 [14] 管华. 对当今Python快速发展的研究与展望[J], 信息系统工程,2015.12.20:114-116 [15] Kong L-B. Querying Techniques for XML Data[J]. Journal of Software, 2007, 18(4). [16] 刘秋香. 对XPath_XLink和XPointer的分析研究[J], 微机发展2005,15(10):19-22 [17] 刘宇. 基于Scrapy的深层网络爬虫研究[J], 软件,2017,38(7):111-114 [18] 米硕. Scrapy分布式爬虫原理分析与概述[J],互联网+健康:234 [19] 瞿晓婷. 非结构化数据库技术综述[J], 农业图书情报学刊,2004.15(7):8-10 [20] 李慧. 数据库技术发展的新方向_非结构化数据库[J], 情报理论与实践2000,24(4):261,287-288 [21] 李杰. 基于ORM的轻量级数据持久化技术研究及应用[J],计算机科学,2010.37(9):190-193,208 [22] semantie UI官方文档[EB/OL]. http://www.semantic-ui.cn/. [23] 向玉云. 百度_高德及Google地图API比较研究[J], 软件导刊2017.16(9):19-25 [24] 齐金刚. Django框架Web数据查询分页技术研究[J],电子设计工程,2014.22(5):33-37 [26] How are we searching the World Wide Web? A comparison of nine search engine transaction logs[J] . Bernard J. Jansen,Amanda Spink. Information Processing and Management . 2004 (1) [27] Introduction to mongodb. D.Hows,P.Membrey,E.Plugge. Basics . 2014

致谢

学习的时光即将过去，回想过去的几年里，这一切的一切都是太原理工大学我母校给予的，在这里我学习、成长，即将成为一名太原理工大学的本科毕业生。 最要感谢的就是我的指导老师王一铭、赵涓涓，在研究课题的过程中不厌其烦的帮我解决问题，在最早的开题阶段，当我迷茫自己的研究方向的时候，老师帮助我确定研究课题，并在之后的研究中提出创新性的建议，当我在论文写作过程中遇到重要问题的时候，老师也耐心的给我提出了宝贵的建议，在论文的修改过程中，细致入微的为我指导，在这里十分感谢我敬爱的老师。其次要感谢太原理工大学、感谢我的家人、同学、朋友。

附录一 外文文献（原文） How are we searching the World Wide Web? A comparison of nine search engine transaction logs

1 Introduction The Web is now the primary source of information for many people (Cole, Suman, Schramm, Lunn, & Aquino, 2003; Fox, 2002). Over 80% of Web searchers use Web search engines to locate online informationor services (Nielsen Media, 1997). There is a critical need to understand how people use Web search engines. Amichai-Hamburger (2002) presents a review of the effect of the Web and the lack of awareness of the user in the design of Web systems and site content. The research reported in this article attempts to contribute to such a dialogue. Most research of Web searching provides little longitudinal, regional, or across system analysis. We need a clearer understanding of emerging Web searching trends across different global regions and between different Web search engines in order to design better searching systems. This important research area directly impacts pay-per-click marketing, Web-site-optimization strategies, and Web and Intranet search engine design. It complements research such as that conducted by Liawa and Huangb (2003), who showed that individual experience, individual motivation, search engine quality, and user perceptions of technology acceptance are all factors affecting individual desire to use Web search engines. In this paper, we present a comparison of nine major Web studies, four European and five US-based Web search engines, over a seven-year period. We provide a temporal comparison of differences in Web searching among and between US and European-based Web searches as one might expect some divergence due to linguistics and interface factors (Spink, Ozmutlu, Ozmutlu, & Jansen, 2002b). We specifically investigate the interactivity between searchers and Web search engines, identifying changes in the complexity of Web search interactions. In addition, we present a longitudinal analysis of the types of information people are searching for on the Web. We center our research analysis on the interactions between the user and the search engine. Interaction has several meanings in information searching, although the definitions generally encompass query formulation, query modification, and inspection of the list of results, among other actions. Belkin, Cool, Stein, and Theil (1995) have extensively explored user interaction within an information session. Efthimiadis and Robertson (1989) present and categorize interaction at various stages in the information retrieval process from information seeking research. Bates (1990) presents four levels of interaction, which are move, tactic, stratagem, and strategy. Lalmas and Ruthven (1999) present two groups of interaction, that which occurs across sessions and that which occurs within a session. This within-session category is the type of interaction that we examine in this study. We consider an interaction as any specific exchange between the searcher and the system (i.e., submitting a query, clicking a hyperlink, etc.). We define a searching episode as a series of interactions within a limited duration to address one or more information needs. This duration is typically short, with Web researchers using between 5 and 120 min to define a session duration (c.f., He, Go¨ker, & Harper, 2002; Montgomery & Faloutsos, 2001; Silverstein, Henzinger, Marais, & Moricz, 1999). The searcher may be multitasking (Spink, 2004) within a searching episode, or the episode may be an instance of the searcher engaged in successive searching (Lin, 2002; Spink, Wilson, Ellis, & Ford, 1998). We begin with an extensive review of literature concerning the rapidly growing area of Web search engine research. We then present the datasets used in this study. We discuss the analysis, results, and implications of the results for the design of Web searching systems. 2 Related studies There have been a few review articles on Web searching. Jansen and Pooch (2001) provide a review of Web transaction log research of Web search engines and individual Web sites through 2000. Hsieh-Yee (2001) reviews studies conducted between 1995 and 2000 on Web search behaviors. The researcher reports that many studies investigate the effects of certain factors on search behavior, including information organization and presentation, type of search task, Web experience, cognitive abilities, and affective states. Hsieh-Yee (2001) also notes that many studies lack external validity. Bar-Ilan (2004) presents an extension and integrative overview of Web search engines and the use of Web search engines in information science research. Bar-Ilan (2004) provides a variety of perspectives including user studies, social aspects, Web structure, and search-engine evaluation. We extend these review articles in this section, setting the stage for our analysis. Web searching studies fall into three categories: (1) those that primarily use transaction-log analysis, (2) those that incorporate users in a laboratory survey or other experimental setting, and (3) those that examine issues related to or affecting Web searching. In this paper, we focus on studies using transaction log analysis. Romano, Donovan, Chen, and Nunamaker (2003) present a methodology for general qualitative analysis of transaction log data. Wang, Berry, and Yang (2003) and Spink and Jansen (2004) also present detailed explanations of approaches to transaction log analysis. In investigations of single Web sites, Yu and Apps (2000) use transaction log data to examine user behavior in the SuperJournal project. For 23 months (February 1997 to December 1998), the researchers recorded 102,966 logged actions, related these actions to four subject clusters, 49 journals, 838 journal issues, 15,786 articles, and three Web search engines. In another study covering the period from 1 January to 18 September 2000, Kea, Kwakkelaarb, Taic, and Chen (2002) examined user behavior in Elseviers ScienceDirect, which hosts the bibliographic information and full-text articles of more than 1300 journals with an estimated 625,000 users. Loken, Radlinski, Crespi, Millet, and Cushing (2004) examined the transaction log data of the online self-directed studying of more than 100,000 students using a Web-based system to prepare for US college admissions tests for several months of use. The researchers noted several nonoptimal behaviors, including a tendency toward deferring study and a preference for short-answer verbal questions. The researchers discuss the relevance of their findings for online learning. 3 Discussion As the Web is becoming a worldwide phenomenon, we need to understand better the emerging trends in Web searching given the tremendous influence Web search engines have on directing traffic to online information and services. Our findings indicate that the interactions between Web search engines and searchers are not becoming more complex, and in some respects, are becoming less complex. Our comparative analysis also indicates that finding from a study focusing on one Web search engine cannot be applied wholesale to all Web search engines. Sessions lengths are not increasing as measured by number of queries. The percentage of one-term sessions is remaining stable over time and across Web search engines. There was a difference with the 1998 AltaVista study, but this appears to be caused by an artificially short session duration that the researchers used. Queries lengths are also not increasing as measured by number of terms. There was a statistical difference in the percentage of one-term queries on the German Fireball Web search engine, which may be due to linguistic differences with the other Web search engines. The percentage of single-term queries is holding steady, and the use of query operators is also remaining stable. Web search engines in the future may better leverage the implicit feedback from this interaction to provide more personalized results (Callan & Smeaton, 2003). However, the use of query operators between Web search engines varies significantly, so in this area findings from one study cannot necessary be applied to predict behaviors on other Web search engines. The viewing of only the first page of results is extremely high, and it significantly increased over time on the Excite Web search engine. This may indicate increasing simplicity in interactions. It may also be an indication of the increasing ability of Web search engines to retrieve and rank Web documents more effectively. There is certainly a need for more studies that focus on the Web document and virtual document (Watters, 1999) level of analysis. The trend toward viewing fewer result pages with Excite users may be related to a changing user base during the time of the study as the Web population dramatically increased during this time. Excite was the second most popular Web site in 1997 (Munarriz, 1997), and was the fifth most popular in 1999 and 2001 as measured by number of unique visitors (Cyber Atlas, 1999, 2001). There are both similarities and differences between usage on US and European-based Web search engines. Searchers on both are similar in session length, query length, and number of results pages viewed. Additionally, the use of Web query operators on both is fairly stable. However, the usage of these advanced Web-query operators is much higher on US-based Web search engines than on their European counterparts. In investigating this difference, we ruled out size of content collections (they are all immense), user bases (they all number in the millions), or algorithmic sophistication (they are all similar in performance tests). Fireball and BWIE did not prominently display the advanced Web searching options; however, it may be that users of these Web search engines just do not use query operators. This increases the criticality of keyword and phrase selection for Web providers targeting these users. Fireball is a general purpose Web search engine, but, BWIE is also a search directory. A search directory supplements query matching of the entire content collection with directory-based search (c.f., Yahoo http:// www.yahoo.com or Open Directory http://dmoz.org/). The idea behind directory services is to provide additional organization to the content. However, some research has shown that directory-based searching does not improve searching performance and also takes longer (Dennis, Bruza, & McArthur, 2002). There are variations of the search directory including specialized or niche Web search engines that provide content within a specific Web search engines, including computer science literature (CiteSeer http://www.researchindex.com), e-commerce (Froogle http://froogle.google.com/), or personal information (c.f., http:// www.switchboard.com). Some Web search engines provide clustering (Vivisimo http://vivisimo.com/), which one can view as an automated, real time, and virtual directory service. AlltheWeb.com has extensive advanced Web search features, however. Additionally, the results of the 2002 AlltheWeb.com dataset do not conform to the results from studies of the other European-based Web search engines. One possible reason may be that AlltheWeb.com is attracting searchers outside of its traditional European market. From our analysis of the AlltheWeb.com transaction log, nearly 90% of the query requests are in English, with 6% French, 1% each Spanish, German, Italian, and a variety of other languages making up the rest. Further research will be needed to isolate the effects of linguistic differences. Web searching topics are changing. There was a decrease in sexual searching as a percentage of overall Web searching on both European and US-based Web search engines. The overall trend is towards using the Web as a tool for information or commerce, rather than entertainment. This trend is more pronounced with US as opposed to European searchers. This analysis certainly confirms survey and other data that the Web is now a major source of information for most people (Cole et al., 2003; Fox, 2002). There is increased use of the Web as an economic resource and tool (Lawrence & Giles, 1999; Spink et al., 2002a), and people use the Web for an increasingly variety of information tasks (Fox, 2002; National Telecommunications & Information Administration, 2002). The decreased level of interaction of Web searches may be unwelcome news for Web-search engine developers and for those providing Web-based information content, products, and services. Web users appear unwilling to invest additional effort to locate relevant Web content. The trend towards viewing only the first results page is a challenge for those seeking to draw visitors to their Web sites or for Web search engines attempting to generate revenue via ad impressions. Users have a low tolerance of viewing any results past the first page. They prefer to reformulate the Web query rather than wade through result listings. Placement within the first page of Web search engine results of an accurate abstract appears to be a determining factor in drawing traffic to a particular Web site. We continue to conduct ongoing analysis of Web searching trends to provide a valuable insight into this important and critical area of human computer interaction and electronic commerce.

附录二 外文文献（译文） 我们如何搜索万维网？九种搜索引擎事务日志的比较 1 介绍 Web现在是许多人的主要信息来源（Cole, Suman, Schramm, Lunn, & Aquino，2003；福克斯，2002）。超过80%的网络搜索者使用网络搜索引擎来定位在线信息或服务（Nielsen Media，1997）。人们迫切需要了解人们如何使用网络搜索引擎。Amichai-Hamburger（2002）回顾了Web的影响以及用户对Web系统和站点内容的设计缺乏意识。本文的研究试图为这种对话做出贡献。大多数网络搜索研究很少提供纵向、区域或跨系统分析。我们需要更清楚地了解不同的全球区域和不同的Web搜索引擎之间出现的网络搜索趋势，以便设计更好的搜索系统。 这一重要的研究领域直接影响点击付费营销，网站优化策略，以及Web和Intranet搜索引擎的设计。它补充了研究，如 Liawa和 Huangb（2003）进行的研究，显示个人经验、个人动机、搜索引擎质量和用户对技术接受的感知都是影响个人使用网络搜索引擎的因素。 在本文中，我们提出了九个主要的网络研究，四个欧洲和五个基于美国的网络搜索引擎，经过七年的比较。我们提供了一个时间比较的网页搜索之间的差异之间和美国和欧洲之间的网络搜索，因为人们可能会期望一些分歧，由于语言学和接口因素（Spink, Ozmutlu, Ozmutlu, & Jansen，2002年B）。我们具体研究搜索引擎和Web搜索引擎之间的交互性，识别网络搜索交互复杂性的变化。此外，我们还对人们在网上搜索的信息类型进行了纵向分析。 我们的研究集中在用户和搜索引擎之间的交互分析上。交互在信息搜索中具有多个意义，尽管定义通常包括查询公式、查询修改和检查结果列表等。 Belkin, Cool, Stein和 Theil（1995）在信息会话中广泛地探索用户交互。Efthimiadis 和Robertson（1989）从信息寻求研究中提出并分类了信息检索过程中的各个阶段的交互作用。Bates（1990）提出了四个层次的互动，即行动、策略、策略和策略。 Lalmas 和Ruthven（1999）提出了两组交互，这是在会话中发生的，在会话中发生的。 会话内的类别是我们在本研究中研究的交互类型。我们考虑交互作为搜索器和系统之间的任何特定的交换（即提交查询、点击超链接等）。我们定义一个搜索情节作为一系列的相互作用在有限的时间内，以解决一个或多个信息需求。这个持续时间通常很短，Web研究人员使用5到120分钟来定义会话持续时间（C.F.，HE，Go E.KER，HARPER，2002；ManggMoRe＆FalutsOS，2001；Sulvistin，Henzinger，Marais，Myrz，1999）。搜索器可以是搜索事件中的多任务（SPink，2004），或者该事件可以是搜索者进行连续搜索的实例（Lin，2002；Spink，Wilson，埃利斯，Ford，1998）。 我们开始广泛的文献回顾与快速增长的领域的网络搜索引擎研究。然后，我们提出了在本研究中使用的数据集。我们讨论的分析，结果，以及网页搜索系统的设计结果的影响。 2 近期研究 已经有一些关于Web搜索的评论文章。Jansen和PooCH（2001）通过2000对Web搜索引擎和个人网站的Web交易日志进行了综述。Hsieh Yee（2001）回顾了1995到2000年间进行的关于网络搜索行为的研究。研究者发现许多因素对搜索行为的影响，包括信息的组织和呈现、搜索任务的类型、网络体验、认知能力和情感状态。Hsieh Yee（2001）也指出许多研究缺乏外部效度。Bar Ilan（2004）提出了网络搜索引擎的扩展和综合概述，以及网络搜索引擎在信息科学研究中的应用。Bar Ilan（2004）提供了多种视角，包括用户研究、社交方面、Web结构和搜索引擎评价。我们在本节中扩展这些评论文章，为我们的分析设置阶段。 Web搜索研究分为三类：（1）主要使用事务日志分析的方法，（2）将用户纳入实验室调查或其他实验设置，以及（3）检查与Web搜索相关或影响Web搜索的问题。在本文中，我们专注于研究使用事务日志分析。Romano, Donovan, Chen, and Nunamaker （2003）提出了一种用于事务日志数据的一般定性分析的方法。Wang、Berry、Yang（2003）和Spink和Jansen（2004）也对交易日志分析方法进行了详细的解释。 在对单个网站的调查中，Yu和Apple（2000）使用事务日志数据来检查超级日志项目中的用户行为。23个月（1997年2月至1998年12月），研究人员记录了102966个日志记录动作，这些动作与四个主题集群、49个期刊、838个期刊问题、15786篇文章和三个网络搜索引擎相关。在另一项涵盖1月1日至2000年9月18日的研究中，KEA、Kwakkelaarb、Taic和Chen（2002）审查了ELSVEVIES SCIONTION中的用户行为，该数据库承载了超过1300个期刊的书目信息和全文文章，估计有625000个用户。Loken, Radlinski, Crespi, Millet和 Cushing（2004）利用基于Web的系统对100000多名学生进行在线自学习的交易日志数据进行了研究，以准备美国大学入学考试几个月的使用。研究者注意到一些非最佳行为，包括推迟学习的倾向和对简短回答的口头问题的偏好。研究者讨论了他们的研究结果与在线学习的相关性。 3 讨论 随着Web正在成为一种世界性的现象，我们需要更好地了解Web搜索的新趋势，因为Web搜索引擎对引导在线信息和服务的巨大影响。我们的研究结果表明，网络搜索引擎和搜索者之间的交互作用并没有变得越来越复杂，并且在某些方面，变得不那么复杂了。我们的比较分析也表明，从一个专注于一个Web搜索引擎的研究中发现，不能广泛应用于所有的Web搜索引擎。 会话长度不会随着查询次数的增加而增加。一个学期的百分比保持稳定，随着时间的推移和跨网络搜索引擎。1998阿尔塔维斯塔研究有差异，但这似乎是由研究人员使用的人工短会话持续时间造成的。查询长度也没有增加，由数量的条款来衡量。在德国火球网络搜索引擎上的一个术语查询的百分比有统计学差异，这可能是由于与其他网络搜索引擎的语言差异。单项查询的百分比保持稳定，查询操作符的使用也保持稳定。未来的网络搜索引擎可以更好地利用来自这种交互的隐含反馈来提供更个性化的结果（Calaand Simon，2003）。然而，Web搜索引擎之间的查询操作符的使用变化很大，因此在这一领域中，从一个研究中得到的结果不可能被应用于预测其他Web搜索引擎上的行为。 只看到第一页的结果是非常高的，并且随着时间的推移，它在激动人心的Web搜索引擎上显著增加。这可能表明在交互中增加了简单性。这也可能是Web搜索引擎能够更有效地检索和排序Web文档的能力的指示。当然，需要更多的研究集中于Web文档和虚拟文档（Watters，1999）的分析水平。 随着时间的推移，随着网络用户数量的急剧增加，使用ExcTE用户查看较少的结果页面的趋势可能与研究期间的用户基数相关。ExcTITE是第二个最受欢迎的网站1997（MunRiz，1997），是第五最流行的1999和2001，由独特的访问者的数量（Cyber Atlas，1999, 2001）。 美国和基于欧洲的网络搜索引擎的使用既有相似之处又有差异。搜索者在会话长度、查询长度和查看结果页面的数量方面都是相似的。此外，两个Web查询运算符的使用都相当稳定。然而，这些先进的Web查询运算符在基于美国的Web搜索引擎上的使用率要高于欧洲同类搜索引擎。在调查这一差异时，我们排除了内容集合的大小（它们都是巨大的）、用户基础（它们都是数以百万计的）或算法复杂度（它们在性能测试中都是相似的）。FielBand和BWEE并没有显著地显示先进的Web搜索选项；然而，可能是这些Web搜索引擎的用户不使用查询操作符。这增加了针对这些用户的Web提供商的关键字和短语选择的临界性。 火球是一种通用的网络搜索引擎，但BWIE也是一个搜索目录。搜索目录补充整个目录集合与基于目录的搜索的查询匹配（C.F.，雅虎http://wwwayyo.com或OpenDirectory http://dMOZ.org/）。目录服务背后的思想是向内容提供额外的组织。然而，一些研究已经表明，基于目录的搜索不能提高搜索性能，也需要更长的时间（丹尼斯，Bruza，Mcththr，2002）。搜索目录的变体包括专门的或利基的网络搜索引擎，这些搜索引擎在特定的网络搜索引擎中提供内容，包括计算机科学文献（CITESER http://www-ScReChanDeX.com）、电子商务（FROGOLE http://FrooL.C.com）、或个人信息网络。信息（C.F.，http://www. witcBoo.com）。一些Web搜索引擎提供群集（ViVISIMO http://viistimo.com），可以将其视为自动化、实时和虚拟目录服务。 然而，AutoWebWeb具有广泛的高级Web搜索功能。此外，2002 AutoWebWeb数据集的结果不符合其他基于欧洲的Web搜索引擎的研究结果。一个可能的原因可能是AutoWebWeb吸引了搜索者在其传统的欧洲市场之外。从我们分析的AutoWebWeb交易日志中，将近90%的查询请求是英文的，有6%法语，1%西班牙语、德语、意大利语和其他各种语言组成其余的语言。进一步的研究将需要隔离语言差异的影响。 网络搜索主题正在发生变化。在基于欧洲和美国的网络搜索引擎中，性别搜索的减少占了整个网络搜索的百分比。总的趋势是使用网络作为信息或商业的工具，而不是娱乐。与欧洲的搜索者相比，这种趋势在美国更为明显。这一分析肯定证实了调查和其他数据，网络现在是大多数人信息的主要来源（Cole et al., 2003；福克斯，2002）。越来越多的使用Web作为经济资源和工具(Lawrence & Giles，1999；Spink等人，2002年A），人们使用Web的信息任务越来越多（Fox，2002；国家电信和信息管理局，2002）。 网络搜索交互水平的降低可能是网络搜索引擎开发人员和那些提供基于Web的信息内容、产品和服务的不受欢迎的消息。Web用户似乎不愿意投入额外的努力来定位相关的Web内容。只浏览第一个结果页面的趋势对于那些试图吸引访问者访问他们的网站或试图通过广告印象来产生收入的网络搜索引擎来说是一个挑战。用户对通过第一页查看任何结果的容忍度很低。他们倾向于重新构建Web查询而不是涉足结果列表。在Web搜索引擎的第一页中放置一个精确的摘要似乎是吸引特定网站的流量的决定性因素。 我们继续进行网络搜索趋势的持续分析，以提供宝贵的洞察这一重要和关键领域的人机交互和电子商务。

推荐阅读

 您阅读本篇文章共花了：