CN117859111A

CN117859111A - 用于生成和应用补丁包的系统和方法

Info

Publication number: CN117859111A
Application number: CN202280057260.5A
Authority: CN
Inventors: E·H·拉隆; M·J·梅
Original assignee: Philo Systems Ltd
Current assignee: Philo Systems Ltd
Priority date: 2021-06-22
Filing date: 2022-06-22
Publication date: 2024-04-09
Also published as: WO2022269612A1; IL284315B; EP4359915A1

Abstract

用于创建和应用软件包(通常被称为“补丁”或“补丁包”)的系统和方法通过在原始软件版本上应用补丁，能够更高效地创建软件包的更新版本。由于花费了更多的时间来分析各版本的逻辑结构，因此本发明的实施例可能需要(与本领域的差分模块相比)更多的资源，例如时间、处理能力和存储空间来准备(创建)补丁，但是结果通常是更小和更高效的补丁包。还公开了用于压缩和解压缩补丁包(无论是作为更新还是通过使用单存档输入)的系统和方法。

Description

用于生成和应用补丁包的系统和方法

技术领域

本发明总体上涉及增量更新的软件系统和方法，特别是涉及考虑到原始软件的内容和结构而生成高效补丁包的软件系统和方法。

背景技术

若干计算领域依赖于越来越大的文件集合，这些集合需要不时地更新。更新用途广泛，因此它们可能包括添加新特征、删除特征、纠正错误、修复安全问题等。在其他情况下，更新用于跟踪随时间的变化。这在文件管理系统、版本控制、备份和恢复系统以及基于日志的数据库更新中显而易见。

在计算的早期，新版本发布的频率较低，大小较小，并且是在诸如CD-ROM等的硬介质上发布的。如今，在线更新的大小更大，发布更频繁，有时在发布后不久就被大量用户下载，例如，在针对新发现的安全漏洞发布关键安全更新的情况下，或者在流行游戏或应用的新版本变得可用时。

这些更新被分组成应用于现有软件版本的称为“补丁”的单个元素，以将现有软件升级到较新的版本。典型地，用户下载补丁，并且通过在现有软件版本上应用该补丁来升级到较新的版本。就用户下载的文件的大小而言，发送补丁被认为比发送整个全新版本更高效。

当这种更新要在短时间段内被发送到数十万个计算装置或者在某些情况下甚至数亿个计算装置时，减少数据通信成本和带宽要求可能成为高优先级。此外，减少下载和更新这些计算装置所需的时间会改善用户体验。

发明内容

本发明涉及一种补丁生成计算系统，包括：

至少一个处理器；以及

至少一个存储器，其通信地耦合到所述至少一个处理器，并且包括计算机可读指令，所述计算机可读指令在被所述至少一个处理器执行时使得所述计算系统实现用于生成包括补丁数据和补丁指令的补丁包的方法，所述补丁包适于将原始存档元素更新为目的存档元素，所述方法包括：

(i)将原始存档元素指派为匹配对中的原始元素，并且将目的存档元素指派为所述匹配对中的目的元素；

(ii)比较所述匹配对中的所述原始元素和所述目的元素，并且在不同的情况下准备相应的补丁指令，该补丁指令包括指示与所述目的元素相关的添加、删除或更新的补丁操作的动作；

(iii)识别所述原始元素和所述目的元素的结构类型，所述结构类型是“目录”、“存档”、“经压缩”和“数据”其中之一；

(iv)在所述结构类型是复合存档元素的情况下：

a.识别适于应用于所述原始元素和所述目的元素的至少一个解压缩模块或解包模块，

b.将所识别的至少一个解压缩模块或解包模块应用于所述原始元素，并且将得到的零个或多于零个内部存档元素保存到包括多个存档元素的原始存档结构，

c.将所识别的至少一个解压缩模块或解包模块应用于所述目的元素，并且将得到的零个或多于零个内部存档元素保存到包括多个存档元素的目的存档结构；

(v)关于所述目的元素，更新补丁指令，该补丁指令包括所述补丁指令动作、结构类型、所述目的元素的标识符以及所识别的至少一个解压缩或解包模块；

(vi)识别另外的一个或多于一个匹配对，该另外的一个或多于一个匹配对中的各个匹配对包括被指派为内部元素的来自步骤(iv.b)的所述得到的零个或多于零个内部存档元素的一个内部存档元素、以及被指派为目的元素的来自步骤(iv.c)的所述得到的零个或多于零个内部存档元素的一个内部存档元素，其中通过识别相同的标识符来匹配原始元素和目的元素；

(vii)针对所述另外的一个或多于一个匹配对，重复步骤(ii)至(vi)；(viii)将差分模块应用于所述原始存档结构和所述目的存档结构，并且生成包括补丁数据和补丁指令的补丁包，使得能够通过将所述补丁数据与所述补丁指令一起应用于相应的原始存档元素来构建所述目的存档元素。

在一些实施例中，在所识别的存档元素的结构类型是“数据”的情况下，所述方法还包括：

a.识别所述目的元素的数据类型，并且识别能够将所识别的数据类型转换成解码数据格式的解码模块；

b.将所识别的解码模块应用于所述目的元素，并且生成所述目的元素的解码版本以替换所述目的存档结构中的该目的元素；

c.将所识别的解码模块应用于所述原始元素，并且生成所述原始元素的解码版本以替换所述原始存档结构中的该原始元素；以及

d.在所述补丁指令中指示所述数据类型或所述解码模块或这两者。

在一些实施例中，在步骤(viii)之前，根据排序准则将所述存档元素一次或多于一次排序到存档元素的分组序列中，并且在步骤(vi)中，以所述分组序列将所述存档元素一次或多于一次输入到所述差分模块，从而得到一个或多于一个补丁包。

在一些实施例中，排序准则包括：自然顺序；归类顺序；根据所识别的存档元素的数据类型对存档元素的匹配对进行分组；根据匹配对的存档元素的属性对匹配对进行分组；匹配对与所述补丁指令内的存档元素的属性相对应；或它们的任何组合。

在一些实施例中，在步骤(viii)中，应用多个差分模块，从而得到多个补丁包。

在一些实施例中，在步骤(viii)中，使用包括字典大小和/或压缩级别的不同差分模块参数多次运行所述差分模块，从而关于每次差分模块运行，得到多个补丁包。

在一些实施例中，所述计算系统还包括根据预定选择准则从得到的补丁包中识别最高效的补丁的步骤。

在一些实施例中，所述原始存档元素为空，从而得到作为所述目的存档元素的压缩形式的补丁包。

在一些实施例中，所述计算系统还包括补丁生成器策略，所述补丁生成器策略指定针对如何生成所述补丁包的规则和偏好。

在一些实施例中，所述补丁生成器策略包括与转换模块、结构类型、内容识别模块、差分模块、存档元素的数据类型和属性有关的逻辑谓词。

在一些实施例中，在步骤(iii)中，能够识别“链接”的结构类型。

在一些实施例中，所述计算系统还在所述补丁指令中包括：包含与所述目的元素相同数据的其他存档元素的指示、或者得到所述目的元素的其他补丁指令的指示。

在另一方面，本发明涉及一种在计算系统中实现的补丁生成方法，所述计算系统包括：

至少一个处理器；以及

(iv)在所述结构类型是复合存档元素的情况下：

(vii)针对所述另外的一个或多于一个匹配对，重复步骤(ii)至(vi)；

(viii)将差分模块应用于所述原始存档结构和所述目的存档结构，并且生成包括补丁数据和补丁指令的补丁包，使得能够通过将所述补丁数据与所述补丁指令一起应用于相应的原始存档元素来构建所述目的存档元素。

在另一方面，本发明涉及一种补丁应用计算系统，包括：

至少一个处理器；以及

至少一个存储器，其通信地耦合到所述至少一个处理器，并且包括计算机可读指令，所述计算机可读指令在被所述至少一个处理器执行时使得所述计算系统实现用于基于原始存档元素和补丁包生成目的存档元素的方法，所述补丁包包括多个补丁指令和补丁数据，所述方法包括：

针对所述补丁指令中的各个补丁指令，对由该补丁指令指示的元素进行以下操作：

(i)识别所述元素的结构类型和关于所述元素的动作，所述结构类型包括“目录”、“存档”、“经压缩”、“链接”或“数据”；

(ii)将所述原始存档元素内的所述元素识别为原始元素，并且如果需要，则在所述元素在存档内或在压缩位置内的情况下，对所述元素的位置应用步骤(iii)和(iv)以获得所述元素；

(iii)在所述结构类型是压缩的情况下，

a.识别能够对所述原始元素进行解压缩的解压缩模块，

b.将所述原始元素解压缩为目的元素，并且将所述目的元素存储在目的存档结构中，

c.标记所述原始元素以供压缩；

(iv)在所述结构类型是存档的情况下，

a.识别能够对所述原始元素进行解包的解包模块，

b.将所述原始元素解包为目的元素，并且将所述目的元素存储在目的存档结构中，

c.标记所述原始元素以供存档，

d.在所述动作指示“链接”的情况下，获得在所述补丁指令中指示的所述目的存档结构中的其他元素，并且利用所述目的存档结构中的所述其他元素的数据替换所述元素的数据；

(v)在所述原始元素被标记以供存档或压缩的情况下，识别在所述原始元素的位置中具有位置的所有补丁指令，并且针对具有该位置的所述补丁指令中的各个补丁指令执行步骤(i)至(v)；

(vi)在所述动作指示“添加”或“更新”的情况下，使用补丁数据对所述目的元素执行补丁应用模块，从而得到所述目的元素的更新版本；

(vii)在指令动作指示“删除”的情况下，删除所述元素；否则：

a.在所述结构类型是存档或所述元素被标记以供存档的情况下，识别能够对所述元素进行存档的存档模块，根据补丁指令中的指示和/或元数据对所述元素进行存档；以及

b.在所述结构类型是压缩或所述元素被标记以供压缩的情况下，识别能够对所述元素进行压缩的压缩模块，根据补丁指令中的指示和/或元数据对所述元素进行压缩。

在一些实施例中，在步骤(v)之前，在所述补丁指令指示解码的情况下：

(i)将匹配解码模块应用于所述元素，从而得到解码元素，利用所述解码元素替换所述目的元素，并且标记所述目的元素以供编码；

(ii)在进行步骤(vii.b)之后，在所述补丁指令指示编码或者所述元素被标记以供编码的情况下，将匹配编码模块应用于所述更新版本，利用所述更新版本替换所述目的元素，并且标记所述目的元素以供编码。

在一些实施例中，所述计算系统生成目的存档元素还基于补丁应用器策略来进行。

在一些实施例中，所述补丁应用器策略包括与以下项相关的规则：关于转换模块的逻辑谓词；结构类型；数据类型；存档元素的属性；关于补丁应用模块的逻辑谓词；或它们的任何组合。

在另一方面，本发明涉及一种压缩计算系统，包括：

至少一个处理器；以及

至少一个存储器，其通信地耦合到所述至少一个处理器，并且包括计算机可读指令，所述计算机可读指令在被所述至少一个处理器执行时使得所述计算系统实现用于将多个目的存档元素压缩到包括补丁数据和补丁指令的补丁包中的方法，所述方法包括：

(i)将目的存档元素指派为匹配对中的目的元素，并且将空指示指派为所述匹配对中的原始元素；

(ii)针对所述多个目的存档元素中的每个目的存档元素，进行以下操作：

a.识别所述目的存档元素的结构类型，所述结构类型包括“目录”、“存档”、“经压缩”或“数据”，

b.在结构类型是“经压缩”的情况下，

A.识别与所述目的元素兼容的至少一个解压缩模块；

B.将所述至少一个解压缩模块应用于所述目的元素；

C.存储包括存档元素的B的结果，各个存档元素是目的存档结构中的内部存档元素，

c.在结构类型是“存档”的情况下，

A.识别与所述目的元素兼容的至少一个解包模块；

B.将所述至少一个解包模块应用于包括存档元素的目的存档结构，各个存档元素是内部存档元素；

d.关于所述目的元素来更新补丁数据和补丁指令，添加所述结构类型、所述目的元素的标识符、在适用的情况下的所识别的所述至少一个解压缩模块、以及在适用的情况下的所识别的所述至少一个解包模块；

(iii)针对多个所述存档元素重复步骤(ii)，各个存档元素是所述目的存档结构中的内部存档元素；以及

(iv)将所选择的压缩模块或差分模块应用于所述目的存档结构，以及生成适于重建所述多个目的存档元素的包括补丁数据和补丁指令的补丁包。

在一些实施例中，所述计算系统还包括以下步骤：在步骤(iv)中应用所选择的压缩模块或差分模块之前，使用存档模块将所述目的存档结构打包成存档。

在另一方面，本发明涉及一种压缩计算系统，包括：

至少一个处理器；以及

(ii)针对包括空指示作为原始元素且包括所述多个目的存档元素中的一个存档元素作为目的元素的每个匹配对，进行以下操作：

a.识别所述目的元素的数据类型，并且尝试匹配能够将所述目的元素转换成解码数据格式的解码模块，

b.在成功匹配解码模块的情况下，将所述目的元素解码成解码数据格式，并且相应地更新补丁数据和补丁指令，

c.在可用的情况下将所述解码数据格式作为存档元素存储在目的存档结构中，以及在不可用的情况下存储所述目的元素；

(iii)在适用的情况下使用存档模块将所述目的存档结构打包成存档；以及

在一些实施例中，所述计算系统还包括以下步骤：在应用所选择的压缩模块或差分模块之前，使用存档模块将所述目的存档结构打包成存档。

附图说明

图1a是根据本发明实施例的补丁生成器的框图，以及图1b是根据本发明实施例的补丁应用器的框图。

图2是根据本发明实施例的遍历原始和目的存档元素以针对各个存档元素准备解码存档结构的处理的流程图。

图3是用于遍历存档元素的匹配对(典型地目的和原始存档结构)并且构建高效补丁包的处理的流程图。

图4是根据本发明实施例的用于从原始存档元素和补丁指令重建目的存档元素的处理的流程图。

具体实施方式

在以下对各种实施例的详细说明书中，参考构成说明书一部分的附图，并且在说明书中通过例示的方式示出了可以实施本发明的具体实施例。应当理解，可以利用其他实施例，并且可以在不脱离本发明范围的情况下进行结构改变。

