博主介绍:专注于Java .net php phython 小程序 等诸多技术领域和毕业项目实战、企业信息化系统建设,从业十五余年开发设计教学工作
☆☆☆ 精彩专栏推荐订阅☆☆☆☆☆不然下次找不到哟
我的博客空间发布了1000+毕设题目 方便大家学习使用
感兴趣的可以先收藏起来,还有大家在毕设选题,项目以及论文编写等相关问题都可以给我留言咨询,希望帮助更多的人
任何FTP站点的建立都符合文件传输协议(File Transfer Protocol, FTP),由于FTP协议任务是从一台计算机将文件传输到另外一台计算机,它与这两台计算机所处的位置、连接方式、甚至是否使用相同的操作系统都没有关系。在使用FTP协议对话时,我们都可以使用FTP命令来传输文件。虽然在每种FTP服务器上支持的FTP命令有一些细微的差别,但它们所使用的基本命令结构是相同的,对于标准FTP命令也都支持。因此通过FTP命令获取FTP站点数据应该可行,而且拥有较好的兼容特性。本设计为FTP搜索引擎爬虫模块,所需要获取的数据有资源名称、类型、大小和最后修改时间。可以使用FTP服务器提供的标准命令满足此次设计的需求。
按照用户的设置,从众多潜在可访问站点中找出可访问的FTP站点。
利用FTP命令获取该FTP站点下的文件和目录,并分别记录各个目录下的文件和子目录。
读取分类号。按照数据类型的编号列表,对不同类型的文件数据标号。以便对数据进行分类。
利用步骤(1.2.2)和(1.2.3)中获取的数据建立完整的数据源,并且按约定协议存在指定的目录下。
将可访问的站点存入站点列表中,便于下次扫描使用。
利用源文件建立索引数据库,方便数据的检索操作。
用户对在完成对FTP搜索引擎的爬虫模块配置文件的配置,便可执行爬虫程序。FTP搜索引擎的工作模式大概如下:
- 爬虫程序会自动生成用户指定IP网段中包含的所有IP地址,对它们逐一进行扫描,已确认哪些站点提供了匿名的FTP服务。
- 当程序成功登录某个FTP站点之后,程序会自动获取其各级目录下的文件和目录列表,并且会获取各个文件的大小、最后修改时间,最后程序会根据对照表对获取的各个文件进行分类。
- 在所有操作完成之后,会生成该站点的目录和源文件。在扫描完用户配置的站点之后,扫描成功的站点会写入一个站点列表的文件,以便以后使用。
在索引模块中,会根据爬虫模块获取的数据,进行处理,建立索引数据库。
图 21 搜索引擎系统工作图
图 22 FTP搜索引擎工作流程图
如今很多企业和个人都建立了自己的FTP站点,在各个FTP站点中包含有大量的资源,如何才能快速的在浩如烟海的资源中找到自己需要的资源,已经成为一个需要我们不得不解决的难题。要解决这一问题,需要我们建立一个有效的FTP搜索引擎,而实现搜索引擎的第一个问题就是如何获取各个站点提供的资源信息。本次设计的题目为FTP搜索引擎爬虫模块,其用途就是搜集各个FTP站点的数据信息,并且组织成一个特定的数据格式,索引模块得去这组数据之后,利用再次处理这些数据,建立索引数据库。
经过查阅资料,由于Ftp 搜索引擎与WWW 搜索引擎最大的区别就在于Ftp 站点内没有与WWW 页面相对应的超链接,因而Ftp 搜索引擎的站点获得策略就不能模仿搜索引擎业非常时兴的超链分析技术。在本次Ftp 搜索引擎爬虫模块的设计里,我采用了IP 扫描技术和手工添加技术的中和。一方面,程序一开始会读取系统的配置文件,获知本次扫描的网段范围,在对配置文件进行数据效验通过之后,程序会调用相应模块生成该网段中所有的等待访问的IP地址。另一方面,程序本身维护有一个IP站点列表,该列表中会保存用户手工配置的以及上一次扫描成功的IP站点性息,该IP列表中包含有提供FTP服务站点的IP地址和端口号。
-
-
-
- 实现方法
-
-
根据网段生成IP地址的方法多种多样,在本次设计时,我考虑过以下两种方法。
- IP地址分为四段(如:192.168.0.1)每一段可能出现的值为0~255,用程序控制IP地址段的进位(256进1)。用循环的方式,每次为最低位执行加1操作,并验证其是否需要执行进位操作,即可实现对于网段中IP地址的生成操作
这种方法虽然能够较好的实现网段中IP地址的生成操作,但是由于要人工编写代码实现数据的进位操作,实现较为繁琐,而且由于种种原因的综合影响,不能够完全保证代码的稳定性。
- IP地址分为四段(如:192.168.0.1),每一段的长度为256,由于系统本身并不支持256进位的方式,虽然编程可以对其进行认为的进位控制,但是仍然带来一些不必要的麻烦。由十进制和二进制之间的转换得到启发。在实现是我IP地址转换为十进制进行操作。转换方式为(以192.168.0.1为例)。同样使用循环的方式,每次对转换为十进制的IP地址进行加一操作,这样就避免了人工编写代码控制进位的麻烦,程序的稳定性和代码编写的效率都大大提高。
在上面的循环操作执行完成之后,我们可以得到一个IP地址表,注意,此时IP地址表中的IP地址均以十进制的数字方式保存。在使用时,我们需要将这些数字再次转化为IP地址。利用.net Framework中提供的IPAddress类中的Parse方法,可方便的将我们获取的十进制数据再次转换为类型为IPAddress类型的IP地址数据,最后我们使用ToString()方法将其转化为字符串,方便以后的使用
有上面的描述可以看出,在目前的状况下方法2)优于方法1),因此本次设计我选用了方法2)进行实现。
-
-
-
- 核心代码
-
-
图 31 IP网段生成
这一部分的实现虽然比较复杂,但是设计思路却较为简单,首先需要向目标站点发送数据请求。FTP站点会根据请求回传的数据,若请求有误,则会回传错误信息。
-
-
-
- 实现方法
-
-
在前期准备工作结束之后,由于使用的开发语言为C#,因此考虑使用.net Framework中提供的FtpWebRequest类库实现该功能。但是后来发现FtpWebRequest类库中提供的功能并不能很好的满足本次设计的需要,并且对目标FTP站点的配置有一定的要求。因此后来放弃了这种方法,改用套接字的方式实现,向指定站点发送FTP命令,然后获取其回传的数据,由于这种方法可以自由的使用所有FTP命令,所以相对原有的方法更为灵活。下面是两种方法的设计思路。
- 使用FtpWebRequest类:
用此方法,首先需要取得FtpWebRequest的实例。注意,这里必须拥有服务器的有效用户名和密码,或者服务器必须允许匿名登录。当需要指定用户名和密码是,可通过设置Credentials属性来制定用于连接服务器的凭据,也可以将它们包含在传递给 Create 方法的 URI 的 UserInfo 部分中。
使用FtpWebRequest类可以完成对FTP服务器的多种操作,如获取服务器文件简短列表、获取服务器上文件大小等。经过查阅资料,发现其内部的实现方式仍然是使用FTP命令实现。(如ListDirectory对应的是FTP命令中的NLIST命令,ListDirectoryDetails对应的是FTP命令中的LIST命令)下面简要介绍一下这种方法的使用方式(以下代码执行了一次文件删除操作)
图 32 FtpWebRequest方式
- 使用套接字(Socket)方式:
如果编写过网络程序,那么您对这种实现方法一定并不陌生,在.net中Socket类为网络提供了一套丰富的方法和属性。本次设计使用面向连接的协议(FTP),在进行数据通讯时使用Send和Receive方法实现。IP地址和端口号使用IPEndPoint表示。Socket的SendTimeOut属性中可以支持设置等待时间。
使用套接字实现获取数据,可以在代码中选取自己需要的FTP命令使用,因此相比使用FtpWebRequest类库,这种方式拥有更好的灵活性,可以按照自己程序的需要定制。
下面列举出本次设计使用的几条重要的FTP命令:
LIST:获取FTP站点的文件和目录清单
SIZE:获取FTP站点指定文件的大小
MDTM:获取FTP站点文件的最后修改时间
USER:登录FTP站点使用的用户名
PASS:登录FTP站点的用户密码
QUIT:关闭FTP连接
下面给出部分代码(用于登录FTP服务器):
图 33 socket方式
-
-
-
- 获取文件列表
-
-
- 设计思路:
使用List命令获取文件和目录列表,根据回传的数据中包含有标志位,说明了该文件名表示的是目录还是文件。
在此处遇到了一个服务其兼容的问题,测试时发现FTP服务器返回的数据格式风格不同,如IIS和Serv-U,IIS返回的数据为Windows风格,而Serv-U返回的数据则是Linux风格,因此这里对于返回数据的处理不可能用同样的方法,具体解决方法请参见3.2.4服务器兼容中的描述。
- 实现方法:
使用Socket中的Send命令,向FTP服务器发送LIST命令。同样,使用Socket提供的命令Receive,接收指定字节数的数据,并将数据存如缓冲区,此处指定的缓冲区大小为512个字节。通过回传字符串中的标志位,获取回传的字符串中的目录。
下面是用于获取数据的主要代码:
-
-
-
- 获取目录列表
-
-
- 设计思路:
使用List命令获取文件和目录列表,根据回传的数据中包含有标志位,说明了该文件名表示的是目录还是文件。
在此处遇到了一个服务其兼容的问题,测试时发现FTP服务器返回的数据格式风格不同,如IIS和Serv-U,IIS返回的数据为Windows风格,而Serv-U返回的数据则是Linux风格,因此这里对于返回数据的处理不可能用同样的方法,具体解决方法请参见3.2.4服务器兼容中的描述。
- 实现方法:
使用Socket中的Send命令,向FTP服务器发送LIST命令。同样,使用Socket提供的命令Receive,接收指定字节数的数据,并将数据存如缓冲区,此处指定的缓冲区大小为512个字节。通过回传字符串中的标志位,获取回传的字符串中的目录。
下面是用于获取数据的主要代码:
图 35 获取目录列表
-
-
-
- 获取文件大小
-
-
- 设计思路:
使用SIZE命令获取指定目录下指定文件的大小,根据回传的数据中包含有标志位,说明了该命令是否执行成功,若执行成功,则获取了文件的大小。
- 实现方法:
使用Socket中的Send命令,向FTP服务器发送SIZE命令。同样,使用Socket提供的命令Receive,接收指定字节数的数据,并将数据存如缓冲区,此处指定的缓冲区大小为512个字节。使用SIZE命令获得的文件大小单位是字节,通过将返回数据除以1024获得将单位转换为KB。
下面为该部分的主要代码:
图 36 获取文件大小
-
-
-
- 文件分类
-
-
- 设计思路:
在配置文件中建立一个文件分类列表,由于文件的类型划分是根据文件的后缀名进行的,因此单独将文件的后缀名分离出来,对照文件分类表进行类型匹配。若匹配成功则返回类型编号,若失败,则返回一个默认编号。
- 实现方法:
使用.net Framework中提供的文件读取类StreamReader,将文件分类列表读入内存,与从FTP站点上获取的文件的后缀名进行逐一的匹配操作,若成功,返回类型编号,失败返回一个默认值。
从FTP站点上获取的文件名中包含后缀名,使用split()函数将文件的后缀名分离出来用于后缀名匹配。
下面为该部分的主要代码:
图 37 初始化文件读取类
图 38返回文件类型
在最初使用Socket方式获取数据时,对于英文,数据传递没有问题,当出现中文文件时,发现获得的数据中,所有的汉字都变为“?”,更为严重的问题是当利用获取的文件名发送SIZE等命令时,FTP站点不能正确解析这些带有汉字的编码,造成此次数据获取失败。
-
-
-
- 解决方法
-
-
.net提供了Encoding的方法进行编码的转换,于是我尝试将传送数据的编码由ASCII转换为GB2312。因为ASCII编码不支持汉字,而GB2312支持汉字。结果最终发现当发送的字符转换为GB2312后,FTP服务器仍然不能正确解析,获取文件大小以及最后修改时间是仍然会发生错误。
之后又尝试将编码方式改为UTF8编码,结果仍然是不能解决汉字问题。如果FTP搜索引擎的爬虫部分不能有效的获取带有汉字的文件数据,那么它的实用性将大大的降低。经过几天是尝试和查阅网上资料,发现编码问题应该是可以解决的,网上也有人提供了使用其它方式实现的支持汉字的FTP类。由于改动这个FTP类会对本程序造成较大的改动,所以我仍然决定在现有的基础上对程序进行修改。
经过努力,最后终于找到了修改的方法,代码的修改其实很简单,却很容易让人忽略,其方法为将代码Encoding ASCII= Encoding. ASCII改为Encoding ASCCI = Encoding.Default。经此修改,虽然在有些服务器上仍会出现汉字的乱码,但是却能成功的使用这些获取的数据向FTP服务器发送请求。而且这些乱码也可在数据获取完成后使用转码的方式进行修正。
现阶段市面上使用的操作系统只要有Windows系列和Linux,而两个系统的数据传输的风格并不相同。因此,在做数据测试时,我选用了Linux风格的Serv-U和Windows风格的IIS分别搭建了FTP服务器。下面简要介绍一下这两款服务器软件。
- Serv-U:
该软件是 RhinoSoft公司开发的Serv-U作为搭建FTP服务器端的软件,在国内市场被广泛使用。Serv-U 是目前众多的FTP 服务器软件之一。通过使用Serv-U,用户能够将任何一台PC 设置成一个FTP 服务器,这样,用户或其他使用者就能够使用FTP 协议,通过在同一网络上的任何一台PC与FTP 服务器连接,进行文件或目录的复制,移动,创建,和删除等。这里提到的FTP 协议是专门被用来规定计算机之间进行文件传输的标准和规则,正是因为有了像FTP 这样的专门协议,才使得人们能够通过不同类型的计算机,使用不同类型的操作系统,对不同类型的文件进行相互传递。
- IIS:
IIS是Windows系统提供的一种服务,它包括WWW服务器、FTP服务器和SMTP服务器,由于有操作系统提供,且功能强大,操作简便,因此是现在假设个人网站的首选。
-
-
-
- 问题描述
-
-
由于可用于搭建FTP站点的服务器多种多样,如何能够较好的兼容各种社会上所使用的FTP服务器成为一个不容我忽视的问题。
在编写代码时,发现现在失眠上两款被广泛使用FTP服务器软件虽然可以使用相同的FTP命令做它们进行操作,但是在命令执行之后,他们回传的数据格式并不相同。这直接造成程序不能够正常的解析从FTP站点获取的数据。例如IIS传回的数据中如果某一项包含“<dir>”则表明该数据为一个目录,但是如果使用Serv-U作为服务器,则以在开头以“d”表示该条数据为一个目录。
-
-
-
- 解决方法
-
-
如何解决兼容性问题是程序开发中的一个难题,在本次设计开始之初,我就考虑过这个问题,尽量的使用了标准的命令来对服务器进行操作。然而虽然使用FTP命令后对服务器的操作实现了兼容,但是回传数据没有兼容。
因此不得不回传的字符串进行分析。
IIS:
图 39 IIS返回的数据
Serv-U:
图 310 Serv-U返回的数据
如上面所示,两个服务其回传的数据的差距是十分巨大的。但是经过观察,两组数据的相同点也有很多,比如各组数据在其中所占的字符数大致相同(文件名除外),这为我从中提取有效数据带来了很多便利。
另外,要区别这两组数据也并不困难。IIS回传数据的开头始终是日期,而Serv-U的开头始终是Linux风格的权限标识。利用这个特点,可以较为容易的将他们区别开来。
由于回传字符串的问题,对于这两种风格的字符串必须分别编写代码对它们进行解析。经过分析,各组数据都有一个共同的特点,就是其中的间隔数是相同的,利用这一点,可以从字符串的指定位置提取出需要的数据。下面给出这部分的核心代码。
IIS部分的解析代码:
图 311 解析IIS返回字符串
Serv-U部分的解析代码:
图 312 解析Serv-U返回字符串
生成的数据源文件主要用于为后面的建立索引做准备。
-
-
-
- 设计思路
-
-
这部分功能主要是将爬虫模块获取的文件按照指定的格式存为文件,以便为建立索引,方便检索。由于前期已经将实现将爬取的数据分目录暂时存在内存中。因此这部分的工作主要就是将内存中的数据按约定格式写入文件。
-
-
-
- 实现方法
-
-
格式要求:
如有以下一个站点
图 313 站点目录结构
其要求的生成文件格式为(如下图所示):
图 314 生成文件结构
现在分析文件的格式,发现其对每一级目录都是先列出其子目录,再列出该目录下的文件,之后再依次列出其包含的子目录及子目录下的文件。如此重复,直到列出了所有的资源数据。
分析文件结构之后,其符合使用递归的特点,因此这部分使用递归的方式进行编码实现。
下面给出这部分的核心代码:
图 315 生成原始数据代码
将连接成功的FTP站点保存在一个List<String>类型中,在程序执行完成之后,所有成功获取到数据的站点存到一个名为ipList的文件中。以便之后用户的使用和查阅那些能够提供FTP服务的站点。
-
-
-
- 实现方法
-
-
使用List<>中提供的Add()方法将有效的IP地址存入类型为List<String>的变量中。在程序运行结束之后,类型为List<String>的变量中存储的数据即为有效的FTP站点信息。使用StreamWriter类,将变量中的数据按行写入名为ipList的文件。
在得到倒排索引前,首先就要对原始数据进行特殊的处理。因为如果直接从原始数据得到索引,这样执行的效率会很低,而却实现起来也会比较困难。因此,提前执行一次数据处理,这样在后面建立文件索引时效率会有效的提高。
-
-
-
- 实现方法
-
-
原始数据是以FTP站点为单位分开存储的。如站点IP为10.6.76.14端口为21,那么这个站点的原始数据就存放在/Sou_data/10.6.76.14/21/source.txt中如图4.1,原始数据在source.txt中存放的内容和格式如图。
图 41 source文件存放路径
那么现在就对这个文件进行处理,之后将得到一个path.txt文件和一个attr.txt文件,他们也都存放在source.txt的目录下。Path文件是一个用来存放原始数据文件名、文件夹名以及目录记录的如图4.3。他主要是为了提高在建立索引时扫描和划分文件(夹)名的效率和在检索数据时返回结果的效率。
图 42 path文件
attr文件是用来存放原始数据各个文件、文件夹属性,包括文件类型、大小、最后修改时间、文件名的长度、所在路径在对应的path文件中的偏移、文件名在对应的path文件中的偏移这几项如图4.4。attr文件的存在是为了减小在建立索引时的数据量。得到这两个文件后就进入下一步。
图 43 attr文件
文件的IO操作通常会耗费大量的时间,由于源文件分散在各个目录中,因此在读取是不可避免的会频繁的打开和关闭文件进行操作。因此我在这里将属性文件汇总,这样所有的有效数据都集中在了一个文件中,最大限度的减少了IO操作的发生。
-
-
-
- 实现方法
-
-
为什么要把属性文件汇总?这是因为,上面曾提到每一个索引文件存放的是一个一个的32位整数,而这个32位整数的高24位就是该双字母所在文件名的属性项在汇总文件中的索引编号,所以汇总就是为了取得这个索引编号,同时汇总在一起也会省去重复打开关闭文件浪费的时间。
由于整个attr文件存储位置的特殊性,所以在汇总时是比较容易的。最后得到的文件InfoIndex.txt存放在/Index/这个目录里既是索引所在目录如图:
图 44
InfoIndex文件
如何才能快速有效的从原始数据中找出用户需要的数据,这是索引部分索要解决的最大问题,经过查询资料,倒排索引是目前各大搜索引擎所常用的索引建立方式。在数据检索时,用户常采用关键字搜索的方式,因此,在建立索引时我们采用了同样的方式建立了索引数据库。
-
-
-
- 实现方法
-
-
将爬虫模块中获得的原始文件路径字段以及属性进行字段分离操作,分别保存在InfoIndex.txt文件和path.txt文件中,建立一个汇总属性文件,为索引的建立做好准备。
由于我们采用ASCII码建立索引,而汉字编码GB2312编码长度为ASCII码的两倍。因此若建立索引时读入整个汉字的编码,在程序中会自动分别两个部分处理,在检索时不可避免的带来误差,因此,为了保持检索的准确性,我们只读入汉字编码的一半(即一个字节)。比如某个文件名中含有“圆周”两个汉字,“圆”和“周”的ASCII码分别为212、178,214、220。那么我们只对212和220这两个数字建立索引,跳过178,214。这是因为178和214组成了一个新的字“仓”,如果我们以连续的两个ASCII码建立索引,当搜索“仓”时含有圆周的项将显示出来,然而圆周里面并不含有仓字。现在的处理方法是:如果是单字节字符和单字节字符,则直接取ASCII码建立索引;如果是单字节字符与汉字,则取单字节字符的ASCII码和汉字的第二个ASCII码建立索引;如果是汉字与汉字,则取第一个汉字的第一个ASCII码与第二个汉字的第二个ASCII码建立索引;如果是汉字与单字节字符,则取汉字的第一个ASCII码和单字节ASCII码建立索引。
获取这些信息之后,在索引文件中插入一个32位整数,这个数中的高24位即为一个在汇总文件的索引编号,低8位则对应了该关键字的相对偏移量。如“文件夹A”(各个字符对应的ASCII码分别为:206、196,188、254,188、208,65)那么第一个双字母为“文件”,则在Index/206/254.txt中写入一个32位整数值为256如图4.6,它的高24位值为1(文件夹A这个文件的属性对应于InfoIndex文件中的索引编号),低8位的值为0(“文件”在“文件夹A”中的偏移
量);
图 45 索引文件中的偏移量
第二个双字母为“件夹”,则在Index/188/208.txt中写入一个32位整数值为258如图4.7,高24为1(“文件夹A”这个文件的属性对应于InfoIndex文件中的索引编号),低8位为2(“件夹”在“文件夹A中的偏移量)。以此类推直到扫描完整个path文件。
搜索引擎是对大量的数据进行处理,因此用到数据库是必然的。数据库的重点功能在存储。查看资料发现某些搜索引擎是采用标准的数据库来存放索引数据,但是当数据量达到千万级的时候再执行SQL语句,速度将会变得很慢,特别是执行含有like的select语句时。比如一个采用MySQL存储的客户信息表数据记录达到500万行以上时,就算增加再多的索引,采用标准select语句执行查询时,所需时间至少也在2分钟以上,Oracle数据库虽然可以采用分区,或采用Oracle的内置函数来辅助查询,但时间也在1分钟以上。而使用文件系统来存储时,这样的查询耗时一般就是零点几秒。
-
-
-
- 实现方法
-
-
目前全球做的最好的搜索引擎Google的存储方式为GFS(Google file system)分布式存储文件系统,使用文件系统最大的好处就是速度快。因此,本FTP搜索引擎对数据的存储也采用了文件系统的形式,全部数据都以文档的形式存储在硬盘上。这次次设计中,利用双字幕建立了一个文件系统,达到了快速搜索的要求。
由于ASCII编码并不支持汉字,因此不能选用其作为索引文件的编码。UTF-8的编码方式虽然应用广泛,但是其编码的方式较为特殊,因此最后我选用了GB2312的编码方式作为搜索引擎文件的同意编码。
-
-
-
- 实现方法
-
-
非数值信息和控制信息包括了字母、各种控制符号、图形符号等,它们都以二进制编码方式存入计算机并得以处理,这种对字母和符号进行编码的二进制代码称为字符编码(Character Code)[15]。字符的编码有多种包括ASCII编码、EBCDIC编码、GB2312编码、Unicode编码、UTF-8编码、以及Base64编码。如果不对编码进行统一或者进行转换,就会出现编码不匹配引的问题,比如网页乱码、邮件乱码等会引起很多不必要的麻烦。所以对编码进行统一是很有必要的。
由于,一般情况下DOS和Windows系统都使用了ANSI码,而GB2312兼容ANSI编码。我们的搜索引擎一般也是针对这些平台上的文件,为了使搜索引擎对数据的处理更为有效,我们将此FTP搜索引擎文件的编码统一为GB2312。
在文件读入时我们以GB2312的格式将文件读入,由于爬虫部分的数据是按照GB2312保存的,因此在此处不需要特殊的处理。在索引建立之后,我仍然以GB2312的方式写入数据,这样保持了整个系统的编码格式的统一。
处理器:Intel(R) Core(TM) i5 CPU M480
内存(RAM):2GB
操作系统:Windows 7 professional (Service Pack1)
系统类型:32位操作系统
编程语言:C#
开发工具:Visual Studio 2010 旗舰版 (Service Pack1)
软件要求:Windows XP(须安装Microsoft .NET Framework SDK),
Windows 7(Microsoft .NET Framework SDK),
Linux(须安装Mono)
硬件要求:
CPU :Intel Pentium IV(或更高)
内存:512MB(或更高)
经过多次的测试,该程序不管原始数据的大小与否都能够准确的建立索引,能够实现任务书要求的功能,基本满足FTP搜索引擎的整体要求,运行结果如图。
图 51 索引运行结果
经过该程序的运行在/Index/目录下自动生成了InfoIndex.txt文件。
由于在设计之初考虑不足,前期编写的大量核心代码不支持多线程运行。造成在后期修改时需要改动大量的核心代码,编码和调试的时间均不充足。造成程序运行的效率不高。在以后的设计中对这类问题应该尽可能的避免。
大家点赞、收藏、关注、评论啦 其他的定制服务 下方联系卡片↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ 或者私信作者