文檔處理系統和方法

2023-05-13 11:16:51 7

專利名稱：文檔處理系統和方法
技術領域：
本發明涉及一種文檔處理系統和方法。
背景技術：
信息可大致分為結構化數據和非結構化數據，其中以書面文檔和流J 某體為 主的非結構化數據根據資料統計佔有量超過百分之七十。結構化數據的結構比 較簡單，即一個二維表結構，其處理技術以數據為代表，主要是利用資料庫系 統進行處理，從上世紀七八十年代開始發展，到九十年代達到頂峰，研發和應 用已經比較成熟。非結構化數據則沒有固定數據結構，因此對非結構化數據的 處理非常的複雜。
目前處理各種非結構化文檔的軟體已經比較普及，形成了多種文檔格式林
立的狀況。例如，文檔編輯目前就存在Microsoft的word、 WPS、永中的Office、 Red的Office等。通常， 一個內容管理軟體往往要處理二三百種文檔才各式，而 且這些格式還在不斷更新，給這類軟體的開發帶來了巨大的困難。如何解決文 檔通用性、進行數字內容提取、格式兼容越來越成為人們的關注點，人們迫切 希望解決以下問題
1) 文檔不通用
基本上，不同用戶只能交換同一種軟體處理的文檔，無法交換不同軟體處 理的文檔，形成^f言息封閉。
2) 訪問接口不統一、數據兼容代價太高
不同的文檔處理軟體之間，文件格式互不兼容，在處理過程中要麼利用對 方組件解析(前提是對方提供相應接口 )，要麼自己投入研發力量從頭到尾的解 析對方的格式。3) 信息安全較差
目前針對書面文檔的權限控制手段單一，主要是數據加密、口令認證。因 為信息洩露，每年造成巨大損失的公司案例層出不窮。
4) 都是針對單個文檔的處理，缺乏多文檔管理手^:: 每個人電腦中都有大量文檔，但多個文檔之間缺乏有效的組織管理，而且
資源共享很難。如，字庫/字體文件、全文數據;險索等。
5) 頁面分層的技術不完善
目前一些軟體，如Adobe的photoshop， Microsoft的word，多多少少已經 有層的概念，但層的功能還比較單一，管理手段比較簡單，不能滿足應用需求。
6) 檢索手段不夠豐富
隨著信息的海量化，用任何一個關鍵詞來搜索都會得到數量龐大的檢索結 果，全文檢索技術基本解決了查全率的問題，但查準率迅速上升為首要問題。 現有技術還沒有很充分地利用全部信息來解決查準率問題，例如每個文字的字 體、字號完全可以用來判斷該文字的重要性，但都在^r索時被忽略了。
雖然各大公司目前都努力將自己特有的文檔格式發展為市場標準，各標準 組織也致力於制訂通用的文檔格式標準。但不管是專有的文檔格式(如.doc) 還是開放的文檔格式(如PDF)，只要是以文檔格式為標準，就不可避免產生以 下問題
a) 重複開發，效果不統一
使用同一標準的不同軟體都需要自己去解釋、生成該格式的文檔，造成大 量重複開發，而且會因為各家解釋程序不同，例如有的完善有的相對簡單，有 的支持新版本有的只支持舊版本數據，同 一文檔在不同軟體下顯現出不同的版 式，甚至出現解釋錯誤導致無法打開文檔。
b) 阻礙創新
軟體是不斷創新的行業，但由於每增加一個新功能就需要增加描述該功能 的信息，而且只有等到標準修訂的時候才能增加新的格式，因此把存儲格式固 定死，將會妨礙技術創新的竟爭。C)影響檢索性能
對海量信息，需要增加大量的檢索信息以提高檢索性能，但固定死的存儲 格式難以增加檢索信息
d)影響可移植性和可伸縮性
在不同的系統環境下，不同的應用需求，可能會有不同的存儲要求。例如， 存儲在硬碟上就需要考慮如何減少磁頭尋道的次數以提高性能，而在嵌入式應 用中數據都相當於存儲在內存中的，就不存在這個問題。例如，同一個廠商的 資料庫軟體在不同平臺上就可能會使用不同的存儲格式。因此，設置文檔存儲 標準將會影響系統的可移植性和可伸縮性。
現有技術中最開放、可交換性最好的文檔是Adobe Acrobat的PDF。然而， 雖然PDF已經成為全球文檔分發、交換的事實標準，但也不能實現在不同的軟 件之間交換PDF文檔，也就是說，不能實現PDF文檔的互操作性。而且，無 論是Acrobat還是O伍ce，都只能對單文檔進行處理，缺乏對多文檔的管理功能， 不具備對文檔庫進行操作的功能。
另外，在文檔信息安全的方面，現有技術也存在較多缺陷。Word和PDF 這些應用最廣泛的文檔，都是釆用對數據加密或者口令認證等進行數據安全控 制，沒有提供系統的身份認證機制，對權限的控制都是整個文檔範圍的，不能 細化到文檔內的任意區域，無法對任意邏輯數據設定加密和籤名。現有的內容 管理系統雖然能夠提供較好的身份認證機制，但由於與文檔處理系統是分離的， 不僅管理粒度只能做到文檔級，而且無法在文檔使用過程中對文檔實施安全控 制，難以進行必要的安全管理。由此可見，由於現有的安全機制與文檔處理是 分離的模塊，容易出現安全縫隙。

發明內容
本發明實施例提供了 一種文檔處理的系統和方法，實現對文檔的互操作。
本發明實施例提供的文檔處理方法，包括
應用軟體發送指令到平臺軟體，以對抽象非結構化信息進行操作；平臺軟體接收到來自所述應用軟體的指令，根據所述指令，對與所述抽象
非結構化信息對應的存儲數據執行所述操作；
其中，所述抽象非結構化信息與所述存儲it據的存儲方式無關。
本發明實施例提供的一種文檔處理系統，包括
應用軟體，用於發送指令到平臺軟體，以對抽象非結構化信息進行揭:作； 平臺軟體，用於接收到來自所述應用軟體的指令，根據所述指令，對與所 述抽象非結構化信息對應的存儲數據執行所述操作；
其中，所述抽象非結構化信息與所述存儲數據的存儲方式無關。
本發明實施例提供的一種文檔處理方法，包括
第 一應用軟體發送第 一指令到平臺軟體，以創建第 一抽象文檔；
所述平臺軟體接收所述第一指令，創建與所述第一抽象文檔對應的存儲數
據；
第二應用軟體發送第二指令到所述平臺軟體以打開所述創建的存儲數據； 所述平臺軟體接收所述第二指令，打開並解析所述存儲數據，生成與所述
存儲數據對應的第二抽象文檔；
其中，所述第一指令與第二指令符合相同的接口標準。 本發明實施例提供的一種文檔處理系統，包括 第一應用軟體，用於發送第一指令到平臺軟體，以創建第一抽象文檔； 所述平臺軟體，用於接收所述第一指令，創建與所述第一抽象文檔對應的
存儲數據；
第二應用軟體，用於發送第二指令到平臺軟體以打開所述創建的存儲數據； 所述平臺軟體，進一步用於接收所述第二指令，打開並解析所述存儲數據， 生成與所述存儲數據對應的第二抽象文檔；
其中，所述第一指令與第二指令符合相同的接口標準。 本發明實施例提供的一種文檔處理方法，包括
第 一平臺軟體解析以第 一數據格式存儲的第 一存儲數據，生成與所述存儲 數據對應的第 一抽象文檔；所述應用軟體發送第 一指令到所述第 一平臺軟體，以獲取所述第 一抽象文 檔的所有信息；發送第二指令到第二平臺軟體，以創建與所述第一抽象文件相
同或相似的第二抽象文檔；
所述第二平臺軟體根據所述第二指令，創建與所述第二抽象文檔對應並按 第二數據格式存儲的第二存儲數據；
其中，所述第一指令和第二指令符合相同的接口標準。
本發明實施例提供的一種文檔處理系統，包括
第一平臺軟體，用於解析以第一數據格式存儲的第一存儲數據，生成與所 述存儲數據對應的第 一抽象文檔；
所述應用軟體，用於發送第一指令到所述第一平臺軟體，以獲取所述第一 抽象文檔的所有信息；發送第二指令到第二平臺軟體，以創建與所述第一抽象 文件相同或相似的第二抽象文檔；
所述第二平臺軟體，用於才艮據所述第二指令，創建與所述第二抽象文檔對 應並按第二數據格式存儲的第二存儲數據；
其中，所述第一指令和第二指令符合相同的接口標準。
利用本發明實施例提供的方法和系統，應用軟體對一個抽象文檔執行操作， 因此它無需考慮文檔的數據是如何存儲的。平臺軟體維護抽象文檔和存儲數據 (如具有某種格式的文檔文件)之間的關係，如平臺軟體將應用軟體針對抽象 問的那個的操作映射到對存儲數據的實際操作，並對存儲數據執行此操作。這 樣應用軟體和平臺軟體實現了分工，進而實現文檔的互操作。


