CN101322121A

CN101322121A - 对文档实现分层处理的方法和系统

Info

Publication number: CN101322121A
Application number: CNA200680045654XA
Authority: CN
Inventors: 王东临; 郭旭; 刘昌伟; 邹开红; 陆小青
Original assignee: Sursen Corp
Priority date: 2005-12-05
Filing date: 2006-12-05
Publication date: 2008-12-10
Anticipated expiration: 2026-12-05
Also published as: CN1979472A; CN101322136A; CN101322121B; CN101322126A; US20080270463A1; CN101322136B; EP1965308A4; CN101322126B; EP1965308A1; US20130174268A1; WO2007065353A1; JP2009519507A; CN100547590C

Abstract

本发明公开了一种对文档实现分层处理的方法，所述文档分页存储，所述方法包括：对文档中页的数据分组，每组数据为一层，所述各层按顺序排列；对所述各层分别进行管理和控制。本发明还公开了一种对文档实现分层处理的系统包括：第一单元，用于分页存储所述文档；第二单元，用于对所述文档中页的数据分组，每组数据为一层，所述各层按顺序排列；第三单元，用于对所述各层分别进行管理和控制。应用上述技术方案，在文档系统中实现了对文档的分层处理，使文档的操作更加灵活。

Description

对文档实现分层处理的方法和系统

技术领域

本发明涉及文档处理技术，特别涉及一种对文档实现分层处理的方法系统。发明背景

信息可大致分为结构化数据和非结构化数据，其中以书面文档和流媒体为主的非结构化数据根据资料统计占有量超过百分之七十。结构化数据的结构比较筒单，即一个二维表结构，其处理技术以数据为代表，主要是利用数据库系统进行处理，从上世纪七八十年代开始发展，到九' 十年代达到顶峰，研发和应用已经比较成熟。非结构化数据则没有固定数据结构，因此对非结构化数据的处理非常的复杂。

目前处理各种非结构化文档的软件已经比较普及，形成了多种文档格式林立的状况。例如，文档编辑目前就存在 Microsoft的 word、 WPS, 永中的 Office、 Red的 Office等。通常，一个内容管理软件往往要处理二三百种文档格式，而且这些格式还在不断更新，给这类软件的开发带来了巨大的困难。如何解决文档通用性、进行数字内容提取、格式兼容越来越成为人们的关注点，人们迫切希望解决以下问题：

1 )文档不通用：

基本上，不同用户只能交换同一种软件处理的文档，无法交换不同软件处理的文档，形成信息封闭。

2 )访问接口不统一、数据兼容代价太高：

不同的文档处理软件之间，文件格式互不兼容，在处理过程中要么利用对方組件解析（前提是对方提供相应接口），要么自己投入研发力量从头到尾的解析对方的格式。

3 )信息安全较差：

目前针对书面文档的权限控制手段单一，主要是数据加密、口令认证。因为信息泄露，每年造成巨大损失的公司案例层出不穷。

4 )都是针对单个文档的处理，缺乏多文档管理手段：

每个人电脑中都有大量文档，但多个文档之间缺乏有效的组织管理，而且资源共享很难。如，字库 /字体文件、全文数据检索等。

5 ) ^面分层的技术不完善：

目前一些软件，如 Adobe的 photoshop, Microsoft的 word, 多多少少已经有层的概念，但层的功能还比较单一，管理手段比较简单，不能满足应用需求。

6 )检索手段不够丰富：

随着信息的海量化，用任何一个关键词来搜索都会得到数量庞大的检索结果，全文检索技术基本解决了查全率的问题，但查准率迅速上升为首要问题。现有技术还没有很充分地利用全部信息来解决查准率问题，例如每个文字的字体、字号完全可以用来判断该文字的重要性，但都在检索时被忽略了。

虽然各大公司目前都努力将自己特有的文档格式发展为市场标准，各标准组织也致力于制订通用的文档格式标准。但不管是专有的文档格式（如. doc )还是开放的文档格式（如 PDF ), 只要是以文档格式为标准，就不可避免产生以下问题：

a )重复开发，效果不统一：

使用同一标准的不同软件都需要自己去解释、生成该格式的文档，造成大量重复开发，而且会因为各家解释程序不同，例如有的完善有的相对筒单，有的支持新版本有的只支持旧版本数据，同一文档在不同软件下显现出不同的版式，甚至出现解释错误导致无法打开文档。

b ) 阻碍创新：

软件是不断创新的行业，但由于每增加一个新功能就需要增加描述该功能的信息，而且只有等到标准修订的时候才能增加新的格式，因此把存储格式固定死，将会妨碍技术创新的竟争。

c )影响检索性能：

对海量信息，需要增加大量的检索信息以提高检索性能，但固定死的存储格式难以增加检索信息

d )影响可移植性和可伸缩性：

在不同的系统环境下，不同的应用需求，可能会有不同的存储要求。例如，存储在硬盘上就需要考虑如何减少磁头寻道的次数以提高性能，而在嵌入式应用中数据都相当于存储在内存中的，就不存在这个问题。例如，同一个厂商的数据库软件在不同平台上就可能会使用不同的存储格式。因此，设置文档存储标准将会影响系统的可移植性和可伸缩性。

现有技术中最开放、可交换性最好的文档是 Adobe Acrobat的 PDF。然而，虽然 PDF已经成为全球文档分发、交换的事实标准，但也不能实现在不同的软件之间交换 PDF文档，也就是说，不能实现 PDF文档的互操作性。而且，无论是 Acrobat还是 Office, 都只能对单文档进行处理，缺乏对多文档的管理功能，不具备对文档库进行操作的功能。

另外，在文档信息安全的方面，现有技术也存在较多缺陷。 Word 和 PDF这些应用最广泛的文档，都是采用对数据加密或者口令认证等进行数据安全控制，没有提供系统的身份认证机制，对权限的控制都是整个文档范围的，不能细化到文档内的任意区域，无法对任意逻辑数据设定加密和签名。现有的内容管理系统虽然能够提供较好的身份认证机制，但由于与文档处理系统是分离的，不仅管理粒度只能做到文档级，而且无法在文档使用过程中对文档实施安全控制，难以进行必要的安全管理。由此可见，由于现有的安全机制与文档处理是分离的模块，容易出现安全缝隙。

发明内容

本发明提供了一种对文档实现分层处理的方法和系统，可以实现对文档的分层处理。

一种对文档实现分层处理的方法，其包括：

对文档中页的数据分组，每组数据为一层，所述各层按顺序排列；对所述各层分别进行管理和控制。

一种对文档实现分层处理的系统，其包括：

第一单元，用于分页存储所述文档;

第二单元，用于对所述文档中页的数据分组，每组数据为一层，所述各层按顺序排列；

第三单元，用于对所述各层分别进行管理和控制。

才艮据本发明的一方面，一种对文档实现分层处理的方法，在应用软件通过文档库系统对符合通用文档模型的文档进行操作的过程中，执行如下处理：

在该应用软件对文档进 ^亍编辑时，在该文档的页对象中插入层对象，在层对象中插入版面对象，属于同一页的各层按顺序排列；

文档库系统对所述各层分别进行管理和控制。

一种文档库系统，其包括：

第一单元，用于在对文档进行编辑时，在该文档的页对象中插入层对象，在层对象中插入版面对象，属于同一页的各层按顺序排列；第二单元，用于对所述各层分别进行管理和控制。

本法明还公开了一种文档处理系统，其包括：应用层，用于通过文档库系统对符合通用文档模型的文档进行操作；文档库系统，用于在应用层对该文档进行编辑时，在该文档的页对象中插入层对象，在层对象中插入版面对象，属于同一页的各层按顺序排列；对所述各层分别进行管理和控制。

本发明改变了从用户界面到文档存储都由一个软件来完成的现状，将其划分为应用层和文档库系统层，并定义一个规范两层之间交互的接口标准，还可以进一步构建一个符合该接口标准的接口层。文档库系统是具备各种文档操作功能的通用技术平台，应用软件要对文档进行操作时就通过该接口层来向文档库系统发出相应指令，文档库系统根据该指令执行相应操作。这样，只要各应用软件和各文档库系统都遵循同样的标准，不同应用软件就可以通过同一个文档库系统对同一文档操作，即可实现对文档的互操作。同样，同一个应用软件也可以通过不同文档库系统对不同文档进行操作，而不用分别对每种文档格式都进行单独开发。

本发明还包括一个通用文档模型，该模型能与各应用软件所需要处理的文档相符合。接口标准就是基于该文档模型来确定的，这样才能实现不同的应用软件都可以通过接口层来对文档进行操作。该通用文档模型也适用于各种文档格式，这样同一个应用软件才可以通过接口层来对不同文档格式进行操作。

接口标准定义了基于该通用文档模型对文档进行操作的各种指令，以及应用软件向文档库系统发送指令的方式。文档库系统具备实现这些指令的功能，以供应用软件调用。

该通用文档模型还包括由多个文档组成的文档集、文档库和文档仓库等层次，接口标准中也包含对多文档的组织管理、查询检索、安全控制等指令。该通用模型还包括将页由具有上下顺序的层组成，接口标准中也包含对层的各种操作指令，以及对一个文档某一层所对应源文件的存储和提取。

文档库系统还具备对文档的信息安全管理控制功能，如基于角色的细粒度权限管理 , 并在接口标准中定义了相关的操作指令。依照本发明，使得应用层和数据处理层分离。这样应用软件不再直接跟具体的文档格式打交道，文档也不再与特定应用软件绑定，从而使得同一文档能在不同的应用软件之间通用，同一应用软件也能对不同文档进行操作，实现了文档的互操作；整个文档处理系统还具备多文档处理功能，而不局限在单文档处理；将页分成多层后，可以实现对不同层实施不同管理和控制，更便于不同应用软件对同一页的操作（可以设计成不同应用软件管理和维护不同层），为以源文件方式进行编辑提供了便利，也是一种很好的保留历史痕迹的方式；通过将信息安全集成在文档处理的核心层，可以消灭安全缝隙，还能使安全机制与文档操作紧密地结合为一体，而不是可以分离的两个模块，同时有更多的空间部署安全管理技术，相关代码也能隐藏得更深，能更有效地防御非法攻击，提高安全可靠度，另外还能提供细粒度的安全管理手段，如更多的权限类别，更小的管理单元。附图简要说明图 1为文档处理系统的结构框图。

图 2示出了依照本发明一优选实施例的通用文档模型的组织结构。图 3示出了图 2所示通用文档模型中文档库对象的组织结构。图 4示出了图 3所示文档库对象中文档库辅助对象的組织结构。图 5示出了图 3所示文档库对象中文档集对象的组织结构。图 6示出了图 5所示文档集对象中文档对象的组织结构。

