文档处理方法、装置、存储介质及计算机设备

技术领域

本发明涉及文档优化技术领域，尤其涉及一种文档处理方法、装置、存储介质及计算机设备。

背景技术

随着信息技术的发展，越来越多类型的电子产品受到大众的喜爱，如墨水屏电子书阅读器，其作为一种专门阅读电子书的设备，为用户提供了如纸质般的阅读享受，相较于其他设备而言，极大地提升了用户体验。

现有墨水屏电子书阅读器中安装有相应的阅读软件，如NeoReader，用户可登陆NeoReader，并选择相应的电子书下载并阅读；但是，用户在阅读的时候，不同的章节之间没有另起一页，导致阅读体验不佳；另外，NeoReader现有的排版引擎是针对HTML和CSS进行排版，若将TXT文档直接转为HTML，排版速度会很慢，翻页速度也很会慢，尤其是对于缓存较大的文档，无法及时加载并显示，也会导致用户的阅读体验不佳。

发明内容

本发明的目的旨在至少能解决上述的技术缺陷之一，特别是现有技术的墨水屏电子书阅读器中安装的阅读软件的阅读体验不佳的技术缺陷。

本发明提供了一种文档处理方法，所述方法包括：

扫描待处理文档中的每行文本；

基于每行文本包含的字节长度及预设标题规则，筛选作为标题的文本行，并确定各标题在所述待处理文档中的位置；

基于各标题在所述待处理文档中的位置，确定每一标题对应章节的起止位置；

根据所述标题及与所述标题对应章节的起止位置，建立与所述待处理文档对应的目录和章节列表。

可选地，所述的文档处理方法，还包括：

当用户打开所述待处理文档时，根据所述用户停留在所述待处理文档中的当前字节位置，调用所述章节列表确定待读取的字节范围；

读取所述字节范围内的字节流。

可选地，所述扫描待处理文档中的每行文本的步骤，包括：

检测待处理文档的文档编码；

依据所述文档编码扫描所述待处理文档中的每行文本。

可选地，所述依据所述文档编码扫描所述待处理文档中的每行文本的步骤，包括：

基于所述文档编码确定所述待处理文档的每行末尾字节位置；

根据每行末尾字节位置确定所述待处理文档中的每行文本。

可选地，所述基于每行文本包含的字节长度及预设标题规则，筛选作为标题的文本行的步骤，包括：

确定每行文本所对应的字节长度；

筛选字节长度不大于预设标题长度阈值的文本行进行解码；

根据预设标题规则判断解码后得到的各行字符串是否为标题；

若是，则将所述字符串对应的文本行作为标题。

可选地，所述根据预设标题规则判断解码后得到的各行字符串是否为标题的步骤之后，还包括：

若其中一行字符串不是标题，则依据预设章节长度阈值，将所述字符串的相邻两侧作为标题的字符串进行划分；

确定划分后的各章节的起止位置。

可选地，所述基于各标题在所述待处理文档中的位置，确定每一标题对应章节的起止位置的步骤，包括：

对于一目标标题：

将所述目标标题的开头字符在所述待处理文档中的字节位置，作为所述目标标题对应章节的起始位置；

将与所述目标标题相邻的下一标题的开头字符，在所述待处理文档中的字节位置，作为所述目标标题对应章节的截止位置。

本发明还提供了一种文档处理装置，包括：

数据扫描模块，用于扫描待处理文档中的每行文本；

标题确认模块，用于基于每行文本包含的字节长度及预设标题规则，筛选作为标题的文本行，并确定各标题在所述待处理文档中的位置；

章节确认模块，用于基于各标题在所述待处理文档中的位置，确定每一标题对应章节的起止位置；

文档建立模块，用于根据所述标题及与所述标题对应章节的起止位置，建立与所述待处理文档对应的目录和章节列表。

本发明还提供了一种存储介质，所述存储介质中存储有计算机可读指令，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如上述实施例中任一项所述文档处理方法的步骤。

本发明还提供了一种计算机设备，所述计算机设备中存储有计算机可读指令，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如上述实施例中任一项所述文档处理方法的步骤。

从以上技术方案可以看出，本发明实施例具有以下优点：