圖1為依照本發明的文檔處理系統的結構框圖。 圖2示出了依照本發明優選實施例的通用文檔模型的組織結構。 圖3示出了圖2所示通用文檔^^莫型中文檔庫對象的組織結構。 圖4示出了圖3所示文檔庫對象中文檔庫輔助對象的組織結構。 圖5示出了圖3所示文檔庫對象中文檔集對象的組織結構。圖6示出了圖5所示文檔集對象中文檔對象的組織結構。 圖7示出了圖6所示文檔對象中頁面對象的組織結構。 圖8示出了圖7所示頁面對象中層對象的組織結構。 圖9示出了圖8所示層對象中版面對象的組織結構。 圖10-17為本發明的實施例中所定義的動作。 圖18為以UOML接口為例的文檔處理系統的處理示意圖。
具體實施例方式
以下結合附圖及實施例，對本發明進行進一步詳細說明。應當理解，此處 所描述的具體實施例僅僅用於解釋本發明，並不用於限定本發明。
如圖l所示，依照本發明的文檔處理系統主要包括應用軟體、接口層、文 檔庫系統和存儲設備。
其中的應用軟體包括現有的任何文檔處理和內容管理軟體，這些應用軟體 都位於文檔處理系統的應用層，通過發送符合接口標準的指令來對文檔進行操 作，所述操作都是對符合通用文檔模型的文檔進行的，與具體存儲格式無關。
其中的接口層符合規範應用層和文檔庫系統之間交互的接口標準，所述應 用層通過接口層向文檔庫系統發送標準指令，所述文檔庫系統通過接口層向應 用層返回執行的結果。由此可見，由於應用軟體均可以通過接口層發出標準指 令，對符合通用文檔模型的文檔進行操作，所以不同的應用軟體可以通過同一 文檔庫系統對同 一文檔進4亍#:作，同 一應用庫欠件也可以通過不同文檔庫系統對 不同格式的文檔進行操作。
優選地，接口層可包括上接口單元和下接口單元，應用層通過上接口單元 發送標準指令至下接口單元，文檔庫系統通過下接口單元接收標準指令，下接 口單元還用於將文檔庫系統的執行結果通過上接口單元返回給應用系統。在實 現上，上接口單元可位於應用層中，下接口單元可位於文檔庫系統中。
其中的文檔庫系統為文檔處理系統的核心層，根據應用軟體通過接口層發
來的標準指令執行具體的文檔處理操作。
其中的存儲設備為文檔處理系統的存儲層，常用的是硬碟或者內存，也可以是光碟、快閃記憶體、軟盤、磁帶，也可以是遠程的存儲設備，總之只要具備數據 的存儲能力即可。在存儲設備中存儲有多個文檔，但對應用軟體而言並不需要 關心文檔的具體存儲方式。
由此可見，依照本發明，使得應用層和數據處理層真正分離開來，文檔不 再與特定應用軟體綁定，應用軟體不再直接跟具體的文檔格式打交道，不同的 應用軟體可以對符合通用文檔模型的同 一文檔進行編輯，使不同應用軟體之間 具有良好的文檔互操作性。
本發明還公開了一種應用軟體，其包括用於發出標準指令的接口單元，所 述標準指令用於對符合通用文檔才莫型的文檔進行操作。
本發明還公開了一種文檔庫系統，其包括用於接收標準指令的接口單元； 和，用於根據該標準指令對符合通用文檔模型的文檔進行操作的處理單元。 本發明還公開了一種接口層，其包括
上接口單元，用於發送對符合通用文檔模型的文檔進行操作的標準指令； 下接口單元，用於接收該標準指令。
進一步，上接口單元可以才艮據應用層發出的指令生成標準指令，下接口單 元判斷接收到的指令是否符合標準，並解析符合標準的指令。
文檔處理系統可以包括應用軟體和平臺軟體(如文檔庫系統)。應用軟體通 過發送一個或多個指令到平臺軟體來對抽象非結構化信息(abstract unstructured information)進行操作。平臺軟體接收到來自應用軟體的指令後，將針對抽象 非結構化信息的操作映射到針對與該非結構化信息對應的存儲數據的4喿作，並 且對該存儲數據執行該操作。其中，需要說明的是抽象非結構化信息與存儲 數據的存儲方式無關。
存儲數據是指維護或存儲在存儲器(諸如硬碟等非易失性永久存儲器，或 諸如RAM等易失性存儲器)中供長期使用的各種信息，這些信息可由計算裝 置處理。存儲數據可以包括一份完整的或綜合的信息，如o伍ce文檔、圖片或 音頻/視頻節目等。這裡"長期"不是指存儲的介質，而是指數據的形式，表明 數據不是動態存儲(例如運行實例中的一個內存指針)的，而是可被其他軟體或另 一個運行實例以後^f吏用的。
存儲數據通常包含於一個磁碟文件中，但也可以包含在多個(相關聯的) 磁碟文件中或在資料庫的多個(相關聯的)欄位中，或者是在一個獨立的磁碟 分區的一個區域中。其中，該磁碟分區不由作業系統的文件系統管理，而是由 平臺軟體直接管理。可選的，存儲數據還可以分布式存儲在不同地理位置的不 同設備上，也可以具有其他存儲形式。由此可見，存儲數據的格式可以包括如 上所述的將信息存儲為物理數據的各種形式，而不局限於一個或多個;茲盤文件 的格式。
文檔的存儲數據可稱為文檔數據，除了包含文檔的可視化信息以外，還可 以包含其它一些信息，例如安全控制信息或編輯過程信息。文檔文件是以磁碟 文件方式存儲的文檔l史據。
這裡"文檔，，通常有兩個含義 一個是指可列印到紙上的信息，如靜態的 二維信息(static two-dimension information);另 一個則泛指所有可呈現的信息， 包括多維信息或諸如音/視頻等的流媒體信息。本發明中並不嚴格區分這兩種用 法。
在本發明實施例中，應用軟體仿佛是對一個抽象文檔進行操作，它並不需 要關心文檔數據的存儲方式。平臺軟體(如文檔庫系統)負責維護抽象文檔與 存儲數據(如具有特定格式的文檔文件)之間的對應關係，比如將應用軟體 對抽象文檔執行的操作映射到針對存儲數據的實際操作，執行此操作，並在操 作需要返回值的情況下，向應用軟體返回操作結果。
在本發明實施例中，抽象文檔是對文檔數據進行抽象的結果，不同的文檔 數據可以對應相同的抽象文檔。例如，抽象文檔可以基於文檔的可視化外觀(也 稱為文檔的版式)進行抽象，具有相同可視化外觀的不同文檔數據，無論其以 何種方式存卡者，都可以對應同一抽象文檔。比如，當一個Word文件;故轉成一 個與其具有相同可一見化外)i見的PDF文件後，該Word文件與該PDF文件就是對 應同一抽象文檔的不同存儲數據。又比如當同一文檔被保存為不同版本的Word 格式文件時，這些不同版本的Word格式文件也是對應相同抽象文檔的不同存儲數據。
在本發明實施例中，為了更好地記錄可視化外觀信息，最好能記錄文字、 圖形、圖像等可視內容的位置信息，並同時記錄所引用的資源，例如^皮連結的 照片和非標準字庫。這樣，就能保證這些可視內容不會錯位、並且隨時可用。 版式文檔滿足上述條件，因此常常被用作平臺軟體的存儲數據。
由於平臺軟體創建的存儲數據可被標準指令訪問，並且可被符合接口標準 的各種應用軟體使用，因此平臺軟體創建的存儲數據又可稱為通用數據。應用
軟體不僅可以訪問通用數據，還可以定義自己特有的數據格式，如O伍ce文檔
格式。應用軟體打開並解析具有自己特有格式的文檔後，通過一個或多個標準 指令來請求生成相應的抽象文檔，平臺軟體再根據這些指令創建相應的存儲數 據。雖然新生成的存儲數據(通用數據)與原始數據的格式不同，但其與原始 數據對應相同的抽象文檔，如其具有與原始數據相同或者相似的可視化外觀。 因此，只要一個文檔數據(無論其格式如何)對應一個抽象文檔，平臺軟體就 可以創建一個與該抽象文檔對應的存儲數據，任何文檔數據都可以被轉化為與 其對應相同抽象文檔的通用文檔，並可糹皮各種應用軟體使用。這樣就實現了在 符合相同接口標準的不同應用軟體之間的文檔互操作。
下面以兩個應用軟體和一個平臺軟體為例(但不限於此)來說明文檔互操 作過程。第一應用軟體發送第一指令到平臺軟體，以創建第一抽象文檔。平臺 軟體接收到第一指令後，創建與第一抽象文檔對應的存儲數據。第二應用軟體 發送第二指令到平臺軟體以打開上述已創建的存儲數據。平臺軟體根據第二指 令打開並解析該存儲數據，並產生與該存儲數據對應的第二抽象文檔。這裡第 二抽象文檔與第 一抽象文檔相同或相似，並且第 一指令和第二指令符合相同的 接口標準，這樣第二應用軟體就可以打開由第 一應用軟體創建的文檔。
再以一個應用軟體和兩個平臺軟體為例(但不限於此)來說明另一文檔互 操作過程。第一平臺軟體解析以第一數據格式存儲的第一存儲數據，產生與該 存儲數據對應的第一抽象文檔。應用軟體發送第一指令到第一平臺軟體，以獲 取第一抽象文檔的所有信息。應用軟體發送第二指令到第二平臺軟體，以創建一個與第 一抽象文件相同或相似的第二抽象文檔。第二平臺軟體根據第二指令， 創建與第二抽象文檔對應的並且按第二數據格式存儲的第二存儲數據。這裡第 一指令和第二指令符合相同的接口標準這樣應用軟體可以將數據在不同格式間 轉化並且保持其抽象特徵不變。
多個應用軟體與多個平臺軟體情況下的文檔互操作過程可由以上兩個例子 推知。
受到文檔格式和相關軟體功能等因素的限制，存儲數據與抽象文檔的映射 關係不一定能100%完整準確，往往會存在一定程度上的偏差。例如(但不限於 此)，不管用什麼精度的浮點數還是整型數來存儲可視內容的坐標，都不能避免 出現偏差。又如，缺乏必要色彩管理功能的用於顯示/列印的軟體顯示/列印出來 的顏色和預定義的顏色可能會有一定偏差。如果這些偏差不是很明顯的話(例
如但不限於此，某個字符的位置偏離了 O.Olmm,或者某個圖像用JPEG進行了 失真壓縮)，這些偏差可以被使用者忽略。使用者所能接受的偏差程度與其實際 需求等因素有關，例如一個專業美工對色彩偏差的要求就會比一般人苛刻得多。 由此可見，抽象文檔與相對應的存儲悽t據不一定能絕對一致，與一個抽象可視 化外觀對應的多個存儲數據，其顯示/列印效果也未必絕對相同。即使用相同的 應用軟體來處理同樣的存儲數據，其呈現效果也不一定會完全一樣，例如不同 的屏幕解析度下顯示效果就會有細^t的不同。在本發明中，"相似"、"一致"被 用來表示可接受的範圍內的偏差(即偏差程度不超過預設的閾值)。由此可見， 存儲數據可以與多個相似的抽象文檔相對應或相符合。
平臺軟體可以用多種方式建立抽象文檔與存儲數據的對應關係。例如，平 臺軟體可以在打開某個文檔文件、解析該文檔文件的存儲數據並形成一個可供 應用軟體操作的抽象文檔時，建立此抽象文檔和存儲數據的對應關係。又如， 平臺軟體可以在接收到來自應用軟體指令以指示創建一個抽象文檔、並創建相 應的存儲數據時，建立此抽象文檔和存儲數據之間的對應關係。在本發明某些 實施例中，應用軟體知道其所操作的抽象文檔所對應的存儲數據(比如此時 應用軟體可以通知平臺軟體該存儲數據的地址，或者應用軟體可以將文檔數據讀到內存中，並將內存數據塊提交給平臺軟體供其處理)。在本發明另外的實施 例中，應用軟體可能對其所操作的抽象文檔所對應的存儲數據"一無所知"。例 如(但不限於此)，應用軟體可以要求平臺軟體在網際網路上按某個條件搜索，並 打開第一個搜索到的文檔。
一般說來，抽象文檔是不具有存儲的，也就是說其並未存儲在任何存儲介 質中。各種用於記錄和描述抽象文檔的信息可以包含在對應的存儲數據或操作 指令中，但這種信息都不是抽象文檔本身。因此，抽象文檔也可被稱為虛擬文 檔。
在本發明實施例中，抽象文檔可以具有結構，該結構可以用某種文檔模型 來描述，如以下提到的通用文檔模型。所謂"文檔數據符合通用文檔模型"可 以理解為對文檔數據進行抽象得到的抽象文檔符合通用文檔模型。由於通用文 檔模型是基於紙張特性抽象而來，因此所有可列印到紙上的文檔符合通用文檔
模型，這就是通用文檔模型之所以稱為"通用"的由來。
在本發明實施例中，除了可視化外觀外，還可以從文檔數據中抽取其他各 種信息，如安全控制信息、文檔組織管理信息(例如描述一個文檔屬於哪個文 檔集的信息)、導航導讀等互動信息、元數據等非可視信息等各種信息進行抽象， 甚至還可以是多維信息以及如音/視頻信息等的流媒體信息。所有這些被抽取的 信息可以統稱為抽象信息。由於抽象信息本身是沒有存儲的，也可以稱為虛擬"息。
雖然本發明所舉的實施例大都是針對文檔的可視化外觀信息的，但上述方 法也可用於其他的抽象信息，如安全控制信息、文檔組織管理信息、多維信息、 流媒體信息等。
存在多種方式來發送指令以操作抽象信息，如通過發送命令串或調用函數。 可以用不同的指令形式來表示對抽象信息進行的操作。之所以將函數調用也視 為一種指令發送形式，是因為可以將不同函數調用地址視為不同指令，將函數 的參數視為對應的指令參數。當指令以"操作動作+操作對象，，形式描述時，
指令中的對象可以與通用文檔模型中的對象相同，也可以不同。例如，設置文檔的文字對象的位置時，指令中的對象可以是文字對象，此時此指令中的對象
與通用文檔模型中的對象相同；或者，指令中的對象可以是文字的位置對象， 此時此指令中的對象與通用文檔模型的對象不同。在實際應用中，為了方便起 見，還是應當儘量將指令中的對象可以與通用文檔模型的對象統一為好。
以上描述的方法將應用軟體從平臺軟體中分離處理，使得文檔處理更加便 利。在實際應用中，也可能會出現不嚴格區分抽象信息與存儲數據，應用軟體 甚至可以通過指令直接操作文檔數據的情形。但在這種情況下，為了保持通用 性，指令應該與具體的文檔數據格式無關。更具體的，該指令可以符合一個與 文檔數據格式無關的接口標準，並可以通過這個符合該接口標準的接口層發送 該指令。接口層也可以不是一個單獨的層，而是可以分為上接口單元和下接口 單元兩部分，其中上接口單元為應用軟體的一部分，下接口單元為平臺軟體的 一部分。
以下對本發明的文檔處理系統的具體實施方式
進行闡述。 通用文檔模型
可參考紙張的特性定義所述通用文檔模型，這是因為以紙張作為文檔信息 的記錄手段是通行至今的標準方法，只要能具備紙張的所有功能，就能滿足工 作、生活等實際應用的需求。
如果把文檔中的一頁當成一張紙，凡是能畫到紙上的就記錄下來，該通用 文檔模型能夠描述頁面上的所有可見內容。現有技術中的頁面描述語言(如 PostScript)可以描述所有能印在紙上的信息，因此這一部分就不再詳細闡述。 一般說來，頁面上的可見內容最終都可以歸為文字、圖形、圖像三類。
如果文檔中涉及到特定字體或特殊字符的話，為了保證在各臺電腦上都能 有相同的效果，就需要在文檔中嵌入相應字庫。為了提高存儲效率，字庫資源 應當共享，這樣即使在多處使用了同一字符，也只需要嵌入一個字庫。圖像有 時也是可能在多處出現的，例如每一頁共同的底圖，或經常出現的公司標識， 這種情況下最好也能共享這些圖像。
當然，作為更加先進的信息處理工具，不能僅僅模擬紙張的特性，還需要增加一些增強的數字特性，例如元數據、導航、導讀、微縮版面。元數據是描 述數據的數據，例如作者、出版社、出版時間、ISBN號等就是圖書的元數據。 元數據是業內通用名詞，也不在此贅述。導航是類似圖書目錄的信息，也是業 內通用名詞。導讀信息描述了一篇文章所在的區域和閱讀順序，這樣當閱讀者 讀完一屏後就可以根據該信息自動判斷下一屏應該顯示什麼，這樣還能做到自 動換欄、自動轉版，而不用閱讀者再手工指定位置。微縮版面是事先生成的各 頁面的微縮圖，閱讀者可以通過查看微縮版面來指定閱讀哪一頁。
圖2是本發明的一優選實施例的通用文檔模型。如圖2所示，該通用文檔
模型包含文檔倉庫、文檔庫、文檔集、文檔、頁、層、對象組、版面對象等多 個層次。
其中，文檔倉庫由一個或多個文檔庫組成，文檔庫之間的關係相對於文檔 庫之下的層次之間的關係相對要鬆散一些，文檔庫之間可以非常簡單地組合和 拆離，而不用對文檔庫本身的數據做改動，該多個文檔庫之間往往沒有建立統 一索引(特別是全文索引)，很多對文檔倉庫的檢索操作一般都需要遍歷各文 檔庫的索引，而沒有統一的索引可用。每個文檔庫由一個或多個文檔集組成， 每個文檔集由一個或多個文檔組成，還可以包含任意數量的子文檔集。這裡所
說的文檔相當於目前普通的一個文檔文件(例如DOC文檔)，通用文檔才莫型 可以規定一個文檔只能屬於一個文檔集，但也可以允許一個文檔屬於多個文檔 集。文檔庫不是多個文檔的簡單組合，它把多個文檔緊密地組織起來，特別是 為文檔內容統一建立了各種檢索索引後就能帶來更大的便利性。
每個文檔由一頁或存在一定順序(如前後順序)的多頁組成，每頁的版心 可以不同，而且版心也不一定是矩形的，可以是任意形狀，可以用一條或多條 封閉曲線表示版心。
每頁又由一層或按一定順序(如上下順序)的多層組成，各層之間如同玻 璃板的疊加關係。層由任意數量的版面對象和對象組組成，版面對象是指狀態 (如字體、字號、顏色、ROP等)、文字(包括符號)、圖形(如直線、曲線、 填充了指定顏色的閉合區域、漸變色等)、圖象(如TIF、 JPEG、 BMP、 JBIG等)、語義信息(如標題開始、標題結束、換行等)、源文件、腳本、插件、 嵌入式對象、書籤、連結、流媒體、二進位數據流等。 一個或多個版面對象可 以組成一個對象組。對象組也可以包含任意數量的子對象組。
文檔庫、文檔集、文檔、頁、層都可以還包括元數據(如名稱、最後修改 時間等，其類型可以根據應用需求來設置)和/或歷史痕跡；文檔中還可以包
括導航信息、導讀信息、微縮版面；也可以把微縮版面放在頁或者層這個層次； 文檔庫、文檔集、文檔、頁、層、對象組都可以還包括數字籤名；語義信息最 好跟著版面信息走，這樣可以避免數據冗餘，也比較容易與版面建立對應關係； 文檔庫、文檔還可以包括字庫、圖像等共享資源。
該通用文檔模型還可以定義一個或多個角色，為每個角色分配一定權限。 權限以文檔庫、文檔集、文檔、頁、層、對象組、元數據為單元進行分配，定 義每個角色對該單元是否可讀、是否可寫、是否可複製、是否可列印，等等。
該通用文檔模型是一個超越以往單個文檔對應單個文件的方式，文檔庫中 包含多個文檔集、文檔集中包含多個文檔，而對於文檔庫中文檔內容，採用了 細粒度的訪問和安全控制，可以具體訪問文檔庫中某個文字或者矩形，而不像 現在的文檔管理系統只能訪問到文件名。
圖3至圖9示出了本發明一優選實施例的通用文檔模型所涉及的各對象的 組織結構示意圖。所述的各對象的組織結構是樹狀結構，是逐層展開、細化的。
文檔倉庫對象是由一個或多個文檔庫對象組成(圖中未示出)。
如圖3所示，文檔庫對象包括一個或多個文檔集對象、任意數量文檔庫輔 助對象和任意數量的文檔庫共享對象。
如圖4所示，所述的文檔庫輔助對象包括元數據對象、角色對象、權限對 象、插件對象、索引信息對象、腳本對象、數字籤名對象、歷史痕跡對象等。 文檔庫共享對象是指文檔庫中的不同文檔可能共享的對象，如字庫對象、圖像 對象等。
如圖5所示，每個文檔集對象包括一個或多個文檔對象、任意數量的文檔 集對象和任意數量的文檔集輔助對象。文檔集輔助對象包括元數據對象、數字籤名對象、歷史痕跡對象。當文檔集對象包括多個文檔集對象時，其類似於資 源管理器中的文件夾包括多個文件夾的形式。
如圖6所示，每個文檔對象包括一個或多個頁面對象、任意數量的文檔輔 助對象和任意數量的文檔共享對象。文檔輔助對象包括元數據對象、字庫對象、 導航信息對象、導讀信息對象、微縮版面對象、數字籤名對象、歷史痕跡對象 等。文檔共享對象包括文檔中的不同頁面可能共同使用的對象，如圖^象對象、 印章對象等。
如圖7所示，每個頁面對象包含一個或多個層對象和任意數量的頁面輔助 對象組成。頁面輔助對象包括元數據對象、數字籤名對象、歷史痕跡對象。
如圖8所示，每個層對象包括一個或多個版面對象、任意數量的對象組和 任意數量的層輔助對象。層輔助對象包括元數據對象、數字籤名對象、歷史痕 跡對象。對象組包括任意數量的版面對象、任意數量的對象組和可選的數字籤 名對象。當對象組包括多個對象組時，其類似於資源管理器的文件夾包括多個 文件夾的形式。
如圖9所示，版面對象包括狀態對象、文字對象、直線對象、曲線對象、 圓弧對象、路徑對象、漸變色對象、圖像對象、流媒體對象、元數據對象、批 注對象、語義信息對象、源文件對象、腳本對象、插件對象、二進位^:據流對 象、書籤對象以及超連結對象。
其中，狀態對象包括任意數量的字符集對象、字體對象、字號對象、文字 顏色對象，光柵操作對象、背景色對象、線顏色對象、填充色對象、線型對象、 線寬對象、線接頭對象、畫刷對象、陰影對象、陰影顏色對象、旋轉對象、空 心字對象、勾邊字對象、透明對象和渲染模式對象。
在具體實施過程中，可以在上述通用文檔^^莫型基礎上進一步增強或簡化。 如果在簡化模型中省略了文檔集對象，則文檔庫對象直接由文檔對象組成；如 果在簡化模型中省略了層對象，則頁面對象直接由版面對象組成。
可以理解，最簡化的通用文檔模型是僅包含文檔對象、頁面對象和版面對 象。其中版面對象僅包括文字對象、直線對象和圖像對象。完整模型和最簡化模型之間的各種中間模型都屬於本優選實施例的變形。
通用安全模型
為了滿足各種應用對文檔安全性的需求，還需要定義一種通用的文檔安全 ^t型，以解決由於現有軟體的文檔安全功能不夠強，或者是安全管理^4'J與文 檔處理模塊脫節所導致的安全縫隙。根據本發明一優選實施例，通用文檔安全 模型包括
1. 在文檔庫中設置若干角色，角色對象是文檔庫對象的子對象。
2. 可以設置任意角色對任意對象(例如文檔庫、文檔集、文檔、頁、層、 對象組、版面對象等)的訪問權限。如果設置了某角色對某對象的訪問權限， 則該^L限適用於該對象的所有子對象。
3. 文檔庫系統實現的訪問權限包括是否可讀、是否可寫、是否可再授權、 是否可收回授權及其排列組合。也可以定義其他需要由應用軟體來配合實現的 ^J艮，如不可列印。
4. 角色可以對任意對象進行籤名。籤名範圍包括該對象的子對象，以及 引用到的對象。
5. 創建角色對象的指令的執行結果是向應用軟體返回一個密鑰，作為應 用軟體以該角色身份登錄的依據，該密鑰通常是PKI的私鑰，由應用軟體保管， 該密鑰也可以是登錄口令。
6. 當應用軟體以某一角色身份登錄時，通常採用"挑戰-應答"機制，即 文檔庫系統用保存的角色公鑰加密一塊隨機數據發給應用軟體，應用軟體解密 後返回給文檔庫系統，如果解密正確，則表明應用軟體確實擁有該角色對應的 私鑰。"挑戰-應答"機制也可以用以下方式實現，文檔庫系統將一塊隨機數據 發給應用軟體，應用軟體用私鑰加密後返回給文檔庫系統，文檔庫系統用保存 的角色的公鑰解密，如果解密正確，則表明應用軟體確實擁有該角色對應的私 鑰。為保險起見，該認證過程可能會重複幾次。採用"挑戰-應答"機制可以更 好地保護私鑰的安全性。如果角色的密鑰是登錄口令，則需要用戶輸入正確的 登錄口令。7.應用軟體可以同時登錄多個角色，此時擁有的權限是各角色權限的併集。
在具體實施過程中，可以在上述通用安全模型基礎上進一步增強或筒化。 針對上述安全模型的任何簡化模型都是本實施例的變形。 接口層的具體實現
所述接口層的統一接口標準可根據通用文檔模型、通用安全模型和常用的 文檔操作而定義，用於發送對通用文檔模型中各對象進行操作的指令。所述的 對通用文檔模型中各對象進行操作的指令符合接口標準，各種應用軟體可以通 過接口層發出標準指令。
現在介紹接口標準的實現方式。接口標準的實現可以是上接口單元按照預
先定義的標準才各式生成命令串，例如"，，，將該命令串發送給下接口單元，並從下接 口單元接收文檔庫系統對該命令的執行結果或其它反饋信息；或者，接口標準 的實現是下接口單元提供一些具有標準名稱和參數的接口函數，例如"BOOL UOI—InsertPage (UOI—Doc *pDoc, int nPage)，，，上接口單元調用這些標準函數， 調用操作本身就代表上接口單元發出了標準指令；或者是上述方法的組合。
接口標準釆用"操作動作+操作對象"的方式來實現便於學習和理解，也便於 保持接口標準的穩定性。例如，對20種不同對象進行10種操作，可以定義 20x10=200種指令，也可以定義20種對象和10種動作，但顯然後一種方式大 大減輕了記憶的負擔，而且今後在對接口標準進行擴充時，增加一個對象或動 作也很簡單。所述操作對象為通用文檔模型所包含的對象。
例如，定義以下7種操作動作
打開用於創建或打開文檔庫；
關閉用於關閉會話句柄、關閉文檔庫；
獲取用於獲取對象列表、對象相關屬性和數據；
設置用於設置/修改對象數據；
插入插入指定對象或數據；刪除用於刪除對象的某個子對象；
檢索查詢用於根據定義條件在文檔中找到符合條件的內容，這些條件既 可以是準確的信息，也可以是不準確的信息，即模糊查找。
定義如下對象文檔庫、文檔集、文檔、頁、層、對象組、文字、圖像、 圖形、路徑(由一組順序圖形連接組成，可以是閉合也可以不閉合的)、源文 件、腳本、插件、音頻、視頻、角色等。
對象還包括下列狀態對象背景色、線的顏色、填充色、線型、線寬、ROP、 畫刷、陰影、陰影顏色、字符高、字符寬、旋轉、透明、渲染模式等。
可以理解，在採用"操作動作+操作對象"方式實現接口標準時，不能自動理 解為每一個對象和每一個動作的所有組合都一定能構成有實際意義的操作指 令， 一些組合是沒有意義的。
還可以用非"操作動作+操作對象"的函數方式來定義接口標準，例如對每 一個對象的每一種操作都定義一個接口函數，這樣各種操作指令就是上接口單 元以調用下接口單元的接口函數來發送給文檔庫系統。
還可以封裝各個對象類，如文檔庫類，把該對象可以進行的操作定義成該 類的方法。
特別地，如果在接口標準中定義了獲取版面位圖的指令，將對保障版面一 致性和文檔互操作性起到非常關鍵的作用。
在檢索查詢指令中，除了常規的關鍵詞檢索外，還可以提供更加豐富的檢 索手段。在常規的搜索技術中，搜索是和文檔處理分離的，搜索程序只能從文 檔中提取純文本信息，而無法獲取更多信息，只能基於文本信息檢索。但在本 發明中，檢索查詢功能是集成在文檔處理的核心層，即文檔庫系統，這樣就可 以更充分地利用文檔中蘊含的信息來提供更為強大的4全索手段，如
1. 基於字體信息的檢索，如檢索黑體字的"書生"，Times New Roman字體 的"S薦n"
2. 基於字號信息的檢索，如檢索三號字的"書生"，20磅以上的"Sursen", 長字(即字高超過字寬)的"文檔庫，，3. 基於顏色的才全索，如才全索紅色的"書生"，藍色的"Sursen"
4. 基於版面位置的檢索，如檢索位於頁面上半部分的"書生"，位於頁腳的 "Su羅，，
5. 基於特殊修飾效果的檢索，如檢索斜體字的"書生"，順時針旋轉30度 至90度之間的"Sursen",空心字的"SEP",勾邊字的"文檔庫"
6. 根據類似的思路，還可以進一步提供其它類型的檢索，如檢索反白(黑 底白字)的"書生"，壓圖的"Sursen，，等
7. 可以檢索多個版面對象的組合，如"書生"距離"Sursen"不超過5釐米
8. 上述檢索條件的任意組合
以下是用"操作動作+操作對象"的方式實現接口標準的 一 個實施例，在該 實施例中，接口稱為非結構操作標記語言(UOML),是用可擴展標記語言 (XML)描述的一系列的命令。每個動作都對應一個XML元素，每個對象 也都對應一個XML元素；描述一個命令時，將描述對象的XML元素作為 描述動作的XML元素的子元素，即可生成包括動作+對象的字符串。上接 口單元將該字符串發送給下接口單元，就將相應的操作指令發送給了文檔庫 系統。文檔庫系統執行這些命令後，下接口單元將執行結果也生成一個符合 UOML格式的字符串，返回給上接口單元，使應用軟體能夠知曉操作執行結 果。
所有執行結果都由UOML—RET表示，參見圖10,其定義如下 屬性
SUCCESS:值為真(true)時表明操作成功，否則失敗。 子元素
ERR_INFO:可選，僅當操作失敗時出現，描述了相應的錯誤信息。 其它子元素根據具體命令確定，可參考各命令說明。 UOML動作包括
1 UOML—OPEN創建或打開文檔庫，參見圖11。 1.1屬性1.1.1 create:為true時是創建，否則是打開已有文檔庫。 1.2子元素
1.2.1 path:文檔庫路徑。可以是磁碟文件名，也可以是URL,或者是內存 指針，或者是網絡路徑，或者是文檔庫的邏輯名稱，或者其它能夠指定文檔庫 的表示方法。可以用不同特徵的字符串區分上述各種情況，即不用改變命令格 式，只要給字符串設置不同特徵，就可以用不同的方法指定文檔庫。例如，磁 盤文件名採用設備名稱(如盤符)和":"開頭(如"C:"、 "D:"),而且緊跟著":" 不會是"〃"，也不會是又一個":"；URL採用協議名稱和":〃"開頭(如"http:〃")； 內存指針用"MEM::"開頭，後面是指針的字符串表示方式，例如 "MEM::1234:5678，，；網絡路徑是"W，，開頭，後面是伺服器名，以及伺服器上的路 徑，如"\\server\abc\def.sep"; 文檔庫的邏輯名稱可以用"*，，開頭，如 "*MyDocBasel"。在下接口單元解析時，如果第一個字母是"*"就表明該字符串 代表文檔庫的邏輯名稱；否則如果頭兩個字母是"W"就表明該字符串代表網絡路 徑；否則如果頭五個字母是"MEM::"就表明該字符串代表內存指針；否則尋找 字符串的第一個":"，如果該":，，後面是"〃"該就表明字符串代表URL,否則就代 表本地設備上的文件。對於打開伺服器上的文檔庫的情形，可以設立一個專門 的URL協議來區分，例如用"Docbase:〃myserver/mydoc2"指明打開伺服器 myserver上運行的文檔庫系統伺服器系統所管理的mydoc2文檔庫。 總之，只要能給字符串設置不同特徵，就可以用不同的方式來指定文檔庫。根 據上述說明，還可以定義各種不同的字符串特徵；該方式不僅能應用於指定文 檔庫路徑，還能應用於其它場合，特別是用來指定特定資源位置的應用場合。 在很多情況下，希望能夠用一種新方式來指定相關資源，但又不能或不希望改 變現有的協議或函數，這時就可以通過在字符串中設置不同特徵的方式來指定， 這種方法具有最好的通用性，這是因為，無論何種協議或函數，只要支持磁碟 文件名或URL,就支持字符串。
1.3返回值
如果成功，則在UOML—RET中包含一個"handle"子元素，記錄句柄2關閉(UOML—CLOSE),參見圖12。 2.1屬性無。 2.2子元素
2.2.1 handle:對象句柄，是一個字符串表示的對象的引用指針。
2.2.2 db—handle:文檔庫句柄，字符串表示的文檔庫的引用指針。 2.3返回值無返回值。
3 UOML—GET獲取，參見圖13。 3.1屬性
3.1.1 usage:用途，為"GetHandle"(獲取指定對象句柄)、"GetObj"(獲 取指定對象數據)、"GetPageBmp"(獲取版面位圖)中的一個。 3.2子元素
3.2.1 parent:父對象句柄，usage屬性為"GetHandle"時使用。
3.2.2 pos:位置順序號，usage屬性為"GetHandle"時使用。
3.2.3 handle:指定對象的句柄，當usage屬性為"GetObj"時使用。
3.2.4 page:需要顯示的頁面的句柄，當usage屬性為"GetPageBmp"時使用。
3.2.5 input:描述了對輸入頁面的約束，其中可以指定顯示一層或者多層 的內容(可以顯示的層一定是當前角色有權限訪問的層)；也可以通過指定Clip 區域來指定顯示區域的大小。當usage屬性為"GetPageBmp"時使用。
3.2.6 output:描述了版面位圖的輸出方式.，當usage屬性為"GetPageBmp" 時使用。
3.3返回值
3.3.1 當usage屬性為"GetHandle"時，執行成功時在UOML—RET中包含 一個"handle"子元素，記錄parent下第pos個子對象的句柄。
3.3.2 當usage屬性為"GetObj"時，執行成功時在UOML—RET中包含一個 "xobj"子元素，含有handle對象的數據的xml表示。
3.3.3 當usage屬性為"GetPageBmp"時，執行成功時在output指定位置輸出版面位圖。
4 UOML—SET設置，參見圖14。 4.1屬性無。
4.2子元素
4.2.1 Handle:設置對象的句柄。
4.2.2 xobj:對象的描述。 4.3返回值無返回值。
5 UOML—INSERT插入，參見圖15 5.1屬性無。
5.2子元素
5.2.1 parent:父對象句柄。
5.2.2 xobj:對象的描述。
5.2.3 pos:插入位置。
5.3返回值如果執行成功，則將xobj參數表示的對象，插入到parent中 成為其第pos個子對象，並在UOML—RET中包含一個"handle"子元素，表示新 插入對象的句柄。
6 UOML—DELETE 刪除，參見圖16 6.1屬性無。
6.2子元素
6.2.1 handle:需要刪除的對象的句柄。 6.3返回值無返回值。
7 UOML—QUERY檢索查詢，參見圖17 7.1屬性無。
7.2子元素
7.2.1 handle:需要查詢的文檔庫句柄。
7.2.2 condition:查詢條件。
7.3返回值如果成功，在UOML—RET中包含一個"handle，，子元素代表查詢結果的句柄， 一個"number"子元素代表查詢結果的數量，可以用UOML—GET 來獲取每一個查詢結果。 UOML對象包括
文檔庫(UOMLDOCBASE)、 文檔集(UOML_DOCSET)、 文檔 (UOML一DOC)、 頁(UOML—PAGE)、 層(UOML—LAYER)、 對象組 (UOMLOBJGROUP)、文字(UOMLTEXT)、圖像(UOMLIMAGE)、直線 (UOML—LINE)、 曲線(UOML—BEIZER)、 圓弧(UOML—ARC)、 路徑 (UOML—PATH )、源文件(UOMLSRCFILE)、背景色(UOML—BACKCOLOR)、 前景顏色(UOMLCOLOR)、 ROP(UOML—ROP)、字符尺寸(UOML—CHARSIZE)、 字體(UOML—TYPEFACE)。
下文以UOML—DOC、 UOML—TEXT和UOML—CHARSIZE為例i兌明其定 義方式
1 UOML—DOC 1.1屬性無。 1.2子元素
1.2.1 metadata:元悽t據。
1.2.2 pageset:各頁面。
1.2.3 fontinfo:嵌入字庫。
1.2.4 navigation:導航信息。
1.2.5 thread:導讀信息。
1.2.6 minipage:孩i縮片反面。
1.2.7 signiture:數字籤名。
1.2.8 sharesource:共享資源。
2 UOML—TEXT 2.1屬性
2.1.1 Encoding: 文字編碼方式。 2.2子元素2.2.1 TextData: 文字內容。
2.2.2 CharSpacingList:對非等間距文字的字間距列表。
2.2.3 StartPos:起點位置。 3 UOML—CHARSIZE
3.1屬性
3丄1 width:字符寬度。 3丄2 height:字符高度。 3.2子元素無。
以此類推，可以用同樣的方法來描述所有的UOML對象。當應用軟體對文 檔庫進行操作時，由上述UOML動作與UOML對象依照XML語法生成相應 的UOML命令，將該UOML命令發給文檔庫系統，即代表向文檔庫系統發出 了相應操作指令。
例如，對創建文檔庫操作,可以用以下命令來完成