图 7示出了图 6所示文档对象中页面对象的组织结构。

图 8示出了图 7所示页面对象中层对象的组织结构。

图 9示出了图 8所示层对象中版面对象的组织结构。

图 10示出了接口层对执行结果的操作动作定义结构。

图 11示出了接口层对创建或打开的操作动作定义结构。

图 12示出了接口层对关闭的操作动作定义结构。

图 13示出了接口层对获取的操作动作定义结构。

图 14示出了接口层对设置的操作动作定义结构。

图 15示出了接口层对插入的操作动作定义结构。

图 16示出了接口层对删除的操作动作定义结构。

图 17示出了接口层对检索查询的操作动作定义结构。

图 18为以 UOML接口为例的文档处理系统的处理示意图。实施本发明的方式以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用于解释本发明，并不用于限定本发明。

本发明的对文档实现分层处理的方法及系统主要应用于如下所述的文档处理系统。

如图 1所示，本发明所应用的文档处理系统主要由四部分组成：应用软件、接口层、文档库系统和存储设备。

其中的应用软件包括现有的任何文档^理和内容管理软件，这些应用软件都位于文档处理系统的应用层，通过发送符合接口标准的指令来对文档进行操作，所述操作都是对符合通用文档模型的文档进行的，与具体存储格式无关。

其中的接口层符合规范应用层和文档库系统之间交互的接口标准，所述应用层通过接口层向文档库系统发送标准指令，所述文档库系统通过接口层向应用层返回执行的结果。由此可见，由于应用软件均可以通过接口层发出标准指令，对符合通用文档模型的文档进行操作，所以不同的应用软件可以通过同一文档库系统对同一文档进行操作，同一应用软件也可以通过不同文档库系统对不同格式的文档进行操作。

优选地，接口层可包括上接口单元和下接口单元，应用层通过上接口单元发送标准指令至下接口单元，文档库系统通过下接口单元接收标准指令，下接口单元还用于将文档库系统的执行结果通过上接口单元返回给应用系统。在实现上，上接口单元可位于应用层中，下接口单元可位于文档库系统中。

其中的文档库系统为文档处理系统的核心层，根据应用软件通过接口层发来的标准指令执行具体的文档处理操作。

其中的存储设备为文档处理系统的存储层，常用的是硬盘或者内存，也可以是光盘、闪存、软盘、磁带，也可以是远程的存储设备，总之只要具备数据的存储能力即可。在存储设备中存储有多个文档，但对应用软件而言并不需要关心文档的具体存储方式。

由此可见，依照本发明，使得应用层和数据处理层真正分离开来，文档不再与特定应用软件绑定，应用软件不再直接跟具体的文档格式打交道，不同的应用软件可以对符合通用文档模型的同一文档进行编辑，使不同应用软件之间具有良好的文档互操作性。

通用文档模型

可参考纸张的特性定义所述通用文档模型，这是因为以纸张作为文档信息的记录手段是通行至今的标准方法，只要能具备纸张的所有功能，就能满足工作、生活等实际应用的需求。

如果把文档中的一页当成一张纸，凡是能画到纸上的就记录下来，该通用文档模型能够描述页面上的所有可见内容。现有技术中的页面描述语言（如 PostScript )可以描述所有能印在纸上的信息，因此这一部分就不再详细阐述。一^:说来，页面上的可见内容最终都可以归为文字、图形、图像三类。

如果文档中涉及到特定字体或特殊字符的话，为了保证在各台电脑上都能有相同的效果，就需要在文档中嵌入相应字库。为了提高存储效率，字库资源应当共享，这样即使在多处使用了同一字符，也只需要嵌入一个字库。图像有时也是可能在多处出现的，例如每一页共同的底图，或经常出现的公司标识，这种情况下最好也能共享这些图像。

当然，作为更加先进的信息处理工具，不能仅仅模拟纸张的特性，还需要增加一些增强的数字特性，例如元数据、导航、导读、微缩版面。元数据是描述数据的数据，例如作者、出版社、出版时间、 ISBN号等就是图书的元数据。元数据是业内通用名词，也不在此赘述。导航是类似图书目录的信息，也是业内通用名词。导读信息描述了一篇文章所在的区域和阅读顺序，这样当阅读者读完一屏后就可以才艮据该信息自动判断下一屏应该显示什么，这样还能做到自动换栏、自动转版，而不用阅读者再手工指定位置。微缩版面是事先生成的各页面的微缩图，阅读者可以通过查看^ ί敖缩版面来指定阅读哪一页。

图 2是根据一优选实施例的通用文档模型。如图 2所示，该通用文档模型包含文档仓库、文档库、文档集、文档、页、层、对象组、版面对象等多个层次。

其中，文档仓库由一个或多个文档库组成，文档库之间的关系相对于文档库之下的层次之间的关系相对要松散一些 , 文档库之间可以非常简单地组合和拆离，而不用对文档库本身的数据做改动，该多个文档库之间往往没有建立统一索引（特别是全文索引），很多对文档仓库的检索操作一般都需要遍历各文档库的索引，而没有统一的索引可用。每个文档库由一个或多个文档集组成，每个文档集由一个或多个文档组成，还可以包含任意数量的子文档集。这里所说的文档相当于目前普通的一个文档文件（例如 DOC文档），通用文档模型可以规定一个文档只能属于一个文档集，但也可以允许一个文档属于多个文档集。文档库不是多个文档的简单组合，它把多个文档紧密地组织起来，特别是为文档内容统一建立了各种检索索引后就能带来更大的便利性。

每个文档由一页或存在一定顺序（如前后顺序）的多页组成，每页的版心可以不同，而且版心也不一定是矩形的，可以是任意形状，可以用一条或多条封闭曲线表示版心。