本发明提供的文档处理方法、装置、存储介质及计算机设备，在对待处理文档进行处理时，首先扫描待处理文档中的每行文本，然后根据每行文本包含的字节长度及预设标题规则筛选出作为标题的文本行，再基于各标题在待处理文档中的位置，确定每一标题对应章节的起止位置，最终根据标题及与标题对应章节的起止位置，建立目录和章节列表；这样用户在阅读文档时，可以根据用户的阅读位置来加载章节列表中指定范围的字节数据，无需加载整个文档，从而使得文档的排版速度和翻页速度得到提升，并能够支持缓存较大的文档，提升用户阅读体验；而且，由于本申请中的待处理文档在建立目录与章节列表时，是按照不同的标题及标题对应的章节起止位置建立的，不同的章节之间另起一页，使得文档的排版能够有序进行，从而进一步提高用户的阅读体验。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。

图1为本发明实施例提供的一种文档处理方法的流程示意图；

图2为本发明实施例提供的筛选文本行的流程示意图；

图3为本发明实施例提供的一种文档处理装置的结构示意图；

图4为本发明实施例提供的一种计算机设备的内部结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

随着信息技术的发展，越来越多类型的电子产品受到大众的喜爱，如墨水屏电子书阅读器，其作为一种专门阅读电子书的设备，为用户提供了如纸质般的阅读享受，相较于其他设备而言，极大地提升了用户体验。

现有墨水屏电子书阅读器中安装有相应的阅读软件，如NeoReader，用户可登陆NeoReader，并选择相应的电子书下载并阅读；但是，用户在阅读的时候，不同的章节之间没有另起一页，导致阅读体验不佳；另外，NeoReader现有的排版引擎是针对HTML和CSS进行排版，若将TXT文档直接转为HTML，排版速度会很慢，翻页速度也很会慢，尤其是对于缓存较大的文档，无法及时加载并显示，也会导致用户的阅读体验不佳。

因此，本发明的目的是解决现有技术的墨水屏电子书阅读器中安装的阅读软件的阅读体验不佳的技术问题，并提出如下技术方案：

在一个实施例中，如图1所示，图1为本发明实施例提供的一种文档处理方法的流程示意图；本发明提供了一种文档处理方法，具体包括如下步骤：

S110：扫描待处理文档中的每行文本。

本步骤中，在确定需要扫描的文档后，将其作为待处理文档，该待处理文档在进行扫描时，需要从待处理文档中进行逐个字节的读取，并按照待处理文档的文档编码等来确定每行文本，从而对每行文本进行相应的处理操作。

进一步地，在进行文档扫描之前，还可以计算待处理文档的MD5值，并将计算后得到的MD5值作为关键字，从磁盘缓存中查找是否有缓存扫描结果；如果有，则不进行扫描，如果没有，则进行扫描。

可以理解的是，本申请中的待处理文档指的是无格式文本文档，例如TXT文档。

S120：筛选作为标题的文本行，并确定各标题在待处理文档中的位置。

本步骤中，通过步骤S110扫描待处理文档的每行文本后，可以基于每行文本包含的字节长度及预设标题规则，筛选出可以作为标题的文本行，然后确定各标题在待处理文档中的位置，以便确定每一标题对应章节的起止位置。

可以理解的是，这里的待处理文档中包含有多个字节数据，在确定待处理文档中的每行文本后，相当于确定了每行的字节数据，即包含了多少个字节。

这里的预设标题规则指的是预先设定的识别章节标题的规则，该规则可以是使用训练好的机器学习模型来对文本行的字符串进行标题识别，也可以将文本行与预设标题库进行比对，从而根据比对结果来判断是否为标题。

具体地，当需要确定各行文本中可以作为标题的文本行时，可以先依据每行文本包含的字节长度来对各行文本进行初步筛选，然后依据预设标题规则来识别初步筛选后的文本行是否为标题，从而将最终筛选得到的文本行作为标题。

进一步地，对于无法确定为标题的文本行，或者没有标题的章节，还可以通过对扫描得到的各行文本的字节长度总和进行一定长度的划分，从而避免单章过大，导致排版变慢。

当筛选出可以作为标题的文本行后，可以根据各文本行在待处理文档中的位置，来确定各标题在待处理文档中的位置。