用于进行增量更新(incremental update)、差量更新(differential update)、版本控制、版本管理文件系统等的商业可用工具典型地针对最初的大量文件/对象的更高版本来审查这些文件/对象(可以是任何结构类型形式，即压缩、存档等)。这些差分工具典型地将第一版本视为一个二进制套件(不知道内部逻辑结构)，以与第二二进制套件进行比较。

本发明涉及创建和应用软件包(通常称为“补丁”或“补丁包”)的系统和方法，通过在原始软件版本上应用补丁，能够更高效地创建软件包的更新版本。由于本发明的实施例花费更多的时间来分析各版本的逻辑结构，因此这些实施例可能需要更多的资源(例如时间、处理能力和存储空间)来准备(创建)补丁(与本领域的差分模块相比)，但是结果通常是更小和更高效的补丁包。

本发明还涉及压缩和解压缩补丁包(无论是作为更新还是通过使用单存档输入)的系统和方法，如下所述。

行业可应用示例1

软件包“Eclipse”(最初由IBM^TM公司开发)从4.18版本(2020-12，2021年4月下载量超过1600000次)更新到4.19版本(2021-03，2021年4月下载量超过1200000次)。4.19版本仅作为整个新版本的独立下载(没有相对于4.18版本可用的增量或差量上传)而在eclipse.org上可获得，并且下载的包大小约为341MB。

本发明的实施例创建了补丁包170以从版本4.18升级到版本4.19。补丁包的大小仅为13.5MB，大约是4.19版本的原始大小的3.95％，这意味着在目前发送整个4.19版本的单个包花费的时间，eclipse.org网站处的同一服务器可以发送约25个补丁(服务于25个用户)。这将减少网站服务器和通信线路的费用，并且将增加用户满意度，因为下载处理对用户而言将更快。

相比之下，对于相同的包，使用最新技术的“vcdiff”规范(xdelta3)准备的补丁包的大小为59MB，或是4.19的完全版本的大小的约18％，并且是由本发明准备的包4倍以上大(59MB与本发明的13.5MB相比)。

行业可应用示例2

流行的Android^TM游戏“Clash Royale^TM”例如在因特网可访问的Google Play^TM商店经常针对数千万(10000000+)的游戏玩家而更新。使用压缩.xapk格式的压缩存档的Clash Royale^TM的2021年5月更新具有约141兆字节的存储容量。

本发明的实施例创建了补丁包170，以从先前的版本3.4.2升级到当时的当前版本3.5.0。该补丁包170的大小仅约为5.0MB(兆字节)，大约是向市场发布的3.5.0版本的实际原始大小的3.7％，这意味着Google Play^TM的同一服务器可以在当前发送整个3.5.0包的单个包所花费的相同时间发送约27个补丁(服务于27个用户)。这种补丁的大小的减少将减少网站服务器和通信线路的成本，并且增加用户满意度，因为下载处理对它们而言更快。

相比之下，使用最新技术的“vcdiff”规范(xdelta3)准备的竞争补丁包是51MB(兆字节)，或者是由Google Play^TM商店发送的3.5.0完全版本的大小的约38％，并且是由本发明准备的补丁包170大约10倍大(51MB与本发明的5MB相比)。

现在参考图1a，该图示出了生成补丁包170的示例性实施例。输入120可以包含原始存档元素(original archive element)130(也称为“源(source)”)，并且必须包含至少一个目的存档元素(destination archive element)132(也称为“目的”)。可选地，可以提供补丁生成器策略134来指定如何生成补丁包170的偏好。

原始存档元素130是要更新的原始数据结构(例如，如上面示例中包含Eclipse版本4.18的压缩存档“.tar.gz”)，典型地大量文件，有时布置在若干文件夹中，一些或所有文件可以被压缩和/或存档。

存档元素可以被分类为以下5个结构类型中的任何一个或多于一个：

1.“链接”——链接仅是指向另一存档元素的指针，该另一存档元素也可能是这5个结构类型中的任一个；

2.“目录”——目录(又名“文件夹”)是在文件系统中使用的术语，目录逻辑上包含或引用另外的存档元素(诸如文件、目录、存档和/或链接等)；或者当目录的逻辑元素驻留在内部存储器(与例如硬盘类型介质相对)中时，目录被表示为存储器中的数据结构，诸如数组、列表、树、哈希表、哈希映射或能够包含或指向(例如，通过存储器引用)至少一个或多于一个内部存档元素的任何其他类似数据结构；

3.“存档”——存档是如下的结构类型，该结构类型指示存档元素是包含有作为“内部存档元素”的至少一个其他存档元素的组合。与“目录”结构类型不同，“存档”结构类型实际上将若干其他存档元素打包在一起，而不仅仅是指向或引用这些若干其他存档元素。为了使用存档的内部存档元素(查看、编辑、执行(根据相关而定))，首先需要通过使用解包模块145从存档中解包内部存档元素；

4.“经压缩”——压缩存档元素是如下所述通过先前使用压缩模块141而大小减少了的存档元素；可以稍后通过使用解压缩模块144对存档元素进行解压缩；或者

5.“数据(data)”——类型数据的存档元素可以是文件系统上的文件、存储器中的对象、数据库中的记录、以及不是上述4个结构类型的任何逻辑等价物。

每当结构类型是“目录”、“存档”和“经压缩”其中至少之一、并且因此能够包括至少一个内部存档元素时，由结构类型分类的相关相应存档元素被定义为“复合存档元素”(为简洁起见，在下面的描述中使用该术语)。

目的存档元素132是目的数据结构结果，可以通过结合原始存档元素130应用补丁包170例如使用处理400来重新创建目的存档元素。如原始存档元素130那样，目的存档元素132是上述公开的相同的5个结构类型其中至少之一。

可选地，可以使用补丁生成器策略134。这些策略包括关于如何进行下面讨论的处理200和300的规则集合。规则可以包括与转换模块140、结构类型、内容识别模块148、差分模块160、由处理200和处理300处理的存档元素的数据类型和属性有关的任何逻辑谓词。

转换模块140本质上是如下的三个主要的对的类型的编解码器或滤波器：压缩-解压缩、存档-解包和编码-解码。转换模块140中的每一个可以获取输入数据并将其转变成输出数据，使得其的成对模块可以获取该输出数据并将其返回到原始输入数据。转换模块140对为：压缩模块141与解压缩模块144；存档模块142与解包模块145；以及编码模块144与解码模块147。另外，差分模块160和补丁应用模块180也是成对模块。典型地，在行业中，对数据进行转换的模块与对数据进行压缩或解压缩的模块之间没有明确的区别；然而，本发明广泛利用了这种区别。

为了本发明的目的，我们将介绍对数据进行压缩和解压缩的模块与将数据从一个格式编码和解码为另一格式的模块之间的重要区别。我们为本发明做出的第一区别是，压缩模块141可以将包括二进制位的任何输入数据编码成通常包括较少二进制位的输出数据，而编码器143仅可以将特定格式的数据转换成其他特定格式的输出数据。另一区别是，压缩可以是由于数据元素被去除或数学上近似因而结果的大小更小的有损压缩，因此在解压缩之后，非常原始的数据可能不能保留其完整性，例如，可能不能解压缩成完全相同的格式。例如，当将位图格式的图像转换成JPEG格式的更小大小的图像时，图像的质量降低，并且不能仅从JPEG版本重建原始位图图像。另一方面，在例如以保留所有原始图像数据的PNG格式对文件或对象进行编码/解码时，没有数据丢失。

例如，诸如(Google^TM公司的)“brotli”等的流行压缩模块可以将任何输入(例如文件)(无论其数据内容如何)转换成包含brotli字典和解压缩指令的输出(例如另一文件)。然而，诸如“png2bmp”等的滤波器模块仅可以获取以公开可用的“PNG”格式编码并遵守该格式的数据(例如文件)，并且仅可以以现有“bmp”格式之一输出其数据。

我们现在将参考可用的转换模块140：

压缩模块141可以在固件、软件和/或硬件中实现，并且能够转换输入位(例如，文件、存储器对象、记录或者甚至流式位流)，并且将这些输入位转变成例如通常比输入位更高效(例如，大小更小)的输出位。

注意：压缩模块的目标是产生与输入相比大小更小的输出。然而，在一些情况下，输入文件可能不适合被所使用的压缩模块的算法高效地压缩，并且所得输出(包括压缩(例如，字典和解压缩指令)的一些开销)可能实际上比输入文件大。

如今存在的许多压缩模块141被分类为“字典编码器”，这是用于实现一些升级效率的本主题的关键。

作为字典编码器的流行压缩模块包括(按字母顺序)字节对编解码器和以色列LZ压缩系列LZ77和LZ78(由Abraham Lempel和Jacob Ziv提出)及其国际衍生产物：Brotli、Deflate、LZ4、LZFSE、LZJB、LZMA(xz)、LZO、LZRW、LZSS、LZW、LZWL、LZX、以及Snappy和Zstandard。

被分类为“熵编码器”的其他压缩模块也产生输出，该输出被本主题用于实现其一些升级效率。出于本发明的目的，由熵编码器生成的所有元数据、索引、表(例如，统计和频率表)和任何其他非指导性数据也将被简单地称为“字典”。

作为熵编码器的流行压缩模块141包括(按字母顺序)算术编码，近来还包括基于非对称数字系统算法族、霍夫曼编码以及Zstandard的部分的模块。

还存在不同于以上而分类的其他压缩模块141，并且典型地产生比输入位更高效(例如，更少)的输出位。这些最后压缩模块的示例包括BZip2、RLE、PPM等。每当所述其他压缩模块141使用它们生成的元数据、索引、表和任何其他非指导性数据时，为了本发明的目的，也将被简单地称为“字典”。

编码模块143是如下的转换器(滤波器)：其接受一个或多于一个特定格式的输入，并且将该输入处理成另一个或多于一个特定格式的输出，使得输出典型地比输入更高效。

编码模块143典型地适用于特定的上下文/主题或行业。例如，音频(声音)编码模块143包括输出诸如FLAC、MP3、QT、WMAL等的音频格式的模块。

注意，用于文档的许多编码模块143例如在它们的最终阶段包括压缩模块141，并且使用压缩模块来将多个文档元素打包成压缩格式的一个文档。本发明广泛利用该特征，以达到跨多个文档的更好的效率(例如压缩)。分别地，每当编码器使用压缩模块141来打包多个文档元素时，解压缩模块144可以正确地提取多个文档元素。一旦提取，所提取的各元素可以由解码模块146模块进一步处理。除了其他之外，这些格式还包括DOCX、ODP、ODS、ODT、OXPS、PPTX、XLSX、XPS等。

计算机图形领域中的编码模块143的示例包括输出如下图形格式的模块，诸如：BMP、Exif、GIF、JPG(jpeg)、PNG、PNM(PPM、PGM、PBM)、TIFF和用于光栅图形的其他格式；矢量图形的AI、CGM、Gerber、SVG等；AMF、DWG、DXF、FLT、IGES、VRML、xVRML和其他3D矢量图形格式。

文档处理领域中的编码模块143的示例可以包括输出如下文档处理格式的模块，诸如：DOC、HTML、PDF、PPT、WPD、XLS、XML等；然而，诸如OpenOffice(开源)和(Microsoft^TM公司的)Microsoft Office等的办公套件的当代版本所使用的格式(例如DOCX、XLSX等)实际上是在本发明的上下文中应该首先由解压缩模块144处理的压缩格式。

典型地，任何编码模块143(诸如上面列出的编码模块等)将具有相应的解码模块146。对于给定格式，多于一个的编码模块143可能是可用的，并且多于一个的解码模块146也可能是可用的。

解压缩模块144可以在固件、软件和/或硬件中实现，并且能够转换输入位(例如，文件、存储器对象、数据库记录或者甚至流式位流)，并且将该输入位转变成与压缩模块141的输入相同(在非有损压缩中)或等效(在有损压缩实例中)的输出位。提供示例解压缩模块144以反转由任何压缩模块141进行的压缩，并且典型地例如与压缩模块141捆绑地提供解压缩模块144。当前值得注意的示例包括BZip2(开源)、Gunzip(解压缩上面提到的GZIP)、Inflate(解压缩上面提到的Deflate)、LZMA和XZ，例如可以经由诸如unxz和XZ等的工具而访问。

解码模块146是如下转换器(滤波器)，其接受从匹配编码模块143输出的输入，并且处理该输入以生成输出。解码模块146的输出与编码模块143接收到的输入相同。按照流行的概念，解码模块146通过将由所述匹配编码模块143生成的输出反转成与所述匹配编码模块143的输入相同的数据来生成其自己的输出。

典型地，诸如上面列出的编码模块等的任何编码模块143将具有相应的解码模块146。对于给定格式，多于一个的编码模块143可能是可用的，并且多于一个的解码模块146也可能是可用的。

存档模块142可以将如上定义的至少一个“数据”元素的多个存档元素打包成“数据”结构类型的单个存档元素(例如，存储器中的文件或对象)。

计算工业的许多领域中使用的流行存档模块142的示例包括：tar(带存档；Unix系统上的流行存档格式，典型地用作例如压缩模块141的输入)、ar(Unix系统的传统存档格式)、iso(原本主要用于存档和分发诸如CD-ROM或DVD-ROM等的光存储介质的精确、接近精确或定制修改的内容的存档格式)。

解包模块145可以从“数据”结构类型的输入存档元素(例如，存储器中的文件或对象)中解包或提取多个存档元素。

当使用补丁包170将原始存档元素130转换成目的存档元素132时，在大多数情况下，不直接修改(例如，升级)原始存档元素130更有意义，使得如果升级处理被自愿或意外中断，原始存档元素130的旧版本将是完整的和可操作的。因此，大多数实现将选择在单独的位置(暂存区150)中进行升级工作，并且仅在升级成功之后开始使用目的存档元素(可选地将其复制到不同的位置)并清理不再需要的安装文件/对象。

解包模块145可以典型地将来自输入存档的一个或多于一个存档元素解包到暂存区150中；根据步骤，这种解包被进行到原始存档结构152或目的存档结构154中。