每页又由一层或按一定顺序（如上下顺序）的多层组成，各层之间如同玻璃板的叠加关系。层由任意数量的版面对象和对象组组成，版面对象是指状态（如字体、字号、颜色、 ROP等）、文字（包括符号）、图形（如直线、曲线、填充了指定颜色的闭合区域、渐变色等）、图象 (如 TIF、 JPEG、 BMP, JBIG等）、语义信息（如标题开始、标题结束、换行等）、源文件、脚本、插件、嵌入式对象、书签、链接、流媒体、二进制数据流等。一个或多个版面对象可以组成一个对象组。对象组也可以包含任意数量的子对象组。

文档库、文档集、文档、页、层都可以还包括元数据（如名称、最后修改时间等，其类型可以根据应用需求来设置）和 /或历史痕迹；文档中还可以包括导航信息、导读信息、微缩版面；也可以把微缩版面放在页或者层这个层次；文档库、文档集、文档、页、层、对象组都可以还包括数字签名；语义信息最好跟着版面信息走，这样可以避免数据冗余，也比较容易与版面建立对应关系；文档库、文档还可以包括字库、图像等共享资源。

该通用文档模型还可以定义一个或多个角色，为每个角色分配一定权限。权限以文档库、文档集、文档、页、层、对象组、元数据为单元进行分配，定义每个角色对该单元是否可读、是否可写、是否可复制、是否可打印，等等。

该通用文档模型是一个超越以往单个文档对应单个文件的方式，文档库中包含多个文档集、文档集中包含多个文档，而对于文档库中文档内容，采用了细粒度的访问和安全控制，可以具体访问文档库中某个文字或者矩形，而不像现在的文档管理系统只能访问到文件名。

图 3至图 9示出了根据一优选实施例的通用文档模型所涉及的各对象的组织结构示意图。所述的各对象的组织结构是树状结构，是逐层展开、细化的。

文档仓库对象是由一个或多个文档库对象组成（图中未示出）。如图 3所示，文档库对象包括一个或多个文档集对象、任意数量文档库辅助对象和任意数量的文档库共享对象。

如图 4所示，所述的文档库辅助对象包括元数据对象、角色对象、权限对象、插件对象、索引信息对象、脚本对象、数字签名对象、历史痕迹对象等。文档库共享对象是指文档库中的不同文档可能共享的对象，如字库对象、图像对象等。

如图 5所示，每个文档集对象包括一个或多个文档对象、任意数量的文档集对象和任意数量的文档集辅助对象。文档集辅助对象包括元数据对象、数字签名对象、历史痕迹对象。当文档集对象包括多个文档集对象时，其类似于资源管理器中的文件夹包括多个文件夹的形式。

如图 6所示，每个文档对象包括一个或多个页面对象、任意数量的文档辅助对象和任意数量的文档共享对象。文档辅助对象包括元数据对象、字库对象、导航信息对象、导读信息对象、微缩版面对象、数字签名对象、历史痕迹对象等。文档共享对象包括文档中的不同页面可能共同使用.的对象，如图像对象、印章对象等。

如图 7所示，每个页面对象包含一个或多个层对象和任意数量的页面辅助对象组成。页面辅助对象包括元数据对象、数字签名对象、历史痕迹对象。

如图 8所示，每个层对象包括一个或多个版面对象、任意数量的对象组和任意数量的层辅助对象。层辅助对象包括元数据对象、数字签名对象、历史痕迹对象。对象组包括任意数量的版面对象、任意数量的对象组和可选的数字签名对象。当对象组包括多个对象组时，其类似于资源管理器的文件夹包括多个文件夹的形式。

如图 9所示，版面对象包括状态对象、文字对象、直线对象、曲线对象、圆弧对象、路径对象、渐变色对象、图像对象、流媒体对象、元数据对象、批注对象、语义信息对象、源文件对象、脚本对象、插件对象、二进制数据流对象、书签对象以及超链接对象。

其中，状态对象包括任意数量的字符集对象、字体对象、字号对象、文字颜色对象，光栅操作对象、背景色对象、线颜色对象、填充色对象、线型对象、线宽对象、线接头对象、画刷对象、阴影对象、阴影颜色对象、旋转对象、空心字对象、勾边字对象、透明对象和渲染模式对象。

在具体实施过程中，可以在上述通用文档模型基础上进一步增强或简化。如果在筒化模型中省略了文档集对象，则文档库对象直接由文档对象组成；如果在筒化模型中省略了层对象，则页面对象直接由版面对象组成。

可以理解，最简化的通用文档模型是仅包含文档对象、页面对象和版面对象。其中版面对象仅包括文字对象、直线对象和图像对象。完整模型和最简化模型之间的各种中间模型都属于本优选实施例的变形。

通用文档安全模型：为了满足各种应用对文档安全性的需求，还需要定义一种通用的文档安全模型，以解决由于现有软件的文档安全功能不够强，或者是安全管理机制与文档处理模块脱节所导致的安全缝隙。根据本发明一优选实施例，通用文档安全模型包括：

1. 角色对象。在文档库中定义若干角色，角色对象通常是文档库对象的子对象。如果对应的通用文档模型中没有文档库对象，则角色是在文档中定义的，即角色对象是文档对象的子对象，此时本通用文档安全模型中所说的文档库均用文档替代。

2. 指定角色的访问权限。可以指定任意角色对任意对象（例如文档库、文档集、文档、页、层、对象组、版面对象等）的访问权限。如果指定了某角色对某个对象的访问权限，则该权限适用于该对象的所有子对象。

其中，文档库系统实现的访问权限包括是否可读、是否可写、是否可再授权（即：使其他角色拥有自己的部分或全部权限）、是否可收回授权（即：去掉其他角色的部分或全部授权），及上述几种的任意组合。也可以定义其他需要由应用软件来配合实现的权限，如不可打印。

3. 使用角色的身份进行对象签名。角色可以对任意对象进行签名。签名范围包括该对象的子对象, 以及该对象所引用到的对象。

4. 创建角色。创建角色对象的指令的执行结果是向应用软件返回一个密钥, 作为应用软件以该角色身份登录的依据, 该密钥通常是 PKI 的私钥，由应用软件保管，该密钥也可以是登录口令。优选地，任何应用软件都有权创建没有任何权限的新角色。可以用具有再授权权限的角色对新角色授予一定的权限。

5. 角色身份登录。当应用软件以某一角色身份登录时, 通常采用 "挑战 -应答 "机制，即文档库系统用保存的角色公钥加密一块随机数据发给应用软件，应用软件解密后返回给文档库系统，如果解密正确，则表明应用软件确实拥有该角色对应的私钥。 "挑战-应答"机制也可以用以下方式实现，文档库系统将一块随机数据发给应用软件，应用软件用私钥加密后返回给文档库系统，文档库系统用保存的角色的公钥解密，如果解密正确，则表明应用软件确实拥有该角色对应的私钥。为保险起见，该认证过程可能会重复几次。采用"挑战-应答"机制可以更好地保护私钥的安全性。如果角色的密钥是登录口令，则需要用户输入正确的登录口令。另外，应用软件可以同时以多个角色登录，此时该应用软件所拥有的权限是该多个角色权限的并集。

6. 缺省角色。可以创建一个特殊的缺省角色。当存在缺省角色时，即使不以任何角色登录也能以缺省角色身份对文档库进行操作。优选地，文档库初始创建时就自动创建一个拥有所有权限的缺省角色。

在具体实施过程中，可以在上述通用安全模型基础上进一步增强或简化。针对上述安全模型的任何筒化模型都是本实施例的变形。

接口层

所述接口层的统一标准可根据通用文档模型、通用安全模型和常用的文档操作而定义，用于发送对通用文档模型中各对象进行操作的指令。所述的对通用文档模型中各对象进行操作的指令符合接口标准，各种应用软件可以通过接口层发出标准指令。

现在介绍接口标准的实现方式。接口标准的实现可以是上接口单元按照预先定义的标准格式生成命令串 , 例如" <UOML— INSERT (OBJ=PAGE₅ PARENT=123.456.789, POS=3) /> ", 将该命令串发送给下接口单元 , 并从下接口单元接收文档库系统对该命令的执行结果或其它反馈信息；或者接口标准的实现是下接口单元提供一些具有标准名称和参数的接口函数，例如： "BOOL UOIJnsertPage (UOI— Doc *pDoc, int nPage)", 上接口单元调用这些标准函数，调用操作本身就代表上接口单元发出了标准指令；或者是上述方法的组合。

接口标准采用 "操作动作 +操作对象"的方式来实现便于学习和理解，也便于保持接口标准的稳定性。例如，对 20种不同对象进行 10种操作，可以定义 20x10=200种指令，也可以定义 20种对象和 10种动作，但显然后一种方式大大减轻了记忆的负担，而且今后在对接口标准进行扩充时，增加一个对象或动作也很简单。所述操作对象为通用文档模型所包含的对象。

例如 , 定义以下 7种操作动作：

打开用于创建或打开文档库；

关闭用于关闭会话句柄、关闭文档库;

获取用于获取对象列表、对象相关属性和数据;

设置用于设置 /修改对象数据；

插入插入指定对象或数据；

删除用于删除对象的某个子对象；

检索查询: 用于根据定义条件在文档中找到符合条件的内容, 这些条件既可以是准确的信息，也可以是不准确的信息，即模糊查找。

定义如下对象：文档库、文档集、文档、页、层、对象组、文字、图像、图形、路径（由一组顺序图形连接组成，可以是闭合也可以不闭合的）、源文件、脚本、插件、音频、视频、角色等。

对象还包括下列状态对象: 背景色、线的颜色、填充色、线型、线宽、 ROP、画刷、阴影、阴影颜色、字符高、字符宽、旋转、透明、渲染模式等。

可以理解，在采用 "操作动作 +操作对象，，方式实现接口标准时，不能自动理解为每一个对象和每一个动作的所有组合都一定能构成有实际意义的操作指令，一些組合是没有意义的。

还可以用非"操作动作 +操作对象"的函数方式来定义接口标准，例如对每一个对象的每一种操作都定义一个接口函数，这样各种操作指令就是上接口单元以调用下接口单元的接口函数来发送给文档库系统。

还可以封装各个对象类，如文档库类，把该对象可以进行的操作定义成该类的方法。

特别地，如果在接口标准中定义了获取版面位图的指令，将对保障版面一致性和文档互操作性起到非常关键的作用。

通过获取版面位图的指令，应用软件可以直接获取指定页面的指定位图格式的版面位图，即以位图方式表示的该页面的显示效果，而不用自行解释处理每一个版面对象。也就是说，应用软件可以直接获得准确的版面位图用于显示 /打印文档，而不再需要自己逐个读取页面上每一层的每一个版面对象、自行解释该对象的含义并在版面上体现出来。如果釆用后一种方式的话, 就又难免出现有的软件解释的比较全、比较准确，有的软件解释的不全或不准确，导致同一个文档在不同软件出现不同的显示 /打印效果，影响了文档互操作的用户体验。通过由文档库系统统一生成版面位图的方式，将保持版面一致性的关键点从应用软件移到了文档库系统，从而为不同的应用软件打开同一文档都能出现同样的版面效果提供了可行之路。这一方面是因为文档库系统是统一的基础技术平台，其完整准确地解释处理各版面对象是可行的，而同样的要求对应用软件来说就不太可行；另一方面是因为不同应用软件都可以与同一个文档库系统配套使用 , 这样就更能确保显示 /打印效果的一致性了。筒单来说，就是要求应用软件之间保持一致不太可行，而要求文档库系统之间保持一致则是可行的，要求同一个文档库系统保持一致就更没问题了。因此，为了保持同一文档在不同应用软件之间的版面一致性，就需要把相关责任从应用软件转移到文档库系统，而由文档库系统来统一生成版面位图是其中一个简单易行的办法。

更进一步，获取版面位图的指令还可以指定页面上的一个区域，可用于只显示页面的一个区域，例如当页面比屏幕大时就不需要显示整页，滚动页面时也只需要重画滚动的区域；当该指令还允许指定获取特定层组成的版面位图，特别是可以指定由特定层以及该层下的所有层组成的版面位图时，可以艮好地用于展现历史痕迹，即可以查看在添加最近这一层之前或更早以前的版面效果。如果需要的话，还可以具体指定哪一层参与位图的生成，哪一层不参与。

在检索查询指令中，除了常规的关键词检索外，还可以提供更加丰富的检索手段。在常规的搜索技术中，搜索是和文档处理分离的，搜索程序只能从文档中提取纯文本信息，而无法获取更多信息，只能基于文本信息检索。但在本发明中，检索查询功能是集成在文档处理的核心层，即文档库系统，这样就可以更充分地利用文档中蕴含的信息来提供更为强大的检索手段，如：

1. 基于字体信息的检索，如检索黑体字的"书生"， Times New Roman 字体的 "Sursen"

2. 基于字号信息的检索，如检索三号字的"书生，，， 20 磅以上的 "Sursen", 长字（即字高超过字宽）的"文档库"

3. 基于颜色的检索，如检索红色的 "书生"，蓝色的 "Sursen"

4. 基于版面位置的检索，如检索位于页面上半部分的 "书生"，位于页脚的 "Sursen"

5. 基于特殊修饰效果的检索 , 如检索斜体字的"书生", 顺时针旋转 30度至 90度之间的" Sursen"，空心字的" SEP", 勾边字的"文档库"

6. 根据类似的思路，还可以进一步提供其它类型的检索，如检索反白（黑底白字）的"书生"，压图的 "Sursen"等

7. 可以检索多个版面对象的组合，如"书生，，距离 "Sursen"不超过 5 厘米

8. 上述检索条件的任意组合

以下是用 "操作动作 +操作对象"的方式实现接口标准的一个实施例 , 在该实施例中，接口称为非结构操作标记语言（UOML )，是用可扩展标记语言（XML )描述的一系列的命令。上接口单元生成符合 UOML格式的字符串，并将该字符串发送给下接口单元，就将相应的操作指令发送给了文档库系统。文档库系统执行这些命令后，下接口单元将执行结果也生成一个符合 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，，；网络路径是 "\\" 开头，后面是服务器名，以及服务器上的路径，如 "\\server\abc\def.sep"; 文档库的逻辑名称可以用" *，，开头，如" *MyDocBasel"。在下接口单元解析时，如果第一个字母是" *"就表明该字符串代表文档库的逻辑名称；否则如果头两个字母是" \\"就表明该字符串代表网络路径；否则如果头五个字母是 "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对象包括：

文档库（UOML— DOCBASE)、文档集（UOML— DOC SET)、文档 (UOML— DOC)、页（UOML— PAGE)、层（UOML— LAYER)、对象组 (UOML— OBJGROUP)、文字 (UOML— TEXT)、图像 (UOML— IMAGE)、直线 (UOML_LINE)、曲线 (UOML_BEIZER)、圆弧 (UOML— ARC)、路径 ( UOML— PATH ) 、源文件（UOML— SRCFILE) 、背景色 ( UOML— BACKCOLOR ) 、前景颜色（UOML— COLOR) 、 ROP(UOML— ROP) 、字符尺寸（UOML— CHARSIZE) 、字体 (U0ML_TYPEFACE)_o