举例来说，每行文本都包含有多个字节，每个字节都有其在待处理文档中的具体位置，当筛选出可以作为标题的文本行后，可以将该文本行中的首个字节在待处理文档中的位置，作为与该文本行对应的标题在待处理文档中的起始位置，将该文本行中的末尾字节在待处理文档中的位置，作为与该文本行对应的标题在待处理文档中的结束位置。

S130：基于各标题在待处理文档中的位置，确定每一标题对应章节的起止位置。

本步骤中，通过步骤S120中基于每行文本包含的字节长度及预设标题规则，筛选出可以作为标题的文本行，并确定各标题在待处理文档中的位置后，可以基于各标题在待处理文档中的位置，确定每一标题对应章节的起止位置。

例如，当确定好各标题在待处理文档中的位置后，可以根据每一标题的开头字节的位置，来确定每一标题对应章节的起始位置，然后根据每一标题相邻的下一标题的开头字节的位置，来确定每一标题对应章节的截止位置，从而最终确定每一标题对应章节的起止位置。

S140：建立与待处理文档对应的目录和章节列表。

本步骤中，通过步骤S130基于各标题在待处理文档中的位置，确定每一标题对应章节的起止位置后，可以根据根据标题及与标题对应章节的起止位置，建立与待处理文档对应的目录和章节列表。

具体地，当确定好待处理文档的各标题以及对应章节的起止位置后，可以根据待处理文档中的各个标题来建立对应的目录，以及根据与各个标题对应章节的起止位置，来建立章节列表。

例如，一个文件大小为1.15MB(1205862字节)的中文TXT文档，通过本申请的文档处理方法扫描得到的目录为：[第一章XX，第二章XX，第三章XX，...，第十章XX]；

扫描得到的章节列表可以是[开始，第一章XX，第二章XX，第三章XX，...，第十章XX，第十一章，第十二章]。其中，第一章不在文档的开始，所以章节列表中，会多一个开始章节，第十一章和第十二章没有检测到标题，可以按照预设章节长度阈值分割得到。扫描后的章节列表对应的字节起始范围可以是：

开始：[0,1024)

第一章XX：[1024,10240)

第二章XX：[10240,20480)

第三章XX：[20480,40960)

……

第十章XX：[102400,105000)

第十一章：[105000,1155000)，这章最大范围是105000+100*1024＝1152400字节，当读到一行文字，行尾位置字节位置1155000大于1152400后，就将这行记为第十一章的末尾行。

第十二章：[1155000,1205862)，1205862是文件的末尾字节位置。

上述实施例中，在对待处理文档进行处理时，首先扫描待处理文档中的每行文本，然后根据每行文本包含的字节长度及预设标题规则筛选出作为标题的文本行，再基于各标题在待处理文档中的位置，确定每一标题对应章节的起止位置，最终根据标题及与标题对应章节的起止位置，建立目录和章节列表；这样用户在阅读文档时，可以根据用户的阅读位置来加载章节列表中指定范围的字节数据，无需加载整个文档，从而使得文档的排版速度和翻页速度得到提升，并能够支持缓存较大的文档，提升用户阅读体验；而且，由于本申请中的待处理文档在建立目录与章节列表时，是按照不同的标题及标题对应的章节起止位置建立的，不同的章节之间另起一页，使得文档的排版能够有序进行，从而进一步提高用户的阅读体验。

上述实施例主要对本申请的文档处理方法进行了展开说明，下面将对本申请的文档处理方法进行进一步说明。

在一个实施例中，所述的文档处理方法，还可以包括：

S150：当用户打开所述待处理文档时，根据所述用户停留在所述待处理文档中的当前字节位置，调用所述章节列表确定待读取的字节范围。

S160：读取所述字节范围内的字节流。

本实施例中，当用户打开已建立好目录和章节列表的待处理文档时，客户端可以根据用户在待处理文档的停留处的当前字节位置，来调用章节列表，通过章节列表来确定当前字节位置对应的章节列表中待读取的字节范围，从而读取该字节范围内的字节流。

举例来说，当用户打开客户端中的某一阅读软件后，通过该阅读软件选择相应的文档进行阅读，若该文档在此次阅读之前并未被该用户所打开，则此时用户打开该文档时显示为文档的开始页，客户端监测到用户当前停留的位置为文档的开始页后，调用章节列表来确定与开始页对应的字节范围，该字节范围为开始页的字节范围，当确定好字节范围后，客户端便可读取该字节范围所对应的字节流，从而将该字节流进行排版和渲染后显示在客户端。