内容识别模块148是特制的软件、硬件和/或固件，其能够通过读取描述存档元素的元数据或通过读取所述存档元素内包含的全部或部分实际数据来识别“数据类型”(存档元素内包含的数据的类型)。

本领域中确定存档元素的数据类型的流行方法是通过针对“文件系统测试”、“幻数”和语言测试而测试类型来进行的。例如，(在Unix中)被称为“file”的流行操作系统可执行实用程序是通过匹配文件内的数据的模式来检测文件类型的系统的示例。存在更严格的解决方案，例如，可以观察文件的实际内容以确定其格式，并且在不能观察的情况下，确定尽可能接近地匹配文件的格式。

考虑到例如通过将文档存档元素分解成文档对象模型(DOM)、通过使用可以从数据中提取原子数据元素的格式相关的定制组件等对数据的更复杂的分析，存在甚至更复杂的内容识别模块148。补丁生成系统110可以包括多于一个的内容识别模块148，并且所述内容识别模块148可以利用大量的算法和组件来执行其任务。

暂存区150是如下逻辑单元，其包含补丁生成系统110和补丁应用系统112的操作所需的存储空间，该存储空间可由处理200、300和400根据其规格访问。

暂存区150可以以不同的方式来实现：在单个位置或跨若干存储介质划分成例如若干数据库、在分布式数据库中、在单个文件系统中、在跨越若干存储介质或若干存储卷的文件系统中、在RAM中、在虚拟存储器中、在片上存储器高速缓存中等。

补丁生成系统110的操作所需的存储空间可以在处理200或处理400一开始时就预先准备，或者可以在处理200或处理400需要另外的存储空间时分配。在完成处理300或处理400之后，或者在利用暂存区150的内容的步骤已经完成了它们的执行之后，可以释放为暂存区150要求的存储空间。

有时，暂存区150被直接定义在由目的存档元素132分配的相同空间上。在许多人认为有风险的这种情况下，应该实现特定考虑，以避免例如在处理由于任何原因(自愿或意外)而中断的情况下的目的存档元素和补丁包170的数据损坏，如本领域中众所周知的那样。

暂存区150由如下指定的至少一个存档结构构成。

原始存档结构152和目的存档结构154包括如下所述的可遍历数据结构(例如，树、链接列表、散列映射、文件系统等)中的零个或多于零个存档元素集合中的每个。通过使用如下所述的存档元素标识符，可以在所述各个集合内访问所述零个或多于零个存档元素。

差分模块160是如下特制的模块，其生成两个数据集合之间的差的技术描述。差分模块160典型地采用Delta压缩算法来获得补丁数据172，该补丁数据172在本领域中典型地被称为“Delta”、“Delta更新”、“更新”、“有效载荷”或“补丁”，并且在本发明中被称为补丁数据172。

差分模块160接收原始存档元素130(源)和目的存档元素132(目的)作为输入，并且典型地输出关于它们的Delta压缩差分数据，即补丁数据172。

以2种方式定义Delta，对称Delta和有向Delta。对称Delta可以被表示为

Δ(v₁，v₂)＝(v₁\v₂)∪(v₂\v₁)，

其中v₁和v₂表示两个版本，或者在本发明的上下文中，表示原始存档元素130和目的存档元素132。

有向Delta(也被称为如上所述的改变或更新)是一系列(基本)改变操作，当将该改变操作应用于一个版本v₁时，产生另一版本v₂。在计算机实现中，有向Delta典型地采用具有至少两个命令的语言形式：从v₁复制数据和写入文字数据。

众所周知的差分模块160包括：如定义的RFC 3284的VCDiff；如文档编制的打包格式页面中定义的Git重新打包；如Colin Percival例如在“可执行代码的朴素差”中和全球多个公共代码库中定义的BSDiff；甚至如Unix和Linux操作系统下的“diff”命令那样的老式模块。

差分模块160的许多实现可能仅处理结构类型“数据”的单个存档元素，因此由下面讨论的处理200和处理400这两者进行特定处置，以克服该限制，并且能够应对本发明处置的结构类型的多样性。

图1b所示的补丁应用模块180是如下特制的模块，其可以接收原始存档元素130和补丁数据172以及补丁指令174作为输入，以重建目的存档元素132。

在一些情况下，补丁应用模块180可能仅接收结构类型“数据”的一个存档元素。在其他情况下，补丁应用模块180可以接收多个存档元素。在另外情况下，补丁应用模块180可以接收“目录”结构类型的存档元素。在又一另外情况下，补丁应用模块180可以接收“存档”结构类型的存档元素。最后，在其他另外情况下，补丁应用模块180可以接收“经压缩”结构类型的存档元素。

可选地，可以使用图1b所示的应用器策略136。这些策略包括关于如何进行下面讨论的处理400的规则集合。规则可以包括与转换模块140、结构类型、由处理400处理的存档元素的数据类型和属性有关的任何逻辑谓词、以及与补丁应用模块180和传递给在处理400期间使用的任何模块的参数有关的逻辑谓词。

众所周知的补丁应用模块180的范围从Unix和Linux操作系统上的老式“patch”命令到更复杂的模块(诸如用于处理VCDiff补丁数据的xdelta3、用于处理BSDiff生成的补丁数据的bspatch等)。

现在参考图2，图2示出了根据本发明的实施例的遍历原始存档元素130和目的存档元素132以针对各个存档元素准备解码存档结构的处理200。

处理200优选地在暂存区150上遍历原始存档元素130和目的存档元素132以针对各个存档元素准备解码存档结构。然后，处理200遍历各个所述解码存档结构，进一步解包、解压缩和解码其中包含的存档元素。

该处理的前两个结果是原始存档结构152和目的存档结构154。这两者都包括可遍历数据结构中(例如，在文件系统、树、链接列表、哈希映射等中)的零个或多于零个存档元素集合，如下所述。附加的结果是补丁指令174，即由处理200在遍历原始存档元素130和目的存档元素132以及原始存档结构152和目的存档结构154时构建的补丁指令集合。例如，在处理200的进一步执行步骤中，关于包括一个原始元素和一个目的元素的匹配对，以及关于包括在原始存档元素130和目的存档元素132内出现的内部存档元素的匹配对，构建补丁指令。

补丁指令也是关于其各自的存档元素的结构类型和数据类型来构建的，并且如下文详细描述的，还可以包括另外的数据，诸如动作、所选择的解码模块141、所选择的压缩模块141和用于其操作的元数据。在优选实施例中，补丁指令174可以在处理200进行时被处理200合并到补丁包170中，或者可替代地或附加地在处理300进行时被处理300合并到补丁包170中。

处理200可以由一个或多于一个处理器例如通过使用堆存储器、通过使用栈存储器等以递归或渐进的方式运行。在使用多于一个的处理器或多于一个的处理核或线程运行处理200的情况下，处理200(在适用的情况下，例如通过多任务处理，例如使用分叉操作，通过多线程，或以其他方式)可以在单独的核或线程中执行步骤，例如以处理在处理200操作期间揭示的存档元素。

处理200还可以被配置成以不同的、可能更复杂的布置或使用不同的硬件运行(前提是保持其功能、步骤和结果)。处理200典型地由补丁生成系统110进行。

在步骤201中，补丁生成系统110典型地例如从用户或应用软件接收两个主要输入(原始存档元素130和目的存档元素132)、以及可选的补丁生成器策略134。这两个主要输入被认为是存档元素的“匹配对”。通常，大多数处理步骤是针对匹配对进行的，并且一些处理步骤是针对匹配对中的一个存档元素或匹配对中的两个存档元素进行的。

存在原始存档元素130可以被完全省略、指定为“null”、或者以其他方式向补丁生成系统110指示其不存在的特定实施例。将在处理300的描述之后描述典型地得到目的存档元素132的压缩格式的这种特定实施例。

文件、记录、存储器——当输入存档元素是例如驻留在存储介质上的文件系统上的文件时，输入的标识符可以是输入文件的完全路径、输入文件的相对路径、诸如MFT记录等的存储索引号或i存档元素号(Unix风格的文件系统中的索引存档元素)等。在输入是存储器位置的情况下，输入的标识符例如在指定处理器上的处理的运行上下文中等(在适用的情况下)可以是绝对存储器引用、相对存储器引用。在输入是数据库中的记录的情况下，可以通过使用特定于数据库的符号，或者通过使用特定于驱动程序的符号(例如，ODBC/JDBC数据库连接和数据库访问符号(例如具有安全凭证))，通过数据库中的表中的记录号，通过文档数据库中的数据库记录的ID，在图形数据库的情况下通过存档元素ID等，来指定输入。

位置——通常，当第一次执行处理200时，构建第一匹配对，该第一匹配对包括设置为原始存档元素130本身的原始元素和设置为目的存档元素132本身的目的元素。例如，目的存档元素132可以指向压缩存档文件“b.tar.gz”。

然而，在许多情况下，处理200可以由开始点指示存档的更具体部分(例如，仅存档的一部分)的补丁生成系统110或补丁应用系统112执行。在这些情况下，处理200将针对目的存档元素132的子集构建目的存档结构154。例如，目的存档元素132可以指向压缩存档文件“b.tar.gz”内的目录“/images/pngs”，即，具有类似于“b.tar.gz:/images/pngs”的符号。

通常，任何存档元素的标识符可以指示嵌套的包含级别，例如，类似于“b.tar.gz:/images/pngs/2020-images.jar:/january/”的标识符将指示包含在.jar压缩存档文件内的目录“january”，其中.jar压缩存档文件位于压缩存档文件“b.tar.gz”内的“/images/pngs/”目录中。

在处理400的上下文中，嵌套存档的存档元素和可以包括内部存档元素的压缩存档元素经常以使用这种嵌套的包含级别的位置标识符来标注。在这种情况下，可能需要处理400至少重新创建嵌套位置。为了重新创建嵌套位置，处理400可以随后处理位置中的各个嵌套的包含级别，并且针对各个嵌套的包含级别使用正确结构类型重新创建适当的存档元素。

例如，在上述非限制性示例中，压缩存档“b.tar.gz”的位置将首先例如在目的存档结构152上被重新创建，然后是所述压缩存档中的目录/image，然后是前面的/image目录内的另一目录/pngs，然后是名称为2020-images.jar的jar压缩存档，并且最终是jar压缩存档内的最后目录/january。

在重新创建时，嵌套位置不需要是其最终格式，而是，如果目的存档结构154在文件系统上，嵌套位置可以简单地是特制的目录，或者在目的存档结构154是在存储器中的情况下，嵌套位置作为相关数据结构。例如，使用下面处理400中指定的转换模块140，处理400典型地将每个嵌套级别转换成其正确的结构类型。

分配(PI)——典型地，步骤201将至少针对暂存区150上的当前补丁指令174和补丁数据172分配存储空间。补丁指令174将可在处理400中使用，以通过使用补丁应用系统112将当前补丁指令174应用于原始元素，并且在一些情况下还使用补丁数据172来重建目的元素。

在步骤210中，补丁生成系统110识别(上面公开的)5个结构类型中的哪个与目的元素和可选的原始元素的存档元素相关联。首先，补丁生成系统110可以识别结构类型。结构类型在修补处理400、遍历处理200和打包处理300中具有特定考虑，并且影响所述处理的执行流及其输出。上面对于原始存档元素130公开了由步骤210识别的5个结构类型。

识别结构类型——存在许多方法来识别结构类型。有时，从步骤210处理的输入(例如当通过诸如文件系统API等的相关API处理存档元素时)可以明显看出，已经具有是处置文件还是处置目录的信息。补丁生成系统110还可以简单地检查上述示例中存档元素的文件扩展名，以尝试识别其结构类型，例如“.tar”针对“存档”，并且“jar”针对使用“Deflate”方法进一步“经压缩”的“存档”。

然而，如果没有读取存档元素内包含的数据并将其与有效的已知数据格式进行比较，这种方法通常会失败。因此，在步骤210中，除了识别结构类型之外，步骤210还可以前进通过使用内容识别模块148来识别存档元素的数据类型，使得具有正确识别结构类型的更高确定性，以及具有存档元素中数据格式的更高确定性。

另外，步骤210还可以读取与所识别的结构类型相关的任何元数据，并且验证这种元数据与所识别的结构类型的规范兼容。

建立补丁指令174——在识别了目的元素和原始元素的被检查的存档元素的结构类型以及任何相关联的元数据之后，处理200已经具有足够的信息以关于将原始元素修补到目的元素、针对被检查的存档元素构建至少一个初始补丁指令174，并且可以构建初始补丁指令(但是这可以推迟到其他步骤，只要其在步骤260和270之前进行即可)。如下构建补丁指令174：

动作——在原始元素在目的存档结构154中缺失(例如，由“空(null)”指针表示)的情况下，针对原始元素的标识符构建“删除”动作的指示被添加到补丁指令174。在原始元素在目的存档结构154中缺失的情况下，构建“添加”动作的指示，并且将目的元素的标识符添加到补丁指令174。典型地，当存在具有相同标识符的存档元素、但任何所述存档元素的至少一个其他属性在原始存档结构152和目标存档结构154这两者中都不相同时，可以通过构建“更新”动作并将其添加到补丁指令174来指示这些存档元素。

典型地，当关于具有相同标识符的原始元素在目的存档结构154中缺失目的元素时，例如，在“删除”动作的情况下，处理200可以直接前进到步骤270。在步骤230识别出一个或多于一个解码模块146的情况下，补丁生成系统110继续到步骤240；否则，直接前进到步骤270。在原始元素和目的元素这两者都相同的特定情况下，尽管可以将其动作指示为“未改变的”，但是这种指示是多余的，因此典型地当两个元素相同时，在当前补丁指令中不包括任何动作是更高效的(例如，节省存储空间；节省执行时间)。关于动作的指示可以以简洁的形式编码以占用少于1字节的存储空间，或者以详尽的形式编码，例如以表示英语的UTF-8字符串编码。

在结构类型是“存档”类型的情况下，在补丁指令174中明确指示该存档元素的数据类型(例如，该存档元素的数据格式)典型地是有用的。建议通过使用明确定义的格式指示符(诸如在国际公认的标准中，例如使用mime类型、ISO定义等)来格式化结构类型的所述明确指示，而不是简单地依赖可能被解释为不同(尽管相关)格式的模糊符号(例如“BMP”)。

