CN101322136A

CN101322136A - 一种文档数据安全管理方法和***

Info

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

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文档，也就是说，不能实现 FDF文档的互操作性。而且，无论是 Acrobat还是 Office, 都只能对单文档进行处理，缺乏对多文档的管理功能，不具备对文档库进行操作的功能。然而，在文档信息安全方面，现有技术还存在较多缺陷。 Word和 PDF这些应用最广泛的文档，都是采用对数据加密或者口令认证等进行数据安全控制，没有提供***的身份认证机制，对权限的控制都是整个文档范围的，不能细化到文档内的任意区域，对逻辑数据指定加密和签名是受限的，无法对任意逻辑数据设定加密和签名。内容管理***虽然能够提供很好的身份认证机制，但由于与文档处理***是分离的，不能在核心层集成，不仅管理粒度只能做到文档级，而且在文档使用过程中就脱离了内容管理***的安全控制，难以进行必要的安全管理。通常情况下，安全机制与文档处理是分离的模块，容易出现安全缝隙。

下面介绍现有的一些安全管理技术和概念：

目前的安全管理技术通常采用非对称密钥加密算法也叫公开密钥体系（Public Key Infrastructure, PKI )算法，其主要指加密密钥和解密密钥不相同，而且相互之间不存在推导关系，用户公开其中一个密钥并不会泄漏另一把密钥。这样其他人可以用公钥对发送的信息进行加密，安全地传送到该用户，然后由该用户用自己的私钥进行解密。 ΡΚΙ技术解决了密钥的发布和管理问题，是目前常用的密码技术。使用 ΡΚΙ技术，进行数据通信的双方可以安全地确认对方身份和公开密钥，提供通信的可鉴别性。目前，常用的 ΡΚΙ 算法有椭圆曲线密码加密算法（Elliptic Curves Cryptography, ECC ), RSA加密算法 ( Ron Rivest, Adi Shamir, Len Adleman公私钥算法）等。以下分别对 RSA加密算法和椭圆曲线密码加密算法加以简述。

1、 RSA算法

公钥： n=pq, ( p, q为两个不同的很大的盾数， p和 q必须保密）将 (p-1)和 (q-1)相乘得到 φ(η)

选择一个整数 e ( Ke<9(n) )与 φ(η)互质私钥： d=e-lmodcp(n), 即计算一个数字 d, 使得它满足公式 de=l modcp(n)

力口密： c=mc(mod n)

解密： m=cd(mod n), m为明文， c为密文。

2、椭圆曲线密码加密算法（ECC )

其为另一种非对称密钥加密算法，将椭圆曲线用于密码算法。该算法问世以来一直是密码分析学的研究对象。现在，在商业和政府的用途中，椭圆曲线密码***（ ECC )都被认为是安全的。才艮据已知的密码分析学知识 , 椭圆曲线密码***相比于传统的密码***来说提供了更高的安全性。

下面对 ECC加密算法描述如下：

大素数域上的椭圆曲线可通过同构映射将一般的曲线方程变换为特别简单的形式： y2=x3+ax+b , 其中曲线参数 a, b ^ Fp 并且满足 4a3+27b2≠0(mod p)。

因此，满足下列方程的所有点 (x,y), 再加上无穷远点 0∞ , 构成一条定义在大素数域 Fp上的椭圆曲线。

Y2=x3+ax+b (mod p)

其中 x, y属于 0到 p-1间的大素数，并将这条椭圆曲线记为 Ep(a,b)。考虑如下等式：

K=kG [其中 K,G为 Ep(a,b)上的点 , k为小于 n ( n是点 G的阶）的整数，不难发现，若给定 k和 G, 则根据加法法则，计算 K很容易；但若给定 K和 G, 则求 k就相当困难了。

这就是椭圆曲线密码***基于的数学难题。把点 G称为基点（base point ), k ( k<n, n为基点 G的阶）称为私有密钥（private key ), K称为公开密钥（public key )。加密算法还可以是公知的对称算法，对称算法就是指加密和解密过程均采用同一把密钥。如： AES算法，其目的是开发一种新的能保证政府信息安全的编码算法。最后经过多方评估从 15种算法中选出 Rijndael 算法作为 AES编码标准算法。 AES算法是对称加密的迭代分组密码。它把数据块分成比特阵列，每一项密码操作都是面向比特的。 Rijndael 算法分为四层，第一层是 8x8比特置换（即输入 8比特，输出 8比特）；第二、三层是线性混合层（阵列的行移位、列混合）；第四层是子密钥与阵列的每比特异或。

AES的分组长度为 128比特，密钥长度为 128/192/256比特，相对应的轮数 r为 10/12/14, 相应的密钥方案为：在加密的过程中，需要 r + 1个子密钥，需要构造 4 ( r + 1 )个 32比特字。当种子密钥为 128和 192比特时，构造 4 ( r + 1 )个 32比特字的过程是一样的。但当种子密钥为 256比特时，构造 4 ( r + 1 )个 32比特字的过程是不同的。

另外，哈希（HASH )也是安全信息管理方面常用的概念，其也称为散列或消息摘要或数字摘要，就是通过把单向 HASH 函数应用于信息，将任意长度的一块数据转换为一段定长的、不可逆转的数据，称为该数据的 HASH值。从理论上讲，任何 HASH算法，产生碰撞（即两块不同的数据具有相同的 HASH值）是必然的。 HASH算法的安全性有两层含义：一、由 HASH值不能反推出原数据；二、要构造两块具有相同 HASH值的不同的数据在计算上是不可行的，尽管理论上是存在的。目前 MD5、 SHA1和 SHA256被认为是比较安全的 HASH算法。另一方面， HASH函数的计算一般都比较快，相对筒单。发明内容

本发明提出了一种文档数据安全管理方法和***以及文档库***，以克服上述文档处理技术中的安全缺陷，其具有强大的嵌入式信息安全功能，在核心层紧密结合信息安全技术，为文档提供最大程度的安全性。

为实现本发明目的，本发明公开了如下技术方案：

本发明公开了一种文档数据安全管理方法，应用于对符合通用文档模型的文档或文档库进行管理的文档库***，其包括：

创建所述文档库或文档的角色；

为所述角色分配权限；

以角色登录所述文档或文档库；

在通过该文档库***访问该文档或文档库时，检查已登录角色的权限。上述方案中，所述为所述角色分配权限可包括：为角色分配针对所述通用文档模型中部分或全部对象的权限。所述通用文档模型中部分或全部对象可包括：文档库对象、文档集对象、文档对象、页对象、层对象、对象组和版面对象中任一项或任意组合。

上述方案中，所述为角色分配权限，包括：应用软件发出授权请求, 该授权请求要求针对目标对象为目标角色分配目标权限；计算该应用软件已登录的所有角色对该目标对象的权限的并集，如果该并集是该目标权限的超集并同时拥有再授权权限，则将该目标权限增加到该目标角色的权限中。

