用于在打包模型的组件与包的物理表示的特征之间进行映射的方法和系统

摘要

提供了用于在打包模型的组件与包的物理表示的特征之间进行映射的方法和系统。仅作为示例，打包模型的组件可包括部分名、内容类型、部分内容、和/或生长启示。仅作为示例，包的物理表示可包括物理存留格式和/或例如基于网络的协议的各种传送。还提供了具有用于执行所公开的方法的计算机可执行指令的计算机可读介质以及被编程以执行所公开的方法的计算机。

说明书

技术领域

本发明涉及计算环境。特别地，本发明的实施例涉及在打包模型的组件与包的物理表示的特征之间进行映射的方法。仅作为示例，打包模型的组件可包括部分名、内容类型、部分的内容、和/或生长启示。仅作为示例，包的物理表示可包括物理存留格式和/或例如基于网络的协议等各种传送。

背景技术

通常，用于组织数据的打包模型与它们所直接对应的物理格式相关联。例如，用于打包ZIP档案的打包模型直接与ZIP文档的格式相关联从而能够容易地确定打包模型与物理格式之间的直接相关性。然而，如果有人希望将具有这种格式的包转换为例如基于网络的协议，这将极难实现。

相应地，定义独立于任何具体物理格式的抽象并可被映射到各种不同物理表示的打包模型将是合乎需要的。另外，用于将该抽象打包模型映射到多个物理表示中的每一个的方法将是有利的。

发明内容

本发明的实施例涉及在打包模型的组件与具有至少一个部分的包的物理表示的特征之间进行映射的方法。在一个实施例中，该方法包括：标识打包模型的一个或多个组件；标识物理表示中与所标识的一个或多个组件中的每一个相对应的特征；以及将打包模型的一个或多个组件映射到物理表示的相应特征。

本发明的又一些实施例涉及在打包模型的组件与具有至少一个部分的包的物理表示的特征之间进行映射的方法，组件包括至少一个部分名、部分内容类型、以及部分的内容。在一个实施例中，该方法包括：标识物理表示中与部分名、部分内容类型、以及部分的内容中的每一个相对应的特征并将部分名、部分内容类型、以及部分的内容中的每一个映射到物理表示中与它们相对应的特征。如果需要，打包模型的组件还可包括生长启示。在这样的实施例中，该方法还包括标识物理表示中与生长启示相对应的特征并将生长启示映射到所标识的特征。

此外，本发明的实施例还涉及具有用于执行在此所公开的方法的计算机可执行指令的计算机可读介质以及被编程以执行所公开的方法的计算机。

本发明的其它实施例涉及用于在打包模型的组件与具有至少一个部分的包的物理表示的特征之间进行映射的计算机系统。在一个实施例中，该计算机系统包括：用于标识打包模型的一个或多个组件的装置；用于标识物理表示中与所标识的一个或多个组件中的每一个相对应的特征的装置；以及用于将打包模型的一个或多个组件映射到物理表示的相应特征的装置。

附图说明

以下参照附图对本发明进行了具体说明，其中：

图1是在实现本发明时适于使用的一个示例性计算环境的框图；

图2是示出了根据本发明的一个实施例在打包模型的组件与包的物理表示的特征之间进行映射的方法的流程图；以及

图3是示出了在根据本发明的一个实施例在打包模型的组件与包的物理表示的特征之间进行映射时打开包的方法的流程图；

图4是示出了比图3中所示方法说明更为具体的用于在根据本发明的一个实施例在打包模型的组件与包的物理表示的特征之间进行映射时打开包的方法的流程图；

图5是示出了根据本发明的一个实施例将文件名映射到ASCII部分名的方法的流程图；

图6是示出了根据本发明的一个实施例从Unicode字符串获得部分的内容的方法的流程图；

图7是示出了用于根据本发明的一个实施例从Unicode字符串和内容类型创建部分的方法的流程图；

图8是示出了用于根据本发明的一个实施例基于指定Unicode字符串移除部分的方法流程图；

图9A-9C是(A)引用图像的标记、(B)使用简单排序的部分布局、以及(C)使用交织的部分布局的示意图；以及

图10是示出了将ASCII部分名标准化为标准化Unicode部分名的方法的流程图。

具体实施方式

为了满足法定要求本发明的主题在本申请中被说明为具有特异性。然而，说明本身并无意限制本专利的范围。相反，发明人构想所要求保护的主题还可结合其它现有或将来的技术以其它方法来体现从而包括与本文献中所说明的相类似的不同步骤或步骤组合。此外，虽然术语“步骤”和/或“块”在本申请中可用于表示所采用的方法的不同要素，然而除非明确地说明了个别步骤的顺序，否则这些术语不应该被解释为提出本申请中所公开的各个步骤之间的任何具体顺序。

本发明的实施例提供了用于在打包模型的组件与包的物理表示的特征之间进行映射的方法。仅作为示例，打包模型的组件可包括部分名、内容类型、部分的内容、和/或生长启示。仅作为示例，包的物理表示可包括物理存留格式和/或例如基于网络的协议的各种传送。

已简短地对本发明的概要进行了说明，以下说明本发明的一个示例性操作环境。

总体参照附图并且首先具体参照图1，其中相同附图标记标识各个附图中相同的组件，用于实现本发明的一个示例性操作环境被大体地显示和指定为计算系统环境100。计算系统环境100仅是合适计算环境的一个示例，并无意对本发明的使用或功能的范围暗示任何限制。也不应将计算环境100理解为具有与在示例性操作环境100中示出的任意一个组件或其组合相关的任何依存性或要求。

