集成桌面搜索引擎的內(nèi)容檢測系統(tǒng)設(shè)計(jì)

賈 默，陳 梅

(貴州大學(xué)計(jì)算機(jī)科學(xué)與信息學(xué)院，貴州貴陽550025)

0 引言

PC機(jī)的大量使用以及磁盤存儲能力的增強(qiáng)，使得單個(gè)桌面機(jī)所能包含的信息量也隨之增大。特別是對于一些企業(yè)和機(jī)構(gòu)，使用人員所接觸的文件、電子材料等信息與日俱增，那么難以保證每個(gè)終端所存儲的信息都能達(dá)到企業(yè)的規(guī)定標(biāo)準(zhǔn)。因此，對于這種能夠達(dá)到TB級別的桌面內(nèi)容的監(jiān)控和檢測成為了即網(wǎng)絡(luò)內(nèi)容檢測之后的下一個(gè)關(guān)注點(diǎn)，企業(yè)對于掌握其內(nèi)部PC的桌面內(nèi)容的詳細(xì)情況的需求也越來越迫切。由此我們將內(nèi)容檢測的范圍深入到了與用戶粘性更大的桌面機(jī)上。所謂針對的對象不同，那么解決問題的策略也需要因地制宜。針對所要研究的對象是桌面內(nèi)容來說，本文將桌面搜索引擎［1］集成到系統(tǒng)中。桌面搜索引擎則成為本文設(shè)計(jì)的主要關(guān)注點(diǎn)，而傳統(tǒng)桌面搜索引擎在初次建立全文索引時(shí)用時(shí)較長，且由于它為所有內(nèi)容片斷均建立索引導(dǎo)致索引文件較大，并隨著用戶的使用不斷增大，占用了用戶較大的磁盤空間，通常達(dá)到了GB級別［2］。針對以上弊端以及系統(tǒng)的實(shí)際用戶需求，本文對傳統(tǒng)桌面搜索引擎的一些設(shè)計(jì)思路進(jìn)行了相應(yīng)的修改，使得設(shè)計(jì)既要能夠保證系統(tǒng)擁有完備的功能，并且還能夠高效的運(yùn)行，從而帶來較好的用戶體驗(yàn)。

1 系統(tǒng)設(shè)計(jì)模型與功能

1.1 系統(tǒng)總體設(shè)計(jì)模型

本文設(shè)計(jì)的內(nèi)容檢測系統(tǒng)需要管理桌面搜索引擎的平臺和桌面搜索引擎兩部分組成。將管理平臺部署在服務(wù)器上，使檢查終端可以僅通過瀏覽器便完成了對桌面搜索引擎的流程管理。檢查代理端則通過安裝桌面搜索引擎，接受檢查終端發(fā)送的相關(guān)參數(shù)，完成檢測工作并報(bào)告給檢查終端最終的結(jié)果。系統(tǒng)總體模型圖如圖1所示［3］。

圖1 系統(tǒng)總體模型

檢測總控端通過制定計(jì)劃、目錄設(shè)置、任務(wù)類型3個(gè)模塊設(shè)置搜索任務(wù)所需要的搜索內(nèi)容、搜索對象等搜索條件，而檢查代理端的PC機(jī)只要處于開機(jī)狀態(tài)，那么這個(gè)代理端的桌面搜索引擎會(huì)及時(shí)監(jiān)聽到總控端所發(fā)布的這些搜索條件，根據(jù)這些條件，對磁盤內(nèi)容進(jìn)行掃描和檢測的工作將自動(dòng)開始，搜索完成后把符合條件的文件信息的集合報(bào)告給檢測總控端。總控端則會(huì)通過查看報(bào)告模塊對代理端上報(bào)的疑似文件的詳細(xì)信息進(jìn)行查看，同時(shí)還可以提取文件全文對相關(guān)信息進(jìn)行深入了解。