上述方案中，在将目标权限增加到该目标角色的权限中之后，如果该目标权限包含读权限，则可进一步包括：以加密方式存储目标对象，将其解密密钥存入目标角色中。

上述方案中，在将目标权限增加到该目标角色的权限中之后，如果该目标权限包含写权限，则可进一步包括：以加密方式存储目标对象，将其加密密钥存入目标角色中。

上述方案中，所述将解密密钥存入目标角'色中可包括：用角色对应的密钥对该解密密钥进行加密后，存储密文。

上述方案中，所述将加密密钥存入目标角色中可包括：用角色对应的密钥对该加密密钥进行加密后，存储密文。

上述方案中，所述以加密方式存储目标对象可包括：生成随机对称密钥和随机 PKI密钥；用该对称密钥对以该目标对象进行加密；使用该 PKI加密密钥加密该对称密钥，存储加密后的密文，并对该目标对象进行签名。上述方案可进一步包括：对文档库或文档中的对象进行数字签名。

上述方案中，所述对对象进行数字签名可包括：对该对象进行正则化，计算正则化结果的 HASH值，并将 HASH值发给应用软件；应用软件使用已登录的所有角色的私钥对该 HASH值进行加密，将签名结果回传。

本发明还公开了一种正则化方法，用于对树形结构进行正则化，包括：按预定遍历顺序计算该树形结构中的每一结点的正则结果，并组合成该树形结构的正则结果。

上述方案中，所述计算一个结点的正则结果可包括：将该结点的子结点数、类型、各属性的原值或变换值按照预定顺序连接起来，再取连接结果的原值或变换值作为该结点的正则结果。

上述方案中，所述计算一个结点的正则结果可包括：将该结点的子结点数、类型和各属性的原值或变换值，以及子结点数、类型和各属性的长度的原值或变换值中任一项或任意组合按照预定顺序连接起来，再取连接结果的原值或变换值作为该结点的正则结果。

本发明又公开了一种文档库***，用于对符合通用文档模型的文档或文档库进行安全管理，包括：

角色管理单元，用于创建所述文档或文档库的角色，为所述角色分配权限；

身份认证单元，用于在角色登录所述文档或文档库，通过所述角色管理单元验证该角色的身份；

访问控制单元，用于在访问该文档或文档库时通过所述角色管理单元和身份认证单元检查已登录角色的权限。

根据权利要求 35 所述的***，其特征在于，所述角色管理单元进一步用于为角色分配针对所述通用文档模型中部分或全部对象的权限。

上述***中，所述通用文档模型中部分或全部对象可包括：文档库对象、文档集对象、文档对象、页对象、层对象、对象组和版面对象中任一项或任意组合。

本发明还公开了一种文档数据安全管理***，用于对文档进行安全管理，其包括：

角色管理单元，用于创建所述文档的角色，为所述角色分配对文档对象、页对象或页对象的子对象的权限；

身份认证单元，用于在角色登录所述文档，通过所述角色管理单元验证该角色的身份；

访问控制单元，用于在访问该文档时通过所述角色管理单元和身份认证单元检查已登录角色的权限。依照本发明，基于应用层和数据处理层分离的文档处理技术，可将信息安全集成在文档处理的核心层，可以消灭安全缝隙，还能使安全机制与文档操作紧密地结合为一体，而不是可以分离的两个模块，同时有更多的空间部署安全管理技术，相关代码也能隐藏得更深， .能更有效地防御非法攻击，提高安全可靠度，另外还能提供细粒度的安全管理手段, 如更多的权限类别，更小的管理单元。本发明还提出了一个通用文档安全模型，该通用文档安全模型符合各应用软件对文档安全的需求，使不同的应用软件都可以通过同一个接口部实现对文档的安全控制。

本发明的有益效果是：文档数据安全管理***集成了身份认证机制，可以对任意的逻辑数据指定访问控制权限，也可以对任意逻辑数据进行加密，并且这种加密是与身份认证关联的，其可以关联到任意指定的一个或者多个角色，本发明***还可以对任意的逻辑数据进行签名，从而达到具有多重的安全特性文档数据安全管理，保证文档数据不被破坏。附图简要说明

图 1为文档处理***的结构框图。

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

图 4示出了图 3所示文档库对象中文档库辅助对象的组织结构。图 5示出了图 3所示文档库对象中文档集对象的组织结构。

图 6示出了图 5所示文档集对象中文档对象的組织结构。

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

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

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

图 10为以 UOML接口为例子的文档处理***。

图 11为本发明文档数据安全管理方法流程图。实施本发明的方式

以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用于解释本发明，并不用于限定本发明。

1U 本发明安全管理方法及***主要应用于如下所述的文档处理***。为解决现有文档处理软件存在的通用性较差、文档信息提取困难、访问接口不统一、数据兼容困难或代价太高、可移植性和可伸缩性较差、页面分层的技术不完善、检索手段单一等问题，本发明改变了从用户界面到文档存储都由一个软件来完成的现状，将其划分为应用层和文档库 ***层，并定义一个规范两层之间交互的接口标准，还可以进一步构建一个符合该接口标准的接口层。文档库***是具备各种文档操作功能的通用技术平台，应用软件要对文档进行操作时就通过该接口层来向文档库***发出相应指令，文档库***根据该指令执行相应操作。这样，只要各应用软件和各文档库***都遵循同样的标准，不同应用软件就可以通过同一个文档库***对同一文档操作，即可实现对文档的互操作。同样，同一个应用软件也可以通过不同文档库***对不同文档进行操作，而不用分别对每种文档格式都进行单独开发。

另外，该技术还提出了一个通用文档模型，该模型能与各应用软件所需要处理的文档相符合。接口标准就是基于该文档模型来确定的，这样才能实现不同的应用软件都可以通过接口层来对文档进行操作。该通用文档模型也适用于各种文档格式，这样同一个应用软件才可以通过接口层来对不同文档格式进行操作。其中，接口标准定义了基于该通用文档模型对文档进行操作的各种指令，以及应用软件向文档库***发送指令的方式。文档库***具备实现这些指令的功能，以供应用软件调用。该通用模型还包括由多个文档组成的文档集、文档库和文档仓库等层次，接口标准中也包含对多文档的組织管理、查询检索、安全控制等指令。该通用模型还包括将页由具有上下顺序的层组成，接口标准中也包含对层的各种操作指令，以及对一个文档某一层所对应源文件的存储和提取。文档库***还具备对文档的信息安全管理控制功能，如基于角色的细粒度权限管理，并在接口标准中定义了相关的操作指令。

依照本发明，使得应用层和数据处理层分离。这样应用软件不再直接跟具体的文档格式打交道，文档也不再与特定应用软件绑定，从而使得同一文档能在不同的应用软件之间通用，同一应用软件也能对不同文档进行操作，实现了文档的互操作；整个文档处理***还具备多文档处理功能，而不局限在单文档处理；将页分成多层后，可以实现对不同层实施不同管理和控制，更便于不同应用软件对同一页的操作（可以设计成不同应用软件管理和维护不同层），为以源文件方式进行编辑提供了便利，也是一种艮好的保留历史痕迹的方式。