本发明可在许多其它的通用或专用计算系统环境或配置上运行。可适合用于本发明的公知的计算系统、环境、和/或配置的示例包括，但并不限于，个人计算机、服务器计算机、手持式或膝上型设备、多处理器系统、基于微处理器的系统、机顶盒、可编程电子消费品、网络PC、微型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等。

可在诸如程序模块等由计算机执行的计算机可执行指令的一般性环境背景中对本发明进行说明。一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件组件、数据结构等。本发明还可在任务由通过通信网络所链接的远程处理设备来执行的分布式计算环境中来实践。在分布式计算环境中，程序模块位于包括存储器存储设备的本地和远程计算机存储介质两者中。

参照图1，用于实现本发明的一个示例性系统包括计算机110形式的通用计算设备。计算机110的组件可包括，但并不限于，处理单元120、系统存储器130、以及将包括系统存储器在内的各种系统组件耦合至处理单元120的系统总线121。系统总线121可以是包括存储器总线或存储器控制器、外围总线、以及使用各种总线体系结构中任一总线体系结构的局部总线在内的诸多类型的总线结构中任一种。作为示例而非限制，这些体系结构包括工业标准体系结构(ISA)总线、微通道体系结构(MCA)总线、增强型ISA(EISA)总线、视频电子标准协会(VESA)局部总线、以及也被称为Mezzanine总线的外围部件互联(PCI)总线。

计算机110通常包括各种计算机可读介质。计算机可读介质可以是可由计算机110访问的任何可用介质并包括易失性和非易失性介质、可移动和不可移动介质。作为示例而非限制，计算机可读介质可包括计算机存储介质和通信介质。计算机存储介质包括以任何方法或技术实现的用于存储诸如计算机可读指令、数据结构、程序模块或其它数据等信息的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括，但并不限于，RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字通用盘(DVD)或其它光盘存储、磁带盒、磁带、磁盘存储或其它磁存储设备、或可用于存储所需信息并可由计算机110访问的任何其它介质。通信介质通常以诸如载波或其它传输机制之类的已调制数据信号的形式体现计算机可读指令、数据结构、程序模块或其它数据，并包括任何信息传递媒介。术语“已调制数据信号”是指这样一种信号，它的一个或多个特性已以在信号中编码信息的方式被设置或改变。作为示例而非限制，通信介质包括诸如有线网络或直接有线连接等有线介质，以及诸如声波、RF、红外及其它无线介质等无线介质。以上介质的任意组合也应被包括在计算机可读介质的范围内。

系统存储器130包括诸如只读存储器(ROM)131及随机存取存储器(RAM)132等易失性和/或非易失性存储器形式的计算机存储介质。含有有助于在诸如启动期间在计算机110内的各要素之间传送信息的基本例程的基本输入/输出系统(BIOS)133通常被存储在ROM 131中。RAM 132通常包含即刻可为处理单元120存取和/或当前正由处理单元120操作的数据和/或程序模块。作为示例而非限制，图1示出了操作系统134、应用程序135、其它程序模块136、以及程序数据137。

计算机110还可包括其它可移动/不可移动、易失性/非易失性计算机存储介质。仅是作为示例，图1示出了对不可移动、非易失性磁介质进行读取和写入的硬盘驱动器141，对可移动、非易失性磁盘152进行读取或写入的磁盘驱动器151，以及对诸如CD-ROM等可移动、非易失性光盘156或其它光学介质进行读取或写入的光盘驱动器155。可在该示例性操作环境中使用的其它可移动/不可移动、易失性/非易失性计算机存储介质包括，但并不限于，磁带盒、闪存卡、数字通用盘(DVD)、数字录像带、固态RAM、固态ROM等。硬盘驱动器141通常通过诸如接口140等不可移动存储器接口连接至系统总线121，而磁盘驱动器151和光盘驱动器155通常通过诸如接口150等可移动存储器接口连接至系统总线121。

以上讨论并在图1中示出的驱动器及其相关联的计算机存储介质提供了用于计算机110的计算机可读指令、数据结构、程序模块和其它数据的存储。在图1中，例如，硬盘驱动器141被示为存储操作系统144、应用程序145、其它程序模块146、以及程序数据147。需要注意的是，这些组件可以与操作系统134、应用程序135、其它程序136、以及程序数据137相同或不同。这里操作系统144、应用程序145、其它程序模块146、以及程序数据147被给予不同编号以说明它们至少是不同的副本。用户可通过例如键盘162、以及通常是指鼠标、跟踪球或触摸垫等定点设备161等输入设备向计算机110输入命令和信息。其它输入设备(未示出)可包括操话筒、纵杆、游戏垫、盘式卫星天线、扫描仪等。这些和其它输入设备经常通过耦合至系统总线的用户输入接口160连接至处理单元120，但也可通过诸如并行端口、游戏端口或通用串行总线(USB)等其它接口和总线结构来连接。监视器191或其它类型的显示器设备也通过诸如视频接口190等接口连接至系统总线121。除了监视器191，计算机还可包括诸如扬声器197和打印机196等可通过输出外围接口195连接的其它外围输出设备。

计算机110可在使用到诸如远程计算机180等一个或多个远程计算机的逻辑连接的联网环境中操作。远程计算机180可以是个人计算机、服务器、路由器、网络PC、对等设备或其它公共网络节点，并且虽然图1中仅示出了存储器存储设备181，但通常包括以上关于计算机110所描述的许多或所有要素。图1中绘制的逻辑连接包括局域网(LAN)171和广域网(WAN)173，并且还可包括其它网络。这些联网环境在办公室、企业范围的计算机网络、内联网和因特网中是很普遍的。

