基于Python的高校電子文檔管理系統①

黃 昇

(上海旅游高等專科學校 設備處,上海 201418)

隨著高校信息化建設的高速發展,越來越多的電子文檔出現在日常的工作中,PDF 作為電子文檔歸檔的首選格式,在文件格式的保存完整性方面和平臺兼容性方面有顯著的優勢[1].本電子文檔歸檔管理系統的研發主旨是將采購管理平臺的文檔管理與檔案歸檔管理過程合并成一個整體,解決電子文檔流轉過程中信息化管理缺失的情況,同時提出一種對電子文檔元數據自動提取來代替傳統的手工提取元數據,并且建立索引庫,為大數據分析奠定了基礎,同時為學校今后的工作決策提供依據.

國內對元數據提取的相關探索起步較晚,主要研究方向也集中在基于正則表達式和基于規則的元數據提取的相關研究[2–6].2001年賀亞鋒首次將元數據提取的相關研究帶入到中國[7],主要對兩種常用的基于網站的元數據的自動生成進行了介紹,并對ROADS 元數據編輯器和MeatWeb 元數據生成器做的使用和原理進行了深入的闡釋[8,9].

2004年,王守芳等提出了如何從HTML 文件中提取元數據的方案.該方案主要是基于規則模板,通過對HTML文檔進行分詞,配合使用歸約算法實現元數據的自動提取[10].該方法雖然對元數據提取的準確性卻并不太高,但基本可以實現HTML 文檔元數據的自動提取.

2007年,于江德等首次將條件隨機場應用在中文論文的元數據提取上,該方法主要通過利用論文中換行符、回車符等標志性符號對論文內容進行分割,然后應用條件隨機場對分割內容進行元數據抽取[11,12].該方法對于學術論文的論文頭中的元數據的提取具有比較高的準確度,可以高達90%,但是該方法也局限于論文的頭部進行元數據的提取操作.

2017年,杜秋霞等為了地名文化遺產的保護將隱馬爾可夫模型應用在提取文獻中的地名元數據上[13].該方法主要通過對電子文檔的地名關鍵詞的標注,然后對文本進行分割,進而對元數據進行提取.該方法可以對文獻中的地名進行比較細粒度的抽取,相比傳統地名提取的準確度明顯提升,但該方法卻無法對消失的地名準確的進行抽取.

通過閱讀相關的文獻,研究對比目前流行提取PDF元數據的各種方式,結合實際需求提出一種最適合本課題的提取方法.通過對Flask 框架的學習,以模型驅動工程的思想設計實現一款基于Python的能夠自動、高效、準確地提取PDF中元數據的電子文檔歸檔管理系統.

1 系統需求分析

目前線下歸檔流程仍舊是文檔在各部門之間通過復印和填寫文檔屬性表格資料的方式傳遞.職能部門為執行科研項目建立文檔庫,將其他各類格式的電子文檔和實體文檔轉換或掃描成PDF 格式保存,同時在項目執行過程中不斷更新該文檔庫,項目完成后發起歸檔任務將數據遷移至檔案部門審核,然后根據項目分類存入對應的檔案系統中[14–16].期間需要經歷很多繁瑣的流程,而且還有諸多弊端:(1)項目龐大,涉及的供應商有多家,文檔的完整性無法保證;(2)項目執行過程只有職能部門參與其中,對歸檔工作沒有一個過程把控的機制,檔案部門只是在歸檔任務發起才參與進來;(3)歸檔任務通常集中在年末,會積壓大量的資料,這就勢必在文檔流轉審核過程中產生錯誤和審核不嚴格的情況.

因此,需要將歸檔管理功能一并納入一站式采購平臺且做進一步的完善.(1)增加文檔數據導入功能,保證項目執行期間文檔實時保存;(2)增加監督審核機制,保證上傳電子文檔的準確性,避免項目后期返工的情況;(3)增加電子文檔元數據提取功能,解決目前針對海量數據缺乏大數據分析的情況.這樣電子文檔管理和歸檔管理就涵蓋了整個文檔生命周期,如圖1所示.

圖1 文檔生命周期