下文以部分对象为例说明其定义方式：

1. UOML—DOC

1.1 属性：无

1.2 子元素:

1.2.1 metadata: 元数据

1.2.2 pageset: 各页面

1.2.3 fontinfo: 嵌入字库

1.2.4 navigation: 导航信息

1.2.5 thread: 导读信息

1.2.6 minipage:微缩版面 1.2.7 signiture: 数字签名

1.2.8 log: 历史痕迹

1.2.9 shareobj：文档共享对象

2. UOML— PAGE:

2.1属性：

2.1.1 resolution: 逻辑分辨率

2.1.2 size: 版心大小，用宽高表示

2.1.3 rotaion: 旋转角度

2.1.4 log: 历史痕迹

2.2 子元素：

2.2.1 GS: 初始图形状态，包括 charstyle (字符风格）、 linestyle (线型）、 linecap (线头类型）、 linejoint (接头类型）、 linewidth (线宽）、 fillrule (填充规测 )、 charspace (字间巨）、 linespace (行间^巨）、 charroate

(字符旋转角度）、 charslant (字符倾斜方向 )、 charweight (字色重）、 chardirect (字符方向 ) 、 textdirect (文本方向）、 sliadowwidth (阴影宽度）、 shadowdirect (阴影方向）、 shadowboderwidth (阴影边线宽度）、 outlinewidth (轮廓宽度）、 outlineboderwidth (轮廓边线宽度）、 linecolor

(线的颜色）、 fillcolor (填充色）、 backcolor (背景色）、 textcolor (文字颜色）、 shadowcolor (阴影颜色 )、 outlinecolor (轮廓线颜色 )、 matrix

(变换矩阵）、 cliparea (裁减区）。

2.2.2 metadata: 元数据

2.2.3 layerset: 属于该页的各层

2.2.4 signiture: 数字签名

2.2.5 log: 历史痕迹

3. UOML TEXT 3.1 属性：

3.1.1 Encoding: 文字编码方式

3.2 子元素：

3.2.1 TextData: 文字内容

3.2.2 CharSpacingList: 对非等间距文字的字间距列表

3.2.3 StartPos:起点位置

4. UOML—CHARSIZE

4.1属性：

4.1.1 width: 字符宽度

4.1.2 height: 字符高度

4.2子元素: 无

5. UOML—LINE

5.1属性：

5.1.1 LineStyle: 线型

5.1.2 LineCap: 线的接头类型

5.2子元素：

5.2.1 StartPoint: 线的起点坐标

5.2.2 EndPoint: 线的终点坐标

6. UOML— BEIZER

6.1属性：

6.1.1 LineStyle: 线型

6.2子元素：

6.2.1 StartPoint: 贝塞尔曲线的起点坐标

6.2.2 Contrail— Point: 贝塞尔曲线的第一控制点

6.2.3 Control2_Point: 贝塞尔曲线的第二控制点 6.2.4 EndPoint: 贝塞尔曲线的终点坐标

7. UOML— ARC

7.1 属性：

7.1.1 Clockwise: 弧的方向

7.2 子元素：

7.2.1 StartPoint: 弧的起点坐标

7.2.2 EndPoint: 弧线的终点坐标

7.2.3 Center: 弧的圆心坐标

8. UOML— COLOR

8.1 属性：

8.1.1 Type: 颜色类型， RGB或 CMYK

8.2 子元素：

RGB模式

8.2.1 Red: 红色

8.2.2 Green: 绿色

8.2.3 Blue: 蓝色

8.2.4 Alpha: 透明度

CMYK模式 ·

8.2.5 Cyan: 青色

8.2.6 Magenta: 品红

8.2.7 Yellow: 黄色

8.2.8 Black— ink: 黑色

以此类推，可以用同样的方法来描述所有的 UOML对象。当应用软件对文档库进行操作时，由上述 UOML动作与 UOML对象依照 XML 语法生成相应的 UOML命令。具体地，在本发明中，采用 XML元素来描述动作，该元素下的子元素来描述具体对象，采用字符串来表示数值，并且对象的详细信息采用属性描述。通过这种形式，可以实现对功能调用和调用返回结果的 XML描述。对该 XML描述语义上的约束，采用 DTD或 schema。然后，将该 UOML命令发给文档库系统即代表向文档库系统发出了相应操作指令。 XML ( extensible Markup Language, 可扩展置标语言）是由 W3C ( World Wide Web Consortium,互联网联合组织 ) 于 1998年 2 月发布的一种标准，同 HTML—样是 SGML ( Standard Generalized Markup Language, 标准通用置标语言）的一个简化子集。 XML语法和各种对象操作指令可参见该标准。同时可以参考 "Extensible Markup Language (XML) 1.1 , W3C Recommendation 04 February 2004, edited in place 15 April 2004"、 "W3C ( World Wide Web Consortium ) extensible Markup Language ( XML ) 1.0 ( REC-xml-19980210 ) "、 "W3C XML Schema Part 0-4 ( REC-xmlschema ) "、 "W3C Namespaces in XML ( REC-xml-names-199090114 ) "、 "W3C XSL Transformations (XSLT) Version 1.0( REC-xslt- 19991116 )"、 "Document Object Model (DOM) Level 1 Specification (Second Edition) Version 1.0 , W3C Working Draft 29 September, 2000"、 "美国 Federal CIO Council XML Working Group Draft Federal XML Developer's Guide"以及"英国 Office of the e-Envoy , e-Govemment Schema Guidelines for XML"。

例如,对创建文档库操作，可以用以下命令来完成:

<UOML— OPEN create="tme">

</UOML_OPEN>

对创建文档集操作,可以用以下命令来完成：

<xobj>

</xobj>

</UOML_INSERT>

需要说明的是，虽然 UOML是用 XML定义的，但为了显得更加筒洁，在前面省略了类似" <?xml version="1.0" encoding="UTF-8"?>，，以及 "xmlns:xsi= "http://www.w3.org/200 l/XMLSchema-instance"'，之类的常规 XML格式，只要是熟悉 XML语法的实施者都可以在实施过程中自行添加。

也可以不用 XML方式定义命令串，例如改用类似 PostScript那样的方式，这样上例变成：

1, "f:\\data\\docbasel .sep", /Open

/docset, 1, "123.456.789" , /Insert

根据同样的思路，还可以定义出其它类型的命令串格式，甚至还可以不用文本方式，而用二进制方式来定义命令串。

现在介绍对每一个对象的每一个操作都用一个命令来表示的方式的一个具体实例, 在本实例中，用" UOML— INSERT— DOCSET"来表示插入一个文档集，用" UOML— INSERT— PAGE"来表示插入一页，以这样的方式来定义每个命令：

UOML— INSERT— DOCSET在文档库中创建一个文档集

属性：无

子元素：

parent: 文档库句柄

pos: 插入位置返回值：如果执行成功，则在 UOML— RET中包含一个，， handle" 子元素，表示新插入文档集的句柄

这样上例就变为：

<UOML— INSERT—DOCSET >

</UOML_INSERT_DOCSET >

用这种方法定义命令格式需要对每个对象的每种合法操作都单独定义一条命令，缺点是比较繁瑣。

现在介绍用函数调用的方式来实现接口标准的实例，在该实例中，通过上接口单元调用下接口单元的接口函数的方式来发送操作指令给文档库系统。以下以 C++语言为例说明，该实例称为 UOI。

先定义一个 UOI返回值结构：

struct UOI— Ret {

BOOL m— bSuccess; II操作是否成功

CString mJErrlnfo; II如果操作不成功，错误信息是什么

};

定义所有 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— ObjectO;//构造函数

virtual〜 UOI—ObjectO;//析构函数

static UOI— Object *Create(Type objType); //根据指定类型创建相应对象 };

然后定义如下几个 UOI函数,与 "操作动作 +操作对象"方式实例中的几个 UOML动作相对应：

打开或创建文档库，成功则将其句柄返回在 pHandle中：；

UOI—RET UOI_Open(char *path, BOOL bCreate, HANDLE

*pHandle);

关闭 db— handle文档库中的 handle句柄，如果 handle为 NULL则关闭整个文档库：

UOI—RET UOI_Close(HANDLE 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);

检索查询，检索结果的数量返回在 pResultCount中，检索结果列表的句柄返回在 phResult中：

UOI—RET UOI_Query(HANDLE hDocbase, const char *strCondition, HANDLE *phResult);

然后定义各 UOI 对象，依然以 UOI— Doc、 UOI— Text 和 UOML— CharSize为例说明： 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 *m_pMiniPages; 缩页面

UOI— Signature m— Signature;〃签名

int m— nShared; //共享对象数 UOI— Obj *m_pShared; //共享列表

UOI_Doc(); //构造函数

virtual ~UOI_Doc()； //解析函数

}；

class UOI— Text： public UOI— Object { public:

enum Encoding {

ENCODE— ASCII, //ascii编码

ENCODE— GB13000， //GB 13000编码 ENCODE— UNICODE, //Unicode编码

}；

Encoding m— Encoding;〃编码类型 char *m_pText；〃文字串

Point m— Start ; //起点坐标

int *m_CharSpace；〃字符间距数组

UOI_Text();〃构造

virtual〜 UOI_Text();〃析构

};

〃对象 UOI— CharSize的定义

class UOI— CharSize： public UOI— Object { public：

int m— Width； //宽度

int m— Height；〃高度

UOI— CharSize();〃构造函数

virtual ~UOI_CharSize(); //析构函数

}; 以下说明 UOI的使用方法。首先是创建文档库操作： ret = UOI_Open("f:\\data\\docbasel.sep", TRUE, &hDocBase); 然后是构建一个创建新对象的函数：

HANDLE InsertNewObj(HANDLE hParent, int nPos UOI— Object：: Type type)

{

UOI— Ret ret;//返回值

HAD LEhandle ;//对象句柄

UOI— Obj *pNewObj = UOI—Obj：: Create(type);〃创建对象

if (pNewObj == NULL)

return NULL;//创建失败返回空值

ret = UOI_Insert(hParent, nPos, pNewObj, &handle)；〃插入到父结点，返回对象句柄 handle

delete pNewObj ;//删除临时对象

return ret.m— bSuccess？ handle： NULL;〃成功返回对象句柄 handle, 失败返回空值

}

然后是直接获取对象的函数：

UOI—Obj *GetObj(HANDLE handle)

{

UOI— Ret ret;//返回值

UOI— Object：: Type type;//对象类型

UOI_Obj *pObj;//对象指针

ret = UOI_GetObjType(handle, &type);//根据对象类型 type

if ( !ret. m— bSuccess )

return NULL;//如果返回失败，本函数返回空值

pObj = UOI— Obj::Create(type);//创建 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 bOven'ide:是否覆盖原文件

* \return UOI— DocBase对象

*/

BOOL Create(const char *szPath, bool bOverride = false);

/*!

* \brief 打开文档库

* \param szPath: 文档库全路径 * \return UOI— DocBase对象 BOOL Open(const char *szPath);

/*!

* \brief 关闭文档库

* \param 无

* \return 无

*/

void Close();

/*!

* \brief 获取角色列表

* \param 无

* \return UOI— RoleList对象

* \sa UOI— RoleList

*/

UOI— RoleList GetRoleList();

/*!

* \brief 存储文档库

* \param szPath:存储文档库全路径

* \return 无

*/

void Save(char * szPath = 0);

/*!

\brief 插入文档集

\param nPos:插入文档集的位置

\return UOI— DocSet对象

\sa UOI DocSet UOI—DocSet InsertDocSet(int nPos);

/* !

* \brief 获取指定索引的文档集

* \param nlndex: 文档列表的索引号

* \return UOI— DocSet对象

* \sa UOI— DocSet

*/

UOI— DocSet GetDocSet(int nlndex);

/*!

* \brief 获取文档集的总数

* \param 无

* \return 文档集个数

*/

int GetDocSetCount();

/*!

* \brief 设置文档库的名称

* \param nLen: 文档库名称长度

* \param szName: 文档库名称

* \return 无

*/

void SetName(int nLen, const char* szName); /*!

* \brief 获取文档库名称长度

* \param 无

* \return 长度

*/

int GetNameLen();

/*! * \brief 获取文档库名称

* \param 无

* \return 文档库名称

*/

const char* GetName();

/*!

* \brief 获取文档库 id长度

* \param 无

* \retura 长度

*/

int GetIDLen();

* \brief 获取文档库 id

* \param 无

* \return id

*/

const char* GetID();

//! 构造函数

UOI_DocBase();

//! 析构函数

virtual〜UOI— DocBase();

};

class UOI Text ： public UOI—Obj

{

public:

//! 构造函数

UOI_Text();

//! 析构函数 virtual ~UOI_Text();

//! 表示文本编码的枚举类型

enum UOI— TextEncoding

{

CHARSET— GB2312，/*!< GB2312, alal-fefe */

CHARSET— HZ2312 , /*!< GB2312 except GBFH, bOal-fefe */ CHARSET— GB12345,/*!< GB 12345, traditional char of GB2312， alal-fefe */

CHARSET— HZ12345,/*!< GB 12345 except GBFH, traditional char of HZ2312， bOal-fefe */

CHARSET— GB 13000,/* !< GBK, 8141-fefe */

CHARSET— HZ13000,/*!< GBK except GBFH, 8141-fefe except alal-affe */

CHARSET— GB18030，/*!< GB 18030 except GBFH, unsupported in this version */

CHARSET—HZ18030，/*!< GB 18030 except GBFH, unsupported in this version */

CHARSET— UNICODE,/* !< UniCode, unsupported in this version */

CHARSET—ASCII , /*!< ASCII编码 */

};

//! 获得文本的编码

UOI— TextEncoding GetEncoding();

//! 设置文本的编码

void SetEncoding(UOI_TextEncoding nEncoding );

//! 获得文本的数据

const char * GetTextData();

//! 获得文本的数据长度 int GetTextDataLen();

III 设置文本的数据

·/*!

\param pData文本数据

\param nLen数据长度

*/

void SetTextData(const char * pData, int nLen);

//! 获得起点位置

Point GetStartPoint();

//! 设置起点位置

void SetStartPoint(Point startPoint);

//! 获得字符间距表大小

int GetCharSpacingCount();

//! 获得字符间距表中指定位置的字符间距

float GetCharSpacing(int nlndex);

//! 设置字符间距表大小

bool S etCharSpacingCount(int nLen);

//! 设置字符间距

bool SetCharSpacing (int nlndex, float charSpace ); //! 获得文本的外框

UOI—Rect GetExtentAreaO；

}；

class UOI_Arc： public UOI_Obj { II 圆弧对象及其操作 public:

//! 构造函数

UOI_Arc();

//! 析构函数

virtual ~UOI_Arc(); //! 获得圆狐起点

/*!

\return 圓瓜起点

*/

UOI— Point GetStartPoint();

//! 获得圆弧终点

/*!

\return 圆孤终点

*/

UOI— Point GetEndPoint();

i 获得圆弧旋转角

/*!

\return橢圆横轴与坐标系 X轴的夹角，单位为弧度 */

float GetRotAng();

//! 设置圆弧旋转角

/*!

\param fRotAng新的旋转角

\sa GetRotAng()

*/

void SetRotAng(float fRotAng);

〃！获得 X半轴长度

float GetRadiusX();

〃！设置 X半轴长度

void SetRadiusX(float fRx);

//!获得 Y半轴长度

float GetRadiusY();

〃！设置 Y半轴长度 void SetRadiusY(float fRy);

//!获得弧线方向（是否为顺时针）

bool GetClockWise();

〃！设置弧线方向（是否为顺时针）

void SetClockWise(bool bClockWise);

〃！获得（由圆弧起点 ->圆心- >圆弧终点，是否为顺时针方向） bool GetGreatArcFlag();

〃！设置（由圆弧起点 ->圆心- >圆弧终点，是否为顺时针方向） void SetGreatArcFlag(bool bGreat);

〃！计算圓心，由参数返回，如果数据无效，则返回 false, 否则返 true

bool GetCenter(float &fCx, float &fCy);

}；

class UOI_RoleList： public UOI— Obj II文档库中的角色列表 {

public:

//! 获得列表中角色的数目

int GetRoleCount();

//! 按指定索引获得角色、

UOI— Role *GetRole(int nlndex);

//! 创建角色

\param pPrivKey私钥緩冲区

\param pnKeyLen用于返回实际私钥的长度

\return新创建的角色

*/

UOI Role AddRole(unsigned char *pPrivKey, int *pnKeyLen); //! 构造函数 UOI— RoleList();

//! 析构函数 '

virtual ~UOI_RoleList();

};

class UOI— Role ： public UOI_Obj II 文档库中的角色

{ '

public:

//! 构造函数

UOI— Role();

//! 析构函数

virtual ~UOI—Role();

//! 获得角色 ID

int GetRoleID();

ll\ 设置角色 ID

/* !

\param nlD角色 ID

*/

void SetRoleID(int nlD);

//! 获得角色名称

const char * GetRoleName();

//! 设置角色名称

\param szName 角色名称

*/

void SetRoleName(const char * szName);

};

class UOI— PrivList： public UOI—Obj II权限列表，每个权限列表由若干角色权限项组成 public:

//! 获得指定角色对应的权限

UOI_RolePriv *GetRolePriv (UOI— Role *pRole);

//! 新建某角色的权限项

UOI—RolePriv *AddRole (UOI— Role *pRole);

//! 获得列表中角色权限项的数目

int GetRolePrivCount()；

//! 按索引值，获得角色权限项

UOI— RolePriv *GetRolePriv (int nlndex);

//! 构造函数

UOI_PrivList();

//! 析构函数

virtual ~UOI_PrivList();

}；

class UOI_RolePriv： public UOI_Obj 〃角色权限项，对应于某一个角色的所有权限，由若干针对某个对象的权限组成

{

public:

//! 获得角色

UOI—Role *GetRole();

//! 设置对某个对象的权限,当权限超过该角色对该对象的当前权限时为授权，小于时为收回授权。当前登录的角色必须有相应的再授权或收回授权权限

bool SetPriv(UOI_Obj *pObj, UOI— Priv *pPriv);

//!获得权限设置数量

int GetPrivCount();

//! 获得索引值对应的权限设置的对象 UOI— Obj *GetObj(int nlndex);

//! 获得索引值对应的权限设置的权限

UOI—Priv *GetPriv(int nlndex);

//! 获得对应于某一个对象的的权限

UOI—Priv *GetPriv(UOI_Obj *pObj);

//! 构造函数

UOI— RolePriv ();

//! 析构函数

virtual ~UOI_RolePriv ();

};

class UOI— Priv : public UOI— Obj //权限的定义 {

public:

enum PrivType { II各权限类型定义

PRIV— READ, II读权限

PRIV— WRITE, II写权限

PRIV_RELICENSE, II再授权权限

PRIV— BEREAVE, II收回授权权限

PRIV— PRINT, II打印权限

其它权限定义

}

//! 是否有相应权限

bool GetPriv(PrivType privType);

//! 设置相应权限

void SetPriv(PrivType privType, bool bPriv); //! 构造函数

UOI—Priv ();

//! 析构函数 virtual ~UOI_Priv ();

}；

class UOI— SignList： public UOI_Obj II数字签名列表 {

public:

//! 构造函数 ·

UOI_SignList();

//! 析构函数

virtual ~UOI_SignList();

//! 添加新的数字签名，返回其索引值

int AddSign(UOI一 Sign *pSign);

//! 按指定索引值，获得指定数字签名

UOI—Sign *GetSign(int index);

//! 按索引值，删除指定数字签名

void DelSign(int index);

//! 获得列表中数字签名的数目

int GetSignCount();

};

class UOI—Sign： public UOI— Obj II数字签名

{

public:

//! 构造函数

UOI— Sign()_;

//! 析构函数

virtual ~UOI_Sign();

//! 执行签名

/*!

\param pDepList签名所依赖的列表 \param pRole用于签名的角色

\param pObj 被签名的对象

*/

void Sign(UOI_SignDepList *pDepList, UOI— Role *pRole UOI—Obj *pObj);

//! 验证签名

bool VerifyO;

//! 获得签名的依赖列表

UOI— SignDepList *GetDepList();

};

class UOI— SignDepList： public UOI—Obj II签名的依赖列表

{

public:

//! 构造函数

UOI_SignDepList();

//! 析构函数

virtual ~UOI_SignDepList();

//! 加入一个依赖项

void InsertSignDep(UOI_Sign *pSign);

//! 获得依赖项的数目

int GetDepSignCount();

//! 按指定索引值，获得依赖项

UOI— Sign *GetDepSign(int nlndex);

//! 按索引值，删除指定依赖项

bool *DelDepSign(int nlndex);

};

这样插入文档集的操作指令就是上接口单元以下列方式调用下接口单元的接口函数来发送给文档库系统的： pDocBase.InsertDocset(O);

还可以用同样的方法为 Java、 C#、 VB、 Delphi等各种编程语言开发的应用软件设计各种不同的接口标准。

只要在接口标准中不含有与特定的操作系统（如 WINDOWS、 UNIX/LINUX、 MAC OS、 SYMBIAN )或特定的硬件平台（如 x86CPU、 MIPS, POWER PC等）相关连的特征，该接口标准就可以具有跨平台性，使得不同平台上运行的应用软件和文档库系统都可以统一使用同样的接口标准，特别是可以让一个平台上运行的应用软件可以调用另一个平台上运行的文档库系统来执行相应操作。例如，应用软件部署在客户端，使用的是 PC机， Windows操作系统，文档库系统部署在服务器端，使用的是大型机， Linux操作系统，但应用软件依然可以像调用本地文档库系统一样调用服务器上的文档库系统来执行相应文档作。

如果在接口标准中不含有与特定编程语言相关的特征，则该接口标准还能做到与编程语言无关。可以看出，用命令串的方式容易构造与平台无关、与编程语言无关的接口标准，更具有通用性。特别是用 XML 来构造命令串的话，由于目前在各种不同平台、不同编程语言都存在易于获得的 XML生成解析工具，因此不仅该接口标准具有很好的跨平台性和与编程语言无关性，也非常便于工程师开发上接口单元和下接口单元。

以上列举了多种接口标准的实现方法，按照类似的思路设计的更多种类的接口标准也包含在本发明的保护范围之内。

应该理解，可以在上述实例的基上按同样的思路增加操作指令，也可以筒化操作指令，特别是文档模型被筒化时操作指令也会相应被简化。最简化情况下只有文档的创建、页面的创建、各版面对象的创建这几个操作指令。文档操作处理

现在，参见图 1，继续描述依照本发明一优选实施例的文档处理系统的工作过程。

应用软件应符合统一的接口标准，例如 Office软件、内容管理、资源采集等。任一应用软件在需要对文档进行操作时，依照前述方法将指令传递给文档库系统，文档库系统根据指令来完成具体操作过程。

文档库系统可以自由地存储、组织文档库数据，例如可以把一个文档库的文件全部都存储在一个磁盘文件中；可以一个文档对应一个磁盘文件，利用操作系统中的文件系统功能实现多文档组织；也可以一页对应一个磁盘文件；还可以完全抛开操作系统，在磁盘上留出一块空间后直接对磁道、扇区进行管理。对文档库数据的存储格式，可以用二进制格式保存，可以用 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.执行获取版面信息指令时，先生成一个指定位图格式的空白位图，其尺寸和指定区域相同，然后遍历指定页面的所有版面对象，凡是位于指定区域内（包括只有一部分在该区域内）的版面对象，都解释其含义，并在版面上相应体现。具体过程虽然比较复杂比较专业，但均属于现有 IP技术范畴，不在此赘述。

文档安全处理

在创建角色对象时，生成一对随机公私钥对（例如 512位的 RSA密钥），将公钥存储在角色对象中，将私钥返回给应用软件。

当应用软件登录时，随机生成一块（例如 128字节 )数据, 用相应角色对象中的公钥加密该数据发给应用软件，应用软件解密后比较验证，如果正确则表明应用软件确实拥有该角色对应的私钥，登录成功。为保险起见，该认证过程可以重复三次，三次全部通过才算登录成功。

当对某一对象进行签名时，也就是对其对应的结点开始的子树进行签名。为了能够使签名不受具体物理存储方式的影响，需要先做一个正则化，使得逻辑上等效的变化（例如存储位置的改变导致相应指针的变化）不会影响签名有效性。该正则化的方法如下：

按深度优先遍历以目标对象为根节点的子树中的各个节点（即目标对象及其各个子对象），按照遍历顺序依次计算每个节点的正则结果并连接起来。

其中，对子树的某一节点计算正则结果的方法为：先计算该节点的子节点数的 HASH值，然后再依次计算该节点类型及其各个属性的 HASH值并按顺序连接在该节点的子节点数的 HASH值的后面，再计算该连接结果的 HASH值，得到该节点的正则结果。如果需要对子树中的某个节点引用的对象也一起做签名 , 则可以将该节点引用的对象也作为该节点的一个子节点来处理，方法同上。

正则化以后，再做 HASH并用角色的私钥进行签名的处理可采用现有技术，这里不再赘述。

在上述正则化过程中，可以把计算一个节点正则结果的方法改成如下方案：将该节点的子节点数、类型及其各属性用分隔符隔开后按照顺序连接起来，计算该连接的结果的 HASH值，得到该节点的正则结果。还可以把计算一个节点正则结果的方法改成如下方案：将该节点的子节点数、类型及其各属性的长度用分隔符隔开后按照顺序连接起来，再与子节点数、类型、各属性连接起来，即得到该节点的正则结果。总之，计算一个节点正则结果的方法可以采用以下各种方案中的任意一种：对树的某一节点，其子节点数、类型、各属性，子节点数 /类型 /各属性的长度（可选的），原值或经过特定变换（如 HASH、压缩），按照预定顺序连接起来（直接连接或用分隔符隔开）。

上述预定顺序的意思是，子节点数长度、类型长度、各属性长度、子节点数、类型、各属性可以按任意顺序排列，只要是预定的顺序即可。

另外，在遍历子树中各个节点时，既可以采用深度优先遍历也可以采用宽度优先遍历。

不难给出上述方案的各种变化方式，如每个结点的子结点数用分隔符隔开后按照深度优先的顺序连接起来，再与各结点其它数据的正则结果连接起来。总之，只要对该子树中的所有结点的子结点数、类型和各属性，按照确定的方法排列在一起就属于本实施例的变化。

当对某一对象设置权限时，最简单的实现方式是简单记录各角色对该对象（及其子对象）的权限，并在今后各角色访问时加以比较，符合权限的则允许相应操作，否则报错返回。更好的实现方式是对相应数据加密，并用密钥来控制权限，如果该角色没有相应密钥就没有对应的权限，这种方式抗攻击能力要更强。具体方案为：

a) 对受保护的数据区域（通常为一个子树，对应某对象及其所有子对象），有一对对应的 PKI密钥对，用其中的加密密钥对该数据区域进行加密。

b) 对具有读权限的角色，授予其解密密钥，该角色可以用该密钥解密该数据区域，从而正确读取这些数据。

c) 对具有写权限的角色，将授予其加密密钥，该角色可以将修改后的数据用该密钥加密，从而可以正确写入该区域的数据。

d) 鉴于 PKI的加密 /解密效率较低，为提高运行效率，也可以用对称密钥来对该数据区域加密，加密密钥用于对该对称密钥进行加密，解密密钥用于解密经过加密后的密钥数据，从而获得正确的对称密钥。为防止只有读权限的角色在获得对称密钥后用其修改数据，可以用加密密钥来对该数据区域进行数字签名，每次拥有写权限的角色修改该数据区域后都重新做一次签名，从而确保数据不会被没有写权限的角色篡改。

e) 当授予某一角色加密密钥或解密密钥时，可以用该角色的公钥对该密钥加密后存储，这样只有拥有该角色的私钥时才能取出该密钥。

以下进一步说明增强系统安全性和文档安全性的技术实施方案：角色由一个唯一的 ID号和一对唯一的 PKI密钥组成，但在角色对象中只存储其 ID号和公钥，私钥由应用软件掌握。 ID号可以是任意的编号或字符串，只要不同角色都分配了不同的 ID即可。 PKI算法可以是 ECC、 RSA中的一种。

安全管理功能由角色管理单元、安全会话通道单元、身份认证单元、访问控制单元、签名单元组成。

以某个角色（或多个角色）登录、执行一系列操作、最后注销的整个过程称为会话。会话包括会话标志、登录角色列表。会话可以通过一个安全会话通道进行。安全会话通道有一个会话密钥，用于加密双方之间传递的数据。会话密钥可以用非对称密钥，但一般常用效率更高的对称密钥。

身份认证单元用于当角色登录时，对登录的身份进行认证。身份认证的单位是角色，只有拥有某个角色的私钥才能以这个角色的身份登录。在登录时，身份认证单元根据登录角色的 ID取出存储在角色对象中的角色公钥，按照前述的 "挑战-应答" 机制进行认证。

角色管理单元包括角色的创建、各角色的权限的授权、收回授权等。访问控制单元，用于对文档数据设置访问控制权限，角色只能根据自己的访问控制权限访问文档数据。我们甚至可以连权限数据都可以置于访问控制的管理之下，这样有的角色可以获取其他人的权限，有的角色不能。但只有拥有再授权或收回授权权限的角色才能按照正常的再授权或收回授权方式改变角色的权限，而不允许直接写入权限数据。

以下详细说明各操作步驟：

1. 新建一文档库时，角色管理单元自动将该文档库的缺省角色的权限设置为拥有所有权限，包括对所有对象的读、写、再授权和收回授权权限

2. 建立安全会话通道，启动会话

a )根据会话标志判断是否已经启动会话，如果是，则完成建立安全会话通道的过程，否则继续；

b )一方生成一对随机 PKI钥对;

c )将公钥发送给对方；

d )对方生成随机对称密钥作为会话密钥，并用该公钥加密会话密钥后传回；

e )用私钥解密出会话密钥;

f )设置会话标志；

g )将登录角色列表设置为缺省角色；

3. 角色登录

a )应用软件提供所要登录角色的 ID和所登录的文档库； b ) 身份认证单元检查会话中的登录角色列表，如果该角色已经登录（包括缺省角色），则该步骤已经完成，否则继续；

c ) 身份认证单元取出存储在角色对象中的角色公钥；

d ) 身份认证单元生成一段随机数据块，用该角色的公钥对该数据块进行加密；

e ) 身份认证单元将加密后的数据块发送给应用软件；

f )应用软件用该角色的私钥进行解密，将解密后的数据发送给身份认证单元；