下面，参照附图 1 ~ 10描述本发明安全管理方法及***所应用的文档处理***。

如图 1所示，依照本发明的文档处理***主要包括应用软件、接口层、文档库***和存储设备。用软件都位于文档处理***的应用层，通过发送符合接口标准的指令来对文档进行操作，所述操作都是对符合通用文档模型的文档进行的 , 与具体存储格式无关。

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

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

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

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

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

以下对本发明应用的文档处理***的具体实施方式进行阐述。

通用文档模型

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

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

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

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

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

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

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

每页又由一层或按一定顺序（如上下顺序）的多层组成，各层之间如同玻璃板的叠加关系。层由任意数量的版面对象和对象组组成，版面对象是指状态（如字体、字号、颜色、 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 UOI— InsertPage (UOI— Doc *pDoc, int nPage)", 上接口单元调用这些标准函数，调用操作本身.就代表上接口单元发出了标准指令；或者是上述方法的组合。接口标准采用 "操作动作 +操作对象"的方式来实现便于学习和理解，也便于保持接口标准的稳定性。例如，对 20种不同对象进行 10种操作，可以定义 20x10=200种指令，也可以定义 20种对象和 10种动作，但显然后一种方式大大减轻了记忆的负担，而且今后在对接口标准进行扩充时，增加一个对象或动作也 4艮筒单。所述操作对象为通用文档模型所包含的对象。

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

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

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

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

设置：用于设置 /4务改对象数据；

***： ***指定对象或数据；

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

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

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

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

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

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

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

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

通过获取版面位图的指令，应用软件可以直接获取指定页面的指定位图格式的版面位图，即以位图方式表示的该页面的显示效果，而不用自行解释处理每一个版面对象。也就是说，应用软件可以直接获得准确的版面位图用于显示 /打印文档，而不再需要自己逐个读取页面上每一层的每一个版面对象、自行解释该对象的含义并在版面上体现出来。如果采用后一种方式的话，就又难免出现有的软件解释的比较全、比较准确，有的软件解释的不全或不准确，导致同一个文档在不同软件出现不同的显示 /打印效果，影响了文档互操作的用户体验。通过由文档库系统统一生成版面位图的方式，将保持版面一致性的关键点从应用软件移到了文档库***，从而为不同的应用软件打开同一文档都能出现同样的版面效果提供了可行之路。这一方面是因为文档库***是统一的基础技术平台，其完整准确地解释处理各版面对象是可行的，. 而同样的要求对应用软件来说就不太可行；另一方面是因为不同应用软件都可以与同一个文档库***配套使用 , 这样就更能确保显示 /打印效果的一致性了。筒单来说，就是要求应用软件之间保持一致不太可行，而要求文档库系统之间保持一致则是可行的，要求同一个文档库***保持一致就更没问题了。因此，为了保持同一文档在不同应用软件之间的版面一致性，就需要把相关责任从应用软件转移到文档库***，而由文档库***来统一生成版面位图是其中一个简单易行的办法。更进一步，获取版面位图的指令还可以指定页面上的一个区域，可用于只显示页面的一个区域，例如当页面比屏幕大时就不需要显示整页，滚动页面时也只需要重画滚动的区域；当该指令还允许指定获取特定层组成的版面位图 , 特别是可以指定由特定层以及该层下的所有层组成的版面位图时，可以很好地用于展现历史痕迹，即可以查看在添加最近这一层之前或更早以前的版面效果。如果需要的话，还可以具体指定哪一层参与位图的生成，哪一层不参与。

以下是用 "操作动作 +操作对象"的方式实现接口标准的一个实施例，在该实施例中，接口称为非结构操作标记语言（UOML )，是用可扩展标记语言（XML )描述的一系列的命令。上接口单元生成符合 UOML格式的字符串，并将该字符串发送给下接口单元，就将相应的操作指令发送给了文档库***。文档库***执行这些命令后，下接口单元将执行结果也生成一个符合 UOML格式的字符串，返回给上接口单元，使应用软件能够知晓操作执行结果。

所有执行结果都由 UOML— RET表示，其定义如下：

属性：

SUCCESS:值为真（true ) 时表明操作成功，否则失败。

子元素：

ERR_INFO: 可选，仅当操作失败时出现，描述了相应的错误信息。其它子元素：据具体命令确定，可参考各命令说明。

UOML动作包括：

1 UOML— OPEN创建或打开文档库。

1.1属性

1.1.1 create: 为 true时是创建，否则是打开已有文档库。

1.2子元素： 1.2.1 path:文档库路径。可以是磁盘文件名，也可以是 URL, 或者是内存指针，或者是网络路径，或者是文档库的逻辑名称，或者其它能够指定文档库的表示方法。

1.3返回值：

如果成功，则在 UOML—RET中包含一个" handle，，子元素， •己录句柄 2 关闭 (UOML— CLOSE)

2.1属性：无。

2.2子元素：

2.2.1 handle: 对象句柄，是一个字符串表示的对象的引用指针。

2.2.2 db— handle: 文档库句柄，字符串表示的文档库的引用指针。 2.3返回值：无返回值。

3 UOML—GET获取。

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 设置

4.1属性：无。

4.2子元素：

4.2.1 Handle: 设置对象的句柄。

4.2.2 xobj: 对象的描述。

4.3返回值：无返回值。

5 UOML— INSERT ***

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 删除 6.1属性：无。

6.2子元素：

6.2.1 handle: 需要删除的对象的句柄。

6.3返回值：无返回值。

7 UOML— QUERY 检索查询

7.1属性：无。

7.2子元素：

7.2.1 handle: 需要查询的文档库句柄。

7.2.2 condition: 查询条件。

7.3返回值：如果成功，在 UOML— RET中包含一个" handle"子元素代表查询结果的句柄，一个" number"子元素代表查询结果的数量，可以用 UOML— GET来获取每一个查询结果。

UOML对象包括：