当在LAN联网环境中使用时，计算机110通过网络接口或适配器170连接至LAN 171。当在WAN联网环境中使用时，计算机110通常包括用于通过诸如因特网等WAN 173建立通信的调制解调器172或其它装置。可为内置或外置的调制解调器172可通过网络接口170或其它适当机制连接至系统总线121。在联网环境中，关于计算机110所描述的程序模块或其部分，可存储在远程存储器存储设备中。作为示例而非限制，图1示出了驻留于存储器设备181上的远程应用程序185。应该认识到的是，示出的网络连接是示例性的，也可使用在计算机间建立通信链接的其它装置。

虽然没有示出计算机110的许多其它内部组件，但是本领域的普通技术人员将认识到这些组件及其互联是公知的。相应地，无需结合本发明公开关于计算机110内部构造的额外细节。

当计算机110被打开或复位时，存储在ROM 131中的BIOS 133指示处理单元120将操作系统或其必要部分从硬盘驱动器141加载到RAM 132中。一旦被标为操作系统144的操作系统的复制部分被加载到RAM 132中，处理单元120就执行操作系统代码并将与操作系统134的用户界面相关联的视觉元素显示在监视器191上。通常，当用户打开一应用程序145时，程序代码和相关数据就从硬盘驱动器141及其必要部分被读取并被复制到RAM 132中，复制部分在此用附图标记135表示。

如上文所提到的，在一个实施例中，本发明涉及在打包模型的组件与包的物理表示的特征之间进行映射的方法。总体参照附图并且首先具体参照图2，所示流程图显示了用于根据本发明的一个实施例在打包模型的组件与包的物理表示的特征之间的进行映射的方法200。仅作为示例，打包模型的组件可包括，部分名、内容类型、部分的内容、和/或生长启示。仅作为示例，包的物理表示可包括，物理存留格式和/或例如基于网络的协议等各种传送。以下更为全面地说明了可在于此说明的方法中使用的一个示例性抽象打包模型。

首先，如块210所示，标识打包模型的一个或多个组件。随后，如块212所示，标识所希望的物理表示中与所标识的每个组件相对应的特征。一旦打包模型组件和相应的物理表示特征被标识，如块214所示，一个或多个组件就被映射到相应的特征。以下参照在此所述的一个示例性抽象打包模型对在打包模型组件与相应的物理表示特征之间进行映射的特定机制进行了更为全面的说明。

该示例性抽象打包模型指定了文档的部分(或其它类型的内容)被命名和关联的方法。在此所述的该示例性模型内的内容被保存在包内。包是保存相关联的部分的集合的逻辑实体。包的用途是将所有文档集合到一个便于程序员和终端用户利用的对象中。例如，保存了含有图片的文档的包可包含两部分：表示该文档的可扩展标记语言(XML)标记部分以及表示图片的另一部分。

除了内容，部分由公共属性和字节流组成。这与文件系统中的文件或超文本传输协议(HTTP)服务器上的资源相类似。公共属性包括部分名、存储在该部分中的内容的类型(内容类型)、部分的内容、以及任选的生长启示(所建议的为该部分在原处生长所预留的字节数目)。以下将对这些属性中的每一个进行更为全面的说明。

部分具有部分名。与在文件系统等中类似，部分名是分层的。部分名被分为各自表示该层次中的层的多个段。例如，部分名/hello/world/doc.xml包含三段：“hello”、“world”、以及“doc.xml”。段是可见的以形成树。这与文件系统中的情况相类似，其中树中的所有非叶节点都是文件夹而叶节点是包含内容的实际文件。名字树中的这些文件夹式的节点(即，非叶节点)起到类似于组织该包中的各部分的功能。需要注意的是，文件夹式的节点、或“文件夹”仅作为命名分层中的概念而存在。文件夹在打包模型中并不显式地表示，并且在打包模型中不存在文件夹目录。然而，物理表示可以具有文件夹的显示表示，并且该表示可采用分层目录的形式。

部分名所采用的确切形式取决于其中使用该名字的语境(例如，在统一资源标识符(URI)从包的外部引用部分时，被用来标记物理包格式的部分的数据等)。部分可以具有为标识包内部分的Unicode字符串的Unicode部分名。Unicode部分名正确地表示全部范围的国际字符并且是人类可读的。虽然Unicode部分名提供了国际通用的部分名的表示，但并不是在所有语境中都允许Unicode字符。特别地，部分通常使用URI被引用而URI不能包含Unicode字符。因此，Unicode字符必须被转换为可兼容的ASCII表示。由此，部分可选择性地具有ASCII部分名，ASCII部分名是使用IRI-URI方式的换码将国际字符ASCII编码的部分名。ASCII部分名被用来表示包语境中的各部分。

包内的部分必须被唯一地命名。为了确保正确地处理部分名中的国际字符，部分名的等价必须只在Unicode层确定。如果Unicode部分名是等价的，则它们表示包内的相同部分。Unicode部分名在它们的标准化形式是按字节相同时被认为是等价的。来自ASCII部分名的标准化可参照图10来理解。

图10是示出了将ASCII部分名标准化为标准化Unicode部分名，该方法被一般性地标为附图标记1000。首先，如块1012所示输入ASCII部分名。随后，如块1014所示，去换码所有的％HH三字符组，并且如块1016所示，执行到大写字母的简单变换。接着如块1018所示，执行到Unicode标准形式“C”的标准化。