由于處于代理端的桌面搜索引擎是作為系統(tǒng)的集成模塊，因此它為了配合控制端的調(diào)度，設(shè)計(jì)思路也做了相應(yīng)的調(diào)整。集成的桌面搜索引擎不采用全文索引的方式，因?yàn)榭偪囟藭?huì)提供表達(dá)式作為搜索的內(nèi)容，因此，本文設(shè)計(jì)的桌面搜索引擎將抽取表達(dá)式中的關(guān)鍵字作為磁盤搜索的內(nèi)容并且僅為它們建立索引，這樣的設(shè)計(jì)不僅節(jié)省了傳統(tǒng)桌面搜索引擎首次建立全文索引時(shí)所需要花費(fèi)的大量時(shí)間，可能會(huì)達(dá)到10個(gè)小時(shí)以上，并且，內(nèi)容檢測系統(tǒng)的用戶與傳統(tǒng)桌面搜索引擎的用戶的使用范圍以及使用需求不同。傳統(tǒng)桌面搜索引擎的用戶更多的是搜索正常的文件內(nèi)容，較之需要搜索的關(guān)鍵字來說，其搜索內(nèi)容更廣、搜索范圍更大［3］。內(nèi)容檢測系統(tǒng)只針對被提供的關(guān)鍵字進(jìn)行檢測，而相對于一般文件內(nèi)容來說，需要搜索的關(guān)鍵字的存在比例總是較小的，因此，本文設(shè)計(jì)的系統(tǒng)中所集成的桌面搜索引擎改變了全文索引的策略，它在首次遍歷過程中采用轉(zhuǎn)換技術(shù)將文件進(jìn)行轉(zhuǎn)換，而不是對所有片段建立索引，并且轉(zhuǎn)換所花費(fèi)的時(shí)間比建立全文索引的時(shí)間更短，在此基礎(chǔ)上，系統(tǒng)執(zhí)行每一次新的搜索任務(wù)時(shí)，通過抓取轉(zhuǎn)換文檔中的內(nèi)容來確定文件命中的情況，據(jù)此為且僅為當(dāng)次關(guān)鍵字建立索引，雖然為當(dāng)次關(guān)鍵字建立索引的時(shí)間要比建立好全文索引的響應(yīng)時(shí)間長，但是在用戶可接受的范圍內(nèi)，重要的是這樣的設(shè)計(jì)方法省掉了為許多不會(huì)搜索到的文件片段建立的索引所花費(fèi)的空間以及時(shí)間［4］。

1.2 檢查總控端功能模塊

根據(jù)以上的總體設(shè)計(jì)，總控端由5個(gè)功能模塊組成，即制定計(jì)劃、查看報(bào)告、設(shè)置目錄、任務(wù)類型。

對于制定計(jì)劃來說，主要分為3個(gè)部分，第一部分是對于邏輯表達(dá)式的管理，即掃描任務(wù)中需要搜索的內(nèi)容，由于邏輯表達(dá)式的更新頻率快且累計(jì)數(shù)量較大，因此采用主題樹對邏輯表達(dá)式進(jìn)行合理的分類，用戶可以直接在主題樹上進(jìn)行更新、編輯等操作來維護(hù)表達(dá)式以及其所屬主題，然后選中本次搜索需要的表達(dá)式之后就可以進(jìn)行第二部分的操作;第二部分是對搜索對象的設(shè)置，即哪些終端機(jī)需要執(zhí)行該計(jì)劃。由于大多數(shù)機(jī)構(gòu)都將人員以部門來進(jìn)行分配，此處仿照上述主題樹建立了部門樹，用戶可以在部門樹結(jié)構(gòu)上對部門名稱以及部門下屬各PC機(jī)的IP信息進(jìn)行編輯，更重要的是通過樹結(jié)構(gòu)選中需要執(zhí)行計(jì)劃的部門或者PC機(jī)。第三部分只需要用戶選擇搜索的時(shí)間，如立即搜索或者是周期性的進(jìn)行搜索等。這時(shí)計(jì)劃需要的基本條件已經(jīng)設(shè)置完成，它會(huì)根據(jù)執(zhí)行時(shí)間將本次設(shè)置的信息發(fā)送到檢查代理端，代理端由此開始執(zhí)行搜索計(jì)劃。