文档库（UOML— DOCBASE)、文档集（UOML_DOCSET)、文档 (UOML_DOC)、页（UOML_PAGE)、层（UOMLJLAYER)、对象组 (UOML_OBJGROUP)、文字 (UOML— TEXT)、图像 (UOMLJ AGE)、直线 (UOML— LINE)、曲线 (UOML_BEIZER)、圓弧 (UOML— ARC)、路径 ( UOML— PATH ) , 源文件（UOML— SRCFILE) 、背景色 ( UOML_BACKCOLOR ) 、前景颜色（UOML— COLOR) 、 ROP(UOML_ROP) 、字符尺寸（UOML— CHARSIZE) 、字体 (UOML— TYPEFACE)。

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

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 (文本方向）、 shadowwidtli (阴影宽度）、 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 Controll— 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命令，再将该 UOML命令发给文档库***，即代表应用软件向文档库***发出了操作指令。

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

<UOML_OPEN create="true">

</UOML_OPEN>

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

<UOML_INSERT >

<xobj>

</xobj>

</UOML_INSERT>

需要说明的是，虽然 UOML是用 XML定义的，但为了显得更加筒洁，在前面省略了类似" <?xml version="1.0" encoding="UTF-8"?>，，以及 "xmlns:xsi= "http：〃 www.w3.om/2001/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"子元素，表示新***文档集的句柄

这样上述命令就变为如下格式：

<U0ML— INSERT— DOCSET >

<parent val=" 123.456.789"/〉

</U0ML— INSERT— DOCSET >

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

此外，接口标准可以用函数调用的方式来实施，即通过上接口单元调用下接口单元的接口函数的方式来发送操作指令给文档库***。以下以 C++语言为例说明，该接口实施例被称为非结构化操作接口（U0I )。

1、定义一个 U0I返回值结构： struct UOI— Ret {

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

CString m— Errlnfo;//如果操作不成功，错误信息是什么

};

然后，定义所有 UOI对象的基础类：

class UOI— Obj ect {

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— Obj ect * Create(Type objType); //根据指定类型创建相应对象

};

2、定义如下几个 UOI 函数,它们与第一个实施例中的几个 UOML 动作相对应，包括：打开或创建文档库，成功则将其句柄返回在 pHandle中：

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

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

UOI— RET UOI_Close(HA DLE 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(HA DLE 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 liDocbase, const char *strCondition, HANDLE *phResult, int *pResultCount);

3、定义各 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,

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；

UOI— CharSize();

virtual〜UOI—CharSize();

}；

以下示例说明 UOI的使用方法。首先是创建文档库操作：

ret = UOI_Open("f:\\data\\docbasel.sep", TRUE, &hDocBase); 4、构建一个创建新对象的函数：

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

{

UOI— Ret ret;

HAD LE handle；

UOI—Obj *pNewObj = UOI_Obj::Create(type);

if (pNewObj == NULL) return NULL;

ret = UOI_Insert(hParent, nPos, pNewObj, &handle) ;

delete pNewObj； .

return ret.m_bSuccess？ handle： NULL;

}

5、直接获取对象的函数：

UOI—Obj *GetObj(HANDLE handle)

{

UOI— Ret ret;

UOI— Object ::Type type;

UOI—Obj *pObj;

ret = UOI_GetObj Type(handle, &type);

if ( !ret. m_bSuccess )

return NULL;

pObj = UOI_Obj::Create(type);

if (pObj == ULL)

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:是否覆盖原文件

* \retum UOI— DocBase对象

*/

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

/*!

* \brief 打开文档库

* \param szPath: 文档库全路径

* \return UOI— DocBase对象

*/

BOOL Open(const char * szPath);

/* !

* \brief 关闭文档库

* \param 无

* Vretum 无

*/

void CloseQ; T N2006/003294

/*!

* \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);

/* t

* \brief 获取文档集的总数

* \param 无

* \retum 文档集个数

*/

int GetDocSetCoimtO;

/* t

* \brief 设置文档库的名称

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

* \param szName: 文档库名称

* \return 无

*/

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

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

* \param 无

* \retum 长度

*/

int GetNameLen();

/* !

* \brief 获取文档库名称

* \param 无

* \return 文档库名称

*/ const char* GetName();

* \brief 获取文档库 id长度

* \param 无

* \return 长度

*/

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— ASCII,

CHARSET_GB 13000,

CHARSET— UNICODE,

}；

//! 获得文本的编码

UOI— TextEncoding GetEncoding();

//! 设置文本的编码

void SetEncoding(UOI— TextEncoding nEncoding );

//! 获得文本的数据

const char * GetTextData();

//! 获得文本的数据长度

int GetTextDataLen();

//! 设置文本的数据

/*!

\param pData文本数据

\param nLen数据长度

*/

void S etTextData(const char * pData, int nLen);

//! 获得起点位置

Point GetStartPointO;

//! 设置起点位置

void SetStartPoint(Point startPoint); //! 获得字符间距表大小

int GetCharSpacingCount();

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

float GetCharSpacing(int nlndex);

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

bool S etCharSpacingCount(int nLen);

//! 设置字符间距

bool SetCharSpacing (int nlndex, float charSpace );

//! 获得文本的外框

UOI Rect GetExtentArea()；

class UOI—RoleList： public UOI—Obj

{

public:

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

int GetRoleCount();

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

UOI— Role *GetRole(int nlndex);

//! 创建角色

/*!

\param pPrivKey私胡緩冲区

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

\retum新创建的角色

*/

UOI— Role AddRole(unsigned char *pPrivKey, int *pn eyLen) //! 构造函数

UOI_RoleList();

//! 析构函数

virtual ~UOI_RoleList();

}； class UOI—Role ： public UOI—Obj {

public:

//! 构造函数

UOI_Role();

//! 析构函数

virtual〜UOI—Role();

//! 获得角色 ID

int GetRoleID();

//! 设置角色 ID

/*!

\param nlD角色 ID

*/

void SetRoleID(int nlD);

//! 获得角色名称

const char * GetRoleName();

//! 设置角色名称

\param szName 角色名称 void SetRoleName(const char *szName);

}； class UOI__PrivList： public UOI_Obj 〃权限列表

{ ,

public:

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

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

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

UOI— RolePriv *pPriv AddRole ();

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

int GetRolePrivCount()；

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

UOI— RolePriv *GetRolePriv (int nlndex);

//! 构造函数

UOI_PrivList();

//! 析构函数

virtual ~UOI_PrivList();

}； class UOI— RolePriv ： public UOI—Obj II对应于某一个角色的所有权限

{

public:

//! 获得角色

UOI一 Role *GetRole();

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

bool SetPriv(UOI_Obj *pObj, UOI_Priv *pPriv);

〃！获得权限设置数量

int GetPrivCount();

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

UOI—Obj *GetObj(int nIndex);

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

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_W ITE, 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

{

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

{

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

{ public:

//! 构造函数

UOI_SignDepList();

//! 析构函数

virtual ~UOI_SignDepList();

//! 加入一个依赖项

void InsertSignDep(UOI— Sign *pSign);

//! 获得依赖项的数目

int GetDepSignCount();

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

UOI— Sign *GetDepSign(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. 执行获取版面信息指令时，先生成一个指定位图格式的空白位图，其尺寸和指定区域相同，然后遍历指定页面的所有版面对象，凡是位于指定区域内（包括只有一部分在该区域内）的版面对象，都解释其含义，并在版面上相应体现。具体过程虽然比较复杂比较专业，但均属于现有 RIP技术范畴，就不在此赘述。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

d) 鉴于 PKI的加密 /解密效率较低，为提高运行效率，也可以用对称密钥来对该数据区域加密，加密密钥用于对该对称密钥进行加密，解密密钥用于解密经过加密后的密钥数据，从而获得正确的对称密钥。为防止只有读权限的角色在获得对称密钥后用其修改数据 , 可以用加密密钥来对该数据区域进行数字签名，每次拥有写权限的角色修改该数据区域后都重新做一次签名，从而确保数据不会被没有写权限的角色墓改。 ' e) 当授予某一角色加密密钥或解密密钥时，可以用该角色的公钥对该密钥加密后存储，这样只有拥有该角色的私钥时才能取出该密钥在本实施例中，本发明的文档数据安全管理***和方法是针对上述文档库***而进行的描述，但本发明同样适用除了以上提到的***之外的任何其他***。

以下先详细说明本发明的文档数据安全管理***。

本发明文档数据安全管理***包括：角色管理单元、安全会话通道单元、身份认证单元、访问控制单元和签名单元。其中，角色管理单元用于管理至少一个角色，具有角色的创建、各角色的权限的授权、收回授权等功能。角色可以由至少一个唯一的 ID号和至少一对唯一的 PKI 密钥来表征，但在角色对象中只存储其 ID号和公钥，私钥由应用软件掌握。角色也可以由一个唯一的 ID 号和登录口令来表征，在角色对象中只保存其 ID号和加密后的登录口令。 ID号可以是任意的编号或字符串，只要不同角色都分配了不同的 ID即可。 PKI算法可以是 ECC、 RSA 中的一种。

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

优选地，任何应用软件都有权创建没有任何权限的新角色。可以用具有再授权权限的角色对新角色授予一定的权限。

创建角色对象的指令返回的密钥将作为今后登录该角色的依据，该密钥需要由应用软件妥善保管，该密钥通常是 PKI的私钥，该密钥也可以是登录口令。

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

应用软件从以某个角色（或多个角色）登录、执行一系列操作到最后注销的整个过程称为会话。会话可由会话标志、登录角色列表等来表通道单元用于保存至少一个会话密钥，用于使用会话密钥加密在安全会话通道之间传递的数据。该会话密钥可以为非对称密钥，也可以为常用的效率更高的对称密钥。

身份认证单元用于当角色登录时对登录的身份进行认证。其中，身份认证的单位是角色，除缺省角色外，只有拥有某个角色的密钥时才能以这个角色的身份登录。在登录时，若该角色的密钥为 PKI密钥，则身份认证单元才艮据登录角色的 ID取出存储在角色对象中的角色公钥，按照前述的"挑战-应答"机制进行认证；若该角色的密钥为登录口令，则身份认证单元根据登录角色的 ID取出存储在角色对象中的登录口令进行比较认证。

应用软件可以同时以多个角色身份登录，此时该应用软件拥有的权限是各角色权限的并集。

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

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

这里，访问权限包括读权限（指示是否可读）、写权限（指示是否可写）、再授权权限（指示是否可再授权，即：使其他角色拥有自己的部分或全部杈限）、回收授权权限（指示是否可收回授权，即：去掉其他角色的部分或全部授权）、打印权限（指示是否可打印）及上述权限的任意组合，本发明对此不作限定。优选地，文档库初始创建时就自动创建一个拥有所有权限的缺省角色，从而使文档库的初始创建者具有对该文档库的所有权限。签名单元，用于在文档数据安全管理***中，对文档数据的任意指定的逻辑数据进行签名，可利用私钥通过该签名单元进行角色签名，并可利用公钥验证在逻辑数据中角色签名的合法性。

可以用某个角色的身份对各对象进行签名。签名范围将包括该对象的子对象以及该对象引用到的对象。

下面结合上述安全管理***进一步详细说明本发明的文档数据安全管理方法：

如图 11所示，本发明文档数据安全管理方法包括如下操作步骤：

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

2. 安全会话通道单元建立应用软件和文档库***之间的安全会话通道，启动会话。

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

b) 应用软件和文档库中的一方生成一对随机 PKI密钥对;

c) 生成一对随机 PKI密钥对的一方将公钥发送给对方;

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

e) 该生成一对随机 PKI密钥对的一方用私钥解密出会话密钥; f) 设置会话标志；

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

3. 角色登录

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

c) 若该角色密钥为 PKI 密钥，身份认证单元取出存储在角色对象中的角色公钥；若该角色密钥为登录口令，执行歩骤 h )。

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

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

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