通常部分会包含对其它部分的引用。作为简单的示例，设想包有两个部分：标记文件和图像。标记文件将希望具有对该图像的引用从而在该标记文件被处理时能够标识和定位相关联的图像。

上文提到的部分的第二个公共属性是内容类型。每个部分具有标识什么类型的内容被存储在部分中的内容类型。仅作为示例，内容类型可包括，图像/jpeg、以及应用/xml。内容类型是用有限的字符集适当构造的ASCII字符串。

上文提到的部分的第三个公共属性是部分本身的内容。该属性是无需说明的。

上文提到的部分的第四个公共属性是生长启示。在一些情形中，部分在其被放入包中后可能会被修改。取决于该修改的性质，该部分可能会需要生长。对于一些物理包格式，这可能是代价较大的操作，甚至可能会损坏其它良好有效地交织的包。理想地，可以在原处增大该部分而无需在包中移动许多字节。

为了有效支持这些情形，可以将生长启示与每个部分相关联。该启示标识该部分的创建者设想可能会对该部分能够生长同时保持原处更新的效能有用的一定数目的字节。在对特定的物理包格式的物理映射中，该信息可以用来预留允许该部分生长的空间。特别地，该数目仅是启示，而物理映射可选择不提供这样的预留空间或宽松地遵循该启示。在于此所述的示例性抽象打包模型中，生长启示是任选的并且在创建该部分时设置。

如之前所提到的，部分通常包含对包中其它部分以及包的外部资源的引用。然而，一般而言这些引用将以引用部分的内容类型所特有的方式即以应用特有编码的任意标记的方式被表示在该部分内部。

关系提供了用以表示源部分与目标资源之间的连接的种类的方法。关系使得这些连接直接“显露”而无需查看这些部分中的内容，所以它们独立于内容特有方案并且可更快地被分解。

关系还提供了第二个重要功能，即允许在不修改部分的情况下将它们相关联。有时该信息作为一种“注释”的形式，其中“被注释”的部分的内容类型没有定义附加给定信息的方法。最后，一些情形要求信息被附到一现有部分且明确地不能修改该部分——不管是该部分被加密且不能被解密还是该部分被数字签名且改变它将使签名无效等原因。

关系是用关系部分中的XML来表示的。作为物理表示中一个或多个关系的源的每个部分都有相关联的关系部分，其保存有该源部分的关系列表。关系还可以定向包外部的在某个绝对位置的资源和/或相对于包实体的当前位置被定位的资源。

关系还可采用包关系的形式。包关系被用来寻找包中已知的部分。包关系的源不是一个部分而是这一整个包。包关系可以使用适用于关系部分的命名约定来命名。

通常包会是可被称为容器的单个文件。这给终端用户例如一条便捷的途径来使用文档的所有组件块(例如，图像、字体、数据等)分配他们的文档。虽然包通常直接对应于单个文件，但并不必要总是如此。包是一个逻辑实体，可以例如以单个文件、以稀疏文件集合、以数据库、以网络连接上的短暂传输等各种方式来物理地表示。因此，所有的容器都保存有包但并不是所有的包都被存储在容器中。

包在于此所述的示例性抽象打包模型中使用访问方式、布局方式、以及通信方式的组合来生成或灭亡。仅作为示例，访问方式包括：流动消费，允许阅读程序在整个包到达之前开始处理部分；流动创建，允许写入程序无需预先知道将被写入的全部部分就可以开始将部分写入到包中；或同时的流动创建和消费，允许关于同一个包同时发生流动创建和流动消费。

仅作为示例，布局方式包括：简单排序，其中部分N的所有字节在包中出现于部分N+1的字节之前；或交织，其中多个部分的字节被交织。在上文参照图10A-10C对简单排序和交织进行了说明。

仅作为示例，通信方式包括：顺序传递，其中整个部分N在部分N+1之前传递给阅读程序；或随机访问传递，其中阅读程序可以请求不按顺序传递部分。在利用在此所述的示例性抽象打包模型映射时使用这三个类别的每一个中的至少一种方式。

在此所述的示例性抽象打包模型仅描述了抽象。包的物理表示通过根据本发明的方法的实施例将打包模型的组件映射到特定物理表示的特征来创建。因此，可在其中利用在此所述的方法的框架的结构和功能不仅由打包模型表示，也由物理模型来表示。物理模型定义写入程序和阅读程序使用包的各种方式。

物理模型通常基于三个组件：写入程序、阅读程序、以及它们之间的管道。管道将数据从写入程序传送到阅读程序。在许多情形中，管道只是阅读程序为从本地文件系统读取包所作出的应用程序接口(API)调用。这被称为直接访问。然而阅读程序和写入程序通常必须通过某种协议来相互通信。该通信可以例如跨过程边界或在服务器与台式计算机之间发生。这被称为联网访问。

所有物理包都具有部分的集合。这些部分可以两种方式之一来布局：简单排序和交织。在简单排序时，包中的各部分以定义的顺序来布局。当这种包以纯粹线性的方式被传递时，从包中的第一个字节开始直到最后一个字节，第一部分的所有字节先到达，然后是第二部分的所有字节，依此类推。在交织布局时，多个部分的字节被交织，允许在某种情形中有最佳性能。得益于交织较多的两种情形是多媒体回放(例如，同时传递视频和音频)以及内联资源引用(例如，在标记文件中间对图像的引用)。