當(dāng)代理端完成了搜索任務(wù)之后，它會(huì)把符合搜索條件的文件信息上報(bào)到控制端，這時(shí)用戶可以通過查看報(bào)告模塊查看掃描結(jié)果。查看報(bào)告模塊同樣提供了主題樹、部門樹來管理所有報(bào)告，用戶通過選中某些條件選項(xiàng)就可以查看相應(yīng)的報(bào)告信息。當(dāng)然，如果對某個(gè)文件比較關(guān)注，可以查看該報(bào)告的詳細(xì)信息，如其匹配的邏輯表達(dá)式是哪些、掃描該文件的日期和時(shí)間等，特別是用戶還可以要求下載文件的全文進(jìn)行查看，確定是否存在不合乎規(guī)范的因素。

為了避免桌面搜索引擎影響到用戶的正常使用，設(shè)計(jì)了設(shè)置目錄模塊讓用戶設(shè)置白目錄，掃描時(shí)將會(huì)忽略這些目錄。任務(wù)類型模塊主要是為了輔助制定計(jì)劃模塊，它提供了設(shè)置和編輯任務(wù)類型的功能。

1.3 檢查代理端功能模塊

代理端的桌面搜索引擎由表達(dá)式解析、內(nèi)容掃描、通信服務(wù)、文檔轉(zhuǎn)換四大模塊構(gòu)成。

表達(dá)式解析模塊主要工作是獲取總控端發(fā)送的該次掃描的邏輯表達(dá)式并對邏輯表達(dá)式進(jìn)行語法解析，從中獲取新的關(guān)鍵字，然后為它們建立索引。內(nèi)容掃描模塊則需要負(fù)責(zé)兩方面的工作，第一部分是遍歷各磁盤目錄，搜索除了白目錄之外的所有目錄中的電子文檔，借助匹配算法對解析出來的關(guān)鍵字和文本進(jìn)行匹配，同時(shí)統(tǒng)計(jì)符合每個(gè)關(guān)鍵字的文件的基本信息，如關(guān)鍵字出現(xiàn)在該文件中的次數(shù)等，由此進(jìn)一步得到匹配關(guān)鍵字所屬表達(dá)式的文件信息;第二部分是捕捉磁盤上的電子文檔的變化，如果代理端用戶有新增文件、刪除文件、更新文件等操作，那么將根據(jù)不同操作修改、更新文件與表達(dá)式之間的映射關(guān)系。

內(nèi)容掃描模塊的匹配過程需要關(guān)鍵字與文件內(nèi)容進(jìn)行匹配，但是如果每次匹配都要打開各種格式的電子文檔，那么將消耗大量的內(nèi)存空間，這樣的策略會(huì)帶來比較大的性能問題。因此，設(shè)計(jì)了文檔轉(zhuǎn)換模塊，把.doc、.xls、.pdf等格式的電子文檔全部轉(zhuǎn)換成文本文件，然后再抽取其中的文本內(nèi)容進(jìn)行匹配。當(dāng)內(nèi)容掃描模塊捕捉到文檔發(fā)生改動(dòng)時(shí)，會(huì)重新請求轉(zhuǎn)換模塊轉(zhuǎn)換該文件并且重建文件和關(guān)鍵字之間的映射關(guān)系，從而保證向總控端報(bào)告的結(jié)果的準(zhǔn)確性和及時(shí)性，這樣可以大大減少內(nèi)存開銷，確保系統(tǒng)的整體性能。

通信服務(wù)模塊則為其他3個(gè)模塊進(jìn)行服務(wù)，例如當(dāng)代理端與服務(wù)器進(jìn)行通信、內(nèi)容掃描模塊與文檔轉(zhuǎn)換模塊的通信、總控端請求全文查看時(shí)上傳文件所需要的FTP通信等等，都需要該模塊的支持。