在结构类型是“链接”类型的情况下，在补丁指令174中包括目的元素中/由目的元素链接到哪个其他存档元素(例如通过包括所述其他存档元素的标识符)的指示是有用的。

在所识别的数据类型需要另外的元数据以由处理400相同地重建、或者在不能由处理400相同地重建、或者由处理400尽可能相似地重建的情况下，如下面将说明的，任何另外的元数据的明确指示然后被添加到补丁指令174。

一些实施例可以具有默认结构类型(例如，“数据”)，并且为了节省更多的空间，选择不在补丁指令174中指示默认结构类型。

数据类型示例

通过非限制性示例的方式，考虑我们将用于演示步骤240至241的参考示例，其中目的存档元素132中的如下存档元素被识别为包含PNG数据内容的文件，该存档元素在目的存档元素132中具有相应的其他存档元素以用于其匹配对。在该参考示例中，步骤210可以通过使用内容识别模块148将作为命名为“file1.png”的文件的存档元素的数据类型识别为“PNG image data”，并且将其一些元数据识别为例如“500x500,8-bit/color RGBA,non-interlaced”。然而，PNG格式和BMP格式这两者都已经包括了关于图像的尺寸的足够信息，因此第一元数据“500x500”可能不是明确需要的。在这种情况下，可以构建补丁指令，使其指示以下内容：{action＝Update；Dtype＝“data”；name＝“file1.png”；metadata＝“8-bit/color RGBA,non-interlaced”}。

在步骤220中，补丁生成系统110考虑目的元素和原始元素的结构类型，以确定它们中的任一个是否是可以包含内部存档元素的复合存档元素，并且在它们是的情况下，根据下文的规范进行步骤250、251、260和261。

存在可能包括内部存档元素的存档元素的许多示例。例如，由流行的MS Word应用保存的文档以DOCX格式保存，其中DOCX格式本质上是使用Deflate算法和配置有特定执行参数的压缩模块的经调整的压缩存档文件。这种DOCX格式可以例如通过简单地对DOCX文件的内容或对表示DOCX文件的数据流的内容执行“INFLATE”解压缩模块144来解压缩。

在另一示例中，存档元素是由流行的“tar”Unix实用程序构建的文件，其中通常通过对该文件应用“gzip”编码器来压缩该文件。结果是通常具有在许多因特网下载网站上可见的(双)扩展名“.tar.gz”的压缩存档文件。在这种情况下，应该依次使用两个转换模块146和144来转换这种存档元素，第一解压缩模块144是诸如Unix计算装置上的“gunzip”实用程序等，第二解码模块146是具有适当命令和/或标志的流行的“tar”Unix实用程序。

在其他情况下，补丁生成系统110可能遇到如下存档元素，该存档元素没有立即指示将其解码成其内部存档元素所需的解码器序列。因此，如将在下面说明的，再次应用处理200(例如，通过递归)来遍历得到的内部存档元素将产生完全解码所述存档元素的预期结果。

在输入目的元素或原始元素是复合存档元素的情况下，补丁生成系统110进行步骤250。否则，并且当目的元素和原始元素不是复合存档元素时，执行步骤230(如图中通过继续指示符225(至图2b)所示)。

在步骤230中，补丁生成系统110尝试识别至少一个解码模块141，该解码模块141可以对匹配对中的存档元素的内容进行解码。

由于在该步骤，补丁生成系统110已经确定为目的元素和原始元素不属于“目录”或“存档”结构类型，并且被识别的转换模块141能够将给定的存档元素转换成解码格式，然后补丁生成系统110已经确定为目的元素和/或原始元素可以包含以某效率级别(例如，压缩)编码的数据。

因此，步骤230至241的目的是将目的元素和/或原始元素转换成更详尽、而不是更压缩的存档元素。这个目标乍一看似乎有悖常理，因为与当今专业人员对软件包、存档和更新的看法、以及当今如何打包和通过网络发送它们(例如，.tar.gz或“.cab”数据结构中的因特网下载)形成对比。这也与保持当前文档存档方式(例如，各自在压缩DOCX数据结构中的多个但独立的文件)形成对比。

然而，以下这些步骤对于以后实现更高的效率(诸如更好的压缩率或更低的存储空间需求等)是必不可少的，如下所述。

步骤230至241可以增加处理200的整体效率，但是这些步骤是可选的，并且处理可以在没有这些步骤的情况下运行。

典型地，步骤230选择解码模块146，该解码模块146将尽可能提供目的元素的最详尽版本，例如，以下面讨论的离散的原子单元的形式描述数据的版本。以离散的原子单元(atomic unit)的形式描述数据，这为差分模块160提供了定位相同数据部分并且在处理300中比这些数据在目的元素中被原始地编码更高效对这些数据进行编码(如下所述)的机会。选择解码模块146的另一方式是选择能够使用相同的离散的原子单元处理尽可能多的存档元素的解码模块。

原子单元——在存档元素已经是编码形式的情况下，包括存档元素的离散的原子单元是描述实际包含的数据的单元，而不是在所述存档元素内以某种编码格式布置的数据。出于本发明的目的，原子单元也可以被定义为如下数据格式，其中在该数据格式中，特定数据类型的大部分数据可以在技术上跨具有相同数据类型的两个或多于两个存档元素来描述。

例如，在计算机图形图像的数据类型的情况下的，离散的原子单元可以是包括所述计算机图形图像的彩色像素。在这种情况下，如果使用mime类型来指示数据格式，则补丁生成系统110可以选择像素位图作为原子单元来描述包括计算机图形图像(例如，包括诸如PNG、JPG等的格式的图像)和用于将存档元素表示为“image/bmp”的数据格式的全部或一部分存档元素。

一旦选择了至少一个形式的离散的原子单元，补丁生成系统110描绘适当的解码模块146，该解码模块可以将目的元素的内容解码成更详尽的形式。补丁生成系统110然后可以包括在补丁指令174中选择详尽格式的指示，然后可以包括该特定编码格式，以使处理400能够根据补丁指令174和原始存档元素130重建目的元素。例如，在补丁指令174的上述示例中包括{action＝Update；name＝“file1.png”；metadata＝“8-bit/color RGBA,non-interlaced”}进一步指示将示例补丁指令174更新为{action＝Update；name＝“file1.png”；metadata＝“8-bit/color RGBA,non-interlaced”；format＝“PNG”；encoding＝“image/bmp”}。

多个解码模块——到目前为止，步骤230已经识别了单个解码模块146。然而，存在不能容易地确定优选的输出数据格式的情景，例如，一旦差分模块160已被应用于解码模块146，哪个解码模块146将得到最佳效率。在这些情况下，步骤230可以选择两个或多于两个解码模块146，然后步骤240将如下所述进行调整。

有时，补丁生成器策略134可以包括用于在解码模块146的选择中进行指导的规则。例如，可能考虑到在执行补丁包170的计算装置处可用的资源或在该计算装置处的已知约束，强制给定解码模块146、指定要使用的某些参数或选项、禁止给定解码模块146等。

在步骤240中，在步骤230已经成功识别出至少一个解码模块146(其中，通过应用所识别的至少一个解码模块146中的各个解码模块146，可以将原始元素和目的元素的内容解码成解码形式)之后，在暂存区150上针对所使用的每个解码模块146构建解码目的存档元素。

当对原始元素进行解码时，解码模块146的所得的输出可以被放置到暂存区150中的原始存档结构152内的解码原始元素130中。解码原始元素然后可以在后续处理中(即在包含原始元素的匹配对中)替换原始元素。

当对目的元素进行解码时，解码模块146的所得的输出可以被放置到暂存区150中的目的存档结构154内的解码目的元素中。解码目的元素然后可以在后续处理中(即在包含目的元素的匹配对中)替换目的元素。

参考步骤210中描述的非限制性参考示例，其中存档元素(例如，目的元素)被识别为PNG格式的计算机图形。补丁生成系统110可以选择由“png2bmp”标识的解码模块146，该解码模块可以将PNG编码的输入解码成BMP格式的输出，该BMP格式可以将图形中的每单个像素详细描述为其数据。然后，将使用命名为“png2bmp”的解码模块146在目的存档结构154上将目的元素解码成解码目的元素，并使用名为“png2bmp”的解码模块146在原始存档结构152上将原始元素解码成解码原始元素。

当构建了任何得到的解码存档元素时，可以以构建的解码存档元素作为输入，重复步骤230-240，直到不再识别出更多的解码器146为止。在一些实施例中，仅指示最后解码模块146可能就足够了，从而使补丁应用系统112确定所需编码模块143的序列，以重新生成其编码形式。在其他实施例中，所有所述重复可以被记录在补丁指令174中。

在步骤241中，补丁生成系统110从解码原始存档元素和解码目的存档元素中选择最后解码形式作为要保留的匹配对。此时，步骤241可以处置(例如，从暂存区150删除或释放)任何其他解码原始和目的存档元素。

这可以根据补丁生成器策略134中的规则来进行，或者如补丁生成系统110中配置的那样，或者在仅存在一个集合的解码原始和目的存档元素的情况下(例如，在仅使用了一个解码模块146的情况下)通过选择仅存在的解码形式来进行。

补丁生成器策略134规则可以使用得到的解码原始存档元素和解码目的存档元素的任何可读属性。例如，简单的规则是选择给定解码器146。

一个或多于一个规则可以直接构建到实现中，因此被“硬编码”到补丁生成系统110中，并且不需要根据补丁生成器策略134。

取决于实现偏好和实施例，步骤241可能需要进行“内务处理”步骤，包括去除除了所选元素之外的所有目的存档元素132，回收例如在暂存区150上的存储器和/或存储空间等。这些内务处理活动也可以在诸如步骤241、252或299等的后续步骤中随时进行。

补丁生成系统110然后向补丁指令添加描述使用了哪个解码器146的元数据和所需的任何另外的元数据、以及目的元素的原始格式。在一些实施例中，也可以添加关于原始元素的元数据，但是对于大多数目的来说，这种信息可以被认为是冗余的。

在一些实施例中，步骤230至241仅在整个目的存档结构154被提取之后发生，使得至少一个解码模块(模块)146的选择处理可以考虑由处理200发现的整个内部存档元素集合。这些实施例可以在存在描述具有离散的原子单元的内部存档元素的多于一个详尽格式的情况下产生更高效的补丁包170。

在其他实施例中，步骤230至241发生在处理200的每次迭代期间，如图2所述。这些其他实施例可以在仅一个详尽格式可用于描述内部存档元素的补丁生成系统110的情况下产生更高效的补丁包170。

在步骤270中，补丁生成系统110记录补丁指令174，该指令现在应该包括原始元素的标识符和/或目的元素的标识符；目的元素的所识别的结构类型和/或数据类型；如上所述要采取的动作；可选地，从原始元素重建目的元素所需的元数据；可选地，描述使用了哪个解码模块146的元数据；以及可选地，针对补丁指令174的目的元素的原始编码格式；在适用的情况下，从原始元素重建目的元素的所述最详尽形式的最低要求。

我们现在转到从步骤220的其他分支(当识别出目的元素或原始元素的结构类型是目录或存档时发生)。

在步骤250中，补丁生成系统110考虑匹配对中的各存档元素的结构类型，即，一次针对原始元素，一次针对匹配的目的元素。对于匹配对中的各存档元素，当结构类型为“存档”时，步骤250尝试识别可以提取包含在原始元素和目的元素内的内部存档元素的至少一个解压缩模块141或解包模块145。

在步骤251中，补丁生成系统110首先确保步骤220中的所述动作不表示“删除”，使得补丁生成系统110现在可以使用在步骤250中识别的至少一个解码模块146或解包模块145以在暂存区150上对目的元素进行解码或解包，以及在暂存区150上对原始元素进行解码或解包。

该步骤的结果典型地是用于原始存档元素130的一个原始存档结构152和用于目的存档元素132的一个目的存档结构154，其各自包括从其相应的存档元素130、132解包的内部存档元素。

步骤230-251背后的推理：

虽然下面的数学讨论超出了理解本发明所必需的范围，但是计划在以后的科学和工程社区的学术期刊论文中提供更数学的讨论。我们在下面给出步骤230-251的推理和益处的简要说明。

通常，压缩模块141构建至少一个内部字典，该内部字典例如使用统计递归模型将原始数据映射到(典型地更短或“更高效”)压缩数据。然后，该字典与如何使用它的指令(例如通过匹配解压缩模块144)一起存储在压缩数据中。

当多个存档元素被存档(例如在大型软件包的更新补丁170中或为存档而存储的文档集合中)时，它们中的一部分典型地已经是压缩形式。典型的例子是2021年3月发布的Eclipse版本4.19的公开可用软件包，其中大量的“jar”类型的文件分布在一个大包中，各“jar”类型的存档元素是内部存档元素的单独压缩存档，这些内部存档元素典型地是java类对象代码。

当检查单独压缩然后一起存档的多个存档元素时，可以观察到各这样的存档元素会典型地具有自己的字典和关于如何使用该字典重建原始数据的自己的指令。

然而，如果我们考虑相关存档元素集合(诸如打包在一起以通过通信网络发送的多个“jar”类型的存档等)，可以看出，跨多个“jar”类型存档的作为整体的原始数据的许多部分是相同的。在从压缩存档元素中解码原始存档结构152和目的存档结构154的情况下，对这些存档结构进行操作的差分模块160现在将有机会对每个内部存档元素的原始数据进行操作，而不是对包括目的元素或原始元素的已经压缩的数据进行操作。

因此，实现更好的效率(例如，压缩)的一个关键是通过转换被打包在一起的两个或多于两个这样的相关存档以准备更少的字典，最终每个整个补丁包170仅一个字典，因此所述更少的字典足以描述所有存档元素。

这种内部存档元素的提取在若干方面是有用和有益的，我们将强调其中的三个主要优点：

