@zhongdao
2019-12-19T18:42:14.000000Z
字数 54658
阅读 1592
未分类
Michael 迈克尔 Nahas
Peter Clements
彼得 · 克莱门茨
Paul Nettle
保罗 · 内特尔
Ryan Gallagher
瑞安 · 加拉格尔
May 11th, 2003
2003年5月11日
Copyright © 2003 The Authors
版权所有2003作者
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". 允许复制,分发和 / 或修改本文件的条款的 GNU自由文档许可证,版本1.2或任何以后的版本由自由软件基金会出版; 没有不变部分,没有封面文本,没有封底文本。 许可证的副本包括在题为"GNU自由文档许可证"的章节中
Revision History 修订历史 | |
---|---|
Revision 1.0 修订版1.0 | October 14th, 2001 2001年10月14日 |
Related specification, Inspiration 相关规格,灵感 | |
Revision 2.0 修订版2.0 | May 11th, 2003 2003年5月11日 |
New Specification, Initial publication and formatting. 新规范,初始发布和格式 |
Table of Contents
Abstract
摘要
Based on Parity Volume Set Specification 1.0 [2001-10-14] by Stefan Wehlus and others.
基于 Stefan Wehlus 等人的奇偶卷集规范1.0[2001-10-14]。
This document describes a file format for storing redundant data for a set of files.
本文档描述用于存储一组文件的冗余数据的文件格式。
In operation, a user will select a set of files from which the redundant data is to be made. These are known as input files and the set of them is known as the recovery set. The user will provide these to a program which generates file(s) that match the specification in this document. The program is known as a PAR 2.0 Client or client for short, and the generated files are known as PAR 2.0 files or PAR files. If the files in the recovery set ever get damaged (e.g. when they are transmitted or stored on a faulty disk) the client can read the damaged input files, read the (possibly damaged) PAR files, and regenerate the original input files. Of course, not all damages can be repaired, but many can.
在操作中,用户将选择一组要从中产生冗余数据的文件。 这些文件称为输入文件,其中的一组文件称为恢复集。 用户将这些提供给程序,该程序将生成与本文档中的规范相匹配的文件。 该程序简称为 PAR 2.0客户机或客户机,生成的文件称为 PAR 2.0文件或 PAR 文件。 如果恢复集中的文件损坏(例如,当它们被传输或存储在错误的磁盘上时) ,客户机可以读取损坏的输入文件,读取(可能损坏的) PAR 文件,并重新生成原始输入文件。 当然,不是所有的损坏都可以修复,但是很多都可以。
A user can also name some input files that are not to be recovered if damaged. These input files are known as the non-recovery set. This feature is in the spec to keep the same functionality as PAR 1.0.
用户还可以命名一些在损坏时不能恢复的输入文件。 这些输入文件称为非恢复集。 这个特性在规范中保持了与 PAR 1.0相同的功能。
The redundant data in the PAR files is computed using Reed-Solomon codes. These codes can take a set of equal-sized blocks of data and produce a number of same-sized recovery blocks. Then, given a subset of original data blocks and some recovery block, it is possible to reproduce the original data blocks. Reed-Solomon codes can do this recovery as long as the number of missing data blocks does not out number the recovery blocks. The design of the Reed-Solomon codes in this spec is based on James S. Plank's tech report at U. of Tennessee entitled A tutorial on Reed-Solomon coding for fault-tolerance in RAID-like systems. The tech report contains an error, so the design is changed slightly to fix the problem. PAR 2.0 uses a 16-bit Reed-Solomon code and can support 32768 blocks.
Par 文件中的冗余数据是使用里所码计算的。 这些代码可以获取一组相同大小的数据块,并生成若干相同大小的恢复块。 然后,给定原始数据块的子集和一些恢复块,就可以重新生成原始数据块。 只要丢失的数据块数量不超过恢复块的数量,里所码可以执行此恢复。 在这个规范中,里所码的设计是基于 James s. Plank 在田纳西大学的技术报告,题为关于 Reed-Solomon 编码在类 raid- 系统中的容错性的教程。 技术报告中包含一个错误,因此设计被稍微改动以修复问题。 Par 2.0使用16位的 Reed-Solomon 代码,可以支持32768块。
The equal-sized blocks for the Reed-Solomon codes come from slices of the input files in the recovery set. The slices are consecutive equal-sized chunks of each file. If a file does not fill out the chunk, i.e. it ends mid-slice, the rest of the slice is treated as if it is padded with zero bytes.
相同大小的恢复里所码块来自恢复集中的输入文件片。 切片是每个文件的连续的相同大小的块。 如果一个文件没有填充这个块,也就是说它结束于切片的中间部分,那么这个切片的其余部分将被当作是用零字节填充的。
The PAR 2.0 file itself is made of packets - self-contained parts with their own checksum. This design prevents damage to one part of the file from making the whole file unusable.
Par 2.0文件本身是由包自包含的部分组成的,它们具有自己的校验和。 这种设计可以防止损坏文件的一部分,使整个文件无法使用。
Packets have a type and each type of packet serves a different purpose. One describes a file. Another contains the checksums of the slices in a file. Another states which files are in the recovery set and which files are in the non-recovery set. And yet another contains a recovery slice - the recovery data produced by the Reed-Solomon code.
数据包有一种类型,每种类型的数据包有不同的用途。 一个描述了一个文件。 另一个包含文件中片的校验和。 另一个状态是哪些文件在恢复集中,哪些文件在非恢复集中。 还有一个包含恢复切片——由 Reed-Solomon 代码产生的恢复数据。
A PAR 2.0 file is only required to contain 1 specific packet - the packet that identifies the type of client that created the file. This way, if clients are creating files that don't match the specification in some way, they can be tracked down.
Par 2.0文件只需包含1个特定的数据包——这个数据包标识创建该文件的客户端类型。 这样,如果客户机创建的文件在某些方面与规范不匹配,就可以跟踪它们。
The packets for a recovery set and non-recovery set can be broken into multiple files. Files can contain duplicate packets - in fact, this is recommended for vital packets, such as the ones that describe the input files and the one that states which files are in the recovery set. Packets can appear in any order in a file.
恢复集和非恢复集的数据包可以分成多个文件。 文件可以包含重复的数据包——事实上,对于重要的数据包,比如描述输入文件的数据包,以及声明哪些文件在恢复集中的数据包,推荐使用这种方法。 数据包可以以任何顺序出现在文件中。
There are a number of conventions used in the design of this specification.
在本规范的设计中使用了许多约定。
The data is 4-byte aligned. That is, every field starts on an index in the file which is congruent to zero, modulus 4. (I.e., address % 4 == 0) This is because some memory systems function faster if 32-bit quantities are 4-byte aligned. It should be noted that a file could be corrupted (bytes inserted or deleted) to throw off the alignment. The spec is designed so that future versions could be 8-byte aligned.
数据是4字节对齐的。 也就是说,每个字段都从文件中的一个索引开始,该索引与0,模4全等。 (例如,地址% 40)这是因为如果32位的数量是4字节对齐的,那么一些内存系统运行得更快。 应该注意的是,文件可能已损坏(插入或删除字节) ,以引发对齐。 规范的设计使得未来的版本可以是8字节对齐的。
All integers in this version of the spec are unsigned integers of either 4 or 8 bytes in length.
该版本规范中的所有整数都是长度为4或8字节的无符号整数。
Strings are not null-terminated. This is to prevent hackers from using stack-overflow attacks. In order to make a string 4-byte aligned, 1 to 3 zero bytes may be appended. (2 bytes in the case of Unicode strings.) If an N-byte field contains an array, a null-terminated string can be created by copying the N-byte field into a character array of length N+1 and then the setting the N+1 character to '\0'.
字符串不是以空结尾的。 这是为了防止黑客使用堆栈溢出攻击。 为了使字符串4字节对齐,可以添加1到3个零字节。 (Unicode 字符串为2字节) 如果一个 n 字节字段包含一个数组,那么通过将 n 字节字段复制到一个长度为 n + 1的字符数组中,然后将 n + 1字符设置为'0',就可以创建一个空终止字符串字符集。
The lengths of arrays and strings are often implicit. For example, if a region is known to be 32 bytes and that region contains an 8-byte integer and a string, then the string is known to take up 24 bytes. The string is then at least 21 bytes in length, since the 24 bytes contains 0 to 3 bytes of null padding at the end.
数组和字符串的长度通常是隐式的。 例如,如果一个区域已知为32个字节,而该区域包含一个8字节的整数和一个字符串,则该字符串已知占用24个字节。 字符串的长度至少为21个字节,因为这24个字节在末尾包含0到3个字节的空白填充。
All strings in the "core" spec are ASCII. This was chosen because Unicode is not sufficiently supported by tools. There exist optional portions of the spec that do support Unicode strings.
"core"规范中的所有字符串都是 ASCII。 之所以选择这个选项,是因为 Unicode 没有得到工具的充分支持。 规范中有一些可选的部分支持 Unicode 字符串。
The lengths of files and parts of files are determined by 8-byte integers. This is to support OSes that can handle files longer than 4GB.
文件和文件部分的长度由8字节的整数决定。 这是为了支持可以处理超过4gb 的文件的操作系统。
All integers are Intel-endian. (That is, little endian.)
所有的整数都是 Intel-endian。 (也就是说,little endian。)
The recovery set (and non-recovery set, if present) is identified by a 16-byte value known as the Recovery Set ID. Every part of the PAR file that affects a recovery set contains the recovery set ID. In this 2.0 version, the Recovery Set ID is calculated as an MD5 Hash of certain values. The way of calculating this value could change in future versions.
恢复集(如果存在非恢复集,则为非恢复集)由一个名为 Recovery Set ID 的16字节值标识。 Par 文件中影响恢复集的每个部分都包含恢复集 ID。 在这个2.0版本中,恢复集 ID 被计算为某些值的 MD5哈希。 在未来的版本中,计算这个值的方法可能会改变。
Files are also identified by a 16-byte value. In this 2.0 Version, it is an MD5 Hash of their name, length and the MD5 Hash of their first 16kB. The way of calculating this value could change in future versions.
文件也由一个16字节的值标识。 在这个2.0版本中,它是一个 MD5散列,其名称、长度和前16kB 的 MD5散列。 在未来的版本中,计算这个值的方法可能会改变。
Every byte of a PAR file is specified. There are no places to throw junk bytes that can be any value. Padding, where needed, is specified to be zero bytes. The order of items in all arrays is specified.
指定 PAR 文件的每个字节。 没有可以抛出任何值的垃圾字节的位置。 需要填充的地方被指定为零字节。 指定所有数组中项的顺序。
The specification is designed so that if two clients generate a packet with the same parameters, the packets are identical (except for client-identifying or client-specific packets). Thus, client writers can compare the output of their program against the reference implementation by comparing packets byte-for-byte.
该规范的设计目的是,如果两个客户机生成具有相同参数的数据包,那么这些数据包是相同的(客户机识别或客户机特定的数据包除外)。 因此,客户机编写器可以通过逐字节比较数据包,将其程序的输出与引用实现进行比较。
A PAR 2.0 file consists of a sequence of "packets". A packet has a fixed sized header and a variable length body. The packet header contains a checksum for the packet - if the packet is damaged, the packet is ignored. The packet header also contains a packet-type. If the client does not understand the packet type, the packet is ignored. To be compliant with this specification, a client must understand the "core" set of packets. Client may process the optional packets or create their own application-specific packets.
Par 2.0文件由一系列"数据包"组成。 一个数据包有一个固定大小的头和一个可变长度的主体。 数据包报头包含数据包的校验和——如果数据包损坏,数据包将被忽略。 包头还包含一个包类型。 如果客户端不理解数据包类型,则忽略该数据包。 为了符合此规范,客户机必须理解"核心"数据包集。 客户端可以处理可选数据包或创建自己的应用程序特定的数据包。
The packet header is:
数据包头是:
Table 87. Packet Header
表87。 包头
Length (bytes) 长度(字节) | Type 类型 | Description 描述 |
---|---|---|
8 | byte[8] 字节[8] | Magic sequence. Used to quickly identify location of packets. Value = {'P', 'A', 'R', '2', '\0', 'P', 'K', 'T'} (ASCII) 魔法序列。 用于快速识别数据包的位置。 值{'p','a','r','2','0','p','k','t'}(ASCII) |
8 | 8-byte uint 8字节 uint | Length of the entire packet. Must be multiple of 4. (NB: Includes length of header.) 整个包的长度。 必须是4的倍数。 (注意: 包括页眉长度。) |
16 | MD5 Hash 5 Hash | MD5 Hash of packet. Used as a checksum for the packet. Calculation starts at first byte of Recovery Set ID and ends at last byte of body. 包的 MD5散列。 用作数据包的校验和。 计算从恢复集 ID 的第一个字节开始,到正文的最后一个字节结束Does not include the magic sequence, length field or this field. NB: The MD5 Hash, by its definition, includes the length as if it were appended to the packet. 不包括幻术序列、长度字段或此字段。 注意: MD5哈希,根据它的定义,包括长度,如果它被追加到数据包 |
16 | MD5 Hash 5 Hash | Recovery Set ID. All packets that belong together have the same recovery set ID. (See "main packet" for how it is calculated.) 恢复设置 ID。 属于一起的所有数据包具有相同的恢复集 ID。 (请参阅"主数据包"以了解其计算方法。) |
16 | byte[16][16] | Type. Can be anything. All beginning "PAR " (ASCII) are reserved for specification-defined packets. Application-specific packets are recommended to begin with the ASCII name of the client. 类型。 可以是任何东西。 所有以"PAR"(ASCII)开头的数据包都保留给规范定义的数据包。 建议特定于应用程序的数据包以客户机的 ASCII 名称开头 |
?*4 ? * 4 | ? | Body of Packet. Must be a multiple of 4 bytes. 数据包的主体。 必须是4字节的倍数 |
There are various types of packets. The "core" set of packets - the set of packets that all clients must recognize and process - are listed next. For each, the value for the "type" field will be listed along with the contents of the body of the packet.
有各种类型的数据包。 接下来列出的是"核心"数据包集——所有客户端必须识别和处理的数据包集。 对于每个字段,"type"字段的值将与数据包正文的内容一起列出。
The main packet contains the slice size and the File IDs of all the files in the recovery set. The MD5 hash of the body of the main packet is used as the Recovery Set ID, which is included in the packet header of every packet for the set. Clients reading a file should just test that the Recovery Set ID is the same in all packets and not check that it was calculated to the right value; the method for calculating the Recovery Set ID could change in future versions.
主数据包包含恢复集中所有文件的片大小和文件 id。 主数据包主体的 MD5散列用作恢复集 ID,该 ID 包含在该集合的每个数据包的包头中。 读取文件的客户端应该只是测试恢复集 ID 在所有数据包中是否相同,而不是检查它是否计算到了正确的值; 计算恢复集 ID 的方法可能会在未来的版本中改变。
The main packet has a type value of "PAR 2.0\0Main\0\0\0\0" (ASCII). The packet's body contains the following:
主数据包的类型值为"PAR 2.00 main 0000"(ASCII)。 数据包的主体包含以下内容:
Table 126. Main packet
表126。 主数据包
Length (bytes) 长度(字节) | Type 类型 | Description 描述 |
---|---|---|
8 | 8-byte uint 8字节 uint | Slice size. Must be a multiple of 4. 切片大小。 必须是4的倍数 |
4 | 4-byte uint 4字节 uint | Number of files in the recovery set. 恢复集中的文件数 |
?*16 ? * 16 | MD5 Hash array 5 Hash 数组 | File IDs of all files in the recovery set. (See File Description packet.) These hashes are 恢复集中所有文件的文件 id。 (见文件描述包。) 这些散列是sorted 分类 by numerical value (treating them as 16-byte unsigned integers). 通过数值(将它们视为16字节的无符号整数) |
?*16 ? * 16 | MD5 Hash array 5 Hash 数组 | File IDs of all files in the non-recovery set. (See File Description packet.) These hashes are 非恢复集中所有文件的文件 id。 (见文件描述包。) 这些散列是sorted 分类 by numerical value (treating them as 16-byte unsigned integers). 通过数值(将它们视为16字节的无符号整数) |
A file description packet is included for each input file - recoverable or non-recoverable. The first thing in the packet is the File ID - this uniquely identifies a file in the PAR file. The packet then contains the MD5 hash, MD5 hash of the first 16kB of the file, file length, and the name of the file. The MD5 hash of the first 16kB of the file is included so that a client can identify a file if its name has been changed without the client reading the entire file. (Of course, that assumes the first 16kB hasn't been damaged or lost!)
每个可恢复或不可恢复的输入文件都包含一个文件描述包。 数据包中的第一件东西是文件 ID ——它唯一地标识 PAR 文件中的文件。 然后数据包包含 MD5散列、文件的前16kB 的 MD5散列、文件长度和文件名。 包含文件前16kB 的 MD5散列,这样,如果文件名已经更改,客户机可以在不读取整个文件的情况下识别该文件。 (当然,前提是前16kB 没有损坏或丢失!)
The File ID in this version is calculated as the MD5 Hash of the last 3 fields of the body of this packet: MD5-16k, length, and ASCII file name. Note: The length and MD5-16k are included because the Recovery Set ID is a hash of the File IDs and the Recovery Set ID should be a function of file contents as well as names.
此版本中的文件 ID 计算为此数据包正文的最后3个字段的 MD5散列: MD5-16k、长度和 ASCII 文件名。 注意: 之所以包含长度和 MD5-16k,是因为 Recovery Set ID 是 File ID 的散列,而 Recovery Set ID 应该是文件内容和名称的函数。
File names are case sensitive and can be of any length. If a client is doing recovery on an operating system that has case-insensitive filenames or limited-length filenames, it is up to the client to rename files and directories. If the file's directory does not exist, the client must create it.
文件名是区分大小写的,可以是任意长度的。 如果客户机在具有不区分大小写的文件名或有限长度的文件名的操作系统上进行恢复,则由客户机重命名文件和目录。 如果文件的目录不存在,客户端必须创建它。
The file description packer has a type value of "PAR 2.0\0FileDesc" (ASCII). The packet's body contains the following:
文件描述打包器的类型值为"PAR 2.00filedesc"(ASCII)。 数据包的主体包含以下内容:
Table 158. File Descriptor Packet Body Contents
表158。 文件描述符包体内容
Length (bytes) 长度(字节) | Type 类型 | Description 描述 |
---|---|---|
16 | MD5 Hash 5 Hash | The File ID. 文件 ID |
16 | MD5 Hash 5 Hash | The MD5 hash of the entire file. 整个文件的 MD5散列 |
16 | MD5 Hash 5 Hash | The MD5-16k. That is, the MD5 hash of the first 16kB of the file. Md5-16k. 也就是文件的前16kB 的 MD5散列 |
8 | 8-byte uint 8字节 uint | Length of the file. 文件长度 |
?*4 ? * 4 | ASCII char array Ascii 字符数组 | Name of the file. 文件名This array is not guaranteed to be null terminated! 此数组不能保证为空终止 Subdirectories are indicated by an HTML-style '/' (a.k.a. the UNIX slash). 子目录由 html 样式的'/'(又名 UNIX 斜杠)指示The filename must be unique. 文件名必须是唯一的 |
This packet type contains checksums for all the slices that are in an input file. It includes a CRC32 checksum to quickly locate the slices and an MD5 checksum to verify they have not been modified. The CRC32 is specified by CCITT and is the same as in Ethernet packets (and PKZIP, FDDI, etc.). If the file would end mid-slice, the remainder of the slice is filled with 0-value bytes.
此数据包类型包含输入文件中所有片的校验和。 它包括一个 CRC32校验和来快速定位片,以及一个 MD5校验和来验证它们没有被修改。 Crc32由 CCITT 指定,与以太网数据包(以及 PKZIP、 FDDI 等)中的 CRC32相同。 如果文件将在切片中间结束,则切片的其余部分将填充0值字节。
The input file slice checksum packet has a type value of "PAR 2.0\0IFSC\0\0\0\0" (ASCII). The packet's body contains the following:
输入文件片校验和包的类型值为"PAR 2.00ifsc 0000"(ASCII)。 数据包的主体包含以下内容:
Table 193. Slice Checksum Packet Body Contents
表193。 分片校验和数据包主体内容
Length (bytes) 长度(字节) | Type 类型 | Description 描述 |
---|---|---|
16 | MD5 Hash 5 Hash | The File ID of the file. 文件的文件 ID |
?*20 ? * 20 | {MD5 Hash, CRC32} array 5 Hash,CRC32} array | MD5 Hash and CRC32 pairs for the slices of the file. The Hash/CRC pairs are in the same order as their respective slices in the file. The Hash comes before the CRC in the array elements. Md5 Hash 和 CRC32对用于文件片。 Hash / crc 对与文件中它们各自的片的顺序相同。 在数组元素中,Hash 位于 CRC 之前 |
The recovery slice packet contains one slice of recovery data. The recovery data is generated using a 16-bit Galois Field (GF) with generator 0x0001100B.
恢复切片包含一个恢复数据切片。 利用16位有限域(GF)和生成器0x0001100B 生成恢复数据。
The algorithm for computing recovery slices is based on James S. Plank's tech report at U. of Tennessee entitled A tutorial on Reed-Solomon coding for fault-tolerance in RAID-like systems. The input slices are ordered and assigned 16-bit constants. Recovery slices are assigned 16-bit exponents. Each 2-byte word of the recovery slice is the sum of the contributions from each input slice. The contribution of each input slice is the 2-byte word of the input slice multiplied by the input slice's constant raised to the recovery slice's exponent. All these computations (adds, multiplys, powers) are done using the 16-bit Galois Field operations.
计算恢复切片的算法是基于 James s. Plank 在田纳西大学发表的题为"Reed-Solomon 编码在类 raid- 系统中容错的教程"的技术报告。 输入片是有序的,并赋予16位常量。 恢复切片被分配为16位指数。 恢复片的每个2字节字都是每个输入片贡献的总和。 每个输入切片的贡献是输入切片的2字节字乘以提高到恢复切片指数的输入切片常数。 所有这些计算(加法、乘法、幂)都是使用16位的伽罗瓦域运算完成的。
To generate the recovery data, the slices of the input files are assigned constants. This is based on the order the File IDs appear in the main packet and then by the order the slices appear in the file. So the first slice of the first file in the main packet is assigned the first constant. The second slice of the first file is assigned the second constant. And so on. If the last slice of the first file has the Nth constant, the first slice of the second file is assigned the (N+1)th. And so on.
为了生成恢复数据,输入文件的片被赋予常量。 这是基于文件 id 在主包中出现的顺序,然后是基于片在文件中出现的顺序。 因此,主数据包中第一个文件的第一个片段被赋予第一个常量。 第一个文件的第二个片段被赋予第二个常量。 诸如此类。 如果第一个文件的最后一个片段具有 Nth 常量,那么第二个文件的第一个片段被赋值为(n + 1) th。 诸如此类。
Here, the PAR 2.0 Spec diverges from Plank's paper. In Plank, the first constant is 1, the second 2, the third 3, etc. This is a bad approach because some constants have an order less than 65535. (That is, there exists constants N where N raised to a power less than 65535 is equal to 1 in the Galois Field.) These constants can prevent recovery matrices from being invertible and can, therefore, stop recovery. This spec does not use those constants. So, the first constant is the first power of two that has order 65535. The second constant is the next power of two that has order 65535. And so on. A power of two has order 65535 if the exponent is not equal to 0 modulus 3, 5, 17, or 257. In C code, that would be (n%3 != 0 && n%5 != 0 && n%17 != 0 && n%257 != 0). Note - this is the exponent being tested, and not the constant itself. There are 32768 valid constants. The first few are:
这里,PAR 2.0规格与普兰克的论文不同。 在 Plank 中,第一个常量是1,第二个是2,第三个是3,等等。 这是一个糟糕的方法,因为一些常量的顺序小于65535。 (也就是说,在 Galois Field 存在常数 n,其中 n 的幂小于65535等于1。) 这些常数可以防止恢复矩阵可逆,因此可以停止恢复。 这个规范不使用这些常量。 所以,第一个常数是2的第一次方,它的次序是65535。 第二个常数是2的下一次幂,它的次序是65535。 诸如此类。 如果指数不等于0的模3、5、17或257,则二的次幂为65535。 在 c 代码中,应该是(n% 3! 0 & n% 5! 0 & n ! 0 & n% 2 57 注意——这是被测试的指数,而不是它的常数 如果。有32768有效的警员 第一部分
The recovery slice packet has a type value of "PAR 2.0\0RecvSlic" (ASCII). The packet's body contains the following:
恢复片数据包的类型值为"PAR 2.00recvslic"(ASCII)。 数据包的主体包含以下内容:
Table 232. Recovery Slice Packet Body Contents
表232。 恢复片包体内容
Length (bytes) 长度(字节) | Type 类型 | Description 描述 |
---|---|---|
4 | 4-byte unit 四字节单位 | Exponent used to generate recovery data 用于生成恢复数据的指数 |
?*4 ? * 4 | byte array 字节数组 | Recovery data. 恢复数据 |
This packet is used to identify the client that created the file. It is required to be in every PAR file. If a client is unable to process a recovery set, the contents of the creator packet must be shown to the user. The goal of this is that any client incompatibilities can be found and resolved quickly.
此数据包用于标识创建文件的客户端。 它必须出现在每个 PAR 文件中。 如果客户端无法处理恢复集,则必须向用户显示创建者数据包的内容。 这样做的目的是能够快速发现和解决任何客户机不兼容问题。
The creator packet has a type value of "PAR 2.0\0Creator\0" (ASCII). The packet's body contains the following:
Creator 数据包的类型值为"PAR 2.00creator 0"(ASCII)。 数据包的主体包含以下内容:
Table 254. Creator Packet Body Contents
表254。 创建者包主体内容
Length (bytes) 长度(字节) | Type 类型 | Description 描述 |
---|---|---|
?*4 ? * 4 | ASCII char array Ascii 字符数组 | ASCII text identifying the client. This should also include a way to contact the client's creator - either through a URL or an email address. NB: 标识客户端的 ASCII 文本。 这也应该包括一种方式来联系客户端的创建者-无论是通过一个 URL 或电子邮件地址。 注意:This is not a null terminated string! 这不是一个以空结尾的字符串 |
Here ends the "core" packets that all clients must recognize and process.
这里结束了所有客户端必须识别和处理的"核心"数据包。
That is the official spec. To make sure clients work similarly, the following client conventions should be followed.
这是官方规格。 为了确保客户端以类似方式工作,应遵循以下客户端约定。
PAR 2.0 files should always end in ".par2". For example, "file.par2". If a file contains recovery slices, the ".par2" should be preceded by ".volXX-YY" where XX to YY is the range of exponents for the recovery slices. For example, "file.vol20-29.par2". More than 2 digits should be used if necessary. Any exponents that contain fewer digits than the largest exponent should be preceded by zeros so that all filenames have the same length. For example, "file.vol075-149.par2". Exponents should start at 0 and go upwards.
Par 2.0文件应该总是以"结尾。 "par2". 例如,"file.par2"。 如果文件包含恢复片,则"。 Par2前面应该加上。 其中 XX 到广州欢聚时代是恢复切片的指数范围。 例如,"file.vol20-29。 "par2". 如有需要,应使用超过两位数字。 任何包含少于最大指数的数字的指数前面都应该有零,以便所有文件名具有相同的长度。 例如,"file.vol075-149。 "par2". 指数应该从0开始向上。
If multiple PAR files are generated, they may either have a constant number of slices per file (e.g. 20, 20, 20, ...) or exponentially increasing number of slices (e.g., 1, 2, 4, 8, ...). Note that to store 1023 slices takes 52 files if each has 20 slices, but takes only 10 files with the exponential pattern.
如果生成了多个 PAR 文件,那么它们可能每个文件有固定数量的片(例如20、20、20、 ...) ,也可能有呈指数增长的片数(例如1、2、4、8、 ...)。 注意,要存储1023个切片,如果每个切片有20个切片,则需要52个文件,但是使用指数模式只需要10个文件。
When generating multiple PAR files, it is expected that one file be generated without any slices and containing all main, file description, and input file checksum packets. The other files should also include the main, file description and input file checksum packets. This repeats data that cannot be recovered.
在生成多个 PAR 文件时,需要生成一个不带任何片的文件,其中包含所有主文件、文件描述和输入文件校验和数据包。 其他文件还应包括主文件、文件描述和输入文件校验和数据包。 这将重复无法恢复的数据。
NOTE: If the files are to be transmitted over usenet, it might be best to place the main, file description and input file checksum packets at the end, so that the equal-sized recovery slice packets are at the beginning. That way it may be possible to put a single recovery slice in each usenet message.
注意: 如果要通过 usenet 传输文件,最好将主文件、文件描述和输入文件校验和数据包放在结尾,这样等大小的恢复切片数据包就在开头。 这样就可以在每个 usenet 消息中放置一个恢复片。
If just a single PAR file is generated, it is expected that the main, file description, and input file checksum packets are repeated multiple times and scattered through out the file. (Once again, repeating data that cannot be recovered.)
如果只生成一个 PAR 文件,那么主文件、文件描述和输入文件校验和数据包将被多次重复并散布到文件中。 (再次重复无法恢复的数据。)
Recall that all files must contain a creator packet.
回想一下,所有文件都必须包含一个创建者包。
It is recommended that users are warned when they create PAR files with names that are incompatible with Windows, Mac, or Linux systems. That is, file or directory names that are more than 255 characters long, start with a period (.) or a dash (-), or contain one of these characters: < > : " ' ` ? * & | [ ] \ ; or newline (\n).
建议在用户创建名称与 Windows、 Mac 或 Linux 系统不兼容的 PAR 文件时警告他们。 也就是说,长度超过255个字符的文件或目录名以句号(.)开头 或者破折号(-) ,或者包含这些字符中的一个:"'? * & | [] ; 或 newline ( n)。
It is strongly recommended that clients query a user before writing to a file whose File Description packet contains an absolute pathname. For Windows, that means one starting with "C:\" or "//" for example. For UNIX, that means one starting with "/" or "//". For Mac, that means one starting with ":". This is to prevent PAR files of unknown origin from cracking a system by overwriting system files.
强烈建议客户端在写入其文件描述包包含绝对路径名的文件之前查询用户。 对于 Windows,这意味着以"c: "或"/ /"开头。 对于 UNIX,这意味着以"/"或"/ /"开头。 对于 Mac 来说,这意味着一个以":"开头的词。 这是为了防止来源不明的 PAR 文件通过覆盖系统文件破解系统。
Clients do not need to process these packets. They are included in this spec because many clients might want to implement the functionality and, if they did, it would be good if they were compatible with each other.
客户端不需要处理这些数据包。 它们被包含在这个规范中,因为许多客户机可能想要实现这个功能,如果他们实现了这个功能,那么如果它们彼此兼容就好了。
This packet provides an alternate name for a file. This packet overrides the default "ASCII" name in the file description packet.
这个数据包提供了一个文件的替代名称。 这个数据包覆盖了文件描述数据包中默认的"ASCII"名称。
The Unicode filename packet has a type value of "PAR 2.0\0UniFileN" (ASCII, ironically). The packet's body contains the following:
Unicode 文件名包的类型值为"PAR 2.00unifilen"(具有讽刺意味的是,这是 ASCII)。 数据包的主体包含以下内容:
Table A.7. Unicode Filename Packet Contents
表 a. 7。 文件名文件包内容
Length (bytes) 长度(字节) | Type 类型 | Description 描述 |
---|---|---|
16 | MD5 Hash 5 Hash | The File ID of the file. 文件的文件 ID |
?*4 ? * 4 | Unicode char array Unicode 字符数组 | The name of the file in Unicode. Unicode 中文件的名称NB: This is not a null terminated array! 注意: 这不是一个空终止的数组 This name must obey all the restrictions of the ASCII filename in the File Description packet. 此名称必须遵守文件描述包中 ASCII 文件名的所有限制 |
The ASCII comment packet contains - would you believe it - a comment in ASCII text! This should be shown to the user. If multiple copies of the same comment are found, only one need be shown.
美国信息交换标准码(ASCII)注释包含——你会相信吗—— ASCII 文本中的注释! 这应该显示给用户。 如果发现同一注释的多个副本,则只需显示一个副本。
The ASCII comment packet has a type value of "PAR 2.0\0CommASCI" (ASCII). The packet's body contains the following
Ascii 注释包的类型值为"PAR 2.00commasci"(ASCII)。 数据包的主体包含以下内容
Table A.28. ASCII Comment Packet Contents
表 a. 28。 美国信息交换标准代码注释包内容
Length (bytes) 长度(字节) | Type 类型 | Description 描述 |
---|---|---|
?*4 ? * 4 | ASCII char array Ascii 字符数组 | The comment. NB: 评论。 注意:This is not a null terminated string! 这不是一个以空结尾的字符串 |
The Unicode comment packet contains a comment in Unicode text. This should be shown to the user. If multiple copies of the same comment are found, only one need be shown. If an analogous ASCII version of the same comment is included in the file, the ASCII comment should not be shown.
Unicode 注释包包含 Unicode 文本中的注释。 这应该显示给用户。 如果发现同一注释的多个副本,则只需显示一个副本。 如果文件中包含相同注释的类似 ASCII 版本,则不应显示 ASCII 注释。
The Unicode comment packet has a type value of "PAR 2.0\0CommUni" (ASCII, ironically). The packet's body contains the following:
Unicode 注释包的类型值为"PAR 2.00communi"(具有讽刺意味的是,ASCII)。 数据包的主体包含以下内容:
Table A.45. Unicode Comment Packet Contents
表 a. 45。 Unicode 注释包内容
Length (bytes) 长度(字节) | Type 类型 | Description 描述 |
---|---|---|
16 | MD5 Hash or zeros 5 Hash 或0 | If an ASCII comment packet exists in the file and is just a translation of the Unicode in this comment, this is the MD5 Hash of the ASCII comment packet. Otherwise, it is zeros. 如果文件中存在一个 ASCII 注释包,并且在这个注释中它只是 Unicode 的翻译,那么这个注释包就是 ASCII 注释包的 MD5 Hash。 否则,它就是0 |
?*4 ? * 4 | Unicode char array Unicode 字符数组 | The comment. NB: 评论。 注意:This is not a null terminated string! 这不是一个以空结尾的字符串 |
The input file slice packet is used if the user wants to include the input file inside the PAR file. This can be used to combine lots of small files into one file or to break a large file into smaller files (by distributing its slices into many PAR files). The length of the slice is determined by the slice size in the main packet, unless the slice would run off the end of the file. The packet contains an index for the slice and the slice contain bytes from (slice_size*index) to (slice_size*index + slice_size -1), unless the end of the file is reached. NOTE: The indices are not the same as the input slice constants used in making recovery slices.
如果用户希望将输入文件包含在 PAR 文件中,则使用输入文件片断包。 这可以用来将许多小文件组合成一个文件,或者将一个大文件分解成更小的文件(通过将其切片分布到许多 PAR 文件中)。 切片的长度由主数据包中的切片大小决定,除非切片在文件末尾运行。 数据包包含片的索引,片包含从(片大小 * 索引)到(片大小 * 索引 + 片大小-1)的字节,除非到达文件的末尾。 注意: 索引与生成恢复切片时使用的输入切片常量不同。
If files contain input slices, the ".par2" in the filename should be preceded by ".partXX-YY" where XX to YY is the indices of the slices. For example, "file.part00-09.par2" Indices are assigned to slices in the same order that constants were assigned in generating the recover packets. "... based on the order the File IDs appear in the main packet and then by the order the slices appear in the file. So the first slice of the first file in the main packet is assigned the first constant. The second slice of the first file is assigned the second constant. And so on. If the last slice of the first file has the Nth constant, the first slice of the second file is assigned the (N+1)th. And so on."
如果文件包含输入片,则"。 文件名中的"par2"前面应该加上"。 其中 XX 到广州欢聚时代是切片的索引。 例如,"file.part00-09。 Par2"索引按照生成恢复包时指定的常量的顺序分配给片 ... 根据文件 id 出现在主包中的顺序,然后根据切片出现在文件中的顺序。 因此,主数据包中第一个文件的第一个片段被赋予第一个常量。 第一个文件的第二个片段被赋予第二个常量。 诸如此类。 如果第一个文件的最后一个片段具有 Nth 常量,那么第二个文件的第一个片段被赋值为(n + 1) th。 等等。"
The input file slice packet has a type value of "PAR 2.0\0FileSlic". The packet's body contains the following:
输入文件片段包的类型值为"PAR 2.00filelic"。 数据包的主体包含以下内容:
Table A.69. Input File Slice Packet Contents
表 a. 69。 输入文件切片数据包内容
Length (bytes) 长度(字节) | Type 类型 | Description 描述 |
---|---|---|
16 | MD5 Hash 5 Hash | The File ID of the file. 文件的文件 ID |
8 | 8-byte uint 8字节 uint | The index of the slice. (See description above.) 切片的索引。 (见上文描述) |
?*4 ? * 4 | byte array 字节数组 | The slice. If the file ends mid-slice, the field is zero padded with 0 to 3 bytes to make it end on a 4-byte alignment. 切片。 如果文件在切片中间结束,则用0到3个字节填充字段,使其以4字节对齐方式结束 |
So far, we've had input and recovery slices in the PAR file and input slices in an external file (i.e., the input file slice checksum packet). This packet covers the last combination - the recovery slices are in an external file (i.e., one where they don't have packet headers). This packet type may never be used, but it is included for completeness.
到目前为止,我们已经在 PAR 文件中有了输入和恢复切片,在外部文件(即输入文件切片校验和包)中有了输入切片。 这个数据包覆盖了最后一个组合——恢复片在一个外部文件中(也就是说,它们没有数据包头)。 这种数据包类型可能永远不会被使用,但是为了完整性而包括在内。
There exists a file description packet for the file. The slices are generated the same as for the recovery slice packet.
该文件存在一个文件描述包。 所生成的片与恢复片包所生成的片相同。
The recovery file slice checksum packet has a type value of "PAR 2.0\0RFSC\0\0\0\0". The packet's body contains the following:
恢复文件片校验和包的类型值为"PAR 2.00rfsc 0000"。 数据包的主体包含以下内容:
Table A.94. Recovery File Slice Checksum Packet Contents
表 a. 94。 恢复文件切片校验和数据包内容
Length (bytes) 长度(字节) | Type 类型 | Description 描述 |
---|---|---|
16 | MD5 Hash 5 Hash | The File ID of the file. 文件的文件 ID |
?*24 ? * 24 | {MD5 Hash, CRC32, 4-byte uint} array { MD5 Hash,CRC32,4字节 uint }数组 | MD5 Hash, CRC32, and exponent triplets for the slices in the file. The Hash/CRC/exponent triplets are in the same order as their respective slices in the file. The order in the array element is MD5 Hash, CRC32, followed by exponent. 文件中的片的 MD5 Hash、 CRC32和指数三元组。 Hash / crc / 指数三元组与文件中它们各自的片的顺序相同。 数组元素的顺序是 MD5 Hash,CRC32,后面是指数 |
The packed main packet replaces the main packet when the client generates packed recover slice packets. The packed format allows recovery on units smaller than the slice size, which both increases the chance of recovery and allows more than 32,768 files. (The non-packed format requires, for each file, at least one slice and the number of slices is limited to 32,768.)
当客户端生成打包恢复片包时,打包的主包替换主包。 打包格式允许在小于片大小的单位上进行恢复,这既增加了恢复的机会,也允许超过32,768个文件。 (非打包格式要求每个文件至少有一个片,并且片的数量限制为32,768。)
The only difference from the main packet is the addition of the subslice size. (See the description of packed recovery slice packets to see how this is used.)
与主数据包的唯一区别是增加了子片大小。 (请参阅打包的恢复切片数据包的描述,以了解如何使用它。)
The main packet has a type value of "PAR 2.0\0PkdMain\0" (ASCII). The packet's body contains the following:
主数据包的类型值为"PAR 2.00pkdmain 0"(ASCII)。 数据包的主体包含以下内容:
Table A.115. Packed Main Packet Contents
表 a. 115。 包装好的主要包装内容
Length (bytes) 长度(字节) | Type 类型 | Description 描述 |
---|---|---|
8 | 8-byte uint 8字节 uint | Subslice size. Must be a multiple of 4. Must equally divide the slice size. 子片大小。 必须是4的倍数。 必须等分切片大小 |
8 | 8-byte uint 8字节 uint | Slice size. Must be a multiple of 4 and a multiple of the subslice size. 切片大小。 必须是4的倍数和子片大小的倍数 |
4 | 4-byte uint 4字节 uint | Number of files in the recovery set. 恢复集中的文件数 |
?*16 ? * 16 | MD5 Hash array 5 Hash 数组 | File IDs of all files in the recovery set. (See File Description packet.) These hashes are 恢复集中所有文件的文件 id。 (见文件描述包。) 这些散列是sorted 分类 by numerical value (treating them as 16-byte unsigned integers). 通过数值(将它们视为16字节的无符号整数) |
?*16 ? * 16 | MD5 Hash array 5 Hash 数组 | File IDs of all files in the non-recovery set. (See File Description packet.) These hashes are 非恢复集中所有文件的文件 id。 (见文件描述包。) 这些散列是sorted 分类 by numerical value (treating them as 16-byte unsigned integers). 通过数值(将它们视为16字节的无符号整数) |
The packed recovery slice packet contains one slice of recovery data. The recovery data is generated in the same manner as the recovery slice packet; the only thing that differs is how the data from the input slices is laid out.
打包的恢复切片包含一个恢复数据切片。 恢复数据以与恢复片数据包相同的方式生成; 唯一不同的是输入片数据的布局方式。
Files are broken into subslices and the subslices are ordered, just as in the recovery slice packet - sorted first by the order of the File ID in the packed main packet and then by the order of the subslice within the file.
文件被分成子片,子片被排序,就像在恢复片包中一样——首先按照打包的主包中文件 ID 的顺序排序,然后按照文件中子片的顺序排序。
These subslices are then grouped to together to make up the slices of input data used in the calculations. If X is the number of subslices in a slice, the first X subslices make up the first slice (which has the recovery constant 2). The next X subslices make up the second slice (which has the constant 4). Etc.
然后将这些子片组合在一起,以组成计算中使用的输入数据片。 如果 x 是一个片中子片的数量,那么第一个 x 子片组成了第一个片(其恢复常数为2)。 下一个 x 子片组成了第二个片(常量为4)。 等等。
In short, the input slices are made by packing the files together, with files starting on subslice boundaries rather than slice boundaries. Note that there are no subslice checksums, but there are file checksums, which can be used to detect bad regions that are smaller than a slice.
简而言之,输入切片是通过将文件打包在一起生成的,文件从子切片边界开始,而不是切片边界。 请注意,没有子片校验和,但有文件校验和,可用于检测小于片的坏区域。
The recovery slice packet has a type value of "PAR 2.0\0PkdRecvS" (ASCII). The packet's body contains the following:
恢复片数据包的类型值为"PAR 2.00pkdrecv"(ASCII)。 数据包的主体包含以下内容:
Table A.152. Packed Recovery Slice Packet Contents
表 a. 152。 打包恢复切片数据包内容
Length (bytes) 长度(字节) | Type 类型 | Description 描述 |
---|---|---|
4 | 4-byte uint 4字节 uint | Exponent used to generate recovery data 用于生成恢复数据的指数 |
?*4 ? * 4 | byte array 字节数组 | Recovery data. 恢复数据 |
This ends the optional packets in this specification.
这结束了本规范中的可选包。
Say the author of "NewsPost" wanted to add his own packet type - one that identified the names of the Usenet messages in which the files are posted. That author can create his own packet type. For example, here is the layout for one where the Usenet messages are identified by a newsgroup and a regular expression which all matches the names of the usenet articles.
假设"NewsPost"的作者想要添加他自己的数据包类型,这种类型可以识别发布文件的 Usenet 消息的名称。 该作者可以创建自己的数据包类型。 例如,下面是 Usenet 消息的布局,其中 Usenet 消息由新闻组和正则表达式标识,所有这些正则表达式都与 Usenet 文章的名称匹配。
The packet has a type value of "NewsPostUsenet\0\0". (NB: Including the name of the client in the type is the recommended way to ensure unique type names.) The packet's body contains the following:
数据包的类型值为"NewsPostUsenet 00"。 (注意: 建议在类型中包含客户端的名称,以确保类型名称的唯一性。) 数据包的主体包含以下内容:
Table B.3. Example Application Specific Packet
表 b. 3。 应用程序特定数据包示例
Length (bytes) 长度(字节) | Type 类型 | Description 描述 |
---|---|---|
16 | MD5 Hash 5 Hash | The File ID of the file. 文件的文件 ID |
4 | 4-byte uint 4字节 uint | The length of the string containing the name of the newsgroup. Must be a multiple of 4. 包含新闻组名称的字符串的长度。 必须是4的倍数 |
?*4 ? * 4 | ASCII char array Ascii 字符数组 | The name of the newsgroup. For example, "alt.binaries.multimedia". 新闻组的名称。 例如,"alt.binaries.multimedia" |
?*4 ? * 4 | ASCII char array Ascii 字符数组 | A regular expression matching the name of articles containing the file. For example, "Unaired Pilot - VCD,NTSC - (??/??)". 与包含文件的项目名称匹配的正则表达式。 例如,"未播出的试播-VCD,NTSC-(? ? ? /??)" |
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
版权(c)2000,2001,2002自由软件基金会,公司59天普广场,套房330,波士顿,马萨诸塞州02111-1307美国每个人都被允许复制和分发这个许可证文件的逐字拷贝,但不允许更改。
The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
本许可证的目的是使手册、教科书或其他功能性和有用的文件在自由的意义上"免费": 以确保每个人有效的自由复制和重新分发它,无论是否修改它,商业或非商业。 其次,这个许可证为作者和出版商保留了一种获得作品荣誉的方式,而不会被认为对其他人的修改负责。
This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.
这个许可证是一种"copyleft",这意味着文档的衍生作品本身也必须是免费的。 它补充了为自由软件设计的著作权许可 GNU通用公共许可协议。
We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
我们设计这个许可证是为了使用它作为自由软件的手册,因为自由软件需要自由的文档: 一个自由的程序应该附带手册,提供与软件一样的自由。 但是这个许可证不仅限于软件手册,它可以用于任何文本作品,不管主题是什么,也不管它是否以印刷书籍的形式出版。 我们建议本许可证主要用于指导或参考作品。
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.
本许可证适用于任何手册或其他作品,在任何媒体,其中包含版权持有人放置的通知,说明它可以根据本许可证的条款分发。 这样的通知授予一个世界范围的,免版税的许可证,无限期的期限,使用该作品在条件下陈述。 下面的"文件"指的是任何这样的手册或工作。 任何公众人士都是持牌人,并被称为"你"。 如果你以版权法允许的方式复制、修改或传播作品,你就接受了许可。
A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.
文件的"修改版本"是指包含文件或其部分内容的任何作品,不论是逐字复制,还是经过修改和 / 或翻译成另一种语言。
A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
"第二部分"是文件的附录或前言部分,专门处理文件的出版者或作者与文件的整体主题(或相关事项)之间的关系,不包含任何可直接属于该整体主题的内容。 (因此,如果文件是数学教科书的一部分,中学部分可能不解释任何数学。) 这种关系可以是与主题或相关事项的历史联系,也可以是与它们有关的法律、商业、哲学、伦理或政治立场。
The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.
"不变章节"是指某些次要章节,它们的标题被指定为不变章节的标题,在通知中说明文件是根据本许可证发布的。 如果一个部分不符合上述次要的定义,那么它就不能被指定为不变式。 文档可以包含零个不变部分。 如果文件没有标识任何不变部分,那么就没有。
The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.
"封面文本"是指在本许可证下发布的通知中,作为封面文本或封底文本列出的某些短文段落。 封面文本最多5字,封底文本最多25字。
A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".
文件的"透明"副本是指一种机器可读的副本,其格式规格可供一般公众查阅,适于用通用文本编辑器直接修改文件,或(对于由像素组成的图像)通用绘图程序或(对于绘图)一些广泛可用的绘图编辑器,并适于输入文本格式器或自动转换为适于输入文本格式器的各种格式。 以其他透明文件格式制作的副本,其标记或缺少标记被安排来阻止或阻止读者的后续修改,这种副本是不透明的。 如果图像格式用于任何大量的文本,那么它是不透明的。 不是"透明"的副本称为"不透明"。
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.
透明拷贝的合适格式包括无标记的纯 ASCII 格式、 Texinfo 输入格式、 LaTeX 输入格式、使用公开的 DTD 的 SGML 或 XML 格式,以及为人工修改而设计的符合标准的简单 HTML、 PostScript 或 PDF 格式。 透明图像格式的例子包括 PNG、 XCF 和 JPG。 不透明格式包括只能由专有文字处理程序读取和编辑的专有格式、 DTD 和 / 或处理工具通常无法获得的 SGML 或 XML,以及某些文字处理程序为输出目的而生成的机器生成的 HTML、 PostScript 或 PDF。
The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.
"标题页"指的是,对于印刷书籍,标题页本身,加上需要持有本许可证要求出现在标题页上的清晰的下列页面。 对于没有任何标题页的格式的作品,"标题页"是指作品标题最显著外观附近的文本,位于正文开头之前。
A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.
"标题为 XYZ"的部分是指文档的一个已命名的子单元,它的标题要么是 XYZ,要么在翻译另一种语言的 XYZ 文本之后的括号中包含 XYZ。 (在这里 XYZ 代表下面提到的一个特定的部分名称,例如"鸣谢"、"致敬"、"背书"或"历史"。) 当您修改文档时,"保留该部分的标题"意味着根据此定义,该部分仍然是"标题 XYZ"部分。
The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.
该文件可以在声明本许可证适用于该文件的通知旁边包括担保免责声明。 这些免责声明被认为是本许可证的参考内容,但仅限于否认保证: 任何其他暗示,这些免责声明可能是无效的,并不影响本许可证的含义。
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.
你可以在任何媒介上复制和分发文件,无论是商业的还是非商业的,只要本许可证、版权声明和许可声明适用于本文件复制的所有复制品,并且你没有在本许可证中添加任何其他条件。 您不得使用技术手段阻碍或控制阅读或进一步复制您制作或分发的副本。 不过,您可以接受补偿,以交换副本。 如果您分发了足够多的副本,那么您还必须遵循第3节中的条件。
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
您也可以出借副本,在上述相同的条件下,您可以公开展示副本。
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
如果你出版的文件印刷本(或通常有印刷封面的媒体)超过100份,而且文件的许可证通知要求封面文本,你必须在封面内附上所有这些封面文本: 封面文本为封面文本,封底文本为封底文本。 这两个封面还必须清楚易读地标明你是这些副本的出版商。 封面必须显示标题的完整标题,标题的所有文字必须同样突出和可见。 你还可以在封面上添加其他材料。 只限于封面的复制,只要保留文件的标题并符合这些条件,在其他方面可视为逐字复制。
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
如果任何一个封面所需的文字太长,难以清晰地容纳,你应该把第一个列出来的(尽可能多的合适)放在实际的封面上,其余的继续放在相邻的页面上。
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
如果发布或分发文件编号超过100的不透明副本,则必须在每个不透明副本中包括一份机器可读的透明副本,或者在每个不透明副本中或在每个不透明副本中声明一个计算机网络位置,使用一般网络的公众可以使用公共标准网络协议下载该文件的完整透明副本,不添加任何材料。 如果您使用后一种选择,您必须采取相当谨慎的步骤,当您开始分发不透明的副本数量,以确保这种透明的副本将继续保持这样的位置,直到至少一年后,您最后一次分发不透明的副本(直接或通过您的代理或零售商)的版本向公众。
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
在重新分发任何大量副本之前,请尽早与文档的作者联系,以便他们有机会向您提供文档的更新版本,但这并不是必须的。
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
你可以在上面第2和第3节的条件下复制和分发文件的修改版本,只要你根据本授权发布修改版本,修改版本充当文件的角色,从而授权分发和修改修改版本给任何拥有它的人。 另外,你必须在修改版本中做这些事情:
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.
如果修改后的版本包括新的前面部分或附录,这些部分或附录有资格作为次要部分,并且不包含从文件复制的材料,您可以选择指定这些部分或全部为不变部分。 为此,将它们的标题添加到修改版本许可通知中的不变部分列表中。 这些标题必须有别于任何其他部分的标题。
You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
你可以添加一个题为"背书"的章节,只要其中除了各方对你的修改版本的背书以外,没有其他内容——例如,同行审查声明,或者该文本已被某个组织认可为标准的权威定义。
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
你可以在修改版本的封面文本列表末尾添加最多五个单词的文章作为封面文本,最多二十五个单词的文章作为封底文本。 只有一段封面文字和一个封底文字可以添加(或通过安排)任何一个实体。 如果文档已经包含了同一封面的封面文字,以前是由你添加的,或者是由你所代表的同一个实体安排的,你不能添加另一封面文字; 但是你可以替换旧的,只要前一个添加旧封面的出版商明确允许。
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
本许可证不允许文件的作者和出版者使用他们的名字进行宣传,也不允许声称或暗示对任何修改版本的认可。
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.
你可以根据上面第4节中定义的修改版本的条款,将文档与本许可证下发布的其他文档组合在一起,但是你必须将所有原始文档的所有不变章节都包含在组合中,未经修改,并且在许可证通知中将它们作为组合作品的不变章节列出,并且保留它们的保证免责声明。
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
合并的作品只需包含本许可证的一个副本,多个相同的恒常章节可以替换为一个副本。 如果有多个具有相同名称但内容不同的恒常章节,请在每个章节的末尾添加一个独特的标题,如果知道该章节的原作者或出版者的名称,则在括号内添加该章节的原作者或出版者的名称,或添加一个唯一的数字。 对合并作品的许可证通知中的不变部分列表中的部分标题进行相同的调整。
In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".
在这个组合中,你必须合并各种原始文件中任何题为"历史"的部分,形成一个题为"历史"的部分; 同样地,合并任何题为"鸣谢"的部分和题为"奉献"的部分。 您必须删除所有题为"背书"的部分。
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
您可以将本许可证发布的文档和其他文档组成一个集合,并将本许可证在各种文档中的单个副本替换为该集合中包含的单个副本,但您必须遵守本许可证在所有其他方面逐字复制每个文档的规则。
You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
您可以从这样的集合中提取单个文档,并根据本许可证单独分发,只要您将本许可证的副本插入所提取的文档中,并在所有其他方面遵循本许可证的规定逐字复制该文档。
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.
如果汇编所产生的版权没有被用于限制汇编使用者的法律权利,使其超出个别作品的许可范围,则该文件或其衍生物与其他单独和独立的文件或作品在一卷储存或分发媒介中或在一卷上的汇编称为"汇总"。 当文件被包含在一个聚合体中时,本许可证不适用于其他聚合体中本身不是文件衍生作品的作品。
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
如果第3节的封面案文要求适用于文件的这些副本,那么如果该文件的封面案文少于整个文件总数的一半,该文件的封面案文可以放在该文件总数中括号内的封面上,如果该文件是电子形式的,封面案文可以放在同等电子形式的封面上。 否则他们必须出现在包括整个集合的印刷封面上。
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.
翻译被认为是一种修改,因此您可以根据第4节的条款分发文档的翻译。 用翻译替换不变部分需要版权所有者的特别许可,但是除了这些不变部分的原始版本之外,还可以包括部分或全部不变部分的翻译。 您可以包括本许可证的翻译,文件中的所有许可证通知,以及任何保证免责声明,只要您还包括本许可证的原始英文版本以及这些通知和免责声明的原始版本。 如果翻译版本与本许可证的原始版本或通知或免责声明有异议,将以原始版本为准。
If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
如果文件中有一节题为"鸣谢"、"致献"或"历史",那么保留其标题(第1节)的要求(第4节)通常需要修改实际标题。
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
除非本授权明确规定,否则不得复制、修改、再授权或分发本文件。 任何其他试图复制、修改、再授权或分发本文件的行为均属无效,并将自动终止您在本许可证下的权利。 但是,根据本许可证从您那里收到副本或权利的各方,只要这些各方完全遵守本许可证,则不会终止其许可证。
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
自由软件基金会可能会不时地出版新的、修订过的 GNU自由文档许可证版本。 这些新的版本在精神上与现在的版本相似,但为了解决新的问题或关注点,可能在细节上有所不同。 参见 http://www.gnu.org/copyleft/ 。
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.
许可证的每个版本都有一个区分的版本号。 如果文档指定本许可证的特定编号版本"或任何以后版本"适用于它,您可以选择遵循指定版本或自由软件基金会发布的任何以后版本(而不是草稿)的条款和条件。 如果文档没有指定本许可证的版本号,您可以选择由自由软件基金会发布的任何版本(不是草稿)。
To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:
在你写的文档中使用许可证,在文档中包含许可证的副本,并在标题页后面加上以下版权和许可声明:
Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".
版权(c)年份姓名。 允许复制,分发和 / 或修改本文件的条款的 GNU自由文档许可证,版本1.2或任何以后的版本由自由软件基金会出版; 没有不变部分,没有封面文本,没有封底文本。 许可证的副本包括在题为"GNU自由文档许可证"的章节中。
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts." line with this:
如果您有不变部分,封面文本和封底文本,取代"与... 文本。" 这样写道:
with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
不变章节是列出他们的标题,封面文本是列表,封底文本是列表。
If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.
如果你有没有封面文本的不变部分,或者其他三者的组合,合并这两个选择以适应情况。
If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.
如果你的文档包含一些重要的程序代码示例,我们建议在你选择的自由软件许可协议下并行发布这些示例,比如 GNU通用公共许可协议许可协议,以允许它们在自由软件中使用。