結(jié)合工程實(shí)際情況，本次大壩除險(xiǎn)加固設(shè)計(jì)擬采用砂巖壓重上游壩坡的方式，提高上游壩坡的穩(wěn)定性。上游壩坡加固設(shè)計(jì)方案為：壓重體頂寬5m，迎水面坡比1∶2，高度3m，如圖1。

文檔轉(zhuǎn)換模塊則不斷接收通信服務(wù)模塊發(fā)出的轉(zhuǎn)換指令，然后通過分解指令內(nèi)容獲得需要進(jìn)行轉(zhuǎn)換的文檔的所在位置，然后依照文檔的后綴內(nèi)容進(jìn)行相關(guān)格式的處理。其中，不僅要考慮到轉(zhuǎn)換是否成功的問題，同時(shí)，轉(zhuǎn)換頻率也成為首當(dāng)其沖的重點(diǎn)問題，當(dāng)需要轉(zhuǎn)換的內(nèi)容不斷涌入隊(duì)列，如果程序不加以控制，轉(zhuǎn)換頻率過快將會(huì)導(dǎo)致內(nèi)存滿溢的現(xiàn)象出現(xiàn)，因此，本文設(shè)計(jì)的檢測系統(tǒng)將考慮轉(zhuǎn)換過程中cpu的使用率，如果使用率超過了70%，那么將暫停轉(zhuǎn)換程序的運(yùn)行，稍事停歇，等待cpu使用率下降到不緊張狀態(tài)時(shí)再重新啟動(dòng)轉(zhuǎn)換程序，防止內(nèi)存溢出以及cpu使用率過高而影響用戶使用其他應(yīng)用的良好體驗(yàn)。

2 主要算法介紹

根據(jù)關(guān)鍵字對文件進(jìn)行匹配的算法設(shè)計(jì)成為影響整個(gè)系統(tǒng)性能的重點(diǎn)。

模式匹配算法主要分為單模式匹配算法和多模式匹配算法。單模式匹配算法即遍歷文本一遍只能匹配一個(gè)模式串。單模式匹配的經(jīng)典算法是BM算法和KMP算法。多模式匹配算法則在一次文本遍歷過程中查找所有模式串。它的經(jīng)典算法包括Wu-Manber算法和AC算法。其中，Wu-Manber算法是由BM算法延伸出來的多模式匹配算法，它的時(shí)間復(fù)雜度由三部分來計(jì)算。首先算法將模式串分隔成一定長度的塊并計(jì)算滑動(dòng)距離，設(shè)其為B;設(shè)需要匹配的文本長度為N;取多模式串中的最短模式串的長度為M，由此可以計(jì)算其時(shí)間復(fù)雜度為O(BN/M)。可見，當(dāng)其有比較短的模式串的時(shí)候，那么M值將隨著該最短模式串的長度而取值，則移位的值將受到極大的限制，從而匹配過程的加速也將受限。而根據(jù)本文的系統(tǒng)需求，不僅需要數(shù)量較大的關(guān)鍵字同時(shí)進(jìn)行匹配，而且系統(tǒng)的關(guān)鍵字由用戶提供，短的關(guān)鍵字也不乏其中，如果采用單模式匹配算法或者Wu-Manber算法，那么匹配過程的效率和速度不能夠得到保證，因此系統(tǒng)設(shè)計(jì)采用多模式匹配算法中的AC算法來實(shí)現(xiàn)匹配功能。

2.1 AC算法原理分析

Aho-Corasick算法［5］，簡稱AC自動(dòng)機(jī)，1975年產(chǎn)生于貝爾實(shí)驗(yàn)室，其應(yīng)用有限自動(dòng)機(jī)將字符比較轉(zhuǎn)化為了狀態(tài)轉(zhuǎn)移。算法的主要結(jié)構(gòu)是在預(yù)處理階段，自動(dòng)機(jī)將創(chuàng)建3個(gè)函數(shù)，轉(zhuǎn)向函數(shù)goto，失效函數(shù)failure和輸出函數(shù)output，三者生成了樹形有限自動(dòng)機(jī)。狀態(tài)樹如圖2所示。