交织是通过用于组织被交织部分的内容的特殊约定来处理的。通过将多个部分分裂为多个块并交织这些块，可能达到理想的交织结果——同时仍然能够容易地重构原始较大的部分。

为了理解如何交织作业，设想涉及两个部分的简单示例(参照图9A)：markup(标记)/page(页面).xml以及images(图像)/picture(图片).jpeg。markup/page.xml描述页面中的内容并且该页面中间是对应该出现在该页面上的图像(images/picture.jpeg)的引用。为了理解交织为何是有价值的，考虑这些部分使用简单排序将被如何排序在包中(图9B)。正在处理该包(并且正在顺序地接收字节)的阅读程序将不能显示图片直到接收到所有markup/page.xml部分以及images/picture.jpeg。在一些情况下(例如，小型或简单包或较快的通信链接)，这可能不是问题。然而在其它情况下(例如，如果markup/page.xml非常大或者通信链接非常慢)，需要读取从头至尾所有markup/page.xml部分以获得图像将导致不可接受的性能或对阅读程序系统提出不合理的存储器要求。

为了更接近理想性能，如果能够将markup/page.xml部分分离开并在其中间即紧靠图片被引用处之后插入images/picture.jpeg部分将是有利的。这将允许阅读程序能较早地开始处理该图像，即一遇到引用，紧接着就是图像数据。这将产生如图9C中所示的包布局。

由于性能上的益处，支持交织的物理包是有益的。然而，取决于使用的物理包的种类，交织可能被支持也可能不被支持。此外，不同的物理包可能处理交织的内部表示有所不同。不管物理包如何处理交织，物理文件中被分成多个块的部分仍然是一个逻辑部分；这些块本身不是部分。

物理包格式可以被描述为从打包模型的组件到特定物理表示的特征的映射。打包模型，例如在此所述的示例性抽象打包模型，通常不指定出于存档、分布或假脱机目的应使用哪种物理包格式。仅是逻辑结构被指定。包可以通过稀疏文件的集合、.ZIP文件档案、OLD复合文件、或其它格式来“物理地”体现。然而，所选格式必须被定向消费设备或该设备的驱动器所支持以便成功映射。

有许多其特征部分地与该示例性抽象打包模型组件匹配的物理包格式。在定义从该示例性抽象打包模型到这些存储格式的映射时，利用该示例性抽象打包模型与物理包介质之间的任何相似性、同时使用提供物理包介质中不是固有存在的其它能力的映射层是理想的。例如，一些物理包格式可将个别部分作为个别文件存储在文件系统中。在这种物理格式中，将许多部分名直接映射到相同的物理文件名是理想的。(需要注意的是，使用非有效文件系统文件名的字符的部分名可能需要某种换码机制。)

在许多情形中，不同物理包格式的设计者可能会遇到一个常见的映射问题。常见映射问题的两个示例发生在将任意内容类型与部分相关联时以及支持交织布局方式时。以下说明的是设计者可选择实现的针对该公共映射问题的示例性方案。本领域的普通技术人员将会理解，该方案仅是示例性的并无意以任何方式限制本发明的范围。

利用在此所述的示例性抽象打包模型的每个物理包格式映射都将定义用于将内容类型与部分相关联的机制。一些物理包格式具有固有的用以表示内容类型的机制(例如，多用途因特网邮件扩展(MIME)中的内容类型标头)。对于这种物理包，映射使用固有机制来表示部分的内容类型是理想的。

对于所有其它物理包格式，需要一些其它机制来表示内容类型。用以在这些包中表示内容类型的一种机制是通过在包中包括特别命名被称为内容类型流的XML流。通过定义，该流不是部分，因此其本身在该示例性抽象打包模型中不可寻址。(然而，它可以使用用以交织部分的相同机制被交织在物理包中。)

内容类型流包含具有顶层“类型”元素、以及一个或多个“默认”和“超驰”子元素的XML。默认子元素定义从部分名的扩展名(例如，文件扩展名)到内容类型的默认映射。这利用了文件扩展名通常(并不总是)对应于内容类型这一事实。超驰子元素被用于指定关于没有被默认映射涵盖或与默认映射不一致的部分的内容类型。如果需要，包写入程序可使用默认子元素来降低每部分超驰子元素的数目。

默认子元素包括部分名字扩展名以及指示任何匹配部分的内容类型的内容类型(除非被超驰子元素所超驰，这将在下文更为全面地描述)。默认的子元素匹配其名字以跟有属性值的句点结束的任何部分。超驰子元素包括部分名URI以及指示匹配部分的内容类型的内容类型。超驰子元素匹配其名字等于属性值的部分。

针对包中的每个部分，内容类型流包含一个匹配默认子元素、一个匹配超驰子元素、或者匹配默认子元素和匹配超驰子元素两者(在超驰子元素优先的情形中)。任何给定的扩展名至多可以有一个默认子元素并且任何给定的部分名至多可以有一个超驰子元素。

默认和超驰子元素在内容类型流中的顺序并不重要。然而，在经交织的包中，如将在下文更为全面地描述的，默认和超驰子元素在物理包中被写于它们所对应的(诸)部分的前面。默认的内容类型映射可以被定义在内容类型流中即使当前现有部分并不使用它们。

如先前所提到的，除了将任意内容类型与部分相匹配之外，在支持交织布局方式时还发生另一常见映射问题。并不是所有物理包都固有地支持各部分的数据流的交织。对于支持流消费的布局情形，往任何这种物理包的映射使用在此所述的允许部分交织的通用机制是理想的。