g ) 身份认证单元判断传回的数据是否正确，如果不正确则登录失败，否则继续；

h )在会话的登录角色列表中增加该角色。

4. 创建新角色

a )应用软件发出创建新角色指令;

b ) 角色管理单元生成一个唯一的角色 ID号；

c ) 角色管理单元生成一对随机的 PKI钥对；

d ) 角色管理单元在文档库中创建一个角色对象，在角色对象中存储上述 ID号和公钥, 该角色的权限为空，即对所有对象都不拥有任何权限；

e )将 ID号和私钥返回给应用软件。

5.对角色 R授与对对象 0的权限 P

a )应用软件发出授权请求；

b )角色管理单元计算登录角色列表中所有角色对 O的权限的并集，判断该并集是否是 P的超集并同时拥有再授权权限。如果否则授权失败 (所有角色都加在一起也没有授权所需要的权限 ) , 否则继续；

c ) 角色管理单元将对 0的权限 P增加到角色 R的权限列表中。如果 P不包含读或写的权限，则授权完成，否则继续；

d )访问控制单元单元检查对象 0是否已经设置了读写的访问控制权限。如果否，则：

i. 生成随机对称密钥和随机 PKI密钥 ii. 用对称密钥对 O进行加密。如果 O的各级子对象中有已经设置了读写访问控制权限的，则该子对象保持不变 iii. 用 PKI加密密钥加密对称密钥，存储加密后的密文，并对 0进行签名