若该文档在此次阅读之前已被该用户所打开，则客户端可以根据用户的历史记录，监测到用户当前打开的页面所对应的字节位置，并调用章节列表来确定对应的字节范围，该字节范围为与该页面对应章节的字节范围，当确定好字节范围后，客户端便可读取该字节范围所对应的字节流，从而将该字节流进行排版和渲染后，显示该页面的页面数据。

当根据章节列表加载指定范围的字节流后，可创建HTML文档，创建CSS样式。例如，第一章XX，根据字节起始范围[1024,10240)，从文件中读取字节流，逐行读取，第一行是标题，应用标题样式；第二行到最后一行，是段落，应用段落样式。

根据创建的HTML文档和CSS样式，在翻页的时候，对每章进行排版，新的章节从新的页面开始排版，这样就达到了新章节另起一页的效果。读取到标题，就根据标题样式进行渲染，例如常见的标题样式就是字号比正文更大，加黑加粗，正文段落就是比标题小一些的字号，不加黑不加粗。

上述实施例中，由于待处理文档进行了分章处理，所以排版速度会很快，加载到内存的文本数据也很小，因而支持大TXT文档，例如500MB的TXT文档。

以一本文件大小为1.15MB(1205862字节)的中文TXT文档为例，使用阅读器NeoReader的现有方案打开时，需要扫描整个TXT文档，耗时1123毫秒，翻页1102毫秒；在使用本方法后，扫描文档花费132毫秒，分割为十三个章节，第一次加载时，只需加载“开始”这一章，只有1024字节数据，耗时1毫秒，翻页109毫秒。所以，使用本方法后，文档打开速度和翻页速度得到了提升。在使用现有方案时，打开文档，需要加载整个TXT文档，占用内存1.15MB；在使用本方法后，只加载了当前章节的字节数据，例如，加载“开始”这一章，只占用了1024字节，内存使用也降低了。

上述实施例对本申请的文档处理方法进行进一步说明，下面将对如何扫描并获取待处理文档中的每行文本进行具体描述。

在一个实施例中，步骤S110中扫描待处理文档中的每行文本的步骤，可以包括：

S111：检测待处理文档的文档编码。

S112：依据所述文档编码扫描所述待处理文档中的每行文本。

本实施例中，在扫描待处理文本的每行文本时，可先通过第三方算法检测待处理文档的文档编码，然后依据该文档编码扫描待处理文档的每行文本。

例如，本申请可以使用Mozilla开源算法来自动检测TXT文档的文档编码，当检测到TXT文档的文档编码后，即可按照对应的文档编码中的格式进行逐行扫描，从而得到每行文本。

上述实施例对如何扫描并获取待处理文档中的每行文本进行具体描述，下面将对如何依据文档编码扫描待处理文档中的每行文本进行展开说明。

在一个实施例中，步骤S112中依据所述文档编码扫描所述待处理文档中的每行文本的步骤，可以包括：

S201：基于所述文档编码确定所述待处理文档的每行末尾字节位置。

S202：根据每行末尾字节位置确定所述待处理文档中的每行文本。

本实施例中，在检测到待处理文档的文档编码后，可以依据该文档编码来确定待处理文档的每行末尾字节位置，然后根据每行末尾字节位置来确定待处理文档中的每行文本。

以GBK编码为例，当检测到待处理文档的文档编码为GBK编码时，GBK编码的换行符可以是\r\n(十六进制表示0x0D 0x0A)，或是\n(0x0A)，然后根据GBK编码的换行符对待处理文档进行逐个字节判断，确定是否为换行符，找到换行符，就可以获取到行末尾字节位置；或者，读取到文件末尾，那么文件末尾字节位置，就是最后一行文本的字节位置。

进一步地，在读取字节时，以GBK编码为例，从待处理文档开始处逐个读取字节，读取到\n(0x0A)的位置为BYTE1，然后判断上一个字节是否为\r(0x0D)，如果是\r，则第一行字节数据范围为LINE_BYTE_RANGE[0,BYTE1-1]；如果不是\r，则第一行字节数据范围为LINE_BYTE_RANGE[0，BYTE1]；然后根据第一行起始范围LINE_BYTE_RANGE，加载第一行字节数据。同理，读取第二行，...第N行，其中最后一行指的是截止到文件末尾字节位置。

