具体实施方式
以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用于解释本发明,并不用于限定本发明。
如图1所示,依照本发明的文档处理***主要包括应用软件、接口层、文档库***和存储设备。
其中的应用软件包括现有的任何文档处理和内容管理软件,这些应用软件都位于文档处理***的应用层,通过发送符合接口标准的指令来对文档进行操作,所述操作都是对符合通用文档模型的文档进行的,与具体存储格式无关。
其中的接口层符合规范应用层和文档库***之间交互的接口标准,所述应用层通过接口层向文档库***发送标准指令,所述文档库***通过接口层向应用层返回执行的结果。由此可见,由于应用软件均可以通过接口层发出标准指令,对符合通用文档模型的文档进行操作,所以不同的应用软件可以通过同一文档库***对同一文档进行操作,同一应用软件也可以通过不同文档库***对不同格式的文档进行操作。
优选地,接口层可包括上接口单元和下接口单元,应用层通过上接口单元发送标准指令至下接口单元,文档库***通过下接口单元接收标准指令,下接口单元还用于将文档库***的执行结果通过上接口单元返回给应用***。在实现上,上接口单元可位于应用层中,下接口单元可位于文档库***中。
其中的文档库***为文档处理***的核心层,根据应用软件通过接口层发来的标准指令执行具体的文档处理操作。
其中的存储设备为文档处理***的存储层,常用的是硬盘或者内存,也可以是光盘、闪存、软盘、磁带,也可以是远程的存储设备,总之只要具备数据的存储能力即可。在存储设备中存储有多个文档,但对应用软件而言并不需要关心文档的具体存储方式。
由此可见,依照本发明,使得应用层和数据处理层真正分离开来,文档不再与特定应用软件绑定,应用软件不再直接跟具体的文档格式打交道,不同的应用软件可以对符合通用文档模型的同一文档进行编辑,使不同应用软件之间具有良好的文档互操作性。
本发明还公开了一种应用软件,其包括用于发出标准指令的接口单元,所述标准指令用于对符合通用文档模型的文档进行操作。
本发明还公开了一种文档库***,其包括:用于接收标准指令的接口单元;和,用于根据该标准指令对符合通用文档模型的文档进行操作的处理单元。
本发明还公开了一种接口层,其包括:
上接口单元,用于发送对符合通用文档模型的文档进行操作的标准指令;
下接口单元,用于接收该标准指令。
进一步,上接口单元可以根据应用层发出的指令生成标准指令,下接口单元判断接收到的指令是否符合标准,并解析符合标准的指令。
文档处理***可以包括应用软件和平台软件(如文档库***)。应用软件通过发送一个或多个指令到平台软件来对抽象非结构化信息(abstractunstructuredinformation)进行操作。平台软件接收到来自应用软件的指令后,将针对抽象非结构化信息的操作映射到针对与该非结构化信息对应的存储数据的操作,并且对该存储数据执行该操作。其中,需要说明的是:抽象非结构化信息与存储数据的存储方式无关。
存储数据是指维护或存储在存储器(诸如硬盘等非易失性永久存储器,或诸如RAM等易失性存储器)中供长期使用的各种信息,这些信息可由计算装置处理。存储数据可以包括一份完整的或综合的信息,如office文档、图片或音频/视频节目等。这里“长期”不是指存储的介质,而是指数据的形式,表明数据不是动态存储(例如运行实例中的一个内存指针)的,而是可被其他软件或另一个运行实例以后使用的。
存储数据通常包含于一个磁盘文件中,但也可以包含在多个(相关联的)磁盘文件中或在数据库的多个(相关联的)字段中,或者是在一个独立的磁盘分区的一个区域中。其中,该磁盘分区不由操作***的文件***管理,而是由平台软件直接管理。可选的,存储数据还可以分布式存储在不同地理位置的不同设备上,也可以具有其他存储形式。由此可见,存储数据的格式可以包括如上所述的将信息存储为物理数据的各种形式,而不局限于一个或多个磁盘文件的格式。
文档的存储数据可称为文档数据,除了包含文档的可视化信息以外,还可以包含其它一些信息,例如安全控制信息或编辑过程信息。文档文件是以磁盘文件方式存储的文档数据。
这里“文档”通常有两个含义:一个是指可打印到纸上的信息,如静态的二维信息(static two-dimension information);另一个则泛指所有可呈现的信息,包括多维信息或诸如音/视频等的流媒体信息。本发明中并不严格区分这两种用法。
在本发明实施例中,应用软件仿佛是对一个抽象文档进行操作,它并不需要关心文档数据的存储方式。平台软件(如文档库***)负责维护抽象文档与存储数据(如具有特定格式的文档文件)之间的对应关系,比如:将应用软件对抽象文档执行的操作映射到针对存储数据的实际操作,执行此操作,并在操作需要返回值的情况下,向应用软件返回操作结果。
在本发明实施例中,抽象文档是对文档数据进行抽象的结果,不同的文档数据可以对应相同的抽象文档。例如,抽象文档可以基于文档的可视化外观(也称为文档的版式)进行抽象,具有相同可视化外观的不同文档数据,无论其以何种方式存储,都可以对应同一抽象文档。比如,当一个Word文件被转成一个与其具有相同可视化外观的PDF文件后,该Word文件与该PDF文件就是对应同一抽象文档的不同存储数据。又比如当同一文档被保存为不同版本的Word格式文件时,这些不同版本的Word格式文件也是对应相同抽象文档的不同存储数据。
在本发明实施例中,为了更好地记录可视化外观信息,最好能记录文字、图形、图像等可视内容的位置信息,并同时记录所引用的资源,例如被链接的照片和非标准字库。这样,就能保证这些可视内容不会错位、并且随时可用。版式文档满足上述条件,因此常常被用作平台软件的存储数据。
由于平台软件创建的存储数据可被标准指令访问,并且可被符合接口标准的各种应用软件使用,因此平台软件创建的存储数据又可称为通用数据。应用软件不仅可以访问通用数据,还可以定义自己特有的数据格式,如Office文档格式。应用软件打开并解析具有自己特有格式的文档后,通过一个或多个标准指令来请求生成相应的抽象文档,平台软件再根据这些指令创建相应的存储数据。虽然新生成的存储数据(通用数据)与原始数据的格式不同,但其与原始数据对应相同的抽象文档,如其具有与原始数据相同或者相似的可视化外观。因此,只要一个文档数据(无论其格式如何)对应一个抽象文档,平台软件就可以创建一个与该抽象文档对应的存储数据,任何文档数据都可以被转化为与其对应相同抽象文档的通用文档,并可被各种应用软件使用。这样就实现了在符合相同接口标准的不同应用软件之间的文档互操作。
下面以两个应用软件和一个平台软件为例(但不限于此)来说明文档互操作过程。第一应用软件发送第一指令到平台软件,以创建第一抽象文档。平台软件接收到第一指令后,创建与第一抽象文档对应的存储数据。第二应用软件发送第二指令到平台软件以打开上述已创建的存储数据。平台软件根据第二指令打开并解析该存储数据,并产生与该存储数据对应的第二抽象文档。这里第二抽象文档与第一抽象文档相同或相似,并且第一指令和第二指令符合相同的接口标准,这样第二应用软件就可以打开由第一应用软件创建的文档。
再以一个应用软件和两个平台软件为例(但不限于此)来说明另一文档互操作过程。第一平台软件解析以第一数据格式存储的第一存储数据,产生与该存储数据对应的第一抽象文档。应用软件发送第一指令到第一平台软件,以获取第一抽象文档的所有信息。应用软件发送第二指令到第二平台软件,以创建一个与第一抽象文件相同或相似的第二抽象文档。第二平台软件根据第二指令,创建与第二抽象文档对应的并且按第二数据格式存储的第二存储数据。这里第一指令和第二指令符合相同的接口标准这样应用软件可以将数据在不同格式间转化并且保持其抽象特征不变。
多个应用软件与多个平台软件情况下的文档互操作过程可由以上两个例子推知。
受到文档格式和相关软件功能等因素的限制,存储数据与抽象文档的映射关系不一定能100%完整准确,往往会存在一定程度上的偏差。例如(但不限于此),不管用什么精度的浮点数还是整型数来存储可视内容的坐标,都不能避免出现偏差。又如,缺乏必要色彩管理功能的用于显示/打印的软件显示/打印出来的颜色和预定义的颜色可能会有一定偏差。如果这些偏差不是很明显的话(例如但不限于此,某个字符的位置偏离了0.01mm,或者某个图像用JPEG进行了失真压缩),这些偏差可以被使用者忽略。使用者所能接受的偏差程度与其实际需求等因素有关,例如一个专业美工对色彩偏差的要求就会比一般人苛刻得多。由此可见,抽象文档与相对应的存储数据不一定能绝对一致,与一个抽象可视化外观对应的多个存储数据,其显示/打印效果也未必绝对相同。即使用相同的应用软件来处理同样的存储数据,其呈现效果也不一定会完全一样,例如不同的屏幕分辨率下显示效果就会有细微的不同。在本发明中,“相似”、“一致”被用来表示可接受的范围内的偏差(即偏差程度不超过预设的阈值)。由此可见,存储数据可以与多个相似的抽象文档相对应或相符合。
平台软件可以用多种方式建立抽象文档与存储数据的对应关系。例如,平台软件可以在打开某个文档文件、解析该文档文件的存储数据并形成一个可供应用软件操作的抽象文档时,建立此抽象文档和存储数据的对应关系。又如,平台软件可以在接收到来自应用软件指令以指示创建一个抽象文档、并创建相应的存储数据时,建立此抽象文档和存储数据之间的对应关系。在本发明某些实施例中,应用软件知道其所操作的抽象文档所对应的存储数据(比如:此时应用软件可以通知平台软件该存储数据的地址,或者应用软件可以将文档数据读到内存中,并将内存数据块提交给平台软件供其处理)。在本发明另外的实施例中,应用软件可能对其所操作的抽象文档所对应的存储数据“一无所知”。例如(但不限于此),应用软件可以要求平台软件在互联网上按某个条件搜索,并打开第一个搜索到的文档。
一般说来,抽象文档是不具有存储的,也就是说其并未存储在任何存储介质中。各种用于记录和描述抽象文档的信息可以包含在对应的存储数据或操作指令中,但这种信息都不是抽象文档本身。因此,抽象文档也可被称为虚拟文档。
在本发明实施例中,抽象文档可以具有结构,该结构可以用某种文档模型来描述,如以下提到的通用文档模型。所谓“文档数据符合通用文档模型”可以理解为对文档数据进行抽象得到的抽象文档符合通用文档模型。由于通用文档模型是基于纸张特性抽象而来,因此所有可打印到纸上的文档符合通用文档模型,这就是通用文档模型之所以称为“通用”的由来。
在本发明实施例中,除了可视化外观外,还可以从文档数据中抽取其他各种信息,如安全控制信息、文档组织管理信息(例如描述一个文档属于哪个文档集的信息)、导航导读等互动信息、元数据等非可视信息等各种信息进行抽象,甚至还可以是多维信息以及如音/视频信息等的流媒体信息。所有这些被抽取的信息可以统称为抽象信息。由于抽象信息本身是没有存储的,也可以称为虚拟信息。
虽然本发明所举的实施例大都是针对文档的可视化外观信息的,但上述方法也可用于其他的抽象信息,如安全控制信息、文档组织管理信息、多维信息、流媒体信息等。
存在多种方式来发送指令以操作抽象信息,如通过发送命令串或调用函数。可以用不同的指令形式来表示对抽象信息进行的操作。之所以将函数调用也视为一种指令发送形式,是因为可以将不同函数调用地址视为不同指令,将函数的参数视为对应的指令参数。当指令以“操作动作+操作对象”形式描述时,指令中的对象可以与通用文档模型中的对象相同,也可以不同。例如,设置文档的文字对象的位置时,指令中的对象可以是文字对象,此时此指令中的对象与通用文档模型中的对象相同;或者,指令中的对象可以是文字的位置对象,此时此指令中的对象与通用文档模型的对象不同。在实际应用中,为了方便起见,还是应当尽量将指令中的对象可以与通用文档模型的对象统一为好。
以上描述的方法将应用软件从平台软件中分离处理,使得文档处理更加便利。在实际应用中,也可能会出现不严格区分抽象信息与存储数据,应用软件甚至可以通过指令直接操作文档数据的情形。但在这种情况下,为了保持通用性,指令应该与具体的文档数据格式无关。更具体的,该指令可以符合一个与文档数据格式无关的接口标准,并可以通过这个符合该接口标准的接口层发送该指令。接口层也可以不是一个单独的层,而是可以分为上接口单元和下接口单元两部分,其中上接口单元为应用软件的一部分,下接口单元为平台软件的一部分。
以下对本发明的文档处理***的具体实施方式进行阐述。
通用文档模型
可参考纸张的特性定义所述通用文档模型,这是因为以纸张作为文档信息的记录手段是通行至今的标准方法,只要能具备纸张的所有功能,就能满足工作、生活等实际应用的需求。
如果把文档中的一页当成一张纸,凡是能画到纸上的就记录下来,该通用文档模型能够描述页面上的所有可见内容。现有技术中的页面描述语言(如PostScript)可以描述所有能印在纸上的信息,因此这一部分就不再详细阐述。一般说来,页面上的可见内容最终都可以归为文字、图形、图像三类。
如果文档中涉及到特定字体或特殊字符的话,为了保证在各台电脑上都能有相同的效果,就需要在文档中嵌入相应字库。为了提高存储效率,字库资源应当共享,这样即使在多处使用了同一字符,也只需要嵌入一个字库。图像有时也是可能在多处出现的,例如每一页共同的底图,或经常出现的公司标识,这种情况下最好也能共享这些图像。
当然,作为更加先进的信息处理工具,不能仅仅模拟纸张的特性,还需要增加一些增强的数字特性,例如元数据、导航、导读、微缩版面。元数据是描述数据的数据,例如作者、出版社、出版时间、ISBN号等就是图书的元数据。元数据是业内通用名词,也不在此赘述。导航是类似图书目录的信息,也是业内通用名词。导读信息描述了一篇文章所在的区域和阅读顺序,这样当阅读者读完一屏后就可以根据该信息自动判断下一屏应该显示什么,这样还能做到自动换栏、自动转版,而不用阅读者再手工指定位置。微缩版面是事先生成的各页面的微缩图,阅读者可以通过查看微缩版面来指定阅读哪一页。
图2是本发明的一优选实施例的通用文档模型。如图2所示,该通用文档模型包含文档仓库、文档库、文档集、文档、页、层、对象组、版面对象等多个层次。
其中,文档仓库由一个或多个文档库组成,文档库之间的关系相对于文档库之下的层次之间的关系相对要松散一些,文档库之间可以非常简单地组合和拆离,而不用对文档库本身的数据做改动,该多个文档库之间往往没有建立统一索引(特别是全文索引),很多对文档仓库的检索操作一般都需要遍历各文档库的索引,而没有统一的索引可用。每个文档库由一个或多个文档集组成,每个文档集由一个或多个文档组成,还可以包含任意数量的子文档集。这里所说的文档相当于目前普通的一个文档文件(例如DOC文档),通用文档模型可以规定一个文档只能属于一个文档集,但也可以允许一个文档属于多个文档集。文档库不是多个文档的简单组合,它把多个文档紧密地组织起来,特别是为文档内容统一建立了各种检索索引后就能带来更大的便利性。
每个文档由一页或存在一定顺序(如前后顺序)的多页组成,每页的版心可以不同,而且版心也不一定是矩形的,可以是任意形状,可以用一条或多条封闭曲线表示版心。
每页又由一层或按一定顺序(如上下顺序)的多层组成,各层之间如同玻璃板的叠加关系。层由任意数量的版面对象和对象组组成,版面对象是指状态(如字体、字号、颜色、ROP等)、文字(包括符号)、图形(如直线、曲线、填充了指定颜色的闭合区域、渐变色等)、图象(如TIF、JPEG、BMP、JBIG等)、语义信息(如标题开始、标题结束、换行等)、源文件、脚本、插件、嵌入式对象、书签、链接、流媒体、二进制数据流等。一个或多个版面对象可以组成一个对象组。对象组也可以包含任意数量的子对象组。
文档库、文档集、文档、页、层都可以还包括元数据(如名称、最后修改时间等,其类型可以根据应用需求来设置)和/或历史痕迹;文档中还可以包括导航信息、导读信息、微缩版面;也可以把微缩版面放在页或者层这个层次;文档库、文档集、文档、页、层、对象组都可以还包括数字签名;语义信息最好跟着版面信息走,这样可以避免数据冗余,也比较容易与版面建立对应关系;文档库、文档还可以包括字库、图像等共享资源。
该通用文档模型还可以定义一个或多个角色,为每个角色分配一定权限。权限以文档库、文档集、文档、页、层、对象组、元数据为单元进行分配,定义每个角色对该单元是否可读、是否可写、是否可复制、是否可打印,等等。
该通用文档模型是一个超越以往单个文档对应单个文件的方式,文档库中包含多个文档集、文档集中包含多个文档,而对于文档库中文档内容,采用了细粒度的访问和安全控制,可以具体访问文档库中某个文字或者矩形,而不像现在的文档管理***只能访问到文件名。
图3至图9示出了本发明一优选实施例的通用文档模型所涉及的各对象的组织结构示意图。所述的各对象的组织结构是树状结构,是逐层展开、细化的。
文档仓库对象是由一个或多个文档库对象组成(图中未示出)。
如图3所示,文档库对象包括一个或多个文档集对象、任意数量文档库辅助对象和任意数量的文档库共享对象。
如图4所示,所述的文档库辅助对象包括元数据对象、角色对象、权限对象、插件对象、索引信息对象、脚本对象、数字签名对象、历史痕迹对象等。文档库共享对象是指文档库中的不同文档可能共享的对象,如字库对象、图像对象等。
如图5所示,每个文档集对象包括一个或多个文档对象、任意数量的文档集对象和任意数量的文档集辅助对象。文档集辅助对象包括元数据对象、数字签名对象、历史痕迹对象。当文档集对象包括多个文档集对象时,其类似于资源管理器中的文件夹包括多个文件夹的形式。
如图6所示,每个文档对象包括一个或多个页面对象、任意数量的文档辅助对象和任意数量的文档共享对象。文档辅助对象包括元数据对象、字库对象、导航信息对象、导读信息对象、微缩版面对象、数字签名对象、历史痕迹对象等。文档共享对象包括文档中的不同页面可能共同使用的对象,如图像对象、***对象等。
如图7所示,每个页面对象包含一个或多个层对象和任意数量的页面辅助对象组成。页面辅助对象包括元数据对象、数字签名对象、历史痕迹对象。
如图8所示,每个层对象包括一个或多个版面对象、任意数量的对象组和任意数量的层辅助对象。层辅助对象包括元数据对象、数字签名对象、历史痕迹对象。对象组包括任意数量的版面对象、任意数量的对象组和可选的数字签名对象。当对象组包括多个对象组时,其类似于资源管理器的文件夹包括多个文件夹的形式。
如图9所示,版面对象包括状态对象、文字对象、直线对象、曲线对象、圆弧对象、路径对象、渐变色对象、图像对象、流媒体对象、元数据对象、批注对象、语义信息对象、源文件对象、脚本对象、插件对象、二进制数据流对象、书签对象以及超链接对象。
其中,状态对象包括任意数量的字符集对象、字体对象、字号对象、文字颜色对象,光栅操作对象、背景色对象、线颜色对象、填充色对象、线型对象、线宽对象、线接头对象、画刷对象、阴影对象、阴影颜色对象、旋转对象、空心字对象、勾边字对象、透明对象和渲染模式对象。
在具体实施过程中,可以在上述通用文档模型基础上进一步增强或简化。如果在简化模型中省略了文档集对象,则文档库对象直接由文档对象组成;如果在简化模型中省略了层对象,则页面对象直接由版面对象组成。
可以理解,最简化的通用文档模型是仅包含文档对象、页面对象和版面对象。其中版面对象仅包括文字对象、直线对象和图像对象。完整模型和最简化模型之间的各种中间模型都属于本优选实施例的变形。
通用安全模型:
为了满足各种应用对文档安全性的需求,还需要定义一种通用的文档安全模型,以解决由于现有软件的文档安全功能不够强,或者是安全管理机制与文档处理模块脱节所导致的安全缝隙。根据本发明一优选实施例,通用文档安全模型包括:
1.在文档库中设置若干角色,角色对象是文档库对象的子对象。
2.可以设置任意角色对任意对象(例如文档库、文档集、文档、页、层、对象组、版面对象等)的访问权限。如果设置了某角色对某对象的访问权限,则该权限适用于该对象的所有子对象。
3.文档库***实现的访问权限包括是否可读、是否可写、是否可再授权、是否可收回授权及其排列组合。也可以定义其他需要由应用软件来配合实现的权限,如不可打印。
4.角色可以对任意对象进行签名。签名范围包括该对象的子对象,以及引用到的对象。
5.创建角色对象的指令的执行结果是向应用软件返回一个密钥,作为应用软件以该角色身份登录的依据,该密钥通常是PKI的私钥,由应用软件保管,该密钥也可以是登录口令。
6.当应用软件以某一角色身份登录时,通常采用“挑战-应答”机制,即文档库***用保存的角色公钥加密一块随机数据发给应用软件,应用软件解密后返回给文档库***,如果解密正确,则表明应用软件确实拥有该角色对应的私钥。“挑战-应答”机制也可以用以下方式实现,文档库***将一块随机数据发给应用软件,应用软件用私钥加密后返回给文档库***,文档库***用保存的角色的公钥解密,如果解密正确,则表明应用软件确实拥有该角色对应的私钥。为保险起见,该认证过程可能会重复几次。采用“挑战-应答”机制可以更好地保护私钥的安全性。如果角色的密钥是登录口令,则需要用户输入正确的登录口令。
7.应用软件可以同时登录多个角色,此时拥有的权限是各角色权限的并集。
在具体实施过程中,可以在上述通用安全模型基础上进一步增强或简化。针对上述安全模型的任何简化模型都是本实施例的变形。
接口层的具体实现
所述接口层的统一接口标准可根据通用文档模型、通用安全模型和常用的文档操作而定义,用于发送对通用文档模型中各对象进行操作的指令。所述的对通用文档模型中各对象进行操作的指令符合接口标准,各种应用软件可以通过接口层发出标准指令。
现在介绍接口标准的实现方式。接口标准的实现可以是上接口单元按照预先定义的标准格式生成命令串,例如“<UOML_INSERT(OBJ=PAGE,PARENT=123.456.789,POS=3)/>”,将该命令串发送给下接口单元,并从下接口单元接收文档库***对该命令的执行结果或其它反馈信息;或者,接口标准的实现是下接口单元提供一些具有标准名称和参数的接口函数,例如:“BOOLUOI_nsertPage(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)描述的一系列的命令。每个动作都对应一个XML元素,每个对象也都对应一个XML元素;描述一个命令时,将描述对象的XML元素作为描述动作的XML元素的子元素,即可生成包括动作+对象的字符串。上接口单元将该字符串发送给下接口单元,就将相应的操作指令发送给了文档库***。文档库***执行这些命令后,下接口单元将执行结果也生成一个符合UOML格式的字符串,返回给上接口单元,使应用软件能够知晓操作执行结果。
所有执行结果都由UOML_RET表示,参见图10,其定义如下:
属性:
SUCCESS:值为真(true)时表明操作成功,否则失败。
子元素:
ERR_INFO:可选,仅当操作失败时出现,描述了相应的错误信息。
其它子元素:根据具体命令确定,可参考各命令说明。
UOML动作包括:
1UOML_OPEN创建或打开文档库,参见图11。
1.1属性
1.1.1create:为true时是创建,否则是打开已有文档库。
1.2子元素:
1.2.1path:文档库路径。可以是磁盘文件名,也可以是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.1handle:对象句柄,是一个字符串表示的对象的引用指针。
2.2.2db_handle:文档库句柄,字符串表示的文档库的引用指针。
2.3返回值:无返回值。
3UOML_GET获取,参见图13。
3.1属性
3.1.1usage:用途,为”GetHandle”(获取指定对象句柄)、”GetObj”(获取指定对象数据)、”GetPageBmp”(获取版面位图)中的一个。
3.2子元素
3.2.1parent:父对象句柄,usage属性为”GetHandle”时使用。
3.2.2pos:位置顺序号,usage属性为”GetHandle”时使用。
3.2.3handle:指定对象的句柄,当usage属性为”GetObj”时使用。
3.2.4page:需要显示的页面的句柄,当usage属性为”GetPageBmp”时使用。
3.2.5input:描述了对输入页面的约束,其中可以指定显示一层或者多层的内容(可以显示的层一定是当前角色有权限访问的层);也可以通过指定Clip区域来指定显示区域的大小。当usage属性为”GetPageBmp”时使用。
3.2.6output:描述了版面位图的输出方式,当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指定位置输出版面位图。
4UOML_SET设置,参见图14。
4.1属性:无。
4.2子元素:
4.2.1Handle:设置对象的句柄。
4.2.2xobj:对象的描述。
4.3返回值:无返回值。
5UOML_INSERT***,参见图15
5.1属性:无。
5.2子元素:
5.2.1parent:父对象句柄。
5.2.2xobj:对象的描述。
5.2.3pos:***位置。
5.3返回值:如果执行成功,则将xobj参数表示的对象,***到parent中成为其第pos个子对象,并在UOML_RET中包含一个”handle”子元素,表示新***对象的句柄。
6UOML_DELETE 删除,参见图16
6.1属性:无。
6.2子元素:
6.2.1handle:需要删除的对象的句柄。
6.3返回值:无返回值。
7UOML_QUERY检索查询,参见图17
7.1属性:无。
7.2子元素:
7.2.1handle:需要查询的文档库句柄。
7.2.2condition:查询条件。
7.3返回值:如果成功,在UOML_RET中包含一个“handle”子元素代表查询结果的句柄,一个“number”子元素代表查询结果的数量,可以用UOML_GET来获取每一个查询结果。
UOML对象包括:
文档库(UOML_DOCBASE)、文档集(UOML_DOCSET)、文档(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)、字体(UOML_TYPEFACE)。
下文以UOML_DOC、UOML_TEXT和UOML_CHARSIZE为例说明其定义方式:
1UOML_DOC
1.1属性:无。
1.2子元素:
1.2.1metadata:元数据。
1.2.2pageset:各页面。
1.2.3fontinfo:嵌入字库。
1.2.4navigation:导航信息。
1.2.5thread:导读信息。
1.2.6minipage:微缩版面。
1.2.7signiture:数字签名。
1.2.8sharesource:共享资源。
2UOML_TEXT
2.1属性:
2.1.1Encoding:文字编码方式。
2.2子元素:
2.2.1TextData:文字内容。
2.2.2CharSpacingList:对非等间距文字的字间距列表。
2.2.3StartPos:起点位置。
3UOML_CHARSIZE
3.1属性:
3.1.1width:字符宽度。
3.1.2height:字符高度。
3.2子元素:无。
以此类推,可以用同样的方法来描述所有的UOML对象。当应用软件对文档库进行操作时,由上述UOML动作与UOML对象依照XML语法生成相应的UOML命令,将该UOML命令发给文档库***,即代表向文档库***发出了相应操作指令。
例如,对创建文档库操作,可以用以下命令来完成:
<UOML_OPEN create=″true″>
<path val=″f:\\data\\docbase l.sep″/>
</UOML_OPEN>
对创建文档集操作,可以用以下命令来完成:
<UOML_INSERT>
<parent val=″123.456.789″/>
<pos val=″1″/>
<xobj>
<docset/>
</xobj>
</UOML_INSERT>
需要说明的是,虽然UOML是用XML定义的,但为了显得更加简洁,在前面省略了类似“<?xml version=″1.0″encoding=″UTF-8″?>”以及“xmlns:xsi=″http://www.w3.org/2001/XMLSchema-instance″”之类的常规XML格式,只要是熟悉XML语法的实施者都可以在实施过程中自行添加。
也可以不用XML方式定义命令串,例如改用类似PostScript那样的方式,这样上例变成:
1,″f:\\data\\docbase l.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>
<parent val=″123.456.789″/>
<pos val=″1″/>
</UOML_INSERT_DOCSET>
用这种方法定义命令格式需要对每个对象的每种合法操作都单独定义一条命令,缺点是比较繁琐。
现在介绍用函数调用的方式来实现接口标准的实例,在该实例中,通过上接口调用下接口的接口函数的方式来发送操作指令给文档库***。以下以C++语言为例说明,该实例称为UOI。在该实例中,定义了UOI_Object作为所有对象的基类,为每个动作定义了一个函数,该函数的参数可以是对基类的指针或引用,这样该函数就可适用于所有对象。
先定义一个UOI返回值结构:
struct UOI_Ret{
BOOL m_bSuccess;
CString m_ErrInfo;
};
定义所有UOI对象的基础类:
class UOI_Object{
public:
enum Type{
TYPE_DOCBASE,
TYPE_DOCSET,
TYPE_DOC,
TYPE_PAGE,
TYPE_LAYER,
TYPE_TEXT,
TYPE_CHARSIZE,
};
Type m_Type;
UOI_Object();
virtual~UOI_Object();
static UOI_Object Create(Type objType);
};
然后定义如下几个UOI函数,与“操作动作+操作对象”方式实例中的几个UOML动作相对应:
UOI_RET UOI_Open(char*path,BOOL bCreate,HANDLE*pHandle);
UOI_RET UOI_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);
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_pMiniPage s;
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);
然后是构建一个创建新对象的函数:
HANDLE InsertNewObj(HANDLE hParent,int nPos,UOI_Object::Type type)
{
UOI_Ret ret;
HADNLEhandle;
UOI_Obj *pNewObj=UOI_Obj::Create(type);
if(pNewObj==NULL)
return NULL;
ret=UOI_Insert(hParent,nPos,pNewObj,&handle);
delete pNewObj;
return ret.m_bSuccess?handle:NULL;
}
然后是直接获取对象的函数:
UOI_Obj *GetObj(HANDLE handle)
{
UOI_Ret ret;
UOI_Object::Type type;
UOI_Obj *pObj;
ret=UOI_GetObjType(handle,&type);
if(!ret.m_bSuccess)
return NULL;
pObj=UOI_Obj::Create(type);
if(pObj==NULL)
return NULL;
ret=UOI_GetObj(handle,pObj);
if(!ret.m_bSuccess){
delete pObj;
return NULL;
}
return pObj;
}
在对每一个对象的每一种操作都定义一个接口函数的方式中,***文档集的操作指令就是上接口以下列方式调用下接口的接口函数来发送给文档库***的:
UOI_InsertDocset(pDocbase,0);
在封装各个对象类(如文档库类)的方式中,把该对象可以进行的操作定义成该类的方法,如:
class UOI_DocBase:public UOI_Obj
{
public:
/*!
*\brief 创建文档库
*\param szPath: 文档库全路径
*\param bOverride:是否覆盖原文件
*\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 nIndex:文档列表的索引号
*\return UOI_DocSet对象
*\sa UOI_DocSet
*/
UOI_DocSet GetDocSet(int nIndex);
/*!
*\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 无
* \return 长度
*/
int GetIDLen();
/*!
* \brief 获取文档库id
* \param 无
* \return id
*/
const char*GetID();
//!构造函数
UOI_DocBase();
//!析构函数
virtual~UOI_DocBase();
};
这样***文档集的操作指令就是上接口以下列方式调用下接口的接口函数来发送给文档库***的:
pDocBase.InsertDocset(0);
还可以用同样的方法为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技术范畴,不在此赘述。
文档安全处理
在创建角色对象时,生成一对随机公私钥对(例如512位的RSA密钥),将公钥存储在角色对象中,将私钥返回给应用软件。
当应用软件登录时,随机生成一块(例如128字节)数据,用相应角色对象中的公钥加密该数据发给应用软件,应用软件解密后比较验证,如果正确则表明应用软件确实拥有该角色对应的私钥,登录成功。为保险起见,该认证过程可以重复三次,三次全部通过才算登录成功。
当对某一对象进行签名时,也就是对其对应的结点开始的子树进行签名。为了能够使签名不受具体物理存储方式的影响,需要先做一个正则化,使得逻辑上等效的变化(例如存储位置的改变导致相应指针的变化)不会影响签名有效性。该正则化的方法如下:
按深度优先遍历以目标对象为根节点的子树中的各个节点(即目标对象及其各个子对象),按照遍历顺序依次计算每个节点的正则结果并连接起来。
其中,对子树的某一节点计算正则结果的方法为:先计算该节点的子节点数的HASH值,然后再依次计算该节点类型及其各个属性的HASH值并按顺序连接在该节点的子节点数的HASH值的后面,再计算该连接结果的HASH值,得到该节点的正则结果。如果需要对子树中的某个节点引用的对象也一起做签名,则可以将该节点引用的对象也作为该节点的一个子节点来处理,方法同上。
正则化以后,再做HASH并用角色的私钥进行签名的处理可采用现有技术,这里不再赘述。
在上述正则化过程中,可以把计算一个节点正则结果的方法改成如下方案:将该节点的子节点数、类型及其各属性用分隔符隔开后按照顺序连接起来,计算该连接的结果的HASH值,得到该节点的正则结果。还可以把计算一个节点正则结果的方法改成如下方案:将该节点的子节点数、类型及其各属性的长度用分隔符隔开后按照顺序连接起来,再与子节点数、类型、各属性连接起来,即得到该节点的正则结果。总之,计算一个节点正则结果的方法可以采用以下各种方案中的任意一种:对树的某一节点,其子节点数、类型、各属性,子节点数/类型/各属性的长度(可选的),原值或经过特定变换(如HASH、压缩),按照预定顺序连接起来(直接连接或用分隔符隔开)。
上述预定顺序的意思是,子节点数长度、类型长度、各属性长度、子节点数、类型、各属性可以按任意顺序排列,只要是预定的顺序即可。
另外,在遍历子树中各个节点时,既可以采用深度优先遍历也可以采用宽度优先遍历。
不难给出上述方案的各种变化方式,如每个结点的子结点数用分隔符隔开后按照深度优先的顺序连接起来,再与各结点其它数据的正则结果连接起来。总之,只要对该子树中的所有结点的子结点数、类型和各属性,按照确定的方法排列在一起就属于本实施例的变化。
当对某一对象设置权限时,最简单的实现方式是简单记录各角色对该对象(及其子对象)的权限,并在今后各角色访问时加以比较,符合权限的则允许相应操作,否则报错返回。更好的实现方式是对相应数据加密,并用密钥来控制权限,如果该角色没有相应密钥就没有对应的权限,这种方式抗攻击能力要更强。具体方案为:
a)对受保护的数据区域(通常为一个子树,对应某对象及其所有子对象),有一对对应的PKI密钥对,用其中的加密密钥对该数据区域进行加密。
b)对具有读权限的角色,授予其解密密钥,该角色可以用该密钥解密该数据区域,从而正确读取这些数据。
c)对具有写权限的角色,将授予其加密密钥,该角色可以将修改后的数据用该密钥加密,从而可以正确写入该区域的数据。
d)鉴于PKI的加密/解密效率较低,为提高运行效率,也可以用对称密钥来对该数据区域加密,加密密钥用于对该对称密钥进行加密,解密密钥用于解密经过加密后的密钥数据,从而获得正确的对称密钥。为防止只有读权限的角色在获得对称密钥后用其修改数据,可以用加密密钥来对该数据区域进行数字签名,每次拥有写权限的角色修改该数据区域后都重新做一次签名,从而确保数据不会被没有写权限的角色篡改。
e)当授予某一角色加密密钥或解密密钥时,可以用该角色的公钥对该密钥加密后存储,这样只有拥有该角色的私钥时才能取出该密钥
需要说明的是,本发明中所说明的文档安全技术,如基于角色的权限管理、角色的认证方式、多重角色登陆、对树结构的正则化技术、细粒度的权限管理单元、基于加密的权限设置等,都不仅适用于本发明所述的文档处理***,还可以运用于更为广泛的其它应用场合。
对层的管理
在本发明中,为了使本文档处理***能很好地模拟纸张的特性,提供了一种“只加不改”的技术方案。也就是说,每个应用软件都只在现有文档内容基础上添加新的内容,但不修改、不删除已有的内容,使文档的一个页面就象一张纸一样,可以由不同的人用不同的笔在纸上不断写写画画,但谁都不能修改、删除已有内容。具体方法是每一个应用软件在编辑其它软件生成的文档时,都在现有文档基础上新增加一层,将本软件新编辑的内容都放到这一层中,不修改和删除前面各层的内容。这样,每个文档的每一层只由一个应用软件来管理和维护,其他应用软件不能对该层进行编辑。由于现有社会就是基于纸张来运转的,因此只要能符合纸张的特性就能满足现有应用的需求,具备足够的实用价值。
为了确保每一层内容在生成后没有被修改、删除,可以利用每一层的数字签名对象。数字签名可以是对本层内容进行签名,优选地,可以是对本层以及本层之前生成的所有层的内容一起签名。签名以后并不妨碍对文档做进一步的批注等编辑,只要新的内容是位于新建的层,没有修改破坏签名时存在的各层,签名依然是有效的,但签名者只对签名以前的内容负责,不对签名以后的内容负责。这是一个非常符合应用需求的技术方案,具有很大的实用价值。相比之下,现有的其它技术或者签名后不允许编辑,或者编辑后(尽管是“只加不改”的编辑)签名被破坏。
前述技术方案不允许修改文档中的已有内容,即使不考虑与纸张特性的兼容以及数字签名问题,需要修改的话也只能做版面级编辑,即对每个版面对象的编辑(增、删、改)都不会对其它版面对象产生影响(这是由于通用文档模型是基于可见部分为基础构建的,不包含大量不可见的、关于版面对象之间的关系,因此修改任何一个版面对象时,其它版面对象不会产生相应的调整,例如删掉一个字,就会在其位置留下空白,右边的文字不会自动左移)。如果用户需要对文档中的已有内容进行编辑,并且还希望能像在原来那样编辑的话,有一个技术方案可以很好地满足这个应用需求。该方案是当应用软件完成初始编辑时,除了新建一层存放当前编辑的内容外,还将源文件(按照应用软件自有的格式存储,记录了各对象之间完整关系的文件,例如.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软件发出指令,在坐标(x1,y1)位置***文字串“书生意气挥斥方遒”:
UOI_Text text;
text.m_pText=Duplicate(“书生意气挥斥方遒”);
text.m_Encoding=UOI_Text::ENCODE_GB13000;
text.m_Start.x=x1;
text.m_Start.y=y1;
UOI_Insert(hLayer,1,&text);在本实例中,该层的第二个对象是文字对象;
8.A软件发出指令,关闭文档库hDocBase:
UOI_Close(hDocBase);
B软件发出指令,打开文档库c:\sample\mydocbase.sep,将其句柄存放在hDocBase:
UOI_Open(“c:\\sample\\mydocbase.sep”,FALSE,&hDocBase);
B软件发出指令,获取文档库hDocBase第一个文档集的指针,将其句柄存放在hDocSet:
UOI_GetHandle(hDocBase,0,&hDocSet);
9.B软件发出指令,获取文档集hDocSet第一个文档的指针,将其句柄存放在hDoc:
UOI_GetHandle(hDocSet,0,&hDoc);
10.B软件发出指令,获取文档hDoc第一页的指针,将其句柄存放在hPage:
UOI_GetHandle(hDoc,0,&hPage);
11.B软件获取该页版面位图,用于显示该页
UOI_GetPageBmp(hPage,rect,buf);
12.B软件发出指令,获取hPage第一层的指针,将其句柄存放在hLayer:
UOI_GetHandle(hPage,0,&hLayer);
13.B软件发出指令,获取第一个版面对象的句柄hObj:
UOI_GetHandle(hLayer,0,&hObj);
14.B软件发出指令,获取hObj的类型
UOI_GetObjType(hObj,&type);
15.B软件发现这是一个字号对象,获取该对象
UOI_GetObj(hObj,&charSize);
16.B软件将字高放大一倍:
charSize.m_Height*=2;
UOI_SetObj(hObj,&charSize);
B软件重新获取版面位图并显示,这时会发现屏幕上的“书生意气挥斥方遒”变成长体字了。
本发明改变了从用户界面到文档存储都由一个软件来完成的现状,将其划分为应用层和文档库***层,并定义一个规范两层之间交互的接口标准,还可以进一步构建一个符合该接口标准的接口层。文档库***是具备各种文档操作功能的通用技术平台,应用软件要对文档进行操作时就通过该接口层来向文档库***发出相应指令,文档库***根据该指令执行相应操作。这样,只要各应用软件和各文档库***都遵循同样的标准,不同应用软件就可以通过同一个文档库***对同一文档操作,即可实现对文档的互操作。同样,同一个应用软件也可以通过不同文档库***对不同文档进行操作,而不用分别对每种文档格式都进行单独开发。
本发明还包括一个通用文档模型,该模型能与各应用软件所需要处理的文档相符合。接口标准就是基于该文档模型来确定的,这样才能实现不同的应用软件都可以通过接口层来对文档进行操作。该通用文档模型也适用于各种文档格式,这样同一个应用软件才可以通过接口层来对不同文档格式进行操作。
接口标准定义了基于该通用文档模型对文档进行操作的各种指令,以及应用软件向文档库***发送指令的方式。文档库***具备实现这些指令的功能,以供应用软件调用。
该通用文档模型还包括由多个文档组成的文档集、文档库和文档仓库等层次,接口标准中也包含对多文档的组织管理、查询检索、安全控制等指令。
该通用模型还包括将页由具有上下顺序的层组成,接口标准中也包含对层的各种操作指令,以及对一个文档某一层所对应源文件的存储和提取。
文档库***还具备对文档的信息安全管理控制功能,如基于角色的细粒度权限管理,并在接口标准中定义了相关的操作指令。
依照本发明,使得应用层和数据处理层分离。这样应用软件不再直接跟具体的文档格式打交道,文档也不再与特定应用软件绑定,从而使得同一文档能在不同的应用软件之间通用,同一应用软件也能对不同文档进行操作,实现了文档的互操作;整个文档处理***还具备多文档处理功能,而不局限在单文档处理;将页分成多层后,可以实现对不同层实施不同管理和控制,更便于不同应用软件对同一页的操作(可以设计成不同应用软件管理和维护不同层),为以源文件方式进行编辑提供了便利,也是一种很好的保留历史痕迹的方式;通过将信息安全集成在文档处理的核心层,可以消灭安全缝隙,还能使安全机制与文档操作紧密地结合为一体,而不是可以分离的两个模块,同时有更多的空间部署安全管理技术,相关代码也能隐藏得更深,能更有效地防御非法攻击,提高安全可靠度,另外还能提供细粒度的安全管理手段,如更多的权限类别,更小的管理单元。
下面,参照图18描述依照本发明的文档操作***执行一操作的一个实例。在该实例中,应用软件通过统一的接口标准(例如UOML接口)请求对文档的操作。文档库***可能会有不同厂商的不同型号,但是对于应用开发厂商来说面向的都是同一个接口标准,因此都可以与之配套使用。Red Office、OCR、网页生成软件、乐谱编辑软件、书生阅读器、Office编辑软件、其他阅读器等通过UOML接口指示文档库***进行操作,文档库***可以有多个,在图中显示为文档库***1、文档库***2和文档库***3,文档库***根据UOML发来的统一标准指令对符合通用文档模型的文档进行操作,例如创建、保存、显示、呈现文档。在本发明中,不同的应用软件可以同时或不同时调用同一个文档库***,同一应用软件可以同时或不同时调用不同的文档库***。
依照本发明,使得应用层和数据处理层分离,使得同一文档能在不同的应用软件之间通用,使不同应用软件之间具有良好的文档互操作性。
依照本发明,形成产业分工,减少重复开发,并更加专业、完备、正确;对文档的基本操作都在文档库***中处理,各应用软件不必重复开发。而且由于文档库***是由专业厂商开发,相关技术的专业性、完备性、正确性较有保障,而且应用软件厂商和用户可以选择做的最好的一家文档库***厂商,从而保证处理效果的正确性和一致性。
依照本发明,提供多文档甚至海量文档的管理机制,使文档之间能够有效组织起来,便于检索、查询、保管,便于嵌入较强的信息安全机制。
依照本发明,提供更好的安全机制,可以设置多种角色,细粒度地设置每个角色的权限。其中细粒度是双重的,一方面可以对整个文档或文档的一个细微之处进行权限设置,另一方面可以设置种类非常多的权限,而不仅仅是传统的读/写/不可访问三级。
依照本发明,鼓励创新,合理竞争。形成合理的产业分工后,各文档库***厂商和各应用软件厂商就会在领域展开竞争,而不会再出现Microsoft Word一样靠文档格式来垄断应用软件的情形发生。各文档库***厂商也可以在标准之外增加新的功能以吸引用户,标准并不会对创新形成束缚。
依照本发明,便于优化性能,有更好的可移植性和可伸缩性。无论是什么平台,什么样的性能,都可以遵循同样的调用接口,使得在不改变接口标准的情况下可以不断优化性能,并移植到不同的平台。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等,均应包含在本发明的保护范围之内。