iv. 检查文档库中的所有角色，凡是对 O具有读权限的（这时 O是该角色拥有读权限的某个对象的子对象），用该角色的公钥对解密密钥进行加密，将加密后的密文存储到该角色的权限列表中；凡是对 o具有写权限的（这时 o是该角色拥有读权限的某个对象的子对象），用该角色的公钥对加密密钥进行加密，将加密后的密文存储到该角色的权限列表中

v. 转到步骤 h

e )从当前登录的角色中，选择对 O具备相应权限的角色； f)将该角色权限列表中 0的对应密钥（读权限对应解密密钥，写权限对应加密密钥，可读可写则包含两个密钥）的密文，发送给应用软件；

g )应用软件用该角色的私钥解密出密钥，返回给访问控制单元； h )根据 P的设定，使用目标角色 R的公钥，加密相应的密钥，生成对应的密文，并存储到 R的权限列表中。

6. 收回 R对对象 0的权限 P

a )应用软件发出收回授权请求；

b ) 角色管理单元查找登录角色列表中的所有角色，是否有对 O的收回授权的权限。如果都没有，则收回授权失败，否则继续；

c )从 R对 0的权限中去掉 P;

d )如果 P包含读或写权限，从 R的权限列表中删除对 O的相应解密密钥和 /或加密密钥。