现在所述的交织机制将一个部分的数据流分为随后可与其它部分的块交织或与整个部分交织的多个块。如将在下文更为全面地描述的，各个块使用来自该部分名的唯一的映射被命名。这使得阅读程序能够将这些块以它们原始的顺序连结起来，形成该部分的数据流。

部分的各个块仅存在于物理映射中，而在打包模型中并不可寻址。

一个单独的部分经交织地或者不经交织地被存储。对于一个单独的部分混合交织和未交织在于此所述的示例性抽象模型中是无效的。

为给定部分派生块名的语法如下：

piece_name＝part_name“/”“[“1*digit“]”[“.last”]“.piece”

由以上语法生成的piece_name(块名)有许多要求。首先，块号必须以零开始，并且必须是非负的、连续十进制正数。块号不能左端补零。其次，部分的块集的最后一块在块名中必须在“piece”之前包含“last”。第三，块名是在往物理包中的名字映射之前从逻辑部分的名字生成的。以及第四，虽然并不需要以它们本来的顺序存储各块，但能提供最佳效率是理想的。

如果需要，包含经交织的(经分块的)部分的物理包还可包含未交织的(一块)部分。

为了根据经交织的块创建原始数据，消费应用按块号升序来排序各个块。必须获得并且没有间隙的排序从块[0].piece到[N].last.piece所有所需要的块。消费应用然后可以连接包含在每个块中的二进制数据。

示例

以下是以上所述的示例性抽象打包模型，与诸多物理表示即ZIP文档以及可从华盛顿州雷德蒙市的微软公司得到的WINDOWS文件系统中的稀疏文件中的数据项之间的具体映射的示例。此外，也提供了在映射时可执行的各种操作的示例，即打开包、基于指定的Unicode字符串获得部分、基于指定的Unicode字符串和内容类型创建部分以及基于指定的Unicode字符串删除部分。本领域的普通技术人员可以懂得和理解的是这些示例仅是示例性的，而非旨以任何方式限制本发明的范围。

在以物理格式存储时，部分可以被表示为一个或许多数据项。用以标识这些数据项的名字可以有不同的格式，但要遵循在此所述的规则以使其可靠地被映射到其相应部分。

每个物理映射都支持包中的部分与作为物理实体存储的部分之间的一对一映射。精确的物理映射操作是物理适配器与实体所特有的。另外，每个物理映射支持包中的部分与作为物理实体存储的部分之间的一对多映射以支持交织情形。每个物理映射还保证存储的不同实体在被映射到包语境时没有等价的部分名并能从该物理实体得到该部分名。

示例1

映射至ZIP文档

ZIP档案包含ZIP档案数据项。ZIP档案数据项通常在该档案被解压缩时变为文件。当用户解压缩基于ZIP的包时，用户将看到文件系统中有组织的文件和文件夹集，它们分别大致地反映了包中的部分以及它们的分层命名结构。即，逻辑部分组件物理上由ZIP档案数据项来表示。逻辑部分名组件通常被存储在ZIP中央目录的档案数据项标头中。如将在下文更为全面地描述的，在ASCII部分名与ZIP档案数据项名字之间映射可使用约定规则。逻辑部分内容类型组件物理上由包含标识每个部分的内容类型的XML的ZIP档案数据项来表示。并且，逻辑成长启示组件在物理上由在档案数据项之前保存在本地标头中的ZIP附加字段中的填充来表示。

在ZIP档案中，与部分相关联的数据被表示为一个或多个档案数据项。未交织的部分被存储为单个ZIP档案数据项。在经过交织时，部分使用上述方法被表示为一个或多个块。各个块使用特定模式来命名，以使得能够从其组成块重建整个部分。每个块作为单个ZIP档案数据项被存储在ZIP档案内。

在ZIP档案中，表示数据项的比特片被连续地存储。ZIP数据项序列可以有目的地排序在ZIP档案中以使得有效组织部分数据(例如，为了实现正确和/或最佳交织)。

为了各种操作，可能需要将ASCII部分名转换为ZIP档案数据项名。为此，在ASCII部分名开头的前端“/”字符被移除。或者如果必须将ZIP档案数据项名转换为ASCII部分名，可在ASCII部分名的开头添加“/”。

ZIP文档中数据项名、附加字段、以及注解字段的组合长度不能超过65,535个字节。相应地，取决于附加字段和注解字段的大小，存储在ZIP档案中的部分名被限制在小于65,535个字节的某一长度。

另外，在创建可存储在ZIP文件中的部分名时需要适应文件系统的限制。虽然对于不同的文件系统有不同的限制，然而这些限制中的两个示例包括：(A)对于WINDOWS文件系统，字符“*”和“:”无效，所以以这些字符命名的部分不能成功解压缩，以及(B)对于WINDOWS文件系统，许多程序只能处理小于256个字符长的全文件名路径(包括路径)；一旦被解压缩名字长于此的部分则不能正确运行。

在此所述的示例性抽象打包模型中的部分内容类型被用于将内容类型与部分数据相关联。在ZIP档案中，内容类型信息使用将该信息存储在单个XML流中的映射模式来存储。内容类型数据被存储在名为“[Content_Types].xml”的档案数据项中。该档案数据项包含将ASCII部分名映射至内容类型的XML数据。该档案数据项不是部分，因此没有其自己的内容类型。“[Content_Types].xml”数据项可以被分为多个数据项并且随后通过使用上述的“Piece”命名模式来交织。