圖2 狀態(tài)樹

算法主要原理為:第一步，構(gòu)造樹狀狀態(tài)轉(zhuǎn)移圖。設(shè)節(jié)點(diǎn)集合為T={n|n∈Z*，0≤n≤7}，設(shè)t1≠t2and t1，t2，t3∈T，邊的集合為 V={a，b，c}，設(shè) v1≠v2and v1，v2，v3∈V，模式串的集合為P={a，abc，bc，ca}，設(shè)p1≠p2and p1，p2∈P;其中T代表自動(dòng)機(jī)的狀態(tài)集合，P代表所有模式串的集合，V代表組成P的所有單個(gè)元素的集合。轉(zhuǎn)向函數(shù)goto將根據(jù)P組建樹狀結(jié)構(gòu)，由初始狀態(tài)t0開始，根據(jù)輸入的p1中的每個(gè)v1創(chuàng)建t1，如果t1已經(jīng)存在，那么循環(huán)該過程建立剩下的樹結(jié)構(gòu)［6］。

第二步，建立失效函數(shù)failure，提高匹配效率。失效函數(shù)failure則將在goto函數(shù)的基礎(chǔ)上為每個(gè)t1建立失效指針，失效指針將指向在匹配v1失敗的時(shí)候最節(jié)省后續(xù)匹配次數(shù)的t2。而初始狀態(tài)的失效指針指向自己，初始狀態(tài)的孩子節(jié)點(diǎn)的失效指針也將指向初始狀態(tài)，即回到終點(diǎn)。相對于KMP算法，失效函數(shù)成為了一項(xiàng)重要改進(jìn)，其不再浪費(fèi)已經(jīng)匹配過的所有信息，而是利用所有已匹配信息為后續(xù)的匹配工作提供再利用的機(jī)會(huì)。

第三步，p1與文本進(jìn)行匹配，如果v1匹配成功，那么沿著樹結(jié)構(gòu)繼續(xù)完成整個(gè)過程，直到達(dá)到某個(gè)終結(jié)節(jié)點(diǎn)v2;如果v1匹配失敗，那么沿著v1的失效指針?biāo)赶虻膙3繼續(xù)匹配過程，直到回到初始狀態(tài)。

而output函數(shù)將通過判斷t1來記錄p1形成的信息，如果是終結(jié)狀態(tài)則記錄p1，否則為空，并且在建立failure函數(shù)的過程中也會(huì)動(dòng)態(tài)修改output函數(shù)。

AC算法的時(shí)間復(fù)雜度為O(N)，其中N為需要匹配的文本長度。由此可見，其時(shí)間復(fù)雜度與模式串的多少和長度均無關(guān)，比較適合應(yīng)用于本系統(tǒng)中。與其他算法相比，其能夠較大的提高匹配的效率，且較少的依賴其他因素的干擾。

2.2 算法應(yīng)用

AC算法主要應(yīng)用于桌面搜索引擎的內(nèi)容掃描模塊中。桌面搜索引擎所處的檢查代理端收到總控端提供的新的邏輯表達(dá)式并且將它們進(jìn)行了語法解析后，它將調(diào)用算法對解析出來的關(guān)鍵字進(jìn)行有效的組織和應(yīng)用。首先把關(guān)鍵字作為模式串用來初始化狀態(tài)樹，即完成goto函數(shù)的構(gòu)建，然后為樹結(jié)構(gòu)中的每個(gè)節(jié)點(diǎn)建立失效指針，創(chuàng)建失效函數(shù)failure，完成算法原理的前兩步。根據(jù)算法的第三步，內(nèi)容掃描模塊會(huì)逐個(gè)獲取已轉(zhuǎn)換文檔隊(duì)列中等待的文本文件，抽取它們的內(nèi)容作為文本，然后與狀態(tài)樹中的每個(gè)模式串進(jìn)行匹配，這個(gè)過程中累加每個(gè)關(guān)鍵字在文件中匹配成功的次數(shù)，根據(jù)這個(gè)數(shù)值決定是否將文件作為疑似文件報(bào)告給總控端。