7. 读取对象 O

a )应用软件发出需要读取 0的操作的指令；

b )访问控制单元检查登录角色列表中所有角色对 O的权限，确认是否至少有一个角色对 0有读权限。如果均无，则失败，否则继续； c )检查对象 O是否已经设置了读写的访问控制权限。如果否，则检查其父对象，还不是的话则再检查父对象的父对象，直到找到了设置读写访问控制权限的对象；

d )选择一个对该对象有读权限的角色;

e )将该角色权限列表中保存的该对象的解密密钥的密文，发送给应用软件；

f)应用软件用该角色的私钥解密出解密密钥，返回给访问控制单元； g )访问控制单元用该解密密钥解密出该对象的对称密钥； h )用该对称密钥解密出对象 O的数据；

i )将解密后的数据返回给应用软件。

8. 写对象 O

a )应用软件发出需要修改 0的操作的指令；

b )访问控制单元检查登录角色列表中所有角色对 0的权限，确认是否至少有一个角色对 O有写权限。如果均无，则失败，否则继续; c )检查对象 0是否已经设置了读写的访问控制权限。如果否，则检查其父对象，还不是的话则再检查父对象的父对象，直到找到了设置读写访问控制权限的对象 Ol;

d )选择一个对 01有写权限的角色；

e )将该角色权限列表中保存的 Ol的加密密钥的密文，发送给应用软件； f)应用软件用该角色的私钥解密出 Ol的加密密钥，返回给访问控制单元；

g )用该加密密钥加密 o的新数据 (如果 o的各级子对象中有已经设置了读写访问控制权限的，则仍然用其密钥对该子对象加密)；

h )用加密后的数据覆盖原数据，完成写入过程。

9. 对对象 0进行签名

a )应用软件发出对 0进行签名的指令；

b )签名单元用前面所述的方法对对象 0的数据进行正则化； c )计算正则化结果的 HASH值；

d )将 HASH值发给应用软件；

e )应用软件用登录角色列表中所有角色的私钥对该 HASH值进行加密（即签名）；

f)应用软件将签名结果返回给签名单元；

g )签名单元将签名结果保存在数字签名对象中。

10. 注销登录角色

a )应用软件发出注销某个登录角色的指令；

b )如果登录角色列表中存在该角色，安全会话通道单元将该角色从登录角色列表中去掉。

11. 结束会话

a )一方发出结束会话请求；

b )停止一切与当前会话相关的线程，消除会话标志，删除登录角色列表。

为了提高工作效率，在实施时还可以对上述方法进行增强、简化和变化，例如分解或合并各组成单元、将某个组成单元的某个功能调整为由另一各组成单元来完成、将各角色私钥緩存在会话数据中（会话结束后删除），而不用每次都需要发到应用软件进行解密，或者省略一些安全措施，或者减少一些功能。总之，任何对上述方法进行简化、变化的方法都是本方法的变形。

需要说明的是，本发明中所说明的文档安全技术，如基于角色的权限管理、角色的认证方式、多重角色登陆、对树结构的正则化技术、细粒度的权限管理单元、基于加密的权限设置等，都不仅适用于本发明所述的文档处理系统，还可以运用于更为广泛的其它应用场合。

对文档的分层处理

在本发明中，为了使本文档处理系统能很好地模拟纸张的特性 , 提供了一种"只加不改，，的技术方案。也就是说，每个应用软件都只在现有文档内容基础上添加新的内容，但不修改、不删除已有的内容，使文档的一个页面就象一张纸一样，可以由不同的人用不同的笔在纸上不断写写画画，但谁都不能修改、删除已有内容。

根据本发明的对文档进行分层处理的一个优选实施例 , 在一应用软件对符合通用文档模型的文档进行编辑时 , 在该文档对象中插入页对象，在页对象插入版面对象, 属于同一页的各层按顺序排列；文档库系统对所述各层分别进行管理和控制。

例如，每一个应用软件在编辑其它软件生成的文档时，都在现有文档基础上新增加一层，将本软件新编辑的内容都放到这一层中，不修改和删除前面各层的内容。这样，每个文档的每一层只由一个应用软件来管理和维护，其他应用软件不能对同一层进行编辑。由于现有社会就是基于纸张来运转的，因此只要能符合纸张的特性就能满足现有应用的需求，具备足够的实用价值。

为了确保每一层内容在生成后没有被修改、删除，可以利用每一层的数字签名对象。数字签名可以是对本层内容进行签名，也可以是对本层以及本层之前生成的所有层的内容一起签名，将签名结果保存在数字签名对象中。在增加新的层时，保持原有各层数据和各层之间相互关系不变，保持原有层已进行的数字签名有效。签名以后并不妨碍对文档做进一步的批注等编辑，只要新的内容是位于新建的层，没有修改破坏签名时存在的各层，签名依然是有效的，但签名者只对签名以前的内容负责，不对签名以后的内容负责。这是一个非常符合应用需求的技术方案，具有很大的实用价值。相比之下，现有的其它技术或者签名后不允许编辑，或者编辑后（尽管是"只加不改"的编辑）签名被破坏。

前述技术方案不允许修改文档中的已有内容，即使不考虑与纸张特性的兼容以及数字签名问题，需要修改的话也只能做版面级编辑，即对每个版面对象的编辑（增、删、改）都不会对其它版面对象产生影响（这是由于通用文档模型是基于可见部分为基础构建的，不包含大量不可见的、关于版面对象之间的关系，因此修改任何一个版面对象时，其它版面对象不会产生相应的调整，例如删掉一个字，就会在其位置留下空白，右边的文字不会自动左移）。设置各层的显示 /打印方式，如果显示 /打印某一层，则同时以叠加方式显示 /打印其之前的所有层。也可以设置各层的显示 /打印方式，所述显示 /打印方式为水印效果、叠加或不显示 /打印。所述文档的显示 /打印方式也可以为：所述各层叠加显示 /打印。

如果用户需要对文档中的已有内容进行编辑，并且还希望能像按照原来使用应用软件所进行的编辑的话，有一个技术方案可以很好地满足这个应用需求。该方案是当应用软件完成初始编辑时，除了新建一层存放当前编辑的内容外，还将源文件（按照应用软件自有的格式存储，记录了各对象之间完整关系的文件，例如. doc文件）嵌入到文档中。当下次需要进行继续编辑时，从文档中取出该源文件，并使用该源文件继续编辑。编辑完成后清除该软件所管理的那一层，重新生成该层的内容，并继续将新修改的源文件嵌入到文档中。

具体方法如下：

1.应用软件第一次处理该文档时，新建一层，将新编辑内容对应的版面对象插入到新建层中，同时用自身格式另存一份新编辑的内容（即源文件）。

2.在文档对象中新建一个源文件子对象，用来嵌入源文件（例如用二进制数据的方式整体嵌入），并记录是哪一层对应该源文件对象。

3.用同一应用软件再次编辑该文档时，从对应的源文件对象中取出对应的源文件。

4.使用该源文件继续编辑该层内容。由于该源文件是该应用软件自身的格式，可以按照该应用软件自身的功能继续对该层内容进行编辑。

5.再次编辑结束后，根据新编辑后的结果更新该层内容（例如用全部清除后全部重新生成的方式） , 同时将新修改后的源文件重新嵌入到文档对象中。

6.如此循环往复，就可以用原有应用软件按照原有方式对文档中的已有内容进行编辑。

采用上述技术方案，可以最大程度地实现文档的互操作性。在应用软件、文档都采用本发明技术时, 在有足够安全权限的前提下, 可以实现以下功能：

1.对任何文档，用任何应用软件都可以正确打开、显示、打印。

2.对任何文档, 用任何应用软件都可以新添加任何内容，而且不会破坏文档已有签名。

3.对任何文档，在不必考虑文档已有签名（没有签名或者虽有签名但允许破坏）的前提下，用任何应用软件都可以对文档已有内容进行版面级编辑。 4.对任何文档，使用文档已有内容的原始编辑软件可以对该内容进行正常编辑。

由此可见，通过本发明中对层的管理，对文档的管理、互操作、安全设置都带来极大的便利。

应该理解，本发明的对文档实现分层处理的方法，不仅适用于文档处理系统，还适用于其他可对文档分页存储的系统。

而且，本发明包含按预定规则对数据分组的情况，例如按文档的管理主体对所述数据分组；按对文档执行操作的时间对所述数据分组；或按数据的功能对所述数据分组。

下面以 A软件创建一个文档并且 B软件对其进行编辑为例说明其工作过程。在本例中选用 UOI作为接口标准:

1. A软件发出指令,创建文档库 c:\sample\mydocbase.sep, 将其句柄存放在 hDocBase:

UOI_Open("c:\\sample\\mydocbase.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, 将其句柄存放在 hPage:

UOI— Page page; page.size.w = w;

page.size.h = 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— GB 13000;

text.m— Star x = xl;〃起点的 X坐标

text.m— Star y = yl; //起点的 Y坐标

UOI_Insert(hLayer, 1， &text) ；在本实例中，该层的第二个对象是文字对象；

8. A软件发出指令,关闭文档库 hDocBase:

UOI— Close(hDocBase);

9. B软件发出指令,打开文档库 c:\sample\mydocbase.sep,将其句柄存放在 hDocBase: UOI_Open("c:\\sample\\mydocbase.sep"_? FALSE, &hDocBase);

10. B软件发出指令，获取文档库 hDocBase第一个文档集的指针，将其句柄存放在 hDocSet:

UOI_GetHandle(hDocBase, 0， &hDocSet);

11. B软件发出指令，获取文档集 hDocSet第一个文档的指针，将其句柄存放在 hDoc:

UOI_GetHandle(hDocSet, 0， &hDoc);

12. B软件发出指令,获取文档 hDoc第一页的指针,将其句柄存放在 hPage:

UOI— GetHandle(hDoc, 0， &hPage);

13. B软件获取该页版面位图，用于显示该页

UOI_GetPageBmp(hPage, rect， but);

14. B软件发出指令，获取 hPage第一层的指针，将其句柄存放在 hLayer:

UOI_GetHandle(hPage, 0, &hLayer);

15. B软件发出指令,获取第一个版面对象的句柄 hObj：

UOI_GetHandle(hLayer, 0， &hObj);

16. B软件发出指令，获取 hObj的类型

UOI_GetObjType(hObj , &type);

17. B软件发现这是一个字号对象, 获取该对象

UOI_GetObj(hObj, &charSize);

18. B软件将字高放大一倍：

charSize.m— Height *= 2;

UOI— SetObj(hObj， &charSize);

B软件重新获取版面位图并显示，这时会发现屏幕上的 "书生意气挥斥方遒"变成长体字了下面，参照图 18描述依照本发明的文档处理系统的一个实例。在该实例中，应用软件通过统一的接口标准（例如 UOML接口）请求对文档的操作。文档库系统可能会有不同厂商的不同型号，但是对于应用开发厂商来说面向的都是同一个接口标准，因此都可以与之配套使用。 Red Office, OCR, 网页生成软件、乐谱编辑软件、书生阅读器、 Office编辑软件、其他阅读器等通过 UOML接口指示文档库系统进行操作，文档库系统可以有多个，在图中显示为文档库系统 1、文档库系统 2和文档库系统 3 ,各文档库系统根据 UOML发来的统一标准指令对通用文档模型的文档进行操作，例如创建、保存、显示、呈现文档。在本发明中，不同的应用软件可以同时或不同时调用同一个文档库系统，同一应用软件可以同时或不同时调用不同的文档库系统。

依照本发明，使得应用层和数据处理层分离，使得同一文档能在不同的应用软件之间通用，使不同应用软件之间具有良好的文档互操作性。

依照本发明，形成产业分工，减少重复开发，并更加专业、完备、正确；对文档的基本操作都在文档库系统中处理，各应用软件不必重复开发。而且由于文档库系统是由专业厂商开发，相关技术的专业性、完备性、正确性较有保障，而且应用软件厂商和用户可以选择做的最好的一家文档库系统厂商 , 从而保证处理效果的正确性和一致性。

依照本发明，提供多文档甚至海量文档的管理机制，使文档之间能够有效组织起来，便于检索、查询、保管，便于嵌入较强的信息安全机制。

依照本发明，提供更好的安全机制，可以设置多种角色，细粒度地设置每个角色的权限。其中细粒度是双重的，一方面可以对整个文档或文档的一个细微之处进行权限设置，另一方面可以设置种类非常多的权限，而不仅仅是传统的读 /写 /不可访问三级。

依照本发明，鼓励创新，合理竟争。形成合理的产业分工后，各文档库系统厂商和各应用软件厂商就会在领域展开竟争，而不会再出现

Microsoft Word—样靠文档格式来垄断应用软件的情形发生。各文档库系统厂商也可以在标准之外增加新的功能以吸引用户，标准并不会对创新形成束縛。

依照本发明，便于优化性能，有更好的可移植性和可伸缩性。无论是什么平台，什么样的性能，都可以遵循同样的调用接口，使得在不改变接口标准的情况下可以不断优化性能，并移植到不同的平台。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明, 凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims

权利要求书

1、一种对文档实现分层处理的方法，其特征在于，所述文档分页存储，所述方法包括：

对文档中页的数据分组，每组数据为一层，所述各层按顺序排列；对所述各层分别进行管理和控制。

2、根据权利要求 1 所述的方法，其特征在于，所述对文档中页的数据分组为：按预定规则对所述数据分组。

3、根据权利要求 2 所述的方法，其特征在于，所述按预定规则对数据分组包括：

按文档的管理主体对所述数据分组;

按对文档执行操作的时间对所述数据分组; 或

按数据的功能对所述数据分组。

4、根据权利要求 1 所述的方法，其特征在于，所述层包括：文字信息、图形信息、图象信息中任一项或任几项的组合。

, 5、根据权利要求 4所述的方法，其特征在于，进一步包括：以页面描述语言描述所述层所包含的信息。

6、根据权利要求 5 所述的方法，其特征在于，不同层由不同的页面描述语言描述。

7、根据权利要求 1至 5 中任一项所述的方法，其特征在于，所述对各层分别进行管理和控制包括：

对所述某层单独进行数字签名 , 或者对所述某层及其之前的所有层进行数字签名。

8、根据权利要求 7 所述的方法，其特征在于，在增加新的层时，保持原有各层数据和各层之间相互关系不变，保持原有层已进行的数字签名有效。

9、根据权利要求 1至 5 中任一项所述的方法，其特征在于，所述文档的显示 /打印方式为：所述各层叠加显示 /打印。

10、根据权利要求 1至 5中任一项所述的方法，其特征在于，所述对各层分别进行管理和控制包括：

设置各层的显示 /打印方式，所述显示 /打印方式为水印效果、叠加或不显示 /打印。

11、一种对文档实现分层处理的方法，其特征在于，在应用软件通过文档库系统对符合通用文档模型的文档进行操作的过程中，执行如下处理：

在该应用软件对文档进行编辑时，在该文档的页对象中插入层对象，在层对象中插入版面对象，属于同一页的各层按顺序排列；

文档库系统对所述各层分别进行管理和控制。

12、居权利要求 11 所述的方法，其特征在于，所述版面对象包括：文字对象、图形对象和图象对象中任一项或任几项的组合。

13、根据权利要求 11 所述的方法，其特征在于，进一步包括：所述文档库系统以页面描述语言描述所述各层。

14、根据权利要求 11 所述的方法，其特征在于，所述对各层分别进行管理和控制包括：

对所述某层单独进行数字签名，或者对所述某层及其之前的所有层进行数字签名，数字签名的结果保存在数字签名对象中。

15、根据权利要求 14所述的方法，其特征在于，所述插入新的层对象时或在新插入的层对象中插入子对象时，保持原有各层数据和各层之间相互关系不变，保持原有层已进行的数字签名有效。

16、根据权利要求 11至 15中任一项所述的方法，其特征在于，所述文档的显示 /打印方式为：所述各层叠加显示 /打印。

17、根据权利要求 11至 15中任一项所述的方法，其特征在于，所述对各层分别进行管理和控制包括：

设置各层的显示 /打印方式，所述显示 /打印方式为水印效果、叠加或不显示 /打印。

18、根据权利要求 11至 15中任一项所述的方法，其特征在于，所述对各层分别进行管理和控制包括：

设置各层的显示 /打印方式，如果显示 /打印某一层，则同时以叠加方式显示 /打印其之前的所有层。

19、根据权利要求 11至 15中任一项所述的方法，其特征在于，应用软件将某层对应的源文件嵌入文档；

同类应用软件再次编辑该文档的同一层时，取出该源文件进行编辑；

编辑结束后更新该层，并重新将源文件嵌入该文档。

20、根据权利要求 19所述的方法，其特征在于，所述将源文件嵌入文档包括：

在当前文档中创建一源文件子对象，将源文件嵌入该源文件子对象，该源文件子对象中记录源文件各页与文档中相应页的相应层的对应关系；

所述同类应用软件再次编辑该文档时，从所述源文件子对象中取出该源文件进行编辑。

21、根据权利要求 20所述的方法，其特征在于，所述将源文件嵌入该源文件子对象为：采用二进制数据的方式将源文件整体嵌入该源文件子对象。

22、一种对文档实现分层处理的系统，其特征在于，包括：第一单元，用于分页存储所述文档；

第二单元，用于对所述文档中页的数据分组，每组数据为一层，所述各层按顺序排列；

第三单元，用于对所述各层分别进行管理和控制。

23、根据权利要求 22所述的系统，其特征在于，所述第三单元包括：

用于对所述层单独签名的子单元；或者

用于对所述层及其之前的所有层签名的子单元。

24、根据权利要求 22所述的系统，其特征在于，所述第三单元包括：用于设置各层的显示方式的子单元。

25、一种文档库系统, 其特征在于，包括：

第一单元，用于在对文档进行编辑时, 在该文档的页对象中插入层对象，在层对象中插入版面对象，属于同一页的各层按顺序排列；第二单元，用于对所述各层分别进行管理和控制。

26、根据权利要求 25所述的系统，其特征在于，还包括:

第三单元，用于将某层对应的源文件嵌入文档；

第四单元，用于在应用软件再次编辑该文档的同一层时，取出该源文件进行编辑；

第五单元，用于在编辑结束后更新该层，并重新将源文件嵌入该文档。

27、根据权利要求 25 所述的系统，其特征在于，所述第二单元包括：

用于对所述层单独签名并将签名结果保存在数字签名对象的子单元；或者

用于对所述层及其之前的所有层签名并将签名结果保存在数字签名对象的子单元。

28、根据权利要求 25 所述的系统，其特征在于，所述第二单元包括：用于设置各数据层的显示方式的子单元。

29、一种文档处理系统，其特征在于，包括：

应用层，用于通过文档库系统对符合通用文档模型的文档进行操作；文档库系统，用于在应用层对该文档进行编辑时，在该文档的页对象中插入层对象，在层对象中插入版面对象，属于同一页的各层按顺序排列；对所述各层分别进行管理和控制。