(1)第一益处是向差分模块160提供机会来找到如下的数据部分，该数据部分跨两个或多于两个内部存档元素而相同但是不一定经常出现在内部存档元素之一内。通过非限制性示例的方式，考虑数百个照片集合，这些照片都是由相同的照相机型号和相同的图像尺寸(例如，2000×3000像素)拍摄的。尽管该数据可以每个内部存档元素仅重复一次，但是跨多个内部存档元素而重复，因此计算重复数据部分的差分模块160现在可以有机会将该数据考虑为重复数据部分。类似地，相同颜色的长像素带可能在若干这样的图像中存在；然而，当单独压缩时，这种长像素带可能重复很少次，例如仅一次。

(2)第二益处是向差分模块160提供机会以减少映射内部存档元素中的数据部分的字典(例如，图、频率表等)的数量。典型地，各内部存档元素被单独压缩(例如，作为单独的“.xz”或“.pptx”文件)，因此包含其自己的字典。然而，当由差分模块160一起计算时，有机会减少字典的数量，通常甚至减少到由两个或多于两个内部存档元素共享的仅一个字典。

(3)第三益处是跨所有内部存档元素识别重复内部存档元素。例如，考虑“.pptx”格式的演示文档集合，这些演示文档都属于同一组织的同一部门，因此具有在每个文件中被单独编码和/或压缩的相同的多个图像(诸如公司徽标和部门“主题”等)，包括颜色定义、字体定义、背景图像、页眉和页脚等。在内部存档元素之间存在这种重复内部存档元素的情况下，至少可以引入以下两个改进：

(3a)首先，补丁生成系统110将有机会通过仅保持第一个重复内部存档元素来指示重复内部存档元素，同时在补丁指令中将其余的重复内部存档元素指示为到第一个所述重复内部存档元素的“链接”。当重复内部存档元素仍然是压缩形式时，它们的存在对于差分模块160而言是不可见的，因为仅看到压缩数据，这将会跨不同的压缩存档而看起来是不同的。

(3b)其次，一旦重复存档元素被处理200提取，通过作为向步骤230-251的输入，它们继而可以有助于在该步骤中描述的第一益处和第二益处。

在步骤260中，补丁生成系统110添加处理400根据补丁指令174正确地重新创建目的元素所需的所有元数据。随后，步骤260在所述补丁指令174中记录步骤250-251中使用的解压缩模块144和解包模块145的指示。

在步骤261中，补丁生成系统110构建新的匹配对集合，各匹配对包括原始元素和目的元素，其中各匹配对对应于在步骤251中解包或解压缩的内部存档元素。

这个新的匹配对集合典型地通过遍历在步骤251中解包和解压缩的所有内部存档元素并在两者中找到相同的标识符来构建的。典型地，一个循环将会在原始存档结构152中的每个内部存档元素上迭代，并且将该内部存档元素与目的存档结构154中具有相同标识符的一个内部存档元素相匹配。每当匹配了相同的标识符时，通过步骤261构建匹配对。

典型地，第二循环将会在目的存档结构154中的至少剩余(不匹配)存档元素上迭代，并且每当相同标识符在原始存档结构152中被匹配时，通过步骤261构建匹配对。

一旦匹配对准备好，所述匹配对被用作新输入，并且以作为原始和目的存档元素方面的新匹配对的所述新输入来执行步骤210至270。在优选实施例中，例如以递归方式，这由步骤261重复，直到在步骤250中没有另外的解包或解压缩的内部存档元素为止。

在一些实施例中，补丁生成系统110可以使用例如应用器策略136中的规则，来确定何时将匹配对作为新输入传递给步骤210至270以及何时避免这样做。

一旦所有的(例如，生成器策略134)需要的内部存档元素被解包和解压缩，处理200再次针对各个需要的内部存档元素执行步骤210-260，如补丁指令174所指示的。

在步骤270中，补丁指令174和补丁数据172被准备好，并且可以以其最终形式(包括如上所述的任何所需的元数据)被记录在补丁包170中。

在一些实施例中，步骤270可以检查任何先前遇到的补丁数据172是否与准备好的补丁数据172相同，并且在是的情况下，不是在补丁包170中记录所述补丁数据172，而是利用“链接”结构类型和利用参考所述先前遇到的补丁数据172的指示来调整补丁指令174，从而多于一次保存记录相同的补丁数据172。

在一些实施例中，众所周知的内务处理操作可以根据更平滑执行的需要进行，包括确保足够的存储空间可用、足够的存储器空间可用以及去除后续步骤和处理(例如，处理300)不需要的中间物。这种内务处理操作在本领域中是众所周知的，并且尤其包括堆存储器分配的处置；释放文件句柄等；处理相关的内务处理操作，诸如在步骤251或步骤241之后释放或删除目的存档元素132；在步骤251或步骤241之后释放或删除原始存档元素130等。

在另外的实施例中，例如以递归方式，例如使用原始存档结构152和目的存档结构154作为向递归的输入，多于一次地进行处理200，可以保证包含在原始存档元素130和/或目的存档元素132和/或包含它们中的任一个的任何内部存档元素中并且在遍历中发现的任何存档和压缩存档元素依次分别被解包和解码，因此从中提取它们的内部存档元素。这是本主题的许多实施例的关键属性，通常增强补丁包170的效率。尽管在优选实施例或最佳执行中，处理200解码并提取每个单个存档和复合存档元素，但是可以对处理200的操作施加一些约束，例如通过施加的生成器策略134，因此仅存档或复合存档元素的子集将被解码或其内部存档元素被遍历。

典型地，可以通过在补丁生成器策略134中包括规则来施加这种约束。这种规则的示例包括但不限于以下类型的约束：

1.如下的约束规则，其中在该约束规则中，例如，在由补丁生成系统110采用的DFS或BFS遍历算法中，遍历级别被限制为N个级别。

2.如下的约束规则，该约束规则将复合存档元素的数据格式限制为例如tar.gz、bz2、jar和xz的数据格式；

3.如下的约束规则，该约束规则将存档的数据格式限制为例如tar和ar的数据格式；

4.如下的约束规则，该约束规则将遍历限制为仅复合存档元素、仅存档或其组合；

5.如下的约束规则，该约束规则例如通过限制在操作之前要遍历的存储量、通过限制已经遍历的复合元素或存档元素的数量，来管控处理300何时应该在遍历的数据上进行操作；

等等。

根据补丁生成系统110进行操作的硬件、固件、软件、存储装置、操作系统和文件系统的特定配置，可以在补丁生成器策略134中描述另外的约束规则。

现在参考图3，该图示出了根据本发明实施例的用于遍历存档元素(典型地是目的存档结构154和原始存档结构152)的匹配对并构建高效补丁包170的处理300的流程图。

硬件限制——处理300的优选实施例典型地需要RAM和/或存储介质的量是原始存档元素130大小的许多倍和/或目的存档元素132大小的许多倍。所需的实际量将受制于许多因素，尤其包括所选择的解码模块146；用于创建原始存档130的压缩级别；压缩模块140所使用的压缩级别；用于执行压缩模块140其他参数等。

处理300的优选实施例在这里被描述为仅运行一次，例如在处理200的最终迭代(递归)中，或者紧接在处理200的所选步骤之后。然而，本领域技术人员可以容易地构建具有解码步骤执行序列的其他实施例(例如，通过在完成步骤252或步骤253之后调用处理300；或者例如，通过针对目的存档结构154中的不同位置和/或原始存档结构152中的不同位置对处理300的操作进行多任务处理；或者在两个或多于两个硬件处理器或虚拟处理器之间；或者例如，通过以交错模式进行处理200和处理300中的步骤，使得所生成的目的存档结构154的部分由处理200遍历和解码，然后由处理300重建(如下所述)；等等)。这些其他实施例可以证明是有用的，特别是如果在具有约束资源(诸如如果用于暂存区150的RAM和/或存储介质的量对于一次运行优选实施例而言、以及对于利用多于一个处理器来准备正在处理的DAT的部分(无论是目的存档结构154还是原始存档结构152)而言太有限)的环境中操作。

处理300可选地包括本质上是循环或递归的多遍，如下文在优选实施例中所述。根据下面的教导，每遍与使用由“s”(以下简称P_S)标识的排序构建的对象元素的各补丁中的目的存档结构154的存档元素的不同顺序选择(在这里和下面由字母“s”指定)相关联。在例如可以通过s＝0来识别的处理300的第一遍，计算用于目的存档元素132和原始存档元素130的原始排序的补丁包170。因此，由所述第一遍得到的补丁包170可以被称为“P₀”。

由于在目的存档结构154或原始存档结构152中由处理300遍历的存档元素不一定与目的存档元素132或原始存档元素132相同，因此我们在处理300中使用不同的符号来在原本出现在原始存档元素130和目的存档元素132中的内部存档元素(“原始存档元素”)与从处理200得到的内部存档元素之间进行区分。

目标和益处——虽然数学基础超出了本领域技术人员构建本主题的实施例所需的范围，但我们将简要强调与通过在目的存档结构154上进行处理300而获得的益处和/或效率相关的几点。

处理300的目标之一是当两个或多于两个原始元素或目的元素处于压缩形式时，减少可能与拥有大量离散字典相关联的开销。

处理300的另一目标是试图通过利用更大多样性或量的数据输入压缩模块141和/或编码模块143来达到更好的压缩结果，这典型地实现了补丁数据172中不同但更少的字典。

处理300的另一目标是尝试通过以与普通或默认遍历算法将会输入的不同顺序、利用存档元素输入压缩模块141和/或编码模块143来达到更好的压缩结果。

处理300的另一目标是尝试通过用补丁数据172替换效率较低的原始编码补丁数据172来达到改进的压缩效率，补丁数据172被不同的压缩模块141/编码模块143或被以不同参数(例如，压缩级别、字典大小、例如算法XZ和/或LZMA中的“匹配查找器”的类型等)执行的相同编码模块143更高效地编码。

然后，处理300尝试通过考虑构建的不同替代补丁170的效率(无论是绝对的还是相对的)来选择最高效的补丁数据172(“MEP”)。

从执行步骤310-340获得了若干益处，步骤310-340部分地解决了处理300的一些目标。

(1)通过构建替代补丁包170(P_S)，可以找到比原始压缩(例如对于P₀)更高效的压缩。

(2)通过构建替代补丁包170(P_S)，先前例如在目的存档元素132中被压缩的若干原始存档元素现在可以以较少开销的数据(例如，针对每个单个原始压缩存档元素需要较少的数据字典)来压缩。

(3)通过将内部存档元素的替代布置输入转换模块140来构建替代补丁包170(P_S)，也可以得到两个主要益处：

(3.1)替代的字典，其更高效地描述内部存档元素的数据；以及

(3.2)在不同存档元素中被压缩(例如，作为不同压缩存档的内部存档元素)的并且因此未被差分模块160发现为相同(由于字典中的差而被不同地表示)的相同存档元素现在是可见的，并且可以被更好地压缩或者被向第一出现的链接的引用所替换。例如，假设发现了相同存档元素的20个出现，第一存档元素可以被压缩并如此保存，而剩余的19个出现将不以压缩形式写入，而是作为向包含该存档元素的压缩形式的第一出现的链接。

可以全部或部分地寻求处理300的上述目标，这取决于许多因素，包括但不限于：所实现的实施例中包括的实际步骤；用于创建P_S的转换模块140；用于创建P_S的转换模块140；在内部存档元素的集合上执行转换模块140时使用的参数；等等。

在步骤302中，修补系统110被输入有包括两个数据流(原始元素和目的元素)的匹配对。

如果在执行处理300之前执行了处理200，则这两个输入数据流都是用于处理由处理200得到的两个存档结构152和154的开始点；否则，开始点被视为原始存档元素130和目的存档元素132本身。

类似于处理200，原始元素130中的第一输入位置是原始存档结构152中的用于读取存档元素以供比较或引用的初始位置。目的元素中的第二输入位置是目的存档结构154中的用于读取存档元素以供比较或引用的初始位置。

类似于处理200，处理300也可以仅以一个输入位置来输入。在描述处理300之后，这种情况在下面被描述为“单存档输入”情况。

在步骤310中，修补系统110应该选择内部存档元素的排序。该步骤对于实现针对得到的补丁数据172的另外效率(例如压缩)是关键。

注意，在处理200中，修补系统110准备包含解包和解压缩的存档元素的存档结构。

排序的思想是用于创建替代补丁包170，各补丁包通过运行匹配对的不同排序作为向模块的输入来创建。各排序是根据两个选择(一个是匹配对的“序列”，并且另一个是将匹配对的序列“分组”到子组中)而生成的。

排序可以包括如下规则，该规则陈述了处理300的目的是差分还是压缩，即执行差分模块160、压缩模块141(例如，在如下所述的单存档输入的情况下)或这两者。

修补系统110通过获取由所有先前处理步骤构建的存档元素，并且排列它们的输入顺序来进行这一点，如下所述。

为了在序列中排列存档元素的顺序，可以使用查询来创建适合作为输出的存档元素的结果集合。后续步骤(或者如果可能，在查询中)将根据一个或多于一个分组准则对存档元素的匹配对进行分组。

有许多方法可以对存档元素进行排序和分组。修补系统110可以被建立成适应可以在规则集合中定义的任何排序和分组。一些示例包括：

1.自然顺序——当存档元素的匹配对从它们各自的位置(例如，原始存档结构152和目的存档结构154)读取时被添加到差分模块160(或压缩模块141)。这典型地用于构建第一P_S(P₀)。

2.归类顺序——例如，根据例如生成器策略134中的准则对存档元素的匹配对进行归类。准则可以针对存档元素的任何属性，例如，按大小、按父目录名称、按文件名称、按数据类型等。例如，按文件大小归类以首先构建最大文件的字典。

3.类型顺序——存档元素的匹配对是根据其被识别的数据类型进行分组的。例如，首先输入所有BMP，然后输入XML。

4.N-off——存档元素的匹配对是根据其存档元素的属性(例如，数据类型、文件名称的第一个字母等)进行分组的，以升序或降序形式归类，然后选择前N个。例如，根据数据类型以5个为一组从最大大小到最小大小匹配所有存档元素，将产生如下的分组：例如，对于仅包含2个数据类型(BMP，XML)的存档元素的存档结构，将首先返回5个最大的BMP，接着是5个最大的XML文档，接着是第二大的5个BMP，接着是5个第二大的XML，等等。

5.补丁指令元素——补丁指令174内的元素，特别是所需的元数据，可以在分组和排序中发挥重要作用。