上述实施例对如何依据文档编码扫描待处理文档中的每行文本进行展开说明，下面将对如何筛选标题对应的文本行进行详细描述。

在一个实施例中，如图2所示，图2为本发明实施例提供的筛选文本行的流程示意图；步骤S120中基于每行文本包含的字节长度及预设标题规则，筛选作为标题的文本行的步骤，可以包括：

S121：确定每行文本所对应的字节长度。

S122：筛选字节长度不大于预设标题长度阈值的文本行进行解码。

S123：判断解码后的各行字符串是否为标题，若是的话，则执行步骤S124，若其中一行字符串不是标题，则执行步骤S125。

S124：将所述字符串对应的文本行作为标题。

本实施例中，如图2所示，通过每行文本包含的字节长度及预设标题规则，筛选作为标题的文本行时，可先确定每行文本所对应的字节长度，然后筛选出自己长度不大于预设标题长度阈值的文本行进行解码，然后依据预设标题规则对解码后得到的各行字符串进行判断，判断其是否为标题，若是的话，则将该行字符串对应的文本行作为标题。

可以理解的是，这里的预设标题长度阈值指的是不大于最大标题字节长度的取值，由于解码需要花费较长时间，所以这里通过预设标题长度阈值来提高文本扫描速度。

例如，预设中文标题长度阈值为40个字符，检测到的待处理文档的文档编码是UTF-8，一个UTF-8编码的字符，最大为3个字节，则最大字节长度为预设中文标题长度阈值*文本编码中每个字符对应的最大字节数，那么预设中文标题长度阈值为40*3＝120字节。

当筛选出字节长度不大于预设标题长度阈值的文本行进行解码后，可根据预设标题规则来判断解码后得到的各行字符串是否为标题，若是的话，则将各行字符串对应的文本行作为标题。

其中，预设标题规则指的是预先设定的识别章节标题的规则，该规则可以是使用训练好的机器学习模型来对文本行的字符串进行标题识别，也可以将文本行与预设标题库进行比对，从而根据比对结果来判断是否为标题。

上述实施例对如何筛选标题对应的文本行进行详细描述，下面将对识别不出是否为标题的文本行进行展开说明。

在一个实施例中，如图2所示，步骤S123中根据预设标题规则判断解码后得到的各行字符串是否为标题的步骤之后，还可以包括：

S125：依据预设章节长度阈值，将所述字符串的相邻两侧作为标题的字符串进行划分。

S126：确定划分后的各章节的起止位置。

本实施例中，若对各行字符串进行标题识别时，某些字符串行存在标题无法识别，或没有章节标题的情况的话，则可以依据预设章节长度阈值，将该行字符串的相邻两侧作为标题的字符串进行划分，并确定划分后的各章节的起止位置。

举例来说，如果识别不成功，则表示当前文本行的标题识别失败，或是没有章节标题，此时，可通过预设章节长度阈值，来判断当前章节扫描过的字节长度是否大于预设章节长度阈值，如果大于的话，则将当前位置记为当前章节的末尾位置，以及下一章节的起始位置，此时下一章节无标题。

其中，预设章节长度阈值指的是不大于最大章节长度的取值，使用预设章节长度阈值，主要是为了避免单章过大，导致排版变慢。预设章节长度阈值可以是100KB，则每章最大字节数就是100KB。

例如，一个文件大小为1.15MB(1205862字节)的中文TXT文档，通过本申请的文档处理方法扫描得到的章节列表可以是[开始，第一章XX，第二章XX，第三章XX，...，第十章XX，第十一章，第十二章]。

其中，第一章不在文档的开始，所以章节列表中，会多一个开始章节，第十一章和第十二章没有检测到标题，可以按照预设章节长度阈值分割得到。分割时，可依据第十章到第十三章的标题，确定分割的起止位置，然后对第十章至第十三章之间的章节长度，按照预设章节长度阈值进行划分，当第十章到第十三章之间按照预设章节长度阈值划分为四段后，可确定中间两段分别为第十一章和第十二章，但由于该方式为依据章节长度进行划分，因而第十一章和第十二章没有标题。