<path val="f:\\data\\docbasel .sep'V〉
</UOML—OPEN〉
對創建文檔集操作，可以用以下命令來完成
<parent val= "123.456.7897〉




需要說明的是，雖然UOML是用XML定義的，但為了顯得更加簡潔，在 前面省略了類似"，，以及"xmlns:xsi: "http:〃www.w3.org/2001/XMLSchema-instance""之類的常規XML格式，只要是 熟悉XML語法的實施者都可以在實施過程中自行添加。也可以不用XML方式定義命令串，例如改用類似PostScript那樣的方式， 這才羊上例變成
1, "f:WdataWdocbasel.sep", /Open /docset, 1, "123.456.789" ， /Insert
根據同樣的思路，還可以定義出其它類型的命令串格式，甚至還可以不用 文本方式，而用二進位方式來定義命令串。
現在介紹對每一個對象的每一個操作都用一個命令來表示的方式的一個具 體實例，在本實例中，用"UOML—INSERT—DOCSET"來表示插入一個文檔集， 用"UOML—INSERT—PAGE"來表示插入一頁，以這樣的方式來定義每個命令 UOML—INSERT—DOCSET在文檔庫中創建一個文檔集 屬性無 子元素
parent: 文檔庫句柄 pos:插入位置
返回值如果執行成功，則在UOML一RET中包含一個"handle"子元
素，表示新插入文檔集的句柄 這才羊上例就變為
〈parent val="123.456.7897>

