集成桌面搜索引擎的內容檢測系統設計

賈 默，陳 梅

(貴州大學計算機科學與信息學院，貴州貴陽550025)

0 引言

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

1 系統設計模型與功能

1.1 系統總體設計模型

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

圖1 系統總體模型

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

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

1.2 檢查總控端功能模塊

根據以上的總體設計，總控端由5個功能模塊組成，即制定計劃、查看報告、設置目錄、任務類型。

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

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

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

1.3 檢查代理端功能模塊

代理端的桌面搜索引擎由表達式解析、內容掃描、通信服務、文檔轉換四大模塊構成。

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

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

通信服務模塊則為其他3個模塊進行服務，例如當代理端與服務器進行通信、內容掃描模塊與文檔轉換模塊的通信、總控端請求全文查看時上傳文件所需要的FTP通信等等，都需要該模塊的支持。

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

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

2 主要算法介紹

根據關鍵字對文件進行匹配的算法設計成為影響整個系統性能的重點。

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

2.1 AC算法原理分析

Aho-Corasick算法［5］，簡稱AC自動機，1975年產生于貝爾實驗室，其應用有限自動機將字符比較轉化為了狀態轉移。算法的主要結構是在預處理階段，自動機將創建3個函數，轉向函數goto，失效函數failure和輸出函數output，三者生成了樹形有限自動機。狀態樹如圖2所示。

圖2 狀態樹

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

第二步，建立失效函數failure，提高匹配效率。失效函數failure則將在goto函數的基礎上為每個t1建立失效指針，失效指針將指向在匹配v1失敗的時候最節省后續匹配次數的t2。而初始狀態的失效指針指向自己，初始狀態的孩子節點的失效指針也將指向初始狀態，即回到終點。相對于KMP算法，失效函數成為了一項重要改進，其不再浪費已經匹配過的所有信息，而是利用所有已匹配信息為后續的匹配工作提供再利用的機會。

第三步，p1與文本進行匹配，如果v1匹配成功，那么沿著樹結構繼續完成整個過程，直到達到某個終結節點v2;如果v1匹配失敗，那么沿著v1的失效指針所指向的v3繼續匹配過程，直到回到初始狀態。

而output函數將通過判斷t1來記錄p1形成的信息，如果是終結狀態則記錄p1，否則為空，并且在建立failure函數的過程中也會動態修改output函數。

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

2.2 算法應用

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

當本次搜索任務結束后，系統會收集出現的新關鍵字，然后清除這棵樹，減少每次保存樹結構所帶來的系統負擔。

3 實現綜述

通過使用python語言以及多線程、AJAX等技術對本文的設計加以實現。用戶可以登錄網站使用制定任務計劃、設置白名單和任務類型等功能制定搜索計劃，同時也可以查看已經搜索的結果。

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

4 系統驗證

4.1 驗證環境

PC機個數為6臺，每臺PC機的配置如下:

Core 2 E7500 2.93，2GB內存，320GB硬盤，所使用的操作系統范圍是:WINDOWS 7WINDOWS VISTAWINDOWS 8WINDOWSXP。

4.2 驗證數據

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

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

4.3 驗證方法及結果

4.3.1 功能驗證

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

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

4.3.2 性能驗證

本文所設計的內容檢測系統主要集成了桌面搜索引擎，因此系統性能的主要監測點落在桌面搜索引擎的部分，而同類型的桌面搜索軟件眾多，本文選擇了GoogleDesktop作為參考對象。

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

4.3.2.1 全文索引和文檔轉換用時驗證

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

如表1所示，本文系統的遍歷和轉換過程的用時相對更短，有效避免了Google建立全文索引用時過長的弊端。

表1 全文索引和文檔轉換用時對比

4.3.2.2 效率驗證

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

圖3 效率對比

5 結束語

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

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

［2］MENGMeihua.Design and implementation of desktop search engine［D］.Dalian:Dalian University of Technology，2009(in Chinese).［孟美華.桌面搜索引擎的設計與實現 ［D］.大連:大連理工大學系統工程，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).［叢磊.桌面搜索引擎的研究與實現［D］.北京:北京化工大學，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］.計算機應用研究，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).［李偉男，鄂躍鵬，葛敬國，等.多模式匹配算法及硬件實現［J］.軟件學報，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］.現代情報，2007(12):211-213.］

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