g) 身份认证单元判断传回的数据是否正确，如果不正确则登录失败，否则执行步骤 i );

h) 应用软件提供登录口令，身份认证单元将角色对象中保存的登录口令与应用软件提供的登录口令相比较，如果比较正确则登录成功，继续执行；否则登录失败；

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

4. 创建新角色

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

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

c) 若该指令要求创建的角色的密钥为 PKI密钥，则角色管理单元生成一对随机的 PKI密钥对；若该指令要求创建的角色的密钥为登录口令，则该角色的登录口令为该指令指定的登录口令，该角色的登录口令也可以由角色管理单元随机生成。

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

e) 将 ID号和密钥（所述私钥或登录口令 )返回给应用软件。 5. 授与角色 R针对对象 0的权限 P

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

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

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

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

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

i. 生成随机对称密钥和随机 PKI密钥。

ii. · 用对称密钥对对象 O进行加密。如果对象 0的各级子对象中有已经设置了读写访问控制权限的，则该子对象保持不变。

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

iii. 用 PKI加密密钥加密对称密钥，存储加密后的密文，并对对象 0进行签名。

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

' 列表中。

v. 执行步骤 h。

e) 从当前登录的角色中，选择针对对象 O具备相应权限的角色。 f) 取出该角色权限列表中对象 O的对应密钥（读权限对应解密密钥，写权限对应加密密钥，可读可写则包含两个密钥）的密文，若该角色的密钥是 PKI密钥则将该密文发送给应用软件并转步骤 g ),若该角色的密钥是登录口令则访问控制单元对该密文解密后并转步骤 h)。

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

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

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

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

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

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

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

c) 从角色 R对对象 0的权限中去掉权限 P。

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

7. 读取对象 0

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

b) 访问控制单元检查登录角色列表中所有角色对对象 0 的权限，确认是否至少有一个角色对对象 0有读权限。如果无，则失败，如果有，则继续。

c) 检查对象 0是否已经设置了读写的访问控制权限，如果否，则检查其父对象，若还不是的话则再检查该父对象的父对象，直到找到了设置读写访问控制权限的对象。

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

e) 取出该角色权限列表中保存的该对象的解密密钥的密文，若该角色的密钥为 PKI密钥则将该密文发送给应用软件，转步骤 f), 若该角色的密钥为登录口令则由访问控制单元将该密文解密，转步骤 g )。

f) 应用软件用该角色的私钥解密出解密密钥，返回给访问控制单元。

g) 访问控制单元用该解密密钥解密出该对象的对称密钥。

h) 用该对称密钥解密出对象 o的数据。

i) 将解密后的数据返回给应用软件。 8. 写对象 O

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

b) 访问控制单元检查登录角色列表中所有角色对对象 0 的权限，确认是否至少有一个角色对对象 0有写权限，如果无，则失败，如果有，则继续。