2 系統概要設計

2.1 系統基本思想

(1)系統以形成高校一體化的信息高度集成為基準,設計標準數據接口防止信息“孤島”的產生,做到新系統與一站式采購管理平臺的無縫結合[17–19].

(2)出于對安全性的考慮,系統對數據庫管理要采取必要的定期自動數據備份、防災預案和數據恢復等措施;在數據傳輸方面要充分利用校園數據交互中心的標準接口,確保系統數據的安全性、可靠性和一致性[20];對所有用戶的權限必須要有有效的管控機制(如:歸檔角色、審批權限).

(3)設計階段充分考慮后期需求的變化,系統后臺配置應具備靈活性,例如需要增加新的文檔屬性項時只要通過系統后臺配置即可,無需修改系統程序和數據結構.

2.2 系統功能設計

根據需求分析和設計思路可以得到系統的用例圖,如圖2所示,將本系統分為項目文檔整理、檢索與統計、移交接收管理和系統管理4個功能區.

圖2 歸檔系統用例圖

(1)“項目文檔整理”包含6 項子功能:文檔導入(自動導入、人工錄入、本地導入),文檔補充,項目信息補錄,刪除文檔,文檔格式轉換,文檔元數據提取.

(2)“檢索與統計”包含4 項子功能:歸檔任務進度查詢,電子文檔查詢,數據統計,報表管理(包含模板管理).

(3)“移交接收管理”包含3 項子功能:預審,資料移交審核,歸檔內容審核.

(4)“系統管理”包含3 項子功能:用戶和權限配置,文件擴展屬性管理,各類標準接口配置.

2.3 數據庫設計

在大數據背景下,要求應用系統具有高性能、弱事務的特性,因此數據結構需要以橫向擴展的方式進行分布式存儲,數據模式多元化,數據相對獨立存在.通過功能業務分析電子文檔歸檔系統并非事務性系統,為了使本系統在擴展性、并發處理和讀/寫方面更有優勢,而且需要考慮到系統后期的升級與功能擴展,摒棄使用傳統關系數據庫,采用MongoDB 半結構化的非關系型數據庫,它有著分布式的存儲架構,這樣數據之間分散存儲更容易擴展,數據庫不需要事先定義數據字段,可以隨時自定義寫入數據的格式.NoSQL 來處理大量多元化數據存儲運算與高并發訪問有更顯著的效果[21–23].數據庫采用1 主節點+1 副節點+1 仲裁節點的基本架構,以減輕數據服務器的訪問壓力,同時提升容災能力,如圖3所示.

圖3 數據庫存儲架構

3 系統對象模型的建立

3.1 業務邏輯分析

通過對實際業務進行系統建模更有利于把握系統的整體格局,在更高的抽象水平上考慮系統的設計,而不是程序編碼,這樣可以降低前期出錯率,縮短系統實現的周期[24,25].由于篇幅有限僅以文檔遷移導入為例,其包括的主要功能:文檔鎖定,項目移交接收,文檔信息補充,本地導入,具體業務邏輯如表1所示.

表1 文檔遷移導入主要業務邏輯

3.2 類定義與類間關系

根據模型驅動工程的思想方法,首先建立系統的對象模型,接著通過對象模型建立系統類集,并對每個類都定義屬性和操作方法,如表2所示.

(1)ModelManager 屬于EJB 類,封裝的組件為前臺與服務端的交互提供數據訪問接口.

(2)公共類(ConDefiner),它主要封裝了基本查詢、第三方插件調用和翻頁等方法,前臺只需要實例化這個類就能繼承并使用.

(3)對象抽象類:將實體類AmObject 類作為系統Model 類的基類,Model 類就是把數據庫的字段映射為各類中各個對象的屬性,為模型操作類提供數據來源.

(4)數據操作抽象類:將AmObjectDAO 類作為數據操作類的基類,除了從父類AmObject 繼承的一些通用對象數據操作,還自定義特殊的數據對象操作方法.如圖4所示.

3.3 數據操作類的邏輯實現