在ZIP档案中，生长启示被用来预留可被用于在原处生长档案数据项的额外字节。填充被存储在具有以下结构的“附加字段”中：[2字节]标头ID、[2字节]附加字段的长度、[2字节]签名(为了验证)、[2字节]填充初始值、以及[填充长度]<填充>。这些字段的每个的值如下：ID＝A220、长度＝签名长度(2字节)+填充初始值长度(2字节)+填充长度(可变)、签名＝A208、填充初始值＝在创建数据项时由调用程序设置的十六进制数字、以及<填充>用NULL字符填充。

包的交织顺序可能会被诸如使用ZIP效用来对包进行部分的添加或移除等特定操作所干扰。当消费程序将经交织的包标识为不再排序良好时，消费程序就会放弃消费、生成错误消息、回到随机访问模式并等待整个包到达。

为了标识对先前排序良好的经交织的包的干扰，第一个ZIP档案数据项的ZIP标头EXTRA字段可被生成程序用来存储“交织标头”。

EXTRA标头将ZIP档案标识为经交织的档案并且可以具有关于生成程序所作的假设的额外信息，例如该设备的工作存储器大小等。对于每个接着的档案数据项，生成程序添加包含连续序列号的ZIP标头EXTRA字段。

对于具有存储在EXTRA字段中的序列号的经交织的包的消费程序，可采取许多步骤来确保该包保持排序良好。首先，可以检查第一个档案数据项的EXTRA字段。如果其指示交织，则可以检查其它信息以保护生成程序关于消费程序作出的正确假设。接着，对于每个之后的档案数据项，可检查存储在EXTRA字段中的序列号。如果序列号丢失，则可作出到随机访问模式的切换(虽然必须等待整个包到达)。如果序列号顺序错误，则可继续接收流动模式中的数据项并可以尝试填充序列号的间隙。一旦填充了这些间隙，就可继续处理。如果仍有间隙则其自动默认随机访问模式。

示例2

往WINDOWS文件系统中的稀疏文件的映射

为了更好地理解如何将示例性抽象打包模型的元素映射到物理表示，考虑将包表示为WINDOWS文件系统中的稀疏文件的集合的基本情形。示例性包中的每个部分都将被包含在单独的文件(流)中。示例性抽象打包模型中的每个部分名对应于文件名。

即，部分逻辑组件对应于物理表示的(诸)文件。部分名逻辑组件对应于包括路径在内的物理表示的文件名。部分内容类型逻辑组件对应于包含表示每个部分的内容类型的XML的文件。生长启示逻辑组件可以忽略。

为了将ASCII部分名转换为WINDOWS文件系统名，第一个字符(会是“/”)被移除。随后，所有的“/”字符都被转换为“\”字符。接着，冒号和星号字符通过精确地使用两个十六进制数字被换码。冒号字符被转换为序列“^3a”而星号字符被转换为序列“^2a”。例如，部分名/a:b/c/d*xaml变为以下文件名：a^3ab\c\d^2a.xaml。

为了执行相反映射，所有的“\”被转换为“/”。在字符串的开头添加“/”。冒号和星号字符去换码(即，序列“^3a”被转换为冒号字符(“:”)而序列“^2a”被转换为星号字符(“*”))。

当映射到稀疏文件时，经交织的部分与未交织部分没有任何区别地被存储。换言之，每个部分都被存储为一个文件。

示例3

打开包

当从在此所述的示例性抽象打包模型映射至物理表示时，各种操作被执行。这样操作中的一个是打开包。参照图3，示出了显示用于根据本发明的一个实施例打开包的一个示例性方法300的流程图。开始，如块310所示，物理存储/表示(例如，ZIP档案)被打开。随后，如块312所示，获得能够被转换为有效ASCII部分名的文件名并排除不能被转换的那些。接着，如块314所示，用由此获得的ASCII部分名建立内存储器数据结构。参照图4对该方法进行了更为具体的说明。或者，如果需要也可以存储标准的Unicode字符串本身。

现在参照图4，所示流程图示出了用于当根据本发明的实施例在于此所述的示例性抽象打包模型的组件与包的物理表示的特征之间进行映射时打开包的方法400，其比图3的方法300说明得更为具体。开始，如块410所示，物理存储/表示(例如，ZIP档案)被打开。随后，如块412所示，获得物理存储中文件名的初始集。针对经交织的文件名，获得与经交织的文件名集相对应的实际文件名。接着，判定是否可以执行文件名初始集中的每个文件名往ASCII部分名的映射。这在块414中示出。该判定是针对初始集中的每个文件名逐个作出的。如果不能执行映射，则如块416所示，排除该个别文件名从而不作进一步处理。

然而如果能够执行初始集中文件名往ASCII部分名的映射，则接着如块418所示判定是否有与该ASCII部分名相关联的内容类型。如块416所示，如果没有与该ASCII部分名相关联的内容类型，则该文件名被排除从而不作进一步处理。

如块420所示，如果一内容类型与该ASCII部分名相关联，则该文件名被认为是能够被转换为有效ASCII部分名的文件名，并且如块422所示标识该内容类型。在图5的流程图中示出了用于根据本发明的实施例将文件名映射到ASCII部分名的方法500。

开始，如块510所示，输入Unicode文件名。随后，如块512所示，该Unicode字符串被转换成UTF-8八位组序列。接着，每个非ASCII对象被转换成％HH形式的三字符序列，其中HH是八位组值的十六进制标示。这在块514中示出。随后，如块516所示，获得作为结果的ASCII字符串。

在一些实例中，能够被转换为有效ASCII部分名的文件名可以作为ASCII字符串直接被获得并被输入以转换为ASCII部分名。这在块518中示出。