c) 检查对象 O是否已经设置了读写的访问控制权限，如果否，则检查其父对象，若该父对象还不是的话则再检查该父对象的父对象，直到找到了设置读写访问控制权限的对象 01。

d) 选择一个对对象 Ol有写权限的角色。

e) 取出该角色权限列表中保存的对象 01的加密密钥的密文，若该角色的密钥为 PKI密钥则发送该密文给应用软件并执行步骤 f),若该角色的密钥为登录口令则由访问控制单元将该密文解密并执行步骤 g )。

f) 应用软件用该角色的私钥解密出对象 Ol的加密密钥，返回给访问控制单元。

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

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

9. 对对象 O进行签名

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

b) 访问控制单元对对象 0的数据进行正则化。

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

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

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

f) 应用软件将签名结果返回给访问控制单元。

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

10. 注销登录角色

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

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

11. 结束会话

a) 应用软件和文档库***中的一方发出结束会话请求。

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

下面是本发明文档数据安全管理方法的一个计算机实现的例子： class UOI—RoleList： public UOI—Obj

{

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

{

public:

//! 构造函数

UOI—RoleO;

//! 析构函数

virtual ~UOI_Role();

//! 获得角色 ID

int GetRoleID();

//! 设置角色 ID

/*!

\param nlD角色 ID

*/

void SetRoleID(int nlD);

//! 获得角色名称

const char * GetRoleName(); //! 设置角色名称

/*!

\param szName 角色名称

*/

void SetRoleName(const char *szName);

}; class UOI— PrivList : public UOI__Obj //权限列表

{

public:

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

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

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

UOI— RolePriv *pPriv AddRoie ();

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

int GetRolePrivCount();

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

UOI— RolePriv *GetRolePriv (int nlndex);

//! 构造函数

UOI_PrivList();

//! 析构函数

virtual〜UOIJPrivList();

}； class UOI一 RolePriv ： public UOI—Obj II对应于某一个角色的所有权限

{ public:

//! 获得角色

UOI—Role *GetRole();

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

//!获得权限设置数量

int GetPrivCount();

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

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 { 〃各权限类型定义

PRIV_READ, II读权限 PRIV— WRITE, II写权限

PRIV— RELICENSE, II再授权权限

PRIV_BEREAVE, II 收回授权权限 PRTV— PRINT, II打印权限

其它权限定义

}

//! 是否有相应权限

bool GetPriv(PrivType privType);

//! 设置相应权限

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

UOI_Priv ();

//! 析构函数

virtual ~UOI_Priv ();

}; class UOI—SignList： public UOI—Obj

{

public:

//! 构造函数

UOI— SignListO;

//! 析构函数

virtual〜UOI— SignListO;

//! 添加新的结点签名,返回其索引值 int AddSign(UOI_Sign *pSign); //! 按指定索引值，获得结点签名

UOI—Sign GetSign(int index);

//! 按指定索引值，删除结点签名

void DelSign(int index);

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

int GetSignCountQ;

}; class UOI—Sign： public UOI—Obj

{

public:

//! 构造函数

UOI—SignO;

//! 析构函数 '

virtual〜UOI—Sign();

//! 执行签名

/*!

\param pDepList签名所依赖的列表

\param pRole用于签名的角色

\param pObj 被签名的对象

*/

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

//! 验证签名

bool VerifyO;

//! 获得签名的依赖列表 UOI—Sign epList GetDepList();

}; class UOI—SignDepList： public UOI—Obj

{

public:

//! 构造函数

UOI_SignDepList();

//! 析构函数

virtual ~UOI_SignDepList();

//! 加入一个依赖项

void InsertSignDep(UOI_Sign *pSign);

//! 获得依赖项的数目

int GetDepSignCount();

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

UOI— Sign *GetDepSign(int nlndex); 为了提高工作效率，在实施时还可以对上述步骤进行增强或筒化，例如将各角色私钥緩存在会话数据中（会话结束后删除），而不用每次都需要发到应用软件进行解密，或者省略一些安全措施，或者減少一些功能。总之，任何对上述方法进行筒化的方法都是本方法的变形。

本实施例通过树形的文档管理结构提供安全管理***，用角色进行身份认证，在与安全认证相关的安全会话中，可以有多个角色登陆，利用不同的角色进行身份认证，权限控制或者签名并猃证签名。当访问控制时，可以对任意的子树的文档数据指定安全控制的权限，而权限是由角色分配的。而在当前的安全会话中，对某个特定的子树的文档数据的权限是所有角色的权限的并集。在安全会话中，也可以对安全控制的文档数据的权限进行授权与回收，而这样的授权与回收都可以由角色来提供。而访问控制通过加密来进行，加密可以针对任意的子树文档数据而进行。同时，可以对任意的子树数据进行签名和签名验证，而签名是在安全会话过程中，用某个角色的私钥进行的，进行签名的私钥可以是角色列表单元中的某个角色。在树形结构的文档数据进行签名前，可以进行正则化，以确保各个结点之间的数字签名不相同。

本发明给出了一个文档数据安全管理***，提供了集成的身份认证机制、访问控制机制和签名验证机制，对文档数据进行身份认证、访问控制、签名不受特定文档数据的限制， ***中所有可能的文档数据都可以进行安全控制即认证、访问控制、签名及签名验证。

本发明中所说明的文档安全技术，例如基于角色的权限管理、安全会话通道、角色的认证方式、多重角色登陆、对树结构的正则化技术、细粒度的权限管理单元、基于加密的权限设置等，都不仅适用于本发明所述的文档处理***，还可以运用于其它环境，本发明对此不作限定。

在本发明应用的文档处理***中，为了使本文档处理***能很好地模拟纸张的特性，提供了一种"只加不改"的技术方案。也就是说，每个应用软件都只在现有文档内容基石出上添加新的内容，但不修改、不删除已有的内容，使文档的一个页面就象一张纸一样，可以由不同的人用不同的笔在纸上不断写写画画，但谁都不能修改、删除已有内容。具体方法是每一个应用软件在编辑其它软件生成的文档时，都在现有文档基础上新增加一层，将本软件新编辑的内容都放到这一层中，不修改和删除前面各层的内容。这样，每个文档的每一层只由一个应用软件来管理和维护，其他应用软件不能对该层进行编辑。由于现有社会就是基于纸张来运转的，因此只要能符合纸张的特性就能满足现有应用的需求，具备足够的实用价值。

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

前述技术方案不允许修改文档中的已有内容，即使不考虑与纸张特性的兼容以及数字签名问题，需要修改的话也只能做版面级编辑，即对每个版面对象的编辑（增、删、改）都不会对其它版面对象产生影响。如果用户需要对文档中的已有内容进行编辑，并且还希望能像在原来那样编辑的话，有一个技术方案可以很好地满足这个应用需求。该方案是当应用软件完成初始编辑时，除了新建一层存放当前编辑的内容外，还将源文件（按照应用软件自有的格式存储，记录了各对象之间完整关系的文件，例如. doc文件）嵌入到文档中。当下次需要进行继续编辑时，从文档中取出该源文件，并使用该源文件继续编辑。编辑完成后清除该 ^件所管理的那一层，重新生成该层的内容，并继续将新修改的源文件嵌入到文档中。

具体方法如下：

1.应用软件第一次处理该文档时，新建一层，将新编辑内容对应的版面对象***到新建层中，同时用自身格式另存一份新编辑的内容（即源文件）。 2.在文档对象中新建一个源文件子对象，用来嵌入源文件（例如用二进制数据的方式整体嵌入），并记录是哪一层对应该源文件对象。

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

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

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

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

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

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

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

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

4.对任何文档，使用文档已有内容的原始编辑软件可以对该内容进行正常编辑。

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

下面，参照图 10描述依照本发明的文档操作***执行一操作的一个实例。在该实例中，应用软件通过统一的接口标准（例如 UOML接口）请求对文档的操作。文档库***可能会有不同厂商的不同型号，但是对于应用开发厂商来说面向的都是同一个接口标准，因此都可以与之配套使用。 Red Office, 0CR、网页生成软件、乐 i普编辑软件、书生阅读器、 Office编辑软件、其他阅读器等通过 UOML接口指示文档库***进行操作，文档库***可以有多个，在图中显示为文档库*** 1、文档库*** 2和文档库*** 3 , 文档库***根据 UOML发来的统一标准指令对符合通用文档模型的文档进行操作，例如创建、保存、显示、呈现文档。在本发明中，不同的应用软件可以同时或不同时调用同一个文档库***，同一应用软件可以同时或不同时调用不同的文档库***。

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

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

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

Claims

权利要求书

1、一种文档数据安全管理方法，其特征在于，应用于对符合通用文档模型的文档或文档库进行管理的文档库***，包括：

创建所述文档库或文档的角色；

为所述角色分配权限；

以角色登录所述文档或文档库；

在通过该文档库***访问该文档或文档库时，检查已登录角色的权限。
2、根据权利要求 1 所述的方法，其特征在于，所述创建文档或文档库的角色，包括：应用软件通过所述文档库***创建文档或文档库的角色；

所述以角色登录所述文档或文档库，包括：应用软件通过所述文档库***登录所述文档或文档库。
3、根据权利要求 2所述的方法，其特征在于，在应用软件登录文档或文档库之前，进一步包括：该应用软件与该文档库***建立安全会话。
4、根据权利要求 3 所述的方法，其特征在于，所述该应用软件与该文档库***建立安全会话，包括：

在该应用软件与该文档库***中，一方生成随机的包括公钥和私钥的 PKI密钥对，并将该公钥发送给对方；

收到该公钥的一方生成随机对称密钥作为会话密钥，并用该公钥加密该会话密钥后传回给对方；

收到传回的经过加密的会话密钥的一方用所述 PKI密钥对中的私钥解密得到会话密钥。 5、根据权利要求 1 所述的方法，其特征在于，所述为所述角色分配权限，包括：为角色分配针对所述通用文档模型中部分或全部对象的权限。
6、根据权利要求 5 所述的方法，其特征在于，所述通用文档模型中部分或全部对象，包括：文档库对象、文档集对象、文档对象、页对象、层对象、对象组和版面对象中任一项或任意组合。
7、根据权利要求 5 所述的方法，其特征在于，所述为角色分配权限，包括：

应用软件发出授权请求，该授权请求要求针对目标对象为目标角色分配目标权限；

计算该应用软件已登录的所有角色对该目标对象的权限的并集，如果该并集是该目标权限的超集并同时拥有再授权权限，则将该目标权限增加到该目标角色的权限中。
8、根据权利要求 7 所述的方法，其特征在于，在将目标权限增加到该目标角色的权限中之后，如果该目标权限包含读权限，则进一步包括：以加密方式存储目标对象，将其解密密钥存入目标角色中。
9、根据权利要求 7 所述的方法，其特征在于，在将目标权限增加到该目标角色的权限中之后，如果该目标权限包含写权限，则进一步包括：以加密方式存储目标对象，将其加密密钥存入目标角色中。
10、根据权利要求 8所述的方法，其特征在于，所述将解密密钥存入目标角色中，包括：用角色对应的密钥对该解密密钥进行加密后，存储密文。
11、根据权利要求 9所述的方法，其特征在于，所述将加密密钥存入目标角色中，包括：用角色对应的密钥对该加密密钥进行加密后，存储密文。 12、根据权利要求 8 - 11中任一项所述的方法，其特征在于，所述以加密方式存储目标对象，包括：

生成随机对称密钥和随机 PKI密钥；

用该对称密钥对以该目标对象进行加密；

使用该 PKI加密密钥加密该对称密钥，存储加密后的密文，并对该目标对象进行签名。
13、根据权利要求 1所述的方法，其特征在于，该方法进一步包括：创建文档库或文档时自动创建缺省角色，该缺省角色拥有对该文档库对象或文档对象本身及其所有子对象的所有权限。
14、根据权利要求 5 - 13中任一项所述的方法，其特征在于，所述权限包括：读权限、写权限、再授权权限和收回授权权限中的一项或任意几项的组合。
15、根据权利要求 1所述的方法，其特征在于，所述创建所述文档库或文档的角色，包括：

应用软件请求创建目标文档库对象或文档对象的新角色；

文档库***创建该新角色的角色对象。
16、根据权利要求 15 所述的方法，其特征在于，所述文档库*** 创建该新角色的角色对象，包括：

生成唯一的角色 ID号和角色密钥，通过文档库***创建该新角色的角色对象，在该角色对象中存储所述角色 ID号和密钥，再将该角色对象的角色 ID号和密钥返回给应用软件。
17、根据权利要求 16所述的方法，其特征在于，将该新创建的角色的权限设置为对任何对象都无权限。
18、根据权利要求 16所述的方法，其特征在于，所述以角色登录文档或文档库，包括：应用软件提供所要登录的角色的 ID号；

文档库***使用该角色的角色对象中存储的密钥对该角色进行身份验证；

若身份验证通过，则登录成功。
19、根据权利要求 18 所述的方法，其特征在于，所述角色对象中存储的密钥为随机生成的 PKI公钥；所述使用该角色的角色对象中存储的密钥对角色进行身份验证，包括：使用挑战一一应答的方式对该角色进行身份验证；或者，

角色对象中存储的密钥为登录口令；所述使用该角色的角色对象中存储的密钥对对角色进行身份验证，包括：比较该角色的角色对象中存储的登录口令与应用软件提供的登录口令是否一致。
20、根据权利要求 1所述的方法，其特征在于，进一步包括：收回角色针对目标对象的权限。
21、根据权利要求 20所述的方法，其特征在于，所述回收角色针对目标对象的权限，包括：

应用软件发出收回授权请求，该收回授权请 ^要求收回目标角色针对目标对象的目标权限；

查找该应用软件已登录的所有角色，确定对该目标对象具有收回授权的权限；

从目标角色针对该目标对象的权限中删除该 S标权限。
22、根据权利要求 21 所述的方法，其特征在于，从目标角色针对该目标对象的权限中删除该目标权限时，进一步包括：

如果该目标权限包含读和 /或写权限，则从目标角色的权限中删除针对该目标对象的目标权限对应的解密密钥和 /或加密密钥。
23、根据权利要求 1所述的方法，其特征在于，当所述访问文档库或文档为读取该文档库或文档中的对象时，该访问包括：应用软件发出读取对象的指令，该指令要求读取目标对象；检查该应用软件已登录的所有角色针对该目标对象的权限，如果有至少一个角色针对该目标对象具有读权限，则执行如下步骤：

11 )检查该目标对象是否已经设置了读写的访问控制权限，如果未设置，则执行步骤 12 ); 如果设置，则执行步骤 13 );