排列可以根据任何规则和偏好的任何集合来进行，并且不限于单个规则，规则可以以任何序列组合。另外，即使在使用存档元素的相同序列的情况下，排序也可以排列所使用的实际转换模块140和差分模块160。这样，可以由系统创建针对不同差分模块160和/或不同压缩模块的结果。

当第一次被执行时，步骤310简单地选择第一排序。如果仅针对修补系统110指定了一个排序(例如在补丁生成器策略134中，或者“硬编码”到其处理中)，则选择该排序。否则，借助于补丁生成器策略134来确定接下来应该出现哪个排序。

当接下来在另外的迭代中被执行时，步骤310将计算来自规则集合(例如在补丁生成器策略134中)的下一个排序。

在步骤320中，修补系统110根据当前排序中的相关规则将所有存档元素分组到不同的存档元素序列中。这些存档元素序列将用于在步骤330中构建补丁包170。

可以通过使用不同的分组规则(例如，如补丁生成器策略134中定义的)，通过使用一个或多于一个不同的轴(例如，根据存档元素的不同属性)对存档元素进行分组。

例如，按文件类型进行分组可以在步骤322中创建将包括用于所有PNG文件的一个存档、用于所有PDF的另一存档以及用于剩余存档元素的另外存档的存档元素序列。

在另一示例中，按大小规则对元素进行分组可以在步骤322中创建受大小限制的存档，例如，一旦达到了某个大小，例如存档已经超过了256兆字节，步骤322将关闭存档。

在又一非限制性示例中，按名称规则进行分组可以创建根据文件名称的第一个字符(例如“a”、“b”、“1”……等)对所有文件名称进行分组的存档。

分组应用于原始存档元素130的内部存档元素和目的存档元素132的内部存档元素这两者，或者如果可用，应用于原始存档结构152和目的存档结构154中的存档元素。

在步骤322中，修补系统110通过使用至少一个存档模块142构建针对每个组的两个分组存档，构建两个存档中的第一个。

步骤322识别所选择的差分模块160是否能够输入包括多于一个的存档元素，并且在不能输入多于一个的存档元素的情况下，添加一个分组规则(因此另一步骤322迭代)，其中原始存档结构152中的所有存档元素将被分组到一个分组存档中，并且目的存档结构154中的所有存档元素将被存档到另一分组存档中。

然后针对来自原始存档结构152的存档元素(其对应于在步骤320中构建的组)创建第一存档。针对来自原始存档结构152的存档元素(其对应于在步骤320中构建的组)创建第二存档。

各存档被典型地存储在暂存区150中的指定位置，并且如果不再需要，例如在进行步骤330之后，可以被删除。可替代地，各存档可以被存储在RAM中、虚拟存储器中、存储介质上的文件系统或存储器内文件系统中，或者存储在步骤330可访问的任何其他位置中。

在步骤330中，修补系统110在通过步骤320和322正确分组之后，构建与所选择的排序相对应的补丁包P_S170。

为了构建补丁包170，修补系统110在步骤322检查是否准备了分组存档，并且如果是，则选择所有分组存档。

接着，步骤330将原始存档结构152的分组存档作为源输入而输入到差分模块160，将目的存档结构154的分组存档作为目的输入而输入到差分模块160，并执行差分模块160。

差分模块160将关于源输入和目的输入的每个集合生成一个补丁数据172。在仅存在源输入和目的输入的一个集合的情况下，差分模块160创建单个补丁数据172，否则创建多个补丁数据172。在后者中，修补系统110关于各补丁数据172生成一个补丁指令174，并将该补丁指令174添加到补丁包170。

修补系统110现在构建一个补丁包P_S170，其中“s”是该特定补丁包的唯一标识符。

在下面定义的一些“单存档输入”实施例中，向步骤330的输入可以仅包括一个存档输入，例如仅包括目的输入。在这种情况下，步骤330可以根据实现将原始输入视为“null”、“nil”或“empty”，或者将原始输入视为不存在。如果步骤330将原始输入视为不存在，则可以在输入上执行压缩模块141而不是差分模块160，并且将所述压缩模块141的输出存储在补丁数据172中，可选地在相应的补丁指令174中指示如此。

在步骤340中，修补系统110例如根据生成器策略134检查是否需要另外的排序，并且如果需要，则根据类型(整数、散列键等)适当地递增“s”，并且重复步骤310至340。

在步骤350中，修补系统识别补丁包P_1...s中最高效的补丁包，并且使用唯一标识符“D”来标识。现在保持所述最高效的补丁包(“MEP”或P_D)，同时可选地丢弃除P_D之外的其他补丁包P_1...s。

由先前步骤要求和/或使用的任何暂存区150存储空间典型地在此时被释放，无论是在存储器、RAM或存储介质上，还是在暂存区150使用的任何其他位置。

在仅一个存档元素(例如目的存档元素132)被输入到处理中的情况下，现在再次参考图2所示的处理200。在上述处理200的这种特定情况下(在本公开的上下文中被称为“单存档输入”情况)，不存在原始存档元素130来区分，或者原始存档元素130不包含存档元素或不包含数据。因此，处理200可以通过假设在处理200和/或300的执行期间在任何匹配对中都不存在原始元素来进行操作，以推断为目的元素的所有数据实际上在接收端缺失，从而典型地指示如上所述的“添加”动作。

“单存档输入”的情况不同于目的元素全部缺失或缺失内部存档元素的情况(其中处理200将指示对这种缺失的存档元素的“删除”动作)。

在原始存档元素130中不包括数据的情况下通过执行处理200和/或300准备的补丁包170可以受益于所有上述益处或目标。

这种补丁包170在许多用例中是有用的。值得注意的示例包括：

(1)在目的存档元素132中的两个或多于两个内部存档元素先前例如使用压缩模块141被分别压缩并且将一起被存档的情况下，准备了通常比常规压缩存档压缩得更好的压缩存档；

(2)存档作为开放文档(基于XML)压缩格式之一的文档的相关存档元素集合。这在诸如美国专利8,768,962等的文档管理和版本控制系统中特别有用；

(3)准备大量存档元素的快照，例如用于备份和以后的恢复，其中两个或多于两个存档元素包括相同的数据部分，包括如上所述的相同的内部存档元素，或者包括相同的存档元素。这在备份和恢复系统和方法的上下文中特别有用。

可以构建单存档输入处理200和300的不同实施例。在优选实施例中，实现处理200的所有步骤和处理300的所有步骤，从而可以寻求最大效率。

通常，如上所述处置单存档输入情况可以通过执行处理200和/或300的步骤(具有对于阅读本公开的本领域技术人员而言显而易见的微小调整)来进行，如下所述。

例如，在一些单存档输入实施例中，差分模块160可以输入有例如不包含存档元素的空原始存档结构152，而在一些其他单存档输入实施例中，根据差分模块160的规范，差分模块160可以输入有指示没有原始存档结构152的空引用(null reference)或零指针(nilpointer)。

在另外的单存档输入实施例中，在步骤330中，执行差分模块160可以完全替换为压缩模块141的执行，并且在补丁包170中指示使用所述压缩模块141，而不是如上所述指示差分模块160。

另外，在没有原始元素的情况下，可以对补丁包170、补丁数据172和补丁指令174的数据结构进行一些优化。例如，这种优化可以尤其包括去除所述数据结构内的某些字段。

下面在图4的描述之后描述可以使用所述补丁数据172和补丁指令174来应用或解压缩得到的补丁包170的实施例。

现在参考图4，该图示出了用于从原始存档元素130和包括补丁数据172和补丁指令174的补丁包170重建目的存档元素132的示例处理400。

处理400的目标是逆转由处理200进行的结构提取；对由处理200解码的存档元素进行编码；以及将由处理300构建的MEP(在适用的情况下)应用于原始存档元素130中或原始存档元素130处的存档元素(最终得到正确构建的目的存档结构154)。

处理400的执行中的一个关键要素是正确地存档、编码或压缩先前在修补系统110计算机上在处理200、300期间解包、解码或解压缩的存档元素。由于一些这样的存档元素最初是具有“目录”、“存档”或“经压缩”结构类型的容器存档元素的一部分，因此为了重建所述容器存档元素，所述这样的存档元素应该首先例如通过转换模块140被转换成其原始格式。在一些实施例中，这可以通过以相反的顺序遍历补丁指令174来实现，而在其他实施例中，这可以通过在处理200、300已经以与补丁应用顺序一致的序列记录了补丁指令174的情况下遍历补丁指令174来实现。

在步骤401中，补丁应用器112接收三个输入：原始存档元素130，作为包括用于使用原始存档元素130重建目的存档元素132的补丁指令174的补丁包170的P₀，以及要由处理400的步骤处理的补丁数据(又名“有效载荷”)172。在一些实施例中，步骤401可以首先确保两个输入130、170是有效的，例如，是正确的格式，包含有效数据，不包含恶意内容的“注入”数据等，如本领域所知。

典型地，在第一次被执行时，原始存档元素130指定存在于执行计算装置(OA)上的原始存档元素130；P₀包括关于使用P₀从原始存档元素130构建目的存档元素132的所有补丁指令174和补丁数据172；并且原始存档元素130和P₀这两者都包含要根据P₀中的补丁指令174更新、添加或删除的内部存档元素。

在一些实施例中，所述补丁指令174可以与P₀的数据一起打包在相同的文件或数据结构中，例如，以更高效地传输这两个数据元素；以将处理400所需的所有输入打包在一个数据结构中等。在一些实施例中，所述补丁指令174被存储在补丁包P₀内的内部存档元素(例如，文件)中。

在一些实施例中，处理400在暂存区150内的指定区(即目的存档结构154)中准备原始存档元素130(即OA)的工作副本。在一些实施例中，处理400然后首先对暂存区150中的所述副本进行其处理步骤，并且仅当完成时，才将得到的目的存档结构154应用于原始存档结构152。例如，当处理400更新“C:\Program Files”下的子目录时，通常可以创建原始存档元素130的内部存档元素的副本作为暂存区150上所提取的原始存档结构152，以及创建包括暂存区150上的结果目的存档结构的空副本。在一些另外的实施例中，处理400可以仅在暂存区150上创建一个副本(例如结果目的存档结构154)，并且将处理400的步骤应用于所述结果目的存档结构154。在又一实施例中，原地进行处理400的步骤，因此不创建原始存档元素130的内部存档元素的副本，并且处理400的步骤直接对原始存档元素130的存储位置中的内部存档元素进行操作。通常，当整个数据驻留在存储器中(例如RAM中)时，所述又一实施例是优选的。

通常，处理400可以被分割成关于补丁指令174发生的四个主要步骤集群：步骤401-420进行补丁应用120的内务处理活动，包括存储器分配和内部处理测试；步骤430-440确保要更新的存档元素例如在暂存区150上以可以将补丁数据172应用于的数据格式准备好；步骤450应用补丁数据172以在目的存档结构154中构建修补的存档元素；以及最后，步骤460-480确保所述修补的存档元素处于它们的最终数据格式。典型地，处理400重复直到没有另外的补丁指令174存在为止；然而，处理400可以根据例如在应用器策略136中设置的规则停止重复。

在步骤410中，补丁应用器112迭代通过所有补丁指令174，在每次迭代中从补丁包170读取下一补丁指令174。在步骤410的第一次执行中，这典型地是第一补丁指令。

在优选实施例中，由遍历算法根据深度优先搜索(DFS)算法的处理200和300创建的补丁指令的顺序将意味着与一个存档元素(例如，与由补丁指令描述的压缩存档元素)相关的所有指令将一个接一个地跟随，从而简化了跟踪开放存档(例如，栈数据结构)的负担。然而，在某些实施例中，例如，在广度优先搜索(BFS)的情况下，可能需要对开放存档进行更复杂的跟踪，因此可选的内务处理步骤420将确保这种情形被适当处置。

典型地，此时补丁应用器112将测试OA中的匹配存档元素。通过将所述存档元素标识符的标识符与存储在所述补丁指令中的标识符进行比较，匹配存档元素是补丁指令应用于的元素，即补丁。在某些情况下，在OA中没有找到匹配存档元素，因此需要在OA中创建空的匹配存档元素。在其他一些情况下，在补丁指令中没有找到OA中存档元素的匹配存档元素，例如，指示没有对OA中的所述存档元素进行改变。

如果在174中没有下一个补丁指令，应当理解，处理已经执行了所有补丁指令174，并且该处理因此通过执行步骤499而结束。

在可选的步骤420中，补丁应用器112检查是否有任何内务处理活动处于未决状态。未决的内务处理活动包括处置处理400的先前迭代留下的任何存档元素。

补丁应用器112可以关闭和/或删除处理400使用的存档元素，以包括存档(“被存档的存档元素”)和/或被解压缩的存档元素，并且进行指示所述存档和/或被解压缩的存档元素在处理400中不再使用并且可以被释放所需的任何内务处理(例如，存储器释放、API调用)。

在一个非限制性示例中，已经被存档到例如“.tar”格式的被存档的存档元素在没有被具有“链接”结构类型的任何另外的补丁指令174引用的情况下可以被删除。

在另一非限制性示例中，例如从“.xz”格式解压缩的存档元素在没有被具有“链接”结构类型的任何另外的补丁指令174引用的情况下可以被删除。

在又一非限制性示例中，对于在处理400的执行期间准备的、并且不需要构建补丁指令174(在补丁包170中)中指定的任何存档元素的被存档的存档元素和被解压缩的存档元素，可以在没有被具有“链接”结构类型的任何另外补丁指令174引用的情况下被删除。

在另一非限制性示例中，分配给暂存区150的不再另外被处理400需要来处置另外的补丁指令174的存储空间可以被安全地释放，例如以减少处理400的存储需求。

如果补丁指令174被排序，使得与一个目录、一个存档或一个压缩存档元素相关的所有补丁指令被分组以彼此跟随，则在优选实施例中，可以通过检查新补丁指令是否引用当前未解包的存档元素，并且还通过确定补丁应用器112是否已经完成到存档位置的遍历来进行步骤420。