进一步地，对于500MB的大TXT，在使用现有方案时，由于设备内存限制为256MB，所以文档无法打开；在使用本方案时，由于限制了每章的预设章节长度阈值，如每章最多占用内存100KB，所以对于大文档，也支持打开。

上述实施例对识别不出是否为标题的文本行进行展开说明，下面将对如何确定每一标题对应章节的起止位置进行详细说明。

在一个实施例中，步骤S130中基于各标题在所述待处理文档中的位置，确定每一标题对应章节的起止位置的步骤，可以包括：

S131：对于一目标标题：将所述目标标题的开头字符在所述待处理文档中的字节位置，作为所述目标标题对应章节的起始位置。

S132：将与所述目标标题相邻的下一标题的开头字符，在所述待处理文档中的字节位置，作为所述目标标题对应章节的截止位置。

本实施例中，在基于各标题在待处理文档中的位置确定每一标题对应章节的起止位置的过程中，可以先确定一待确定章节起止位置的标题作为目标标题，然后将该目标标题的开头字符在待处理文档中的字节位置，作为目标标题对应章节的起始位置，将与目标标题相邻的下一标题的开头字符，在待处理文档中的字节位置，作为目标标题对应章节的截止位置，从而得到目标标题对应章节的起止位置。

下面对本申请实施例提供的文档处理装置进行描述，下文描述的文档处理装置与上文描述的文档处理方法可相互对应参照。

在一个实施例中，如图3所示，图3为本发明实施例提供的一种文档处理装置的结构示意图；本发明还提供了一种文档处理装置，包括数据扫描模块210、标题确认模块220、章节确认模块230、文档建立模块240，具体包括如下步骤：

数据扫描模块210，用于扫描待处理文档中的每行文本。

标题确认模块220，用于基于每行文本包含的字节长度及预设标题规则，筛选作为标题的文本行，并确定各标题在所述待处理文档中的位置。

章节确认模块230，用于基于各标题在所述待处理文档中的位置，确定每一标题对应章节的起止位置。

文档建立模块240，用于根据所述标题及与所述标题对应章节的起止位置，建立与所述待处理文档对应的目录和章节列表。

上述实施例中，在对待处理文档进行处理时，首先扫描待处理文档中的每行文本，然后根据每行文本包含的字节长度及预设标题规则筛选出作为标题的文本行，再基于各标题在待处理文档中的位置，确定每一标题对应章节的起止位置，最终根据标题及与标题对应章节的起止位置，建立目录和章节列表；这样用户在阅读文档时，可以根据用户的阅读位置来加载章节列表中指定范围的字节数据，无需加载整个文档，从而使得文档的排版速度和翻页速度得到提升，并能够支持缓存较大的文档，提升用户阅读体验；而且，由于本申请中的待处理文档在建立目录与章节列表时，是按照不同的标题及标题对应的章节起止位置建立的，不同的章节之间另起一页，使得文档的排版能够有序进行，从而进一步提高用户的阅读体验。

在一个实施例中，本发明还提供了一种存储介质，所述存储介质中存储有计算机可读指令，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如上述实施例中任一项所述文档处理方法的步骤。

在一个实施例中，本发明还提供了一种计算机设备，所述计算机设备中存储有计算机可读指令，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如上述实施例中任一项所述文档处理方法的步骤。

示意性地，如图4所示，图4为本发明实施例提供的一种计算机设备的内部结构示意图，该计算机设备300可以被提供为一服务器。参照图4，计算机设备300包括处理组件302，其进一步包括一个或多个处理器，以及由存储器301所代表的存储器资源，用于存储可由处理组件302的执行的指令，例如应用程序。存储器301中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件302被配置为执行指令，以执行上述任意实施例的文档处理方法。

计算机设备300还可以包括一个电源组件303被配置为执行计算机设备300的电源管理，一个有线或无线网络接口304被配置为将计算机设备300连接到网络，和一个输入输出(I/O)接口305。计算机设备300可以操作基于存储在存储器301的操作系统，例如WindowsServer TM、Mac OS XTM、Unix TM、Linux TM、Free BSDTM或类似。

本领域技术人员可以理解，图4中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间可以根据需要进行组合，且相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。