12 )检查该目标对象的各级父对象中已经设置了读写的访问控制权限的对象；

13 )选择一个对该已设置了读写的访问控制权限的对象有读权限的角色；将所选角色的权限中保存的该对象的解密密钥的密文发送给应用软件；

14 )应用软件使用所选角色的私钥解密得到解密密钥并传回；

15 )使用该被传回的解密密钥解密得到该已设置了读写的访问控制权限的对象的对称密钥，并使用该对称密钥解密得到该已设置了读写的访问控制权限的对象的数据，再将解密后的数据返回给应用软件。
24、根据权利要求 1所述的方法，其特征在于，当所述访问文档库或文档为写入该文档库或文档中的对象时，该访问包括：

应用软件发出修改对象的指令，该指令要求写入目标对象；检查该应用软件已登录的所有角色针对该目标对象的权限，如果有至少一个角色针对该目标对象具有写权限，则执行如下步骤：

21 )检查该目标对象是否已经设置了读写的访问控制权限，如果未设置，则执行步驟 22 ); 否则执行步骤 23 );

22 )查找该目标对象的各级父对象中已经设置了读写的访问控制权限的对象；

23 )选择一个对该已设置了读写的访问控制权限的对象有写权限的角色；将所选角色的权限中保存的该对象的加密密钥的密文发送给应用软件；