當(dāng)本次搜索任務(wù)結(jié)束后，系統(tǒng)會(huì)收集出現(xiàn)的新關(guān)鍵字，然后清除這棵樹，減少每次保存樹結(jié)構(gòu)所帶來的系統(tǒng)負(fù)擔(dān)。

3 實(shí)現(xiàn)綜述

通過使用python語言以及多線程、AJAX等技術(shù)對本文的設(shè)計(jì)加以實(shí)現(xiàn)。用戶可以登錄網(wǎng)站使用制定任務(wù)計(jì)劃、設(shè)置白名單和任務(wù)類型等功能制定搜索計(jì)劃，同時(shí)也可以查看已經(jīng)搜索的結(jié)果。

一旦計(jì)劃發(fā)布后，代理端的桌面搜索引擎將啟動(dòng)main進(jìn)程和converter進(jìn)程，main進(jìn)程主要負(fù)責(zé)調(diào)度多個(gè)線程同步啟動(dòng)，包括磁盤遍歷walker、磁盤監(jiān)測watcher、任務(wù)搜索scan、關(guān)鍵字處理index、通信服務(wù)udp等線程。scan負(fù)責(zé)接收總控端發(fā)送的有關(guān)搜索需要的所有條件，包括邏輯表達(dá)式、白名單等，然后對邏輯表達(dá)式進(jìn)行語法處理獲取關(guān)鍵字并且保存在線程共享的字典keyword中。walker線程會(huì)根據(jù)白名單對磁盤進(jìn)行掃描，它會(huì)把需要轉(zhuǎn)換的文件放入轉(zhuǎn)換隊(duì)列中等待converter進(jìn)程對它進(jìn)行轉(zhuǎn)換，不需要轉(zhuǎn)換的文件放入已轉(zhuǎn)換隊(duì)列queue中等待index對它的提取。converter進(jìn)程監(jiān)聽到隊(duì)列中有需要轉(zhuǎn)換的文件時(shí)，它會(huì)把相應(yīng)格式的電子文檔全部轉(zhuǎn)換成文本文件，并且把這個(gè)文件放入已轉(zhuǎn)換隊(duì)列中等待index的提取。index線程從共享字典keyword中獲取關(guān)鍵字之后，根據(jù)AC算法為它們建立樹形結(jié)構(gòu)，同時(shí)它會(huì)從已轉(zhuǎn)換隊(duì)列queue中不斷獲取文本進(jìn)行匹配，統(tǒng)計(jì)關(guān)鍵字在文件中的匹配信息。完成整個(gè)搜索過程后，通過udp線程的支持，scan會(huì)將搜索結(jié)果報(bào)告給總控端。實(shí)驗(yàn)證明系統(tǒng)能夠高效的完成檢測桌面內(nèi)容的功能。

4 系統(tǒng)驗(yàn)證

4.1 驗(yàn)證環(huán)境

PC機(jī)個(gè)數(shù)為6臺，每臺PC機(jī)的配置如下:

Core 2 E7500 2.93，2GB內(nèi)存，320GB硬盤，所使用的操作系統(tǒng)范圍是:WINDOWS 7WINDOWS VISTAWINDOWS 8WINDOWSXP。

4.2 驗(yàn)證數(shù)據(jù)

在每個(gè)PC上除了C盤之外的每個(gè)磁盤中放置一個(gè)測試文件夾，其中包含.doc、.docx、.xls、.xlsx、.rtf、.pdf、.txt格式的文件各1000個(gè)，并且每個(gè)文件夾中設(shè)定了500個(gè)包含關(guān)鍵字的命中文件，每個(gè)機(jī)器上除了C盤之外，共有3個(gè)磁盤，因此每個(gè)機(jī)器上有測試文件共21000個(gè)，其中包含關(guān)鍵字的命中文件共有1500個(gè)。

6臺機(jī)器上的測試數(shù)據(jù)大小各為:11.19GB、16.74GB、10.53GB、10.41GB、14.43GB、16.50GB。