在补丁指令的排序不同的实施例中，将需要更复杂的遍历和记录保存，以跟踪哪些被存档的存档元素和/或被解压缩的存档元素仍在使用，例如，通过使用散列映射、数组、链接列表、补丁包170内的指示或存储器栈来指示哪些存档被解包。

步骤430是确保补丁指令174中指示的位置可用于应用补丁数据172所需的一系列步骤中的第一步，例如，补丁应用器112检查补丁指令174中指示的存档元素(例如通过其位置和标识符)是否需要结构转换。

在步骤430中，补丁应用器112检查补丁指令174中的位置是否指示原始存档中的压缩存档元素，并且如果不是，则前进到步骤432。为了确定这样，补丁应用器112使用如上所述的补丁指令174或内容识别模块148中的指示。

然后，步骤430从补丁指令174解压缩至少所指示的存档元素。在一些实施例中，例如，由于压缩模块141或解压缩模块144的内置限制，需要解压缩包括所述位置中指示的压缩存档元素的所有内部存档元素。

步骤430可以将所述存档元素标记为解压缩以供以后使用，例如，以向步骤480指示在补丁数据172被应用于所述存档元素之后需要(重新)压缩。

步骤430可以根据需要重复多次，以提取由所述位置指示的存档元素，例如，在要修补的存档元素存在于压缩存档元素内的情况下，该压缩存档元素继而是包含在另一压缩存档元素内的存档元素。因此，步骤430可以重复，例如直到补丁指令174中指示的位置被完全解压缩为止。

步骤430典型地检查目的存档结构154上的所述存档元素是否被解包，以及原始存档(例如，在原始存档结构152中)上的所述存档元素是否被解包；并且如果不是，则在进一步处理之前检查是否需要解包。

为了确定存档元素是否被解包，补丁应用器112可以在确定存档元素的类型时利用与处理200类似的系统和方法，或者根据补丁指令174中的指示，或者通过经由系统调用(例如，API)测试位置中的实际存档元素来指示等(如本领域中适当的)。

在步骤432中，补丁应用器112检查存档元素是否是存档。为了确定这样，补丁应用器112在确定存档元素的类型时利用与处理200类似的系统和方法(例如内容识别模块148)，或者根据补丁指令174中的指示。

如果解包的存档元素是存档，则可以重复步骤432，直到补丁指令174中指示的要更新的存档元素可用于更新为止，例如，直到补丁指令174中指示的位置被完全解包为止。

在步骤432中，补丁应用器112通过使用适当的解包模块145将内部存档元素从存档元素(其是存档)解包到指定位置。在优选实施例中，在位于暂存区150中的目的存档结构154上进行该提取处理，使得所述内部存档元素各自被放置在暂存区150上其自己的指定位置(例如，新创建的文件夹，或者在内部存储器而不是文件系统中进行操作的情况下而分配的存储器位置)。

在其他实施例中，解包可以直接在存储器中进行，然后可以在存储器中进行处理步骤。

在另外的实施例中，通过原地放置解包的元素，可以直接在原始存档130上进行解包。当期望补丁指令174被完全进行(例如，没有错误)时，或者例如，当准备好足够的空间时，这是特别有用的。

例如，在步骤432遇到由步骤431识别为“.cab”(Microsoft^TMCabinet)文件的存档元素的情况下，优选实施例可以在暂存区150上创建新位置(例如，临时目录)，并将所述存档元素解包到其包含的内部存档元素IAEO_1...n中，其中“n”是各IAEO的唯一标识符，例如序列号。

在步骤432中，补丁应用器112可以标记步骤431的所述指定位置以供以后的重新包装。这在补丁指令174指示要关于由步骤432提取的内部存档元素IAEO_n而进行的动作的典型情况中是重要的。

为了继续步骤432的非限制性示例，优选实施例例如通过将所述指定位置放置在栈、链接列表或数组中来标记所述指定位置。

在步骤440中，补丁应用器112检查补丁指令174中是否存在在应用补丁数据172之前对目的存档元素132进行解码的指示。如果这样的指示不存在，则前进以执行步骤442。

步骤440中的指示可以是补丁指令174中包含对补丁指令174中的存档元素进行解码的指示的明确数据。所述指示也可以通过将存档元素的类型与原始存档中的相应存档元素进行比较来隐含地导出。如果补丁应用器112信任文件扩展名，也可以从描述存档元素的文件扩展名导出指示。另一类型的指示可以通过利用内容识别模块148(例如，使用Unix实用程序“文件”中的三重测试)来隐含地导出。

接着，补丁应用器112选择能够对存档元素进行解码的解码模块146。为了选择适当的解码模块146，可以使用所述指示。

在选择解码模块146之后，步骤434操作解码模块146以将存档元素的内容解码成解码数据。在解码的处理期间，解码模块146读取并利用包含在存档元素内的特定元数据，该元数据描述了所包含的编码数据。例如，解码模块146可以读取如下元数据，该元数据指定PNG图像具有以像素表示的特定x轴和y轴尺寸、特定颜色深度、以及透明度(alpha通道)是否存在、以及用于压缩其的压缩级别。补丁应用器112典型地在稍后例如在步骤481中当重建存档元素时重用该元数据，因此步骤434可以保持所述元数据以供以后使用，可选地在内务处理步骤420期间释放所述元数据的存储空间。

然后，原地存储解码数据，例如，通过替换目的存档结构154中的原始存档元素；或者通过将其放置在暂存区150中；或者将其存储在存储器中。

步骤434可以重复，直到补丁指令174中指示的位置被完全解码为止。

由于嵌套位置可以是多个嵌套级别，各个这样的嵌套级别是被压缩的、被存档的或被编码的结构类型，因此步骤430、432和434可以重复，直到补丁指令174中指示的位置根据特定位置被完全解包、解压缩和/或解码为止。

步骤440检查补丁指令174中指示的存档元素是否准备好被更新，例如，其位置已经被解包、解压缩和解码以符合补丁指令174。在检查失败的情况下，重复步骤430至434，直到目的存档元素132可用于更新并被解码为如此指示的格式为止。然后，执行继续到步骤442。

在该阶段，优选实施例具有准备好被修补的存档元素，如上所述，因此处理400可以根据补丁指令174前进到应用其补丁数据172、对其进行编码、存档、压缩或删除。

在步骤442中，补丁应用器112检查补丁指令174中的动作指示是否指定了“删除”操作，并且在指定的情况下，前进到步骤444，在该步骤，补丁应用器112根据先前选择的位置而删除在暂存区150中的位置中或在目的存档结构154中的位置中的存档元素。在执行了步骤444的情况下，处理接着前进到步骤410以获得下一补丁指令，否则前进到步骤450。

在步骤450中，补丁应用器112根据补丁指令174中的指示选择可用于补丁应用器112的补丁应用模块180。该指示可以是明确指示，例如“bsdiff”，或者隐含指示，例如在仅一个补丁应用模块180与补丁应用系统112相关联的情况下，或者例如在P₀中的数据可以仅正确地输入到一个补丁应用模块180的情况下。

一旦选择，使用补丁数据(有效载荷)172对原始元素执行补丁应用模块180。然后，来自所述修补模块180的执行的所得数据被存储在目的元素中。

根据所实现的实施例和/或如应用器策略136中所指示的，所述目的元素然后被存储在补丁指令174中指示的目的存档结构154中的位置，存储在暂存区150中，或者直接存储在(应用于)原始存档元素130。

在步骤460中，补丁应用器112检查是否应该进行来自步骤450的所得目的元素的编码。

存在优选实施例对目的存档元素132进行编码的若干情况：

a)在补丁指令174明确要求这样做的情况下，例如通过指示针对得到的目的存档元素132的所请求的数据格式，诸如PNG图像等；

b)默认地，在步骤434已经解码了原始存档元素130并且对其应用了补丁有效载荷P₀的任何时间；

c)在补丁指令174隐含地要求这样做的情况下，例如通过指示与正被更新的原始存档元素的文件格式不同的目的文件格式。

在一些实施例中，即使在步骤461中没有进行解码，也可以发生目的元素的编码。在另外的实施例中，即使补丁有效载荷172中没有数据，也可以发生目的元素的编码，例如，以得到仅包括所选编码的技术描述而没有任何包含的数据的存档元素。

对于补丁应用器112简单地转变目的元素的所得类型，而不实际存储或发送(例如，通过网络)所述目的元素的任何内容，这种情况可能是特别有用的。例如，在软件发布者仅将文件格式从例如JPG替换为PNG而不在补丁有效载荷172中传播任何数据的情况下，举例说明了这一点。例如，在这种情况下，通过简单地发送指示这样做的100个补丁指令174，可以容易地将包括JPG格式的100个图像的原始存档(OA)的目录中的所有文件的整个数据结构编码为PNG格式。

根据实施例采用的数据结构，这可以通过直接在与目录或存档相关的补丁指令上指示要解码的原始数据格式和要编码的所得数据格式来更简洁地表示。例如：{name＝“archive.tar”；action＝“update”；Dtype＝“JPG”；Etype＝“PNG”}。

补丁应用器112通过首先选择适当的编码模块143，然后使用该编码模块143对目的元素的内容进行编码，将目的元素编码为所指示的编码类型。

这是在补丁指令174中捕获的元数据被使用的情况。由步骤481执行的编码模块143典型地需要一些参数来将目的元素编码或重新编码为其原始形式，尤其是在例如在步骤460中首先被解码的情况下。

如果例如在步骤460中首先被解码，则补丁应用器112使用由步骤434识别的元数据对目的存档元素132进行重新编码。在其他情况下，补丁指令174可以包含指示如何重新创建目的存档元素的元数据，然后补丁应用器112使用该元数据对存档元素进行编码，例如，回到原始形式。

步骤460的所得编码存档元素应该被添加或替换目的存档结构154中具有相同标识符(例如，位置)的任何先前存在的存档元素。

在步骤470中，补丁应用器112检查来自先前步骤的目的存档元素是否应该被存档。为了确定这样，步骤470可以使用补丁指令174中的指示，即由步骤432设置的标记。

在优选实施例中，目的存档元素132的实际存档可以延迟，直到包括的所有目的存档元素132已经完成更新(例如通过步骤430-450)为止。

为了存档目的元素，步骤470首先确定存档模块142。为了确定这样，步骤470可以使用补丁指令174中的指示、应用器策略136中的指示或规则，或者由步骤432做出的标记。根据所确定的存档模块142、目的存档元素132、或者在根据上述规范延迟存档的情况下的所有相关目的元素、以及补丁指令174中指示的存档元素被输入到存档模块142，然后执行存档模块142。

步骤470的所得存档应该被添加到或替换目的存档结构154中具有相同标识符(例如，位置)的任何先前存在的存档。在随后的迭代中，内务处理步骤420可以确保根据步骤420的规范，例如从存储器或文件系统释放所有所述目的元素。

在步骤480中，补丁应用器112确定来自先前步骤的目的存档元素是否应该被压缩。为了确定这样，步骤480可以使用补丁指令174中的指示，或者由步骤430设置的标记。

为了压缩目的元素，步骤480接着选择压缩模块141。为了选择这样，步骤480可以使用补丁指令174中的指示(例如，“xz”)、应用器策略136中的指示或规则、或者由步骤430做出的标记。

在优选实施例中，目的元素的实际压缩可以被延迟，直到包括相同压缩存档元素的所有目的元素已经完成更新(例如通过步骤430-450)为止。然而，在一些情况下，所选压缩模块141不能处理多于一个的元素。在这些情况下，应该针对各个目的元素单独地执行所选压缩模块141。

为了压缩所述目的元素，步骤480接着将所述目的元素以及可以存储在补丁指令174中的任何相关元数据一起输入到压缩模块141。步骤480然后执行压缩模块141，典型地得到压缩存档元素。

得到的压缩存档元素应该被添加到或替换在目的存档结构154中具有相同标识符(例如，位置)的任何先前存在的压缩存档元素。在随后的迭代中，内务处理步骤420可以确保包括相同压缩存档元素的所有所述目的存档元素132根据步骤420的规范(例如从存储器或文件系统中)被释放。

在最终步骤490中，补丁应用器112已经确定为不存在另外的补丁指令174，并且处理400可以结束。

在优选实施例中，步骤490应该确保目的存档结构154不包含不应该是最终目的存档元素134的一部分的数据、元数据或内容(例如，目录、文件、存储器对象等)。步骤490可以实现这一点，例如，通过将所有补丁指令174与得到的目的存档结构154进行比较，通过调用步骤420(例如，在不继续步骤430的情况下)来对处理400先前使用的任何剩余数据和存储空间进行内务处理。在一些实施例中，可能需要针对最后补丁指令174的步骤430-480的最终运行，尤其是在原始存档元素130和目的存档元素132是压缩格式、存档格式或这两者(例如，“tar.gz”压缩存档)的情况下。

最终地，步骤490确保得到的目的存档结构154正确地表示在补丁包170中技术上描述的目的存档。典型地，当处理400例如在暂存区150上使用与目的存档元素132本身不同的目的存档的副本时，步骤490将使目的存档结构154中的所有改变的存档元素复制到目的存档132上，同时删除目的存档132中不存在于目的存档结构154中的任何存档元素。

在一些实施例中，处理400可以接收由处理200和/或300根据单存档输入情况生成的补丁包170。通常，如下所述，可以通过执行处理400的步骤(具有微小调整)来进行上述处置单存档输入情况。

例如，在一些单存档输入实施例中，补丁应用模块180可以输入有例如不包含存档元素的空的原始存档结构152，而在一些其他单存档输入实施例中，根据补丁应用模块180的规范，差分模块160可以输入有指示没有原始存档结构152的空引用或零指针。

在另外的单存档输入实施例中，在步骤450中，执行补丁应用模块180可以完全替换为解压缩模块144的执行，尤其是在补丁包170中指示使用压缩模块141而不是如上所述的差分模块160的情况下。

另外，在没有原始存档元素130的情况下，优化的数据结构可以存在于补丁包170、补丁数据172和补丁指令174中。例如，这种优化尤其可以包括去除所述数据结构内的某些字段，例如，与不存在的原始存档元素相关的字段。

尽管已经详细描述了本发明，但是对于本领域技术而言来说，不偏离本发明教导的改变和修改是显而易见的。这种改变和修改被认为属于本发明和所附权利要求的范围。