如块520所示，不管ASCII字符串是从经标准化的Unicode字符串获得的还是输入的，对应于字符“/”、“\”以及“.”的任何经换码编码的三元组都将被去换码。随后，如块522所示，所有的“\”字符都被转换为“/”字符。接着如块524所示，应用路径压缩。

在路径压缩过程中，所有出现的“./”，其中“.”是完整路径段的，都被从缓冲字符串中移除。如果缓冲字符串以任何“.”字符结尾，则将它们移除。此外，所有出现的“<段>/../”，其中<段>是不等于“..”的完整路径段的，都被从缓冲字符串移除。这些路径段的移除是迭代地执行的，在每次迭代过程中移除最左面的匹配模式直到没有匹配模式留下。接着，如果缓冲字符串以“<段>/..”结尾，其中<段>是不等于“..”的完整路径段，则该“<段>/..”被移除。随后，对应于未保留的字符的这些经换码编码的三元组被去换码。

当ASCII部分名针对等效进行测试时，首先将名字转换为Unicode部分名。如果所得的Unicode部分名是等价的，则ASCII部分名被认为是等价的。当利用在此所述的示例性抽象打包模型时ASCII部分名不应该有重复。

随后，如块526所示，获得作为结果的ASCII部分名。

参照图4，一旦获得每个经标准化的Unicode字符串的ASCII部分名，则如块424所示，就用该ASCII部分名及相关联的内容类型建立内存储器数据结构。为了成功地打开包，必须有具有ASCII部分名和内容类型的内存储器数据结构。

示例4

从Unicode字符串获得部分的内容

参照图6，显示用于获得ASCII部分名并在其后从Unicode字符串获得该部分的内容的方法流程图并示出并被概括地标为附图标记600。开始，如块610所示，Unicode字符串被转换为部分名的标准Unicode字符串。随后，判定内存储器数据结构中是否包含一等价名。该判定在块612示出。如果等价名不在内存储器数据结构中，则如块614所示不能检索到该部分的内容。

然而如果等价的名字在内存储器数据结构中，则如块616所示，返回该部分。随后，如块618所示，可获得该部分的内容。

示例5

根据Unicode字符串和内容类型创建部分

参照图7，示出了用于根据本发明的一个实施例从Unicode字符串和内容类型创建部分的方法700。开始，如块710所示，Unicode字符串被转换为部分名的标准化Unicode字符串(参照图5)。随后，如块714所示，在内存储器数据结构中搜索等价部分名，并判定等价名是否在内存储器数据结构中。这在块716中示出。如果等价名在内存储器数据结构中，则不能创建该部分(因为不允许重复的等价部分名)。

然而，如果等价名不在内存储器数据结构中，如块720所示(参照图5)该Unicode字符串被用来创建ASCII部分名。随后，如块722所示，该ASCII部分名被转换为物理包文件名。接着用该物理包文件名创建包文件。这在块724中示出。需要注意的是，在该过程中并没有利用标准化Unicode字符串从而保持如在基本文件格式中指定的外壳。对于交织的情形，用经交织的名字创建文件。

随后，如块726所示，从该ASCII部分名获得文件名扩展名，并判定是否已为该文件名扩展名注册了指定内容类型。这在块728示出。如果还没有为该文件名扩展名注册指定内容类型，则在对应于该文件扩展名的内容类型流中创建默认条目。或者，如果有一默认条目但并不匹配所指定的内容类型，则在内容类型流中创建超驰条目。这在块730示出。

一旦创建了默认或超驰条目，或者如果已为该文件扩展名注册了指定内容类型，则如块732所示，具有ASCII部分名的新部分被添加到内存储器数据结构中。随后，如块734所示，新添加的部分被返回给用户。

示例6

根据指定Unicode字符串移除部分

参照图8，显示用于根据本发明的一个实施例基于指定Unicode字符串移除部分的方法800的流程图被示出。开始，如块810所示，Unicode字符串被转换为部分名的标准化Unicode字符串(参照图5)。随后，如块814所示，在内存储器数据结构中搜索等价名，并判定等价名是否在内存储器数据结构中。该判定在块816示出。如果等价名不在内存储器数据结构中，如块818所示，并不需要移除。

然而如果等价名在内存储器数据结构中，如块820所示，相应的(诸)文件从包中被移除。随后，如块822所示，相应条目从内存储器数据结构被移除。接着，如块824所示，搜索对应于该ASCII部分名的内容类型流的超驰条目，并如块826所示判定该ASCII部分名是否在超驰条目中。

如果该ASCII部分名不在超驰条目中，如块828所示，操作结束。然而如果该ASCII部分名在超驰条目中，则如块830所示从超驰条目中移除该ASCII部分名。

能够理解的是，本发明的实施例提供了在打包模型的组件与包的物理表示的特征之间进行映射的方法。仅作为示例，打包模型的组件可包括部分名、内容类型、部分的内容、和/或生长启示。仅作为示例，包的物理表示可包括物理存续格式和/或例如基于网络的协议等各种传送。

关于在各方面都旨在为说明性而非限制性的特定实施例对本发明进行了说明。本发明相关的不背离其范围的替换实施例对本领域的普通技术人员将是显而易见的。

从上述内容可以看出，在本系统和方法显而易见和固有的优点之外，本发明还非常适用于达到上述目标和目的。应该理解的是，某些特征和子组合在不引用其它特征和子组合的情况下也是具有实用型并且可被使用的。这是权利要求的范围所预期的并在其范围之内。