4.3 驗(yàn)證方法及結(jié)果

4.3.1 功能驗(yàn)證

對于檢查總控端，管理員可以登錄遠(yuǎn)程服務(wù)器端，打開網(wǎng)站鏈接，選擇搜索關(guān)鍵字若干，然后可以針對包含關(guān)鍵字的特定代理端PC下發(fā)相應(yīng)搜索任務(wù)，并能查看指令下發(fā)后代理端提交的搜索結(jié)果。

對于代理端的六臺PC機(jī)，它們必須處于開機(jī)狀態(tài)同時(shí)已經(jīng)啟動(dòng)了代理端檢測軟件，啟動(dòng)后右下角出現(xiàn)軟件圖標(biāo)，并且圖標(biāo)處于待搜索狀態(tài)。指令下發(fā)之后，首先是圖標(biāo)變成正在搜索狀態(tài)，然后彈出搜索頁面，證明代理端軟件能夠正常接收到下發(fā)指令，并自動(dòng)開始搜索。搜索開始后，頁面會(huì)不斷顯示當(dāng)前更新到的遍歷文件、它的路徑和類型、搜索用時(shí)以及索引情況，遍歷結(jié)束后將顯示正在轉(zhuǎn)換的文檔個(gè)數(shù)。與此同時(shí)，在遍歷以及轉(zhuǎn)換過程中對測試文件夾中包含關(guān)鍵字的文件進(jìn)行復(fù)制、新建、修改等操作，右下角的圖標(biāo)能夠正常顯示監(jiān)控變化，提示有新的監(jiān)控信息。在整個(gè)搜索過程中，只要索引到目標(biāo)文件，即該文件已經(jīng)被遍歷到并且轉(zhuǎn)換成功，那么頁面會(huì)顯示命中文件路徑、時(shí)間、以及在文件中命中了關(guān)鍵字的片段。通過點(diǎn)擊文件路徑可以查看原文，然后確定是否排除或者確定該文件是否是想要的文件，頁面也將記錄該條文件記錄。

4.3.2 性能驗(yàn)證

本文所設(shè)計(jì)的內(nèi)容檢測系統(tǒng)主要集成了桌面搜索引擎，因此系統(tǒng)性能的主要監(jiān)測點(diǎn)落在桌面搜索引擎的部分，而同類型的桌面搜索軟件眾多，本文選擇了GoogleDesktop作為參考對象。

GoogleDesktop［8］是利用系統(tǒng)空閑時(shí)間對用戶設(shè)置的文件范圍和類型建立全文索引，即使用戶可能不會(huì)搜索到的內(nèi)容，這樣便于用戶今后搜索內(nèi)容的便捷。

4.3.2.1 全文索引和文檔轉(zhuǎn)換用時(shí)驗(yàn)證

基于上述機(jī)制的描述，進(jìn)行以下測試，讓本文設(shè)計(jì)的軟件和Googledesktop在每個(gè)測試PC上同時(shí)啟動(dòng)開始工作。表1列出GoogleDesktop對磁盤上的所有內(nèi)容進(jìn)行全文索引的用時(shí)和本文系統(tǒng)在首次進(jìn)行全盤遍歷、轉(zhuǎn)換的用時(shí)，其中所有磁盤內(nèi)容包括測試文件夾在內(nèi)。測試盡量在無操作的基礎(chǔ)上進(jìn)行，這樣可以保證速度達(dá)到最快。［9］

如表1所示，本文系統(tǒng)的遍歷和轉(zhuǎn)換過程的用時(shí)相對更短，有效避免了Google建立全文索引用時(shí)過長的弊端。

表1 全文索引和文檔轉(zhuǎn)換用時(shí)對比

4.3.2.2 效率驗(yàn)證