利用UML 序列圖能描述對象間的交互和消息傳遞順序的特性,完成系統核心功能模塊對象間的輸入輸出.以文檔遷移導入、文檔數據補充、本地導入和移交接收的邏輯實現為例.

表2 整個系統的類定義集合(類集)

文檔遷移導入設計思路:根據前臺應用操作通過EJB 類調用文件模型操作類的具體方法,數據庫返回對應的項目列表.對項目列表內的項目文件進行鎖定操作,調取文件模型操作類的Lock()方法.前臺應用根據界面操作選擇鎖定后的項目,調取文件模型操作類的Move()遷移方法,對項目列表內的對象遷移至歸檔任務庫,如果遷移未成功的文件仍保存在項目資料庫,文檔遷移導入模塊序列圖如圖5所示.

數據補錄的設計思想:前臺應用通過EJB 層調取文件模型操作類的ReInput()方法,同時利用對象模型類顯示對應的操作界面,并寫入到數據庫.本地導入的設計思想:前臺應用通過EJB 層調取文件模型操作類的LocalImport()方法,本地導入數據直接寫入歸檔任務庫.移交接收的設計思想:前臺應用通過EJB 層驗證用戶身份權限,同時調取歸檔任務操作類的Check()方法,如果操作成功則返回審批意見信息并寫入歸檔任務庫,等待后續的歸檔完成操作,否則返回駁回信息并告知原因.

最后通過使用UML 建模工具IBM Rational Architect繪制系統主要功能模塊的時序圖和類圖,有助于完成后續系統框架設計和編碼工作.

圖4 模型數據操作類中各類間的繼承關系

圖5 文檔遷移導入時序圖

4 系統核心功能實現

4.1 系統框架設計

目前基于Python的Web 開發的框架有很多,例如:Flask、Django和Web2Py 等.Django 如同Java的EJB (Enterprise+JavaBeans+JavaEE 服務器端組件模型)多被用于大型網站的開發,而且所有資源每次都要全部加載,造成一定資源的浪費.對于大多數的小型網站的開發,Web2Py的管理接口沒有權限,沒有內建的單元測試,不方便系統的調試.Flask的優點是保持代碼簡潔且具有很強的擴展性和兼容性,通過框架后臺的自由配置,可以使歸檔管理系統支持表單驗證、權限判斷、數據庫操作等基本功能,更符合本系統的實際需求[26,27].

本系統項目歸檔操作,元數據提取和審核管理作為核心功能模塊,數據傳輸/轉換接口則作為與一站式采購管理平臺及其他信息系統間聯系的橋梁,如圖6所示.利用Flask 框架的核心庫Werkzeug的Cookies和Session 組件解決多個用戶快速響應客戶端推送過來的訪問請求,提高用戶訪問速度.同時,系統構建HTML頁面和數據綁定模式,使用knockout.js (一個基于MVVM模式的JavaScript 庫),通過將UI和基礎JavaScript 模型綁定,做到模型和UI 同步更新.通過調用Jinja2 提高系統安全,將變量名中含HTML 自動轉義,但如果是安全的變量名則利用safe 過濾器標記為安全,這樣能夠很好控制外部的腳本攻擊,而且也避免全部轉義所帶來的資源占用.

圖6 歸檔系統架構圖

4.2 元數據提取模塊設計實現

對PDF 文檔進行數據提取的方法有很多,比如使用OCR 文字識別軟件對PDF 文檔中的關鍵信息進行提取[28],利用Adobe Acrobat 所提供的接口編寫Plug-in程序實現對PDF 元數據提取[29],或者Adobe Acrobat X Pro 自帶的工具對頁面文本進行識別提取[30].但這些方法對PDF 文檔的操作太過于繁瑣,后續還要人工對所提取的元數據做進一步處理,故只適用于處理少量文檔的情況,對于體量龐大的歸檔文件元數據提取則不合適.目前比較流行的做法是采取調用已有的PDF 類庫對大量文檔進行批量操作,基于Java 類庫比較常用的兩種操作是iText和PDFBox.