显而易见的是，这里描述的各种方法和算法可以由例如适当编程的通用计算机和计算装置来实现。典型地，处理器(例如，一个或多于一个微处理器)将从存储器或类似装置接收指令，并且执行这些指令，从而进行由这些指令定义的一个或多于一个处理。此外，实现这种方法和算法的程序可以使用各种介质以多种方式来存储和传输。在一些实施例中，硬连线电路或定制硬件可以用来代替软件指令或与软件指令相结合，以实现各种实施例的处理。因此，实施例不限于硬件和软件的任何特定组合。

“处理器”是指任何一个或多于一个微处理器、中央处理器(CPU)、计算装置、微控制器、数字信号处理器或类似装置。

术语“计算机可读介质”是指参与提供可由计算机、处理器或类似装置读取的数据(例如，指令)的任何介质。这种介质可以采取多种形式，包括但不限于非易失性介质、易失性介质和传输介质。非易失性介质包括例如光盘或磁盘以及其他持久性存储器。易失性介质包括动态随机存取存储器(DRAM)，其典型地构成主存储器。传输介质包括同轴电缆、铜线和光纤，包括构成耦合到处理器的系统总线的线。传输介质可以包括或传送声波、光波和电磁辐射，诸如在射频(RF)和红外(IR)数据通信期间生成的这些。计算机可读介质的常见形式包括例如软盘、灵活盘、硬盘、磁带、任何其他磁介质、CD-ROM、DVD、任何其他光学介质、穿孔卡、纸带、任何其他具有孔图案的物理介质、RAM、PROM、EPROM、FLASH-EEPROM、任何其他存储器芯片或盒式磁带、下文描述的载波或计算机可以读取的任何其他介质。

在将指令序列携载到处理器时，可以涉及各种形式的计算机可读介质。例如，指令序列(i)可以从RAM传递到处理器，(ii)可以通过无线传输介质携载，和/或(iii)可以根据多种格式、标准或协议(诸如蓝牙、TDMA、CDMA、3G等)进行格式化。

在描述数据库的情况下，本领域普通技术人员将理解，(i)可以容易地采用所描述的这些数据库结构的替代数据库结构，以及(ii)可以容易地采用除了数据库之外的其他存储器结构。这里给出的任何样本数据库的任何例示或描述都是信息的存储表示的说明性布置。除了例如附图或其他地方所示的表所建议的布置之外，还可以采用任何数量的其他布置。类似地，数据库的任何例示条目仅表示示例性信息；本领域普通技术人员将理解，条目的数量和内容可以不同于这里描述的数量和内容。此外，尽管将数据库描述为表，但其他格式(包括关系数据库、基于对象的模型和/或分布式数据库)可以用于存储和操纵这里描述的数据类型。此外，数据库的对象方法或行为可以用于实现各种处理，如这里所描述的那样。另外，数据库可以以已知的方式被本地存储或从访问这种数据库中的数据的装置远程存储。

本发明可以被配置为在包括经由通信网络与一个或多于一个装置通信的计算机的网络环境中工作。该计算机可以经由诸如因特网、LAN、WAN或以太网、令牌环等的有线或无线介质，或者经由任何适当的通信部件或通信部件的组合，直接或间接地与这些装置通信。各装置可以包括适于与该计算机通信的计算机，诸如基于Intel^R、Xeon^R、Pentium^R或Centrino^TM处理器的计算机等。任何数量和类型的机器都可以与计算机通信。

Claims

1.一种补丁生成计算系统，包括：

至少一个处理器；以及

至少一个存储器，其通信地耦合到所述至少一个处理器，并且包括计算机可读指令，所述计算机可读指令在被所述至少一个处理器执行时使得所述计算系统实现用于生成包括补丁数据(172)和补丁指令(174)的补丁包(170)的方法，所述补丁包适于将原始存档元素(130)更新为目的存档元素(132)，所述方法包括：

(i)将原始存档元素(130)指派为匹配对中的原始元素，并且将目的存档元素(132)指派为所述匹配对中的目的元素；

(ii)比较所述匹配对中的所述原始元素和所述目的元素，并且在所述原始元素和所述目的元素不同的情况下准备相应的补丁指令(174)，该补丁指令包括指示与所述目的元素相关的添加、删除或更新的补丁操作的动作；

(iv)在所述结构类型是复合存档元素的情况下：

a.识别适于应用于所述原始元素和所述目的元素的至少一个解压缩模块(144)或解包模块(145)，

b.将所识别的至少一个解压缩模块或解包模块应用于所述原始元素，并且将得到的零个或多于零个内部存档元素保存到包括多个存档元素的原始存档结构(152)，

c.将所识别的至少一个解压缩模块或解包模块应用于所述目的元素，并且将得到的零个或多于零个内部存档元素保存到包括多个存档元素的目的存档结构(154)；

(v)关于所述目的元素，更新补丁指令(174)，该补丁指令包括所述补丁指令动作、结构类型、所述目的元素的标识符以及所识别的至少一个解压缩或解包模块；

(viii)将差分模块(160)应用于所述原始存档结构和所述目的存档结构，并且生成包括补丁数据(172)和补丁指令(174)的补丁包(170)，使得能够通过将所述补丁数据(172)与所述补丁指令(174)一起应用于相应的原始存档元素(130)来构建所述目的存档元素(132)。

2.根据权利要求1所述的补丁生成计算系统，其中，在所识别的存档元素的结构类型是“数据”的情况下，所述方法还包括：

a.识别所述目的元素的数据类型，并且识别能够将所识别的数据类型转换成解码数据格式的解码模块(146)；

b.将所识别的解码模块(146)应用于所述目的元素，并且生成所述目的元素的解码版本以替换所述目的存档结构(154)中的该目的元素；

c.将所识别的解码模块(146)应用于所述原始元素，并且生成所述原始元素的解码版本以替换所述原始存档结构(152)中的该原始元素；以及

d.在所述补丁指令(174)中指示所述数据类型或所述解码模块(146)或这两者。

3.根据权利要求1所述的补丁生成计算系统，其中，在步骤(viii)之前，根据排序准则将所述存档元素一次或多于一次排序到存档元素的分组序列中，并且在步骤(vi)中，以所述分组序列将所述存档元素一次或多于一次输入到所述差分模块(160)，从而得到一个或多于一个补丁包(170)。

4.根据权利要求3所述的补丁生成计算系统，其中，排序准则包括：自然顺序；归类顺序；根据所识别的存档元素的数据类型对存档元素的匹配对进行分组；根据匹配对的存档元素的属性对匹配对进行分组；匹配对与所述补丁指令(174)内的存档元素的属性相对应；或它们的任何组合。

5.根据权利要求1所述的补丁生成计算系统，其中，在步骤(viii)中，应用多个差分模块(160)，从而得到多个补丁包(170)。

6.根据权利要求1所述的补丁生成计算系统，其中，在步骤(viii)中，使用包括字典大小和/或压缩级别的不同差分模块参数多次运行所述差分模块(160)，从而关于每次差分模块(160)运行，得到多个补丁包(170)。

7.根据权利要求3至6中任一项所述的补丁生成计算系统，还包括根据预定选择准则从得到的补丁包(170)中识别最高效的补丁的步骤。

8.根据权利要求1所述的补丁生成计算系统，其中，所述原始存档元素(130)为空，从而得到作为所述目的存档元素(132)的压缩形式的补丁包(170)。

9.根据权利要求1所述的补丁生成计算系统，还包括补丁生成器策略(134)，所述补丁生成器策略(134)指定针对如何生成所述补丁包(170)的规则和偏好。

10.根据权利要求9所述的补丁生成计算系统，其中，所述补丁生成器策略(134)包括与转换模块(140)、结构类型、内容识别模块(148)、差分模块(160)、存档元素的数据类型和属性有关的逻辑谓词。

11.根据权利要求1所述的补丁生成计算系统，其中，在步骤(iii)中，能够识别“链接”的结构类型。

12.根据权利要求11所述的补丁生成计算系统，还在所述补丁指令(174)中包括：包含与所述目的元素相同数据的其他存档元素的指示、或者得到所述目的元素的其他补丁指令(174)的指示。

13.一种在计算系统中实现的补丁生成方法，所述计算系统包括：

至少一个处理器；以及

(iv)在所述结构类型是复合存档元素的情况下：

14.一种补丁应用计算系统，包括：

至少一个处理器；以及

至少一个存储器，其通信地耦合到所述至少一个处理器，并且包括计算机可读指令，所述计算机可读指令在被所述至少一个处理器执行时使得所述计算系统实现用于基于原始存档元素(130)和补丁包(170)生成目的存档元素(132)的方法，所述补丁包包括多个补丁指令(174)和补丁数据(172)，所述方法包括：

针对所述补丁指令(174)中的各个补丁指令，对由该补丁指令指示的元素进行以下操作：

(iii)在所述结构类型是压缩的情况下，

a.识别能够对所述原始元素进行解压缩的解压缩模块(144)，

b.将所述原始元素解压缩为目的元素，并且将所述目的元素存储在目的存档结构(154)中，

c.标记所述原始元素以供压缩；

(iv)在所述结构类型是存档的情况下，

a.识别能够对所述原始元素进行解包的解包模块(145)，

b.将所述原始元素解包为目的元素，并且将所述目的元素存储在目的存档结构(154)中，

c.标记所述原始元素以供存档，

d.在所述动作指示“链接”的情况下，获得在所述补丁指令(174)中指示的所述目的存档结构(154)中的其他元素，并且利用所述目的存档结构(154)中的所述其他元素的数据替换所述元素的数据；

(v)在所述原始元素被标记以供存档或压缩的情况下，识别在所述原始元素的位置中具有位置的所有补丁指令(174)，并且针对具有该位置的所述补丁指令中的各个补丁指令执行步骤(i)至(v)；

(vi)在所述动作指示“添加”或“更新”的情况下，使用补丁数据(172)对所述目的元素执行补丁应用模块(180)，从而得到所述目的元素的更新版本；

a.在所述结构类型是存档或所述元素被标记以供存档的情况下，识别能够对所述元素进行存档的存档模块(142)，根据补丁指令(174)中的指示和/或元数据对所述元素进行存档；以及

b.在所述结构类型是压缩或所述元素被标记以供压缩的情况下，识别能够对所述元素进行压缩的压缩模块(141)，根据补丁指令(174)中的指示和/或元数据对所述元素进行压缩。

15.根据权利要求14所述的补丁应用计算系统，其中，在步骤(v)之前，在所述补丁指令(174)指示解码的情况下：

(i)将匹配解码模块(146)应用于所述元素，从而得到解码元素，利用所述解码元素替换所述目的元素，并且标记所述目的元素以供编码；

(ii)在进行步骤(vii.b)之后，在所述补丁指令(174)指示编码或者所述元素被标记以供编码的情况下，将匹配编码模块(143)应用于所述更新版本，利用所述更新版本替换所述目的元素，并且标记所述目的元素以供编码。

16.根据权利要求14所述的补丁应用计算系统，其中，生成目的存档元素(132)还基于补丁应用器策略(136)来进行。

17.根据权利要求14所述的补丁应用计算系统，其中，所述补丁应用器策略(136)包括与以下项相关的规则：关于转换模块(140)的逻辑谓词；结构类型；数据类型；存档元素的属性；关于补丁应用模块(180)的逻辑谓词；或它们的任何组合。

18.一种压缩计算系统，包括：

至少一个处理器；以及

至少一个存储器，其通信地耦合到所述至少一个处理器，并且包括计算机可读指令，所述计算机可读指令在被所述至少一个处理器执行时使得所述计算系统实现用于将多个目的存档元素(132)压缩到包括补丁数据(172)和补丁指令(174)的补丁包(170)中的方法，所述方法包括：

(i)将目的存档元素(132)指派为匹配对中的目的元素，并且将空指示指派为所述匹配对中的原始元素；

(ii)针对所述多个目的存档元素中的每个目的存档元素(132)，进行以下操作：

a.识别所述目的存档元素(132)的结构类型，所述结构类型包括“目录”、“存档”、“经压缩”或“数据”，

b.在结构类型是“经压缩”的情况下，

A.识别与所述目的元素兼容的至少一个解压缩模块(144)；

B.将所述至少一个解压缩模块(144)应用于所述目的元素；

C.存储包括存档元素的B的结果，各个存档元素是目的存档结构(154)中的内部存档元素，

c.在结构类型是“存档”的情况下，

A.识别与所述目的元素兼容的至少一个解包模块(145)；

B.将所述至少一个解包模块(145)应用于包括存档元素的目的存档结构(154)，各个存档元素是内部存档元素；

d.关于所述目的元素来更新补丁数据(170)和补丁指令(174)，添加所述结构类型、所述目的元素的标识符、在适用的情况下的所识别的所述至少一个解压缩模块、以及在适用的情况下的所识别的所述至少一个解包模块(145)；

(iii)针对多个所述存档元素重复步骤(ii)，各个存档元素是所述目的存档结构(154)中的内部存档元素；以及

(iv)将所选择的压缩模块(141)或差分模块(160)应用于所述目的存档结构(154)，以及生成适于重建所述多个目的存档元素(132)的包括补丁数据(172)和补丁指令(174)的补丁包(170)。

19.根据权利要求18所述的压缩计算系统，还包括以下步骤：在步骤(iv)中应用所选择的压缩模块(141)或差分模块(160)之前，使用存档模块(142)将所述目的存档结构(154)打包成存档。

20.一种压缩计算系统，包括：

至少一个处理器；以及

a.识别所述目的元素的数据类型，并且尝试匹配能够将所述目的元素转换成解码数据格式的解码模块(146)，

b.在成功匹配解码模块(146)的情况下，将所述目的元素解码成解码数据格式，并且相应地更新补丁数据(170)和补丁指令(174)，

c.在可用的情况下将所述解码数据格式作为存档元素存储在目的存档结构(154)中，以及在不可用的情况下存储所述目的元素；

(iii)在适用的情况下使用存档模块(142)将所述目的存档结构(154)打包成存档；以及

21.根据权利要求20所述的压缩计算系统，还包括以下步骤：在应用所选择的压缩模块(141)或差分模块(160)之前，使用存档模块(142)将所述目的存档结构(154)打包成存档。