用這種方法定義命令格式需要對每個對象的每種合法操作都單獨定義一條 命令，缺點是比較繁瑣。
現在介紹用函數調用的方式來實現接口標準的實例，在該實例中，通過上 接口調用下接口的接口函數的方式來發送操作指令給文檔庫系統。以下以C++ 語言為例說明，該實例稱為UOI。在該實例中，定義了 UOI一Object作為所有對 象的基類，為每個動作定義了一個函數，該函數的參數可以是對基類的指針或引用，這樣該函數就可適用於所有對象。
先定義一個UOI返回值結構 struct UOI—Ret {
BOOL m—bSuccess;
CString m—Errlnfo;
};
定義所有UOI對象的基礎類
class UOI—Object {
public:
enum Type {
TYPE—DOCBASE，
TYPE—DOCSET，
TYPE—DOC, TYPE—PAGE, TYPE—LAYER, TYPE—TEXT, TYPE—CHARSIZE,
Type m—Type;
UOI_Object; virtual UOI—Object; static UOI—Object Create(Type objType);
};
然後定義如下幾個uoi函數，與"操作動作+操作對象，，方式實例中的幾個
UOML動作相對應
UOI—RET UOI—Open(char *path， BOOL bCreate, HANDLE *pHandle); UOI—RET UOI—GloseCHANDLE handle, HANDLE db—handle);UOI—RET UOI—GetHandle(HANDLE hParent， int nPos, HANDLE *pHandle); UOI—RET UOI—GetObjType(HANDLE handle, UOI—Object ::Type *pType); UOI—RET UOI—GetObj(HANDLE handle, UOI—Object *pObj); UOI—RET UOI—GetPageBmp(HANDLE hPage， RECT rect, void *pBuf); UOI—RET UOI—SetObj(HANDLE handle, UOI—Object *pObj); UOI—RET UOI—Insert(HANDLE hParent, int nPos， UOI—Object *pObj, HANDLE *pHandle = NULL);
UOI—RET UOI—Delete(HANDLE handle);
UOI—RET UOI—Query(HANDLE hDocbase， const char *strCondition, HANDLE承phResult);
然後定義各UOI對象，依然以U01—Doc、 UOI—Text和UOML—CharSize為
例i兌明
class UOI一Doc : public UOI一Object { public:
UOI—MetaData m一MetaData;
int m—nPages;
UOI—Page **m_pPages;
int m一nFonts;
UOI—Font **m_pFonts; UOI—Navigation m—Navigation ;
UOI—Thread m—Thread ;
UOI一MiniPage *ip_pMiniPages;
UOI—Signature m—Signature ;
int m—nShared j
UOI—Obj *m_pShared;
UOI—Doc;
virtual UOI一Doc;
};class UOI—Text: public UOI—Object {
public:
enum Encoding { ENCODE—ASCII, ENCODE一GB 13000, ENCODE—UNICODE,
Encoding m一Encoding;
char *m_pText;
Point m一Start;
int *m—CharSpace ;
UOI一Text;
virtual UOI—Text;
};
class UOI一CharSize : public UOI一Object { public :
int m—Width ;
int m一Height j
UOI—CharSize; virtual ~UOI—GharSize;
};
以下說明UOI的使用方法。首先是創建文檔庫操作
ret = UOI—Open("f:WdataWdocbasel.sep", TRUE, &hDocBase);
然後是構建一個創建新對象的函數
HANDLE InsertNewObj (HANDLE hParent, int nPos， UOI一Object ::Type type) {
UOI—Ret ret;HADNLEhandle ;
UOI—Obj *pNewObj = UOI—Obj::Create(type); if(pNewObj==NULL)
return NUIX; ret = UOI—Insert(hParent, nPos, pNewObj， &handle); delete pNewObj;
return ret.m_b Success handle : NULL;
然後是直接獲取對象的函數 UOI—Obj *GetObj(HANDLE handle)
UOI—Ret ret;
UOI一Object ::Type type; UOI—Obj *pObj;
ret = UOI—GetObjType(handle, &type); if ( !ret. m一bSuccess )
return NULL; pObj = UOI一Obj::Create(type); if(pObj==NULL)
return NULL; ret = UOI—GetObj(handle, pObj); if ( !ret. m—bSuccess ) {
delete pObj;
return NULL;
return pObj;
在對每一個對象的每一種操作都定義一個接口函數的方式中，插入文檔集 的操作指令就是上接口以下列方式調用下接口的接口函數來發送給文檔庫系統UOI—InsertDocset(pDocbase, 0);
在封裝各個對象類(如文檔庫類)的方式中，把該對象可以進行的操作定 義成該類的方法，^:
class UOI—DocBase : public UOI—Obj
public:
/承！
* \brief 創建文檔庫
* \param szPath: 文檔庫全路徑
* \param bOverride:是否覆蓋原文件
* Veturn UOI—DocBase對象
承/
BOOL Create(const char *szPath, bool bOverride = false);
* \brief 打開文檔庫
* \param szPath:文檔庫全-各徑
* \retum UOI—DocBase對象
承/
BOOL Open(const char承szPath);
* \brief 關閉文檔庫
* \pamm 無
* \return 無
void Close;
/"
* \brief 獲取角色列表* \param 無
* \retum UOI—RoleList對象
* \sa UOI—RoleList
承/
UOI—RoleList GetRoleList;
/承1
* \brief 存儲文檔庫
* \param szPath:存儲文檔庫全路徑
* \return 無
承/
void Save(char *szPath = 0);
* \brief 插入文檔集
* \param nPos:插入文檔集的位置
* \retum UOI—DocSet對象
* \sa UOI—DocSet
氺/
UOI—DocSet InsertDocSet(int nPos);
* \brief 獲取指定索引的文檔集
* \param nindex:文檔列表的索引號
* \return UOI—DocSet對象
* \sa UOI—DocSet
承/
UOI—DocSet GetDocSet(int nindex); /承1
* \brief 獲取文檔集的總數* \param 無
* \retum 文檔集個悽史 */
int GetDocSetCount; /*!
* \brief 設置文檔庫的名稱
* \param nLen: 文檔庫名稱長度
* \param szName: 文檔庫名稱
* \return 無
*/
void SetName(int nLen， const char* szName); /*!
* \brief 獲取文檔庫名稱長度
* \param 無
* Veturn 長度
*/
int GetNameLen; /*!
* \brief 獲取文檔庫名稱
* \param 無
* \retum 文檔庫名稱 */
const char* GetName;
* \brief 獲取文檔庫id長度
* \param 無
* \return 長度
*/int GetIDLen;
/承！
* \brief 獲取文檔庫id
* \param 無
* \return id
承/
const char* GetID;
//!構造函數
UOI—DocBase;
〃！析構函數
virtual UOI—DocBase;
};
這樣插入文檔集的操作指令就是上接口以下列方式調用下接口的接口函數
來發送給文檔庫系統的
pDocBase.InsertDocset(O);
還可以用同樣的方法為Java、 C#、 VB、 Delphi等各種程式語言開發的應用 軟體設計各種不同的接口標準。
只要在接口標準中不含有與特定的作業系統(如WINDOWS, UNIX/LINUX、 MACOS、 SYMBIAN)或特定的硬體平臺(如x86CPU、 MIPS、 POWER PC等)相關連的特徵，該接口標準就可以具有跨平臺性，使得不同平 臺上運行的應用軟體和文檔庫系統都可以統一使用同樣的接口標準，特別是可 以讓一個平臺上運行的應用軟體可以調用另 一個平臺上運行的文檔庫系統來才丸 行相應操作。例如，應用軟體部署在客戶端，使用的是PC機，Windows操作 系統，文檔庫系統部署在伺服器端，使用的是大型機，Linux作業系統，但應 用軟體依然可以像調用本地文檔庫系統一樣調用伺服器上的文檔庫系統來執行 相應文檔操作。
如果在接口標準中不含有與特定程式語言相關的特徵，則該接口標準還 能做到與程式語言無關。可以看出，用命令串的方式容易構造與平臺無關、與程式語言無關的接口標準，更具有通用性。特別是用XML來構造命令串 的話，由於目前在各種不同平臺、不同程式語言都存在易於獲得的XML生 成解析工具，因此不僅該接口標準具有很好的跨平臺性和與程式語言無關 性，也非常便於工程師開發上接口單元和下接口單元。
以上列舉了多種接口標準的實現方法，按照類似的思路設計的更多種類的 接口標準也包含在本發明的保護範圍之內。
應該理解，可以在上述實例的基礎上按同樣的思路增加操作指令，也可以 筒化操作指令，特別是文檔模型被簡化時操作指令也會相應被簡化。最簡化情 況下只有文檔的創建、頁面的創建、各版面對象的創建這幾個操作指令。
文檔操作處理
現在，參見圖1,繼續描述依照本發明一優選實施例的文檔處理系統的工 作過程。
應用軟體是包含符合接口標準的上接口單元的軟體，例如Office軟體、內 容管理、資源採集等。任一應用軟體在需要對文檔進行操作時，依照前述方法 將指令傳遞給文檔庫系統，文檔庫系統根據指令來完成具體操作過程。
文檔庫系統可以自由地存儲、組織文檔庫數據，例如可以把一個文檔庫的 文件全部都存儲在一個磁碟文件中；可以一個文檔對應一個磁碟文件，利用操 作系統中的文件系統功能實現多文檔組織；也可以一頁對應一個^茲盤文件；還 可以完全拋開梯:作系統，在^f茲盤上留出一塊空間後直接對^磁軌、扇區進行管理。 對文檔庫數據的存儲格式，可以用二進位格式保存，可以用XML,還可以用二 進位XML。頁面描述語言(定義頁面上的文字、圖形、圖像等對象的方法)可 以採用PostScript,可以採用PDF、 SPD (書生公司使用的頁面描述語言)，當 然也可以採用自定義的任何頁面描述語言，只要其符合統一的接口標準。
例如，可以用XML來描述文檔庫數據，當文檔模型是層次型的時候，可 以完全對照建立相應的XML樹。執行創建操作時就在XML樹中增加一個結點， 執行刪除操作就刪掉相應結點，執行設置操作就設置相應結點的屬性，執行獲 取操作就取出相應結點的屬性並返回給應用軟體，執行查詢操作時就遍歷相關結點查找。
以下是該實施例的進一步說明
1. 用XML來描述每個對象。也就是說，為每個對象都建立了一個對應的 XML樹。有的對象屬性比較簡單，其對應的XML樹就只有根結點，有的對象 比較複雜，其對應的XML樹還有子結點。具體描述方法可以參見前面用XML 來定義操:作對象的說明。
2. 當新建一個文檔庫時就新建一個根結點為文檔庫對象的XML文件。
3. 每當在文檔庫中插入一個對象時，如文字對象，就將該對象對應的XML 樹插入到插入位置的父結點(如層)之下。這樣，文檔庫中的每個對象都在文 檔庫為根結點的XML樹中有一個對應的結點。
4. 當刪除一個對象時，就刪除該對象對應的結點，其下屬所有子結點也都 被刪除。刪除過程是從葉子結點開始自下而上遍歷的。
5. 設置一個對象屬性時，將該對象對應的結點的屬性設置成該屬性。如果 該屬性是用子結點表示的，則設置對應的子結點。
6. 獲取一個對象屬性時，訪問該對象對應的結點，根據該結點的屬性和子 結點獲得該對象的屬性。
7. 獲取一個對象的句柄時，返回該對象對應結點的XML路徑。
8. 複製一個對象(如頁面)到指定位置時，就將該對象對應的結點開始的 整個子樹都複製到目標位置對應的父結點(如文檔)之下。如果是複製到另一 個文檔庫中，則需要將該子樹引用的對象(如嵌入字庫)也一起複製過去。
9. 執行獲取版面信息指令時，先生成一個指定位圖格式的空白位圖，其尺 寸和指定區域相同，然後遍歷指定頁面的所有版面對象，凡是位於指定區域內
(包括只有一部分在該區域內)的版面對象，都解釋其含義，並在版面上相應 體現。具體過程雖然比較複雜比較專業，但均屬於現有RIP技術範疇，不在此贅述。
文檔安全處理
在創建角色對象時，生成一對隨機7>私鑰對(例如512位的RSA密鑰)，將公鑰存儲在角色對象中，將私鑰返回給應用軟體。
當應用軟體登錄時，隨機生成一塊(例如128位元組)數據，用相應角色對 象中的公鑰加密該數據發給應用軟體，應用軟體解密後比較驗證，如果正確則 表明應用軟體確實擁有該角色對應的私鑰，登錄成功。為保險起見，該認證過 程可以重複三次，三次全部通過才算登錄成功。
當對某一對象進行籤名時，也就是對其對應的結點開始的子樹進行籤名。 為了能夠使籤名不受具體物理存儲方式的影響，需要先做一個正則化，使得邏 輯上等效的變化(例如存儲位置的改變導致相應指針的變化)不會影響籤名有
歲支性。該正則4b的方法如下
按深度優先遍歷以目標對象為根節點的子樹中的各個節點(即目標對象及 其各個子對象)，按照遍歷順序依次計算每個節點的正則結果並連接起來。
其中，對子樹的某一節點計算正則結果的方法為先計算該節點的子節點 數的HASH值，然後再依次計算該節點類型及其各個屬性的HASH值並按順序 連接在該節點的子節點數的HASH值的後面，再計算該連接結果的HASH值， 得到該節點的正則結果。如果需要對子樹中的某個節點引用的對象也一起做籤 名，則可以將該節點引用的對象也作為該節點的一個子節點來處理，方法同上。
這裡不再贅述。
在上述正則化過程中，可以把計算一個節點正則結果的方法改成如下方案 將該節點的子節點數、類型及其各屬性用分隔符隔開後按照順序連接起來，計 算該連接的結果的HASH值，得到該節點的正則結果。還可以把計算一個節點 正則結果的方法改成如下方案將該節點的子節點數、類型及其各屬性的長度 用分隔符隔開後按照順序連接起來，再與子節點數、類型、各屬性連接起來， 即得到該節點的正則結果。總之，計算一個節點正則結果的方法可以採用以下 各種方案中的任意一種對樹的某一節點，其子節點數、類型、各屬性，子節 點數/類型/各屬性的長度(可選的)，原值或經過特定變換(如HASH、壓縮), 按照預定順序連接起來(直接連接或用分隔符隔開)。上述預定順序的意思是，子節點數長度、類型長度、各屬性長度、子節點 數、類型、各屬性可以按任意順序排列，只要是預定的順序即可。
另外，在遍歷子樹中各個節點時，既可以釆用深度優先遍歷也可以採用寬 度優先遍歷。
不難給出上述方案的各種變化方式，如每個結點的子結點數用分隔符隔開 後按照深度優先的順序連接起來，再與各結點其它數據的正則結果連接起來。 總之，只要對該子樹中的所有結點的子結點數、類型和各屬性，按照確定的方 法排列在一起就屬於本實施例的變化。
當對某一對象設置權限時，最簡單的實現方式是簡單記錄各角色對該對象 (及其子對象)的權限，並在今後各角色訪問時加以比較，符合權限的則允許 相應操作，否則報錯返回。更好的實現方式是對相應數據加密，並用密鑰來控 制權限，如果該角色沒有相應密鑰就沒有對應的權限，這種方式抗攻擊能力要
更強。具體方案為
a) 對受保護的數據區域(通常為一個子樹，對應某對象及其所有子對 象)，有一對對應的PKI密鑰對，用其中的加密密鑰對該數據區域進行加密。
b) 對具有讀權限的角色，授予其解密密鑰，該角色可以用該密鑰解密該 數據區域，從而正確讀取這些數據。
c) 對具有寫權限的角色，將授予其加密密鑰，該角色可以將修改後的數
據用該密鑰加密，〃Mv而可以正確寫入該區域的悽t據。
d) 鑑於PKI的加密/解密效率較低，為提高運行效率，也可以用對稱 密鑰來對該數據區域加密，加密密鑰用於對該對稱密鑰進行加密，解密密鑰用 於解密經過加密後的密鑰數據，從而獲得正確的對稱密鑰。為防止只有讀權限 的角色在獲得對稱密鑰後用其修改數據，可以用加密密鑰來對該數據區域進行 數字籤名，每次擁有寫權限的角色修改該數據區域後都重新做一次籤名，從而 確保數據不會被沒有寫權限的角色篡改。
e) 當授予某一角色加密密鑰或解密密鑰時，可以用該角色的公鑰對該密 鑰加密後存儲，這樣只有擁有該角色的私鑰時才能取出該密鑰需要說明的是，本發明中所說明的文檔安全技術，如基於角色的權限管理、 角色的認證方式、多重角色登陸、對樹結構的正則化技術、細粒度的權限管理 單元、基於加密的權限設置等，都不僅適用於本發明所述的文檔處理系統，還 可以運用於更為廣泛的其它應用場合。
對層的管理
在本發明中，為了使本文檔處理系統能很好地模擬紙張的特性，提供了一 種"只加不改"的技術方案。也就是說，每個應用軟體都只在現有文檔內容基礎 上添加新的內容，但不修改、不刪除已有的內容，使文檔的一個頁面就象一張 紙一樣，可以由不同的人用不同的筆在紙上不斷寫寫畫畫，但誰都不能》務改、 刪除已有內容。具體方法是每一個應用軟體在編輯其它軟體生成的文檔時，都 在現有文檔基礎上新增加一層，將本軟體新編輯的內容都放到這一層中，不修 改和刪除前面各層的內容。這樣，每個文檔的每一層只由一個應用軟體來管理 和維護，其他應用軟體不能對該層進行編輯。由於現有社會就是基於紙張來運 轉的，因此只要能符合紙張的特性就能滿足現有應用的需求，具備足夠的實用 價值。
為了確保每一層內容在生成後沒有被修改、刪除，可以利用每一層的數字 籤名對象。數字籤名可以是對本層內容進行籤名，優選地，可以是對本層以及 本層之前生成的所有層的內容一起籤名。籤名以後並不妨礙對文檔做進一步的 批註等編輯，只要新的內容是位於新建的層，沒有修改破壞籤名時存在的各層， 籤名依然是有效的，但籤名者只對籤名以前的內容負責，不對籤名以後的內容 負責。這是一個非常符合應用需求的技術方案，具有很大的實用價值。相比之 下，現有的其它技術或者籤名後不允許編輯，或者編輯後(儘管是"只加不改" 的編輯)籤名被破壞。
前述技術方案不允許修改文檔中的已有內容，即使不考慮與紙張特性的兼 容以及數字籤名問題，需要修改的話也只能做版面級編輯，即對每個版面對象 的編輯(增、刪、改)都不會對其它版面對象產生影響(這是由於通用文檔才莫
型是基於可見部分為基礎構建的，不包含大量不可見的、關於版面對象之間的關係，因此修改任何一個版面對象時，其它版面對象不會產生相應的調整，例 如刪掉一個字，就會在其位置留下空白，右邊的文字不會自動左移)。如果用 戶需要對文檔中的已有內容進行編輯，並且還希望能像在原來那樣編輯的話， 有一個技術方案可以很好地滿足這個應用需求。該方案是當應用軟體完成初始
編輯時，除了新建一層存;^文當前編輯的內容外，還將源文件(按照應用軟體自 有的格式存儲，記錄了各對象之間完整關係的文件，例如.doc文件)嵌入到文
檔中。當下次需要進行繼續編輯時，/人文檔中取出該源文件，並使用該源文件 繼續編輯。編輯完成後清除該軟體所管理的那一層，重新生成該層的內容，並 繼續將新修改的源文件嵌入到文檔中。
具體方法如下
1. 應用軟體第一次處理該文檔時，新建一層，將新編輯內容對應的版面對 象插入到新建層中，同時用自身格式另存一J分新編輯的內容(即源文件)。
2. 在文檔對象中新建一個源文件子對象，用來嵌入源文件(例如用二進位 數據的方式整體嵌入)，並記錄是哪一層對應該源文件對象。
3. 用同 一應用軟體再次編輯該文檔時， >夂人對應的源文件對象中取出對應的 源文件。
4. 使用該源文件繼續編輯該層內容。由於該源文件是該應用軟體自身的格 式，可以按照該應用軟體自身的功能繼續對該層內容進行編輯。
5. 再次編輯結束後，根據新編輯後的結果更新該層內容(例如用全部清除 後全部重新生成的方式)，同時將新^修改後的源文件重新嵌入到文檔對象中。
6. 如此循環往復，就可以用原有應用軟體按照原有方式對文檔中的已有內 容進行編輯。
採用上述技術方案，可以最大程度地實現文檔的互操作性。在應用軟體、 文檔都採用本發明技術時，在有足夠安全權限的前提下，可以實現以下功能
1. 對任何文檔，用任何應用軟體都可以正確打開、顯示、列印。
2. 對任何文檔，用任何應用軟體都可以新添加任何內容，而且不會破壞文 檔已有籤名。3. 對任何文檔，在不必考慮文檔已有籤名(沒有籤名或者雖有籤名但允許
4. 對任何文檔，使用文檔已有內容的原始編輯軟體可以對該內容進行正常
由此可見，通過本發明中對層的管理，對文檔的管理、互操作、安全設置 都帶來極大的便利。
下面以A軟體創建一個文檔並且B軟體對其進行編輯為例說明其工作過 程。在本例中選用UOI作為接口標準
1. A軟體發出指令,創建文檔庫c:\sample\mydocbase.sep，將其句柄存放 在hDocBase:
UOI—Open("c:WsampleWmydocbase.sep", TRUE, &hDocBase);
2. A軟體發出指令,在文檔庫hDocBase中新建文檔集，將其句柄存放在 hDocSet:
hDocSet = InsertNewObj(hDocBase, 0, UOI—Obj:: TYPE—DOCSET);在本實例中， 該文檔庫中只有一個文檔集，即第一個文檔集；
3. A軟體發出指令,在文檔集hDocBase中新建文檔，將其句柄存;^文在 hDoc:
hDoc = InsertNewObj(hDocSet, 0, UOI—Obj:: TYPE—DOC);在本實例中，該文檔 集只有一個文檔，即第一個文檔；
4. A軟體發出指令，在文檔hDoc中新建一頁，版心大小是寬w,高h,將 其句柄存放在KPage:
UOI—Page page; page.size.w畫 w; page.size.h =
UOI_Insert(hDoc, 0, &page, &hPage);在本實例中，該文檔中只有一頁，即第一
頁；
5. A軟體發出指令，在頁hPage中創建一層，將其句柄存放在hLayer:hLayer = InertNewObj(hPage, 0, UOI—Obj::TYPE—LAYER);在本實例中，該頁只 有一層，即第一層；
6. A軟體發出指令，設置字號為s: UOI—CharSize charSize; charSize.m—Width ■— charSize.m—Height — s;
UOI—Insert(hLayer, 0, &charSize);在本實例中，該層的第一個版面對象是字號
對象；
7. A軟體發出指令,在坐標(xl,yl)位置插入文字串"書生意氣揮斥方遒" UOI—Text text;
text.m_pText = Duplicate("書生意氣揮斥方遒")； text.m—Encoding = UOI—Text:: ENCODE—GB13000; text.m—Start.x = xl; text.m一Start.y = yl;
UOI—Insert(hLayer, 1, &text);在本實例中，該層的第二個對象是文字對象；
8. A軟體發出指令,關閉文檔庫hDocBase: UOI—Close(hDocBase);
B軟體發出指令,打開文檔庫c:\sample\mydocbase.sep，將其句柄存放在
hDocBase:
UOI—Open("c:WsampleWmydocbase.sep", FALSE, &hDocBase);
B軟體發出指令,獲取文檔庫hDocBase第一個文檔集的指針，將其句柄存 放在hDocSet:
UOI—GetHandle(hDocBase, 0, &hDocSet);
9. B軟體發出指令,獲取文檔集hDocSet第 一個文檔的指針，將其句柄 存放在hDoc:
UOI—GetHandle(hDocSet, 0, &hDoc);
10. B軟體發出指令,獲取文檔hDoc第一頁的指針，將其句柄存放在 hPage:
UOI—GetHandle(hDoc, 0, &hPage);11. B軟體獲取該頁版面位圖，用於顯示該頁
UOI—GetPageBmp(hPage， rect, buf);
12. B軟體發出指令,獲取hPage第一層的指針，將其句柄存放在hLayer: UOI—GetHandle(hPage, 0, &hLayer);
13. B軟體發出指令，獲取第一個版面對象的句柄hObj: UOI—GetHandle(hLayer, 0， &hObj);
14. B軟體發出指令,獲取hObj的類型 UOI—GetObjType(hObj， &type);
15. B軟體發現這是一個字號對象，獲取該對象 UOI—GetObj(hObj, &charSize);
16. B軟體將字高放大一倍 charSize.m—Height *= 2; UOI一SetObj(hObj, &charSize);
B軟體重新獲取版面位圖並顯示，這時會發現屏幕上的"書生意氣揮斥方 遒"變成長體字了 。
本發明改變了從用戶界面到文檔存儲都由一個軟體來完成的現狀，將其劃 分為應用層和文檔庫系統層，並定義一個規範兩層之間交互的接口標準，還可 以進一步構建一個符合該接口標準的接口層。文檔庫系統是具備各種文檔操作 功能的通用技術平臺，應用軟體要對文檔進行操作時就通過該接口層來向文檔 庫系統發出相應指令，文檔庫系統根據該指令執行相應操作。這樣，只要各應 用軟體和各文檔庫系統都遵循同樣的標準，不同應用軟體就可以通過同 一個文 檔庫系統對同一文檔操作，即可實現對文檔的互操作。同樣，同一個應用軟體 也可以通過不同文檔庫系統對不同文檔進行操作，而不用分別對每種文檔格式 都進行單獨開發。
本發明還包括一個通用文檔模型，該模型能與各應用軟體所需要處理的文 檔相符合。接口標準就是基於該文檔模型來確定的，這樣才能實現不同的應用 軟體都可以通過接口層來對文檔進行操作。該通用文檔^t型也適用於各種文檔格式，這樣同 一個應用軟體才可以通過接口層來對不同文檔格式進行操作。接口標準定義了基於該通用文檔模型對文檔進行操作的各種指令，以及應用軟體向文檔庫系統發送指令的方式。文檔庫系統具備實現這些指令的功能，以供應用軟體調用。該通用文檔模型還包括由多個文檔組成的文檔集、文檔庫和文檔倉庫等層次，接口標準中也包含對多文檔的組織管理、查詢檢索、安全控制等指令。該通用模型還包括將頁由具有上下順序的層組成，接口標準中也包含對層 的各種操作指令，以及對一個文檔某一層所對應源文件的存儲和提取。文檔庫系統還具備對文檔的信息安全管理控制功能，如基於角色的細粒度 權限管理，並在接口標準中定義了相關的操作指令。依照本發明，使得應用層和數據處理層分離。這樣應用軟體不再直接跟具 體的文檔格式打交道，文檔也不再與特定應用軟體綁定，從而使得同一文檔能 在不同的應用軟體之間通用，同一應用軟體也能對不同文檔進行操作，實現了文檔的互操作；整個文檔處理系統還具備多文檔處理功能，而不局限在單文檔 處理；將頁分成多層後，可以實現對不同層實施不同管理和控制，更便於不同 應用軟體對同 一頁的操作(可以設計成不同應用軟體管理和維護不同層)，為以 源文件方式進行編輯提供了便利，也是一種很好的保留歷史痕跡的方式；通過 將信息安全集成在文檔處理的核心層，可以消滅安全縫隙，還能使安全機制與 文檔操作緊密地結合為一體，而不是可以分離的兩個it塊，同時有更多的空間 部署安全管理技術，相關代碼也能隱藏得更深，能更有效地防禦非法攻擊，提 高安全可靠度，另外還能提供細粒度的安全管理手段，如更多的權限類別，更 小的管理單元。下面，參照圖18描述依照本發明的文檔作業系統執行一操作的一個實例。 在該實例中，應用軟體通過統一的接口標準(例如UOML接口 )請求對文檔的 操作。文檔庫系統可能會有不同廠商的不同型號，但是對於應用開發廠商來說 面向的都是同一個接口標準，因此都可以與之配套使用。RedOffice、 OCR、網 頁生成軟體、樂語編輯軟體、書生閱讀器、Office編輯軟體、其他閱讀器等通過UOML接口指示文檔庫系統進行操作，文檔庫系統可以有多個，在圖中顯示 為文檔庫系統1 、文檔庫系統2和文檔庫系統3 ，文檔庫系統根據UOML發來 的統一標準指令對符合通用文檔模型的文檔進行操作，例如創建、保存、顯示、 呈現文檔。在本發明中，不同的應用軟體可以同時或不同時調用同一個文檔庫 系統，同一應用軟體可以同時或不同時調用不同的文檔庫系統。依照本發明，使得應用層和數據處理層分離，使得同一文檔能在不同的應 用軟體之間通用，使不同應用軟體之間具有良好的文檔互操作性。依照本發明，形成產業分工，減少重複開發，並更加專業、完備、正確； 對文檔的基本操作都在文檔庫系統中處理，各應用軟體不必重複開發。而且由 於文檔庫系統是由專業廠商開發，相關技術的專業性、完備性、正確性較有保 障，而且應用軟體廠商和用戶可以選擇估支的最好的一家文檔庫系統廠商，從而 保證處理效果的正確性和 一致性。依照本發明，提供多文檔甚至海量文檔的管理機制，使文檔之間能夠有效 組織起來，便於檢索、查詢、保管，便於嵌入較強的信息安全機制。依照本發明，提供更好的安全機制，可以設置多種角色，細粒度地設置每 個角色的權限。其中細粒度是雙重的， 一方面可以對整個文檔或文檔的一個細 微之處進行權限設置，另一方面可以設置種類非常多的權限，而不僅僅是傳統 的讀/寫/不可訪問三級。依照本發明，鼓勵創新，合理竟爭。形成合理的產業分工後，各文檔庫系 統廠商和各應用軟體廠商就會在領域展開竟爭，而不會再出現Microsoft Word 一樣靠文檔格式來壟斷應用軟體的情形發生。各文檔庫系統廠商也可以在標準 之外增加新的功能以吸引用戶，標準並不會對創新形成束縛。依照本發明，便於優化性能，有更好的可移植性和可伸縮性。無論是什 麼平臺，什麼樣的性能，都可以遵循同樣的調用接口 ，使得在不改變接口標 準的情況下可以不斷優化性能，並移植到不同的平臺。以上所述僅為本發明的較佳實施例而已，並不用以限制本發明，凡在本 發明的精神和原則之內所作的任何修改、等同替換和改進等，均應包含在本發明的保護範圍之內。
權利要求
1、一種文檔處理方法，其特徵在於，包括應用軟體發送指令到平臺軟體，以對抽象非結構化信息進行操作；平臺軟體接收到來自所述應用軟體的指令，根據所述指令，對與所述抽象非結構化信息對應的存儲數據執行所述操作；其中，所述抽象非結構化信息與所述存儲數據的存儲方式無關。
2、 如;k利要求1所述的方法，其特徵在於，所述抽象非結構化信息不具有 存儲。
3、 如權利要求l所述的方法，其特徵在於，所述抽象非結構化信息包括可 視化信息、和/或流媒體信息、和/或多維信息、和/或安全控制信息、和/或文檔 組織4言息、和/或交互4言息。
4、 如權利要求l所述的方法，其特徵在於，通過發送命令串或調用函數來 發送指令。
5、 如權利要求l所述的方法，其特徵在於，所述存儲數據為一個或多個磁 盤文件、部分磁碟文件、資料庫的一個或多個欄位、或磁碟分區的一個區域。
6、 如權利要求l所述的方法，其特徵在於，所述抽象非結構化信息包括多 個頁的可視化信息。
7、 如權利要求l所述的方法，其特徵在於，所述抽象非結構化信息符合預 定義文檔^t型。
8、 如權利要求l所述的方'法，其特徵在於，所述預定義文檔模型為樹形結 構，並且包括至少文檔對象、頁對象以及用於描述版面的對象。
9、 如權利要求8所述的方法，其特徵在於，所述用於描述版面的對象可以 是文字對象、圖片對象和圖形對象中的任一項或任幾項的組合。
10、 如權利要求9所述的方法，其特徵在於，所述用於描述版面的對象還 可以是狀態對象、文字對象、直線對象、曲線對象、圓弧對象、路徑對象、漸 變色對象、圖像對象、流媒體對象、元數據對象、批註對象、語義信息對象、源文件對象、腳本對象、插件對象、二進位數據流對象、書籤對象以及超連結 對象中任一項或任幾項的組合。
11、 如權利要求8所述的方法，其特徵在於，所述預定義文檔模型進一步包括文檔庫對象，所述文檔庫對象包括至少一個文檔對象；或者，所述預定義^t型進一步包括文檔庫對象和文檔集對象，其中所述文檔庫對 象包括至少一個文檔集對象，所述文檔集對象包括至少一個文檔對象和\或至少 一個文檔集對象。
12、 如權利要求8所述的方法，其特徵在於，所述預定義文檔^t型進一步 包括層對象，所述頁對象包括至少一個層對象，所述層對象包括至少一個用於 描述版面的對象。
13、 如權利要求12所述的方法，其特徵在於，所述預定義文檔模型進一步 包括對象組對象，所述層對象包括至少一個對象組對象，所述對象組對象包括 至少一個用於描述版面的對象。
14、 如權利要求7所述的方法，其特徵在於，所述預定義文檔^f莫型進一步 包括角色對象以及角色的訪問權限。
15、 如權利要求14所述的方法，其特徵在於，所述角色的訪問權限包括所 述角色針對所述抽象非結構化信息的至少一個對象的訪問權限。
16、 如權利要求l所述的方法，其特徵在於，所述指令符合操作動作+操 作對象的標準，以指示一個4喿作。
17、 如權利要求16所述的方法，其特徵在於，所述操作包括獲取信息、 設置對象屬性、插入對象、刪除對象以及查詢。
18、 如權利要求16所述的方法，其特徵在於，所述指令按預定義的格式生成。
19、 如權利要求18所述的方法，其特徵在於，所述指令包含描述操作動作 和操作對象的字符串。
20、 如權利要求19所述的方法，其特徵在於，所述字符串用可擴展標記語 言XML描述。
21、 如權利要求20所述的方法，其特徵在於，所述操作動作對應一個XML 元素，所述操作對象通過句柄handle引用。
22、 如權利要求16所述的方法，其特徵在於，所述平臺軟體提供接口函數， 每個接口函數定義針對一個對象的一個操作；所述應用軟體通過調用與所述操作動作和操作對象對應的接口函數，發送 所述指令。
23、 如權利要求16所述的方法，其特徵在於，所述平臺軟體提供基於對象 類的方法；所述應用軟體通過調用所述對象類的方法發送指令；其中所述對象類由所 述操作對象封裝而成，所述對象類的方法對應所述操作動作。
24、 如權利要求l所述的方法，其特徵在於，所述平臺軟體進一步為應用 軟體提供操作結果。
25、 —種文檔處理系統，其特徵在於，包括應用軟體，用於發送指令到平臺軟體，以對抽象非結構化信息進行操作； 平臺軟體，用於接收到來自所述應用軟體的指令，根據所述指令，對與所 述抽象非結構化信息對應的存儲數據執行所述操作；其中，所述抽象非結構化信息與所述存儲數據的存^f諸方式無關。
26、 一種文檔處理方法，其特徵在於，包括 第一應用軟體發送第一指令到平臺軟體，以創建第一抽象文檔；所述平臺軟體接收所述第 一指令，創建與所述第 一抽象文檔對應的存儲數據；第二應用軟體發送第二指令到所述平臺軟體以打開所述創建的存儲數據； 所述平臺軟體接收所述第二指令，打開並解析所述存儲數據，生成與所述 存儲數據對應的第二抽象文檔；其中所述第 一指令與第二指令符合相同的接口標準。
27、 一種文檔處理系統，其特徵在於，包括第一應用軟體，用於發送第一指令到平臺軟體，以創建第一抽象文檔；所述平臺軟體，用於接收所述第一指令，創建與所述第一抽象文檔對應的存儲數據；第二應用軟體，用於發送第二指令到平臺軟體以打開所述創建的存儲數據； 所述平臺軟體，進一步用於接收所述第二指令，打開並解析所述存儲數據， 生成與所述存儲數據對應的第二抽象文檔；其中，所述第一指令與第二指令符合相同的接口標準。
28、 一種文檔處理方法，其特徵在於，包括第一平臺軟體解析以第一數據格式存儲的第二存儲數據，生成與所述存儲 數據對應的第 一抽象文檔；所述應用軟體發送第 一指令到所述第 一平臺軟體，以獲取所述第 一抽象文 檔的所有信息；發送第二指令到第二平臺軟體，以創建與所述第一抽象文件相 同或相似的第二抽象文檔；所述第二平臺軟體根據所述第二指令，創建與所述第二抽象文檔對應並按 第二數據格式存儲的第二存儲數據；其中，所述第一指令和第二指令符合相同的接口標準。
29、 一種文檔處理系統，其特徵在於，包括第一平臺軟體，用於解析以第一數據格式存儲的第一存儲數據，生成與所 述存儲數據對應的第 一抽象文檔；所述應用軟體，用於發送第一指令到所述第一平臺軟體，以獲取所述第一 抽象文檔的所有信.息；發送第二指令到第二平臺軟體，以創建與所述第一抽象 文件相同或相似的第二抽象文檔；所述第二平臺軟體，用於根據所述第二指令，創建與所述第二抽象文檔對 應並按第二數據格式存儲的第二存儲數據；其中，所述第一指令和第二指令符合相同的接口標準。
全文摘要
本發明公開了一種文檔處理系統和方法，該方法包括應用軟體發送指令到平臺軟體，對抽象非結構化信息進行操作；平臺軟體接收到來自所述應用軟體的指令，根據所述指令，對與所述抽象非結構化信息對應的存儲數據執行所述操作；其中，所述抽象非結構化信息與所述存儲數據的存儲方式無關。本發明的這種系統和方法將應用層和數據處理層分離，有利於產業分工，以及達到文檔互操作、信息資源互聯互通等有益效果。
文檔編號G06F9/44GK101599011SQ20081011445
公開日2009年12月9日 申請日期2008年6月5日 優先權日2008年6月5日
發明者劉寧勝, 王東臨 申請人:北京書生國際信息技術有限公司