iText是sourceforge的一個開源項目,通過iText 不僅可以生成PDF 或rtf的文檔,也可以將XML、HTML 文件轉化為PDF 文件[31],但iText在提取元數據時只能先將PDF 轉換為純文本后進行文本提取,這樣PDF 元數據的提取不準確.而且itextpdf 類本身并不支持中文,需要借助第三方jar (iTextAsian.jar)來實現,有部分版本升級后還需要更改中文包的名稱和存放路徑才能正常使用.

Apache PDFBox是支持操作PDF的開源工具庫[32–35].PDFBox 庫提供一個特殊的對象,該方法涉及Lucence的搜索引擎庫,LucencePDFDocument.getDocument()方法將指定PDF 文檔,提取其內容(包含作者信息和關鍵詞等元數據)并創建一個Lucence 文檔對象,這樣添加到Lucence 索引中的這些元數據方便進行跟蹤,但由于Lucence 創建的索引只支持文本索引,而且創建全文索引也消耗大量資源.

PyPDF2是基于Python 開發的函數庫,它提供對PDF 進行提取元數據和圖片、拆分或合并等基本操作,同時還能編寫腳本完成對PDF 文檔的批量操作,PyPDF2 包可在任何Python 平臺上運行,而且不依賴于其他外部庫的配合.它可以完全在StringIO 對象而不是文件流上工作,允許在內存中進行PDF 操作提高執行效率,而且新版本PyPDF4 功能更趨于完善,相對比較前兩種PDF 元數據提取的方式,此方法更符合本系統的要求,綜上所述,因此決定使用基于 Python的PyPDF2 來解決PDF 元數據提取的功能.

首先,通過pig install pycharm PyPDF2 安裝此模塊“PyPDF2”.然后導入模塊“import PyPDF2”和“import sys”,通過定義一個變量,將PDF 文件路徑賦值給變量.調用open()用“rb”二進制方式讀取文件,讀取的內容傳給PyPDF2.PdfFileReader(),初始化一個PdfFileReader對象.利用PdfFileReader 對象的getDocumentInfo()方法得到PDF 文件元數據,接著利用for 語句遍歷字典的鍵值對.此時docInfo的實例包含了大部分信息,可以使用這些屬性從文檔中獲取所需的其余元數據,將這些數據存放至數據庫以備將來使用.嘗試導入單個PDF文檔驗證程序的可行性和元數據提取準確度,結果如圖7所示.最后,添加OptionParser 方法使腳本只解析我指定的文件元數據,同時完善代碼將提取到的元數據按一定的格式顯示,部分代碼如下所示:

def main():

parser=optparse.OptionParser('usage %prog + -F')

parser.add_option('-F',dest='filename',type='string',help='specify PDF file name')(options,args)=parser.parse_args()

fileName=options.filename

if fileName==None:

print(parser.usage)

exit(0)

else:

printMeta(fileName)

if __name__=='__main__':

main()

本應用通過校園身份統一認證系統驗證才可登錄如圖8所示,登錄后根據用戶權限顯示不同的首頁界面,如圖9所示為具有文檔審核權限的用戶.

圖7 提取PDF 元數據

圖8 登陸頁面

圖9 檔案審批用戶首頁

5 結束語

針對目前學校電子文檔管理和歸檔管理的現狀,以及整個電子文件生命周期的深入分析,提出了對現有一站式采購管理平臺進一步完善的設計方案.本系統遵循模型驅動工程的研發過程,從需求分析、系統設計、系統建模和核心功能邏輯設計本文做了詳細介紹.此方案為全校提供了一個功能完整,數據安全,高效,順暢的一體化歸檔平臺,為解決學校歸檔業務全部流程信息化的最終目的打下了基礎.

下一階段研究方向,對系統的幾個方面進行改進:(1)提高PDF 元數據提取技術的精準度,目前的元數據的提取不夠全面,不利于資源搜索的效率,需要進一步優化相關算法.(2)文檔轉換要增加OFD 格式,OFD 標準是我國2016年自主研發的版式文件格式,現在還在大力推廣中,今后很有可能替代PDF 成為我國電子文檔歸檔標準格式.(3)進一步提升本系統響應時間、吞吐率、并發用戶數等方面的性能.