24 )应用软件使用所选角色的私钥解密得到加密密钥并传回； 25 )使用该被传回的加密密钥加密得到该已设置了读写的访问控制权限的对象的新数据，使用该加密后的新数据覆盖原数据。
25、居权利要求 1所述的方法，其特征在于，该方法进一步包括：对文档库或文档中的对象进行数字签名。
26、根据权利要求 25 所述的方法，其特征在于，所述对对象进行数字签名，包括：

对该对象进行正则化，计算正则化结果的 HASH值，并将 HASH值发给应用软件；

应用软件使用已登录的所有角色的私钥对该 HASH值进行加密，将签名结果回传。
27、根据权利要求 26 所述的方法，其特征在于，所述对象本身及其各个子对象对应一个子树;

所述对目标对象进行正则化，包括: 按预定遍历顺序计算该子树中的每一结点的正则结果，并组合成该目标对象的正则结果。
28、一种正则化方法，其特征在于，用于对树形结构进行正则化，包括：

按预定遍历顺序计算该树形结构中的每一结点的正则结果，并组合成该; 形结构的正则结果。
29、根据权利要求 28 所述的方法，其特征在于，所述遍历为深度优先或宽度优先。
30、根据权利要求 28 所述的方法，其特征在于，该方法进一步包括：对树形结构中引用了其他结点的结点，被引用结点作为该引用结点的子结点参与遍历计算正则结果。
31、根据权利要求 28所述的方法，其特征在于，所述计算一个结点的正则结果，包括：

将该结点的子结点数、类型、各属性的原值或变换值按照预定顺序连接起来，再取连接结果的原值或变换值作为该结点的正则结果。
32、根据权利要求 31 所述的方法，其特征在于，所述计算一个结点的正则结果，包括：

将该结点的子结点数、类型和各属性的原值或变换值，以及子结点数、类型和各属性的长度的原值或变换值中任一项或任意组合按照预定顺序连接起来，再取连接结果的原值或变换值作为该结点的正则结果。
33、根据权利要求 31或 32所述的方法，其特征在于，所述连接为：直接连接或用分隔符连接。
34、根据权利要求 31或 32所述的方法，其特征在于，所述变换值为 HASH值。
35、一种文档库***，其特征在于，用于对符合通用文档模型的文档或文档库进行安全管理，包括：

角色管理单元，用于创建所述文档或文档库的角色，为所述角色分配权限；

身份认证单元，用于在角色登录所述文档或文档库，通过所述角色管理单元验证该角色的身份；

访问控制单元，用于在访问该文档或文档库时通过所述角色管理单元和身份认证单元检查已登录角色的权限。

36、才艮据权利要求 35 所迷的***，其特征在于，该***进一步包括'.

安全会话通道单元，用于使用随机生成的、仅由其与应用软件掌握的会话密钥建立与应用软件之间的安全会话。

j、根据权利要求 35 所述的***，其特征在于，所述角色管理单元进一步用于回收已为角色授予的权限。
38、根据权利要求 35 所述的***，其特征在于，所述角色管理单元进一步用于为角色分配针对所述通用文档模型中部分或全部对象的权限。
39、根据权利要求 38 所述的***，其特征在于，所述通用文档模型中部分或全部对象，包括：文档库对象、文档集对象、文档对象、页对象、层对象、对象组和版面对象中任一项或任意组合。
40、根据权利要求 35 所述的***，其特征在于，当读取文档库或文档中的对象时，

所述访问控制单元进一步用于检查已登录的所有角色针对该对象的权限，如果有至少一个角色针对该对象具有读权限，获取该对象的解密密钥，用该解密密钥对该对象的数据进行解密。 .

41、根据权利要求 35 所述的***，其特征在于，当请求写入文档库或文档中的对象时，所述访问控制单元单元进一步用于检查已登录的所有角色针对该对象的权限, 如果有至少一个角色针对该对象具有写权限，获取该对象的加密密钥，并使用该加密密钥加密的新数据覆盖原数据。
42、根据权利要求 35 所述的***，其特征在于，所述访问控制单元进一步用于对文档库或文档对象进行正则化，计算正则化结果的 HASH值，从所述角色管理单元中提取已登录的角色的私钥，使用该私钥对访问控制单元得到的 HASH值进行加密得到签名结果。 43、一种文档数据安全管理***，其特征在于，用于对文档进行安全管理，其包括：角色管理单元，用于创建所述文档的角色，为所述角色分配对文档对象、页对象或页对象的子对象的权限；

身份认证单元，用于在角色登录所迷文档，通过所述角色管理单元验证该角色的身份；

访问控制单元，用于在访问该文档时通过所述角色管理单元和身份认证单元检查已登录角色的权限。