在其中一臺測試PC上搜索預(yù)設(shè)的100個(gè)較特殊的關(guān)鍵字對兩款系統(tǒng)進(jìn)行測試，然后對這100組查全率和查準(zhǔn)率取平均值，以此驗(yàn)證軟件的效率。［10］對比情況如圖3所示，本文設(shè)計(jì)的內(nèi)容檢測系統(tǒng)與GoogleDesktop相比，查全率與查準(zhǔn)率相差甚微，因此可以說明本文系統(tǒng)的高效性。

圖3 效率對比

5 結(jié)束語

實(shí)驗(yàn)表明，本文所設(shè)計(jì)的內(nèi)容掃描與檢測系統(tǒng)的查詢效率、查詢準(zhǔn)確率較高，它將改進(jìn)后的桌面搜索引擎集成在被檢測終端來避免建立全文索引用時(shí)過長的問題，同時(shí)，通過只為被搜索關(guān)鍵字建立索引提高了建立索引的針對性，避免了索引文件過大的問題。企業(yè)管理人員可以根據(jù)自己的實(shí)際規(guī)則或規(guī)范實(shí)時(shí)、高效的通過系統(tǒng)管理平臺對處于網(wǎng)絡(luò)中的內(nèi)部PC機(jī)的桌面內(nèi)容加以監(jiān)督和檢查，不僅實(shí)現(xiàn)了企業(yè)管理中的監(jiān)控需求，并且為確保和追溯PC的桌面內(nèi)容達(dá)到企業(yè)要求提供了自動(dòng)化的輔助。

［1］LI Xiaoxin.Design of a desktop search engine ［J］.Computer Knowledge and Technology，2011，7(20):4949-4951(in Chinese).［李曉鑫.桌面搜索引擎設(shè)計(jì)［J］.電腦知識與技術(shù)，2011，7(20):4949-4951.］

［2］MENGMeihua.Design and implementation of desktop search engine［D］.Dalian:Dalian University of Technology，2009(in Chinese).［孟美華.桌面搜索引擎的設(shè)計(jì)與實(shí)現(xiàn) ［D］.大連:大連理工大學(xué)系統(tǒng)工程，2009.］

［3］Clay Shields， Ophir Frieder.A system for the proactive，continuous，and efficient collection of digital forensic evidence［J］.Digital investigation，2011，8(s1):3-13.

［4］Cohen M I，Bilby D.Distributed forensics and incident response in the enterprise［J］.Digital investigation，2011，8(s1):101-110.

［5］CONG Lei.Research and implement of desktop search engine［D］.Beijing:Beijing University of Chemical Technology，2006(in Chinese).［叢磊.桌面搜索引擎的研究與實(shí)現(xiàn)［D］.北京:北京化工大學(xué)，2006.］

［6］WANG Peifeng，LI Xiaoli.Research on multi-pattern matching algorithms based on Aho-Corasick algorithm ［J］.Application Research of Computers，2011，28(4):1251-1254(in Chinese).［王培鳳，李莉曉.基于Aho-Corasick算法的多模式匹配算法研究 ［J］.計(jì)算機(jī)應(yīng)用研究，2011，28(4):1251-1259.］

［7］LI Weinan，E Yuepeng，GE Jingguo，et al.Multi-pattern matching algorithms and hardware based implementation［J］.Journal of software，2006，17(12):2403-2415(in Chinese).［李偉男，鄂躍鵬，葛敬國，等.多模式匹配算法及硬件實(shí)現(xiàn)［J］.軟件學(xué)報(bào)，2006，17(12):2403-2415.］

［8］Benjamin Turnbull，DBarry Blundell.Google desktop as a source of digital evidence ［J］.International Journal of Digital Evidence，2006，5(1):1-12.

［9］LI Weichao.Evaluation of desktop search engine ［J］.Journal of Modern Information，2007(12):211-213(in Chinese).［李偉超.桌面搜索引擎評析 ［J］.現(xiàn)代情報(bào)，2007(12):211-213.］

［10］XIE Haichao.The research and implementation of mobile search engine［D］.Dalian:Dalian University of Technology，2009(in Chinese).［謝海潮.手機(jī)桌面搜索引擎的研究與實(shí)現(xiàn)［D］.大連:大連理工大學(xué)，2009.］