Network Working Group A. Surtees
Request for Comments: 4464 M. West
Category: Informational Siemens/Roke Manor Research
May 2006
Network Working Group A. Surtees
Request for Comments: 4464 M. West
Category: Informational Siemens/Roke Manor Research
May 2006
Signaling Compression (SigComp) Users' Guide
信令压缩（SigComp）用户指南
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document provides an informational guide for users of the Signaling Compression (SigComp) protocol. The aim of the document is to assist users when making SigComp implementation decisions, for example, the choice of compression algorithm and the level of robustness against lost or misordered packets.
本文档为信令压缩（SigComp）协议的用户提供信息指南。本文档的目的是帮助用户做出SigComp实施决策，例如，选择压缩算法以及对丢失或错误排列的数据包的鲁棒性水平。
Table of Contents
目录
1. Introduction ....................................................3
2. Overview of the User Guide ......................................3
3. UDVM Assembly Language ..........................................4
3.1. Lexical Level ..............................................4
3.2. Syntactic Level ............................................5
3.2.1. Expressions .........................................7
3.2.2. Instructions ........................................8
3.2.3. Directives ..........................................9
3.2.4. Labels .............................................10
3.3. Uploading the Bytecode to the UDVM ........................11
4. Compression Algorithms .........................................12
4.1. Well-known Compression Algorithms .........................12
4.1.1. LZ77 ...............................................12
4.1.2. LZSS ...............................................16
4.1.3. LZW ................................................18
4.1.4. DEFLATE ............................................21
4.1.5. LZJH ...............................................24
4.2. Adapted Algorithms ........................................28
4.2.1. Modified DEFLATE ...................................28
5. Additional SigComp Mechanisms ..................................31
5.1. Acknowledging a State Item ................................32
5.2. Static Dictionary .........................................33
5.3. CRC Checksum ..............................................34
5.4. Announcing Additional Resources ...........................35
5.5. Shared Compression ........................................37
6. Security Considerations ........................................38
7. Acknowledgements ...............................................38
8. Intellectual Property Right Considerations .....................38
9. Informative References .........................................38
Appendix A. UDVM Bytecode for the Compression Algorithms ..........40
A.1. Well-known Algorithms .....................................40
A.1.1. LZ77 ..............................................40
A.1.2. LZSS ..............................................40
A.1.3. LZW ...............................................40
A.1.4. DEFLATE ...........................................40
A.1.5. LZJH ..............................................41
A.2. Adapted Algorithms ........................................41
A.2.1. Modified DEFLATE ...................................41
1. Introduction ....................................................3
2. Overview of the User Guide ......................................3
3. UDVM Assembly Language ..........................................4
3.1. Lexical Level ..............................................4
3.2. Syntactic Level ............................................5
3.2.1. Expressions .........................................7
3.2.2. Instructions ........................................8
3.2.3. Directives ..........................................9
3.2.4. Labels .............................................10
3.3. Uploading the Bytecode to the UDVM ........................11
4. Compression Algorithms .........................................12
4.1. Well-known Compression Algorithms .........................12
4.1.1. LZ77 ...............................................12
4.1.2. LZSS ...............................................16
4.1.3. LZW ................................................18
4.1.4. DEFLATE ............................................21
4.1.5. LZJH ...............................................24
4.2. Adapted Algorithms ........................................28
4.2.1. Modified DEFLATE ...................................28
5. Additional SigComp Mechanisms ..................................31
5.1. Acknowledging a State Item ................................32
5.2. Static Dictionary .........................................33
5.3. CRC Checksum ..............................................34
5.4. Announcing Additional Resources ...........................35
5.5. Shared Compression ........................................37
6. Security Considerations ........................................38
7. Acknowledgements ...............................................38
8. Intellectual Property Right Considerations .....................38
9. Informative References .........................................38
Appendix A. UDVM Bytecode for the Compression Algorithms ..........40
A.1. Well-known Algorithms .....................................40
A.1.1. LZ77 ..............................................40
A.1.2. LZSS ..............................................40
A.1.3. LZW ...............................................40
A.1.4. DEFLATE ...........................................40
A.1.5. LZJH ..............................................41
A.2. Adapted Algorithms ........................................41
A.2.1. Modified DEFLATE ...................................41
This document provides an informational guide for users of the SigComp protocol, RFC 3320 [2]. The idea behind SigComp is to standardize a Universal Decompressor Virtual Machine (UDVM) that can be programmed to understand the output of many well-known compressors including DEFLATE [8] and LZW [7]. The bytecode for the chosen compression algorithm is uploaded to the UDVM as part of the compressed data.
本文件为SigComp协议RFC 3320[2]的用户提供了信息指南。SigComp背后的理念是标准化通用减压器虚拟机（UDVM），该虚拟机可编程为了解许多知名压缩机的输出，包括DEFLATE[8]和LZW[7]。所选压缩算法的字节码作为压缩数据的一部分上载到UDVM。
The basic SigComp RFC describes the actions that an endpoint must take upon receiving a SigComp message. However, the entity responsible for generating new SigComp messages (the SigComp compressor) is left as an implementation decision; any compressor can be used provided that it generates SigComp messages that can be successfully decompressed by the receiving endpoint.
基本SigComp RFC描述端点在接收SigComp消息时必须采取的操作。然而，负责生成新的SigComp消息的实体（SigComp压缩器）被留作实现决策；可以使用任何压缩器，只要它生成可以由接收端点成功解压缩的SigComp消息。
This document gives examples of a number of different compressors that can be used by the SigComp protocol. It also gives examples of how to use some of the mechanisms (such as acknowledgements) described in RFC 3321 [3].
本文件给出了SigComp协议可使用的许多不同压缩机的示例。它还举例说明了如何使用RFC 3321[3]中描述的一些机制（如确认）。
When implementing a SigComp compressor, the first step is to choose a compression algorithm that can encode the application messages into a (hopefully) smaller form. Since SigComp can upload bytecode for new algorithms to the receiving endpoint, arbitrary compression algorithms can be supported provided that suitable bytecode has been written for the corresponding decompressor.
在实现SigComp压缩器时，第一步是选择一种压缩算法，该算法可以将应用程序消息编码为（希望）更小的形式。由于SigComp可以将新算法的字节码上载到接收端点，因此只要为相应的解压缩器编写了合适的字节码，就可以支持任意压缩算法。
This document provides example bytecode for the following algorithms:
本文档提供了以下算法的字节码示例：
1. LZ77 2. LZSS 3. LZW 4. DEFLATE 5. LZJH
1. lz772。LZSS 3。lzw4。放气5。LZJH
Any of the above algorithms may be useful depending on the desired compression ratio, processing and memory requirements, code size, implementation complexity, and Intellectual Property (IPR) considerations.
根据所需的压缩比、处理和内存需求、代码大小、实现复杂性和知识产权（IPR）考虑，上述任何算法都可能有用。
As well as encoding the application messages using the chosen algorithm, the SigComp compressor is responsible for ensuring that messages can be correctly decompressed even if packets are lost or misordered during transmission. The SigComp feedback mechanism can
除了使用所选算法对应用程序消息进行编码外，SigComp压缩器还负责确保即使数据包在传输过程中丢失或排序错误，也能正确解压缩消息。SigComp反馈机制可以
be used to acknowledge successful decompression at the remote endpoint.
用于确认在远程端点成功解压缩。
The following robustness techniques and other mechanisms specific to the SigComp environment are covered in this document:
本文件涵盖了以下针对SigComp环境的鲁棒性技术和其他机制：
1. Acknowledgements using the SigComp feedback mechanism 2. Static dictionary 3. Cyclic redundancy code (CRC) checksum 4. Announcing additional resources 5. Shared compression
1. 使用SigComp反馈机制的确认2。静态字典3。循环冗余码（CRC）校验和4。宣布追加资源5。共享压缩
Any or all of the above mechanisms can be implemented in conjunction with the chosen compression algorithm. An example subroutine of UDVM bytecode is provided for each of the mechanisms; these subroutines can be added to the bytecode for one of the basic compression algorithms. (Note: The subroutine or the basic algorithm may require minor modification to ensure they work together correctly.)
上述任何或所有机制都可以结合所选择的压缩算法来实现。为每个机制提供UDVM字节码的示例子程序；这些子例程可以添加到基本压缩算法之一的字节码中。（注意：子程序或基本算法可能需要稍加修改，以确保它们正确地协同工作。）
Writing UDVM programs directly in bytecode would be a daunting task, so a simple assembly language is provided to facilitate the creation of new decompression algorithms. The assembly language includes mnemonic codes for each of the UDVM instructions, as well as simple directives for evaluating integer expressions, padding the bytecode, and so forth.
直接用字节码编写UDVM程序将是一项艰巨的任务，因此提供了一种简单的汇编语言来帮助创建新的解压缩算法。汇编语言包括每个UDVM指令的助记符代码，以及用于计算整数表达式、填充字节码等的简单指令。
The syntax of the UDVM assembly language uses the customary two-level description technique, partitioning the grammar into a lexical and a syntactic level.
UDVM汇编语言的语法使用惯用的两级描述技术，将语法划分为词汇级和语法级。
On a lexical level, a string of assembly consists of zero or more tokens optionally separated by whitespace. Each token can be a text name, an instruction opcode, a delimiter, or an integer (specified as decimal, binary, or hex).
在词法级别上，程序集字符串由零个或多个标记（可选地用空格分隔）组成。每个标记可以是文本名称、指令操作码、分隔符或整数（指定为十进制、二进制或十六进制）。
The following ABNF description, RFC 4234 [1], specifies the syntax of a token:
以下ABNF说明RFC 4234[1]指定了令牌的语法：
token = (name / opcode / delimiter / dec / bin / hex)
name = (lowercase / "_") 0*(lowercase / digit / "_")
opcode = uppercase *(uppercase / digit / "-")
delimiter = "." / "," / "!" / "$" / ":" / "(" / ")" /
operator
dec = 1*(digit)
bin = "0b" 1*("0" / "1")
hex = "0x" 1*(hex-digit)
hex-digit = digit / %x41-46 / %x61-66
digit = %x30-39
uppercase = %x41-5a
lowercase = %x61-7a
operator = "+" / "-" / "*" / "/" / "%" / "&" / "|" /
"^" / "~" / "<<" / ">>"
token = (name / opcode / delimiter / dec / bin / hex)
name = (lowercase / "_") 0*(lowercase / digit / "_")
opcode = uppercase *(uppercase / digit / "-")
delimiter = "." / "," / "!" / "$" / ":" / "(" / ")" /
operator
dec = 1*(digit)
bin = "0b" 1*("0" / "1")
hex = "0x" 1*(hex-digit)
hex-digit = digit / %x41-46 / %x61-66
digit = %x30-39
uppercase = %x41-5a
lowercase = %x61-7a
operator = "+" / "-" / "*" / "/" / "%" / "&" / "|" /
"^" / "~" / "<<" / ">>"
When parsing for tokens, the longest match is applied, i.e., a token is the longest string that matches the <token> rule specified above.
解析令牌时，应用最长匹配，即令牌是与上面指定的<token>规则匹配的最长字符串。
The syntax of whitespace and comments is specified by the following ABNF:
空格和注释的语法由以下ABNF指定：
ws = *(%x09 / %x0a / %x0d / %x20 / comment)
comment = ";" *(%x00-09 / %x0b-0c / %x0e-ff)
(%x0a / %x0d)
ws = *(%x09 / %x0a / %x0d / %x20 / comment)
comment = ";" *(%x00-09 / %x0b-0c / %x0e-ff)
(%x0a / %x0d)
Whitespace that matches <ws> is skipped between tokens, but serves to terminate the longest match for a token.
匹配<ws>的空格在标记之间跳过，但用于终止标记的最长匹配。
Comments are specified by the symbol ";" and are terminated by the end of the line, for example:
注释由符号“；”指定，并在行尾终止，例如：
LOAD (temp, 1) ; This is a comment.
负载（温度，1）；这是一个评论。
Any other input is a syntax error.
任何其他输入都是语法错误。
When parsing on the lexical level, the string of assembly should be divided up into a list of successive tokens. The whitespace and comments should also be deleted. The assembly should then be parsed on the syntactic level as explained in Section 3.2.
在词法级别进行解析时，程序集的字符串应划分为连续标记的列表。空白和注释也应该删除。然后，如第3.2节所述，应在语法层面上解析程序集。
Once the string of assembly has been divided into tokens as per Section 3.1, the next step is to convert the assembly into a string of UDVM bytecode.
根据第3.1节将程序集字符串划分为令牌后，下一步是将程序集转换为UDVM字节码字符串。
On a syntactic level, a string of assembly consists of zero or more instructions, directives, or labels, each of which is itself built up from one or more lexical tokens.
在语法级别上，程序集字符串由零个或多个指令、指令或标签组成，每个指令、指令或标签本身都是由一个或多个词汇标记构建的。
The following ABNF description specifies the syntax of the assembly language. Note that the lexical parsing step is assumed to have been carried out; so in particular, the boundaries between tokens are already known, and the comments and whitespace have been deleted:
以下ABNF说明指定了汇编语言的语法。注意，假设已经执行了词法分析步骤；因此，特别是令牌之间的边界已经已知，注释和空白已经删除：
assembly = *(instruction / directive / label)
instruction = opcode ["(" operand *("," operand) ")"]
operand = [["$"] expression]
; Operands can be left blank if they can
; be automatically inferred by the
; compiler, e.g., a literal operand
; that specifies the total number of
; operands for the instruction.
; When "$" is prepended to an operand,
; the corresponding integer is an
; address rather than the actual operand
; value. This symbol is mandatory for
; reference operands, optional for
; multitypes and addresses, and
; disallowed for literals.
label = ":" name
directive = padding / data / set / readonly /
unknown-directive
unknown-directive = name ["(" expression *("," expression) ")"]
; The parser can ignore unknown
; directives. The resulting bytecode
; may or may not generate the expected
; results.
padding = ("pad" / "align" / "at") "(" expression ")"
data = ("byte" / "word") "(" expression *(","
expression) ")"
readonly = "readonly" "(" "0" / "1" ")"
set = "set" "(" name "," expression ")"
expression = value / "(" expression operator expression ")"
value = dec / bin / hex / name / "." / "!"
; "." is the location of this
; instruction/directive, whereas "!" is
; the location of the closest
; DECOMPRESSION-FAILURE
assembly = *(instruction / directive / label)
instruction = opcode ["(" operand *("," operand) ")"]
operand = [["$"] expression]
; Operands can be left blank if they can
; be automatically inferred by the
; compiler, e.g., a literal operand
; that specifies the total number of
; operands for the instruction.
; When "$" is prepended to an operand,
; the corresponding integer is an
; address rather than the actual operand
; value. This symbol is mandatory for
; reference operands, optional for
; multitypes and addresses, and
; disallowed for literals.
label = ":" name
directive = padding / data / set / readonly /
unknown-directive
unknown-directive = name ["(" expression *("," expression) ")"]
; The parser can ignore unknown
; directives. The resulting bytecode
; may or may not generate the expected
; results.
padding = ("pad" / "align" / "at") "(" expression ")"
data = ("byte" / "word") "(" expression *(","
expression) ")"
readonly = "readonly" "(" "0" / "1" ")"
set = "set" "(" name "," expression ")"
expression = value / "(" expression operator expression ")"
value = dec / bin / hex / name / "." / "!"
; "." is the location of this
; instruction/directive, whereas "!" is
; the location of the closest
; DECOMPRESSION-FAILURE
The following sections define how to convert the instructions, labels and directives into UDVM bytecode:
以下各节定义了如何将指令、标签和指令转换为UDVM字节码：
The operand values needed by particular instructions or directives can be given in the form of expressions. An expression can include one or more values specified as decimal, binary, or hex (binary values are preceded by "0b" and hex values are preceded by "0x"). The expression may also include one or more of the following operators:
特定指令或指令所需的操作数值可以用表达式的形式给出。表达式可以包括一个或多个指定为十进制、二进制或十六进制的值（二进制值前面有“0b”，十六进制值前面有“0x”）。表达式还可以包括以下一个或多个运算符：
"+" Addition "-" Subtraction "*" Multiplication "/" Integer division "%" Modulo arithmetic (a%b := a modulo b) "&" Binary AND "|" Binary OR "^" Binary XOR "~" Binary XNOR "<<" Binary LSHIFT ">>" Binary RSHIFT
“+”加法“-”减法“*”乘法“/”整数除法“%”模运算（a%b:=a模b）&“二进制和“|”二进制或“^”二进制异或“~”二进制XNOR“<<”二进制LSHIFT“>>”二进制RSHIFT
The operands for each operator must always be surrounded by parentheses so that the order in which the operators should be evaluated is clear. For example:
每个运算符的操作数必须始终用括号括起来，以便明确运算符的求值顺序。例如：
((1 + (2 * 3)) & (0xabcd - 0b00101010)) gives the result 3.
（（1+（2*3））和（0xabcd-0b0101010））给出结果3。
Expressions can also include the special values "." and "!". When the symbol "." is encountered, it is replaced by the location in the bytecode of the current instruction/directive. When the symbol "!" is encountered it is replaced by the location in the bytecode of the closest DECOMPRESSION-FAILURE instruction (i.e., the closest zero byte). This can be useful when writing UDVM instructions that call a decompression failure, for example:
表达式还可以包括特殊值“.”和“！”。遇到符号“.”时，它将替换为当前指令/指令字节码中的位置。当遇到符号“！”时，它将被最近的解压失败指令（即，最近的零字节）字节码中的位置替换。这在编写调用解压缩失败的UDVM指令时非常有用，例如：
INPUT-BYTES (1, temp, !)
输入字节（1，温度，！）
The above instruction causes a decompression failure to occur if it tries to input data from beyond the end of the compressed message.
如果上面的指令试图从压缩消息的末尾以外输入数据，则会导致解压缩失败。
Note: When using "!" in the assembly language to generate bytecode, care must be taken to ensure that the address of the zero used at bytecode generation time will still contain zero when the bytecode is run. The readonly directive (see Section 3.2.3) can be used to do this.
注意：在汇编语言中使用“！”生成字节码时，必须注意确保在字节码生成时使用的零地址在字节码运行时仍然包含零。只读指令（见第3.2.3节）可用于执行此操作。
It is also possible to assign integer values to text names: when a text name is encountered in an expression, it is replaced by the integer value assigned to it. Section 3.2.3 explains how to assign integer values to text names.
还可以将整数值指定给文本名称：当表达式中遇到文本名称时，它将替换为指定给它的整数值。第3.2.3节解释了如何将整数值分配给文本名称。
A UDVM instruction is specified by the instruction opcode followed by zero or more operands. The instruction operands are enclosed in parentheses and separated by commas, for example:
UDVM指令由指令操作码后跟零个或多个操作数指定。指令操作数用括号括起并用逗号分隔，例如：
ADD ($3, 4)
加上（3,4美元）
When generating the bytecode, the parser should replace the instruction opcode with the corresponding 1-byte value as per Figure 11 of SigComp [2].
在生成字节码时，解析器应按照SigComp[2]的图11用相应的1字节值替换指令操作码。
Each operand consists of an expression that evaluates to an integer, optionally preceded by the symbol "$". This symbol indicates that the supplied integer value must be interpreted as the memory address at which the operand value can be found, rather than the actual operand value itself.
每个操作数由一个计算结果为整数的表达式组成，可以选择前面加符号“$”。此符号表示提供的整数值必须解释为可以找到操作数值的内存地址，而不是实际操作数值本身。
When converting each instruction operand to bytecode, the parser first determines whether the instruction expects the operand to be a literal, a reference, a multitype, or an address. If the operand is a literal, then, as per Figure 8 of SigComp, the parser inserts bytecode (usually the shortest) capable of encoding the supplied operand value.
当将每个指令操作数转换为字节码时，解析器首先确定指令希望操作数是文本、引用、多类型还是地址。如果操作数是一个文本，那么，如SigComp的图8所示，解析器插入能够对提供的操作数值进行编码的字节码（通常是最短的）。
Since literal operands are used to indicate the total number of operands for an instruction, it is possible to leave a literal operand blank and allow its value to be inferred automatically by the assembler. For example:
由于文字操作数用于指示指令的操作数总数，因此可以将文字操作数留空，并允许汇编程序自动推断其值。例如：
MULTILOAD (64, , 1, 2, 3, 4)
多负载（64,1,2,3,4）
The missing operand should be given the value 4 because it is followed by a total of 4 operands.
缺少的操作数应给定值4，因为它后面总共有4个操作数。
If the operand is a reference, then, as per Figure 9 of SigComp, the parser inserts bytecode (usually the shortest) capable of encoding the supplied memory address. Note that reference operands will always be preceded by the symbol "$" in assembly because they always encode memory addresses rather than actual operand values.
如果操作数是一个引用，那么，如SigComp的图9所示，解析器插入能够对提供的内存地址进行编码的字节码（通常是最短的）。请注意，在汇编中，引用操作数的前面总是带有符号“$”，因为它们总是对内存地址而不是实际操作数值进行编码。
If the operand is a multitype, then the parser first checks whether the symbol "$" is present. If so, then, as per Figure 10 of SigComp, it inserts bytecode (usually the shortest) capable of encoding the supplied integer as a memory address. If not, then, as per Figure 10 of SigComp, it inserts bytecode (usually the shortest) that encodes the supplied integer as an operand value.
如果操作数是多类型的，则解析器首先检查符号“$”是否存在。如果是这样，那么，根据SigComp的图10，它插入字节码（通常是最短的），能够将提供的整数编码为内存地址。如果没有，则按照SigComp的图10，它插入字节码（通常是最短的），将提供的整数编码为操作数值。
If the operand is an address, then the parser checks whether the symbol "$" is present. If so, then the supplied integer is encoded as a memory address, just as for the multitype instruction above. If not, then the byte position of the opcode is subtracted from the supplied integer modulo 16, and the result is encoded as an operand value as per Figure 10 of SigComp.
如果操作数是地址，则解析器检查符号“$”是否存在。如果是这样，那么提供的整数将被编码为内存地址，就像上面的多类型指令一样。如果不是，则从提供的整数模16中减去操作码的字节位置，并按照SigComp的图10将结果编码为操作数值。
The length of the resulting bytecode is dependent on the parser in use. There can be several correct and usable representations of the same instruction.
结果字节码的长度取决于使用的解析器。同一条指令可以有几种正确且可用的表示形式。
The assembly language provides a number of directives for evaluating expressions, moving instructions to a particular memory address, etc.
汇编语言为计算表达式、将指令移动到特定内存地址等提供了大量指令。
The directives "pad", "align", and "at" can be used to add padding to the bytecode.
指令“pad”、“align”和“at”可用于向字节码添加填充。
The directive "pad (n)" appends n consecutive padding bytes to the bytecode. The actual value of the padding bytes is unimportant, so when the bytecode is uploaded to the UDVM, the padding bytes can be set to the initial values contained in the UDVM memory (this helps to reduce the size of a SigComp message).
指令“pad（n）”向字节码追加n个连续的填充字节。填充字节的实际值并不重要，因此当字节码上载到UDVM时，可以将填充字节设置为UDVM内存中包含的初始值（这有助于减小SigComp消息的大小）。
The directive "align (n)" appends the minimum number of padding bytes to the bytecode such that the total number of bytes of bytecode generated so far is a multiple of n bytes. If the bytecode is already aligned to a multiple of n bytes, then no padding bytes are added.
指令“align（n）”将最小填充字节数附加到字节码，以便迄今为止生成的字节码总字节数是n字节的倍数。如果字节码已对齐到n字节的倍数，则不添加填充字节。
The directive "at (n)" appends enough padding bytes to the bytecode such that the total number of bytes of bytecode generated so far is exactly n bytes. If more than n bytes have already been generated before the "at" directive is encountered then the assembly code contains an error.
指令“at（n）”将足够的填充字节添加到字节码中，以便到目前为止生成的字节码的总字节数正好是n字节。如果在遇到“at”指令之前已生成超过n个字节，则汇编代码包含错误。
The directives "byte" and "word" can be used to add specific data strings to the bytecode.
指令“byte”和“word”可用于向字节码添加特定的数据字符串。
The directive "byte (n[0],..., n[k-1])" appends k consecutive bytes to the bytecode. The byte string is supplied as expressions that evaluate to give integers n[0],..., n[k-1] from 0 to 255.
指令“byte（n[0]，…，n[k-1]）将k个连续字节追加到字节码。字节字符串作为表达式提供，这些表达式计算得出0到255之间的整数n[0]，…，n[k-1]。
The directive "word (n[0],..., n[k-1])" appends k consecutive 2-byte words to the bytecode. The word string is supplied as expressions that evaluate to give integers n[0],..., n[k-1] from 0 to 65535.
指令“字（n[0]，…，n[k-1]）将k个连续的2字节字附加到字节码。字符串作为表达式提供，这些表达式计算得出0到65535之间的整数n[0]，…，n[k-1]。
The directive "set (name, n)" assigns an integer value n to a specified text name. The integer value can be supplied in the form of an expression.
指令“set（name，n）”将整数值n指定给指定的文本名称。整数值可以以表达式的形式提供。
The directive "readonly (n)" where n is 0 or 1 can be used to indicate that an area of memory could be changed (0) or will not be changed (1) during the execution of the UDVM. This directive could be used, for example, in conjunction with "!" to ensure that the address of the zero used will still contain zero when the bytecode is executed. If no readonly directive is used, then any address containing zero can be used by "!" (i.e., by default, there is assumed to be a readonly (1) directive at Address 0) and it is up to the author of the assembly code to ensure that the address in question will still contain zero when the bytecode is executed. If the readonly directive is used, then bytes between a readonly (0) and readonly (1) pair are NOT to be used by "!". When a readonly directive has been used, the bytes obey that directive from that address to either another readonly directive or the end of UDVM memory, whichever comes first.
指令“readonly（n）”，其中n为0或1，可用于指示在UDVM执行期间内存区域可以更改（0）或不会更改（1）。例如，该指令可与“！”结合使用，以确保在执行字节码时所用零的地址仍包含零。如果未使用只读指令，则任何包含零的地址都可以由“！”使用（即，默认情况下，地址0处假定有一个只读（1）指令），并且由汇编代码的作者来确保在执行字节码时，所讨论的地址仍然包含零。如果使用readonly指令，则readonly（0）和readonly（1）对之间的字节不能由“！”使用。当使用只读指令时，从该地址到另一个只读指令或UDVM内存的末尾（以先到者为准），字节遵循该指令。
A label is a special directive used to assign memory addresses to text names.
标签是一种特殊指令，用于将内存地址分配给文本名称。
Labels are specified by a single colon followed by the text name to be defined. The (absolute) position of the byte immediately following the label is evaluated and assigned to the text name. For example:
标签由一个冒号指定，后跟要定义的文本名称。将计算紧跟在标签后面的字节的（绝对）位置，并将其指定给文本名称。例如：
:start
：开始
LOAD (temp, 1)
负载（温度，1）
Since the label "start" occurs at the beginning of the bytecode, it is assigned the integer value 0.
因为标签“start”出现在字节码的开头，所以它被赋予整数值0。
Note that writing the label ":name" has exactly the same behavior as writing the directive "set (name, .)".
请注意，写入label“：name”的行为与写入指令“set（name，.）”的行为完全相同。
Once the parser has converted a string of assembly into the corresponding bytecode, it must be copied to the UDVM memory beginning at Address 0 and then executed, beginning from the first UDVM instruction in the bytecode.
解析器将程序集字符串转换为相应的字节码后，必须将其从地址0复制到UDVM内存，然后从字节码中的第一条UDVM指令开始执行。
SigComp provides the following message format for uploading bytecode to the UDVM:
SigComp提供以下消息格式，用于将字节码上载到UDVM：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 | T | 0 |
+---+---+---+---+---+---+---+---+
| |
: returned feedback item : if T = 1
| |
+---+---+---+---+---+---+---+---+
| code_len |
+---+---+---+---+---+---+---+---+
| code_len | destination |
+---+---+---+---+---+---+---+---+
| |
: uploaded UDVM bytecode :
| |
+---+---+---+---+---+---+---+---+
| |
: remaining SigComp message :
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 | T | 0 |
+---+---+---+---+---+---+---+---+
| |
: returned feedback item : if T = 1
| |
+---+---+---+---+---+---+---+---+
| code_len |
+---+---+---+---+---+---+---+---+
| code_len | destination |
+---+---+---+---+---+---+---+---+
| |
: uploaded UDVM bytecode :
| |
+---+---+---+---+---+---+---+---+
| |
: remaining SigComp message :
| |
+---+---+---+---+---+---+---+---+
The destination field should be set to the memory address of the first UDVM instruction. Note that if this address cannot be represented by the destination field, then the bytecode cannot be uploaded to the UDVM using the standard SigComp header. In particular, the memory address of the first UDVM instruction must always be a multiple of 64 bytes or the standard SigComp header cannot be used. Of course, there may be other ways to upload the bytecode to the UDVM, such as retrieving the bytecode directly via the INPUT-BYTES instruction.
目标字段应设置为第一条UDVM指令的内存地址。注意，如果目标字段不能表示此地址，则无法使用标准SigComp头将字节码上载到UDVM。特别是，第一条UDVM指令的内存地址必须始终是64字节的倍数，否则无法使用标准SigComp头。当然，可能还有其他方法将字节码上载到UDVM，例如通过INPUT-BYTES指令直接检索字节码。
Additionally, all memory addresses between Address 0 and Address 31 inclusive are initialized to endpoint-specific values by the UDVM, so they must be specified as padding in the bytecode, or the standard SigComp header cannot be used. Memory addresses from Address 32 to Address (destination - 1) inclusive are initialized to 0, so they must be specified either as padding or as 0s if the bytecode is to be successfully uploaded using the standard SigComp header.
此外，地址0和地址31（含）之间的所有内存地址都由UDVM初始化为特定于端点的值，因此它们必须在字节码中指定为填充，否则无法使用标准SigComp头。如果要将地址从0（包含）加载到目标，则必须将地址从0（包含）加载到目标。如果要将地址从0（包含）加载到目标，则必须将地址从0（包含）加载到目标字节码。
The code_len field should be set to the smallest value such that all memory addresses beginning at Address (destination + code_len) are either as initialised by the UDVM (to 0) or as set by the bytecode at runtime.
code_len字段应设置为最小值，以便从Address（destination+code_len）开始的所有内存地址要么由UDVM初始化（设置为0），要么由字节码在运行时设置。
The "uploaded UDVM bytecode" should be set to contain the segment of bytecode that lies between Address (destination) and Address (destination + code_len - 1) inclusive.
“上传的UDVM字节码”应设置为包含地址（目的地）和地址（目的地+代码长度-1）之间的字节码段。
This section describes a number of compression algorithms that can be used by a SigComp compressor. In each case, the document provides UDVM bytecode for the corresponding decompression algorithm, which can be uploaded to the receiving endpoint as part of a SigComp message. Each algorithm (as written in this section) assumes that there is a 16K decompression memory size, there are 16 cycles per bit, and there is an 8K state memory size. Decompression will succeed with a smaller value for state memory size; however, the full state will not be created.
本节介绍了SigComp压缩器可以使用的许多压缩算法。在每种情况下，文档都为相应的解压缩算法提供UDVM字节码，该字节码可以作为SigComp消息的一部分上载到接收端点。每个算法（如本节所述）都假定有16K的解压缩内存大小，每比特有16个周期，并且有8K的状态内存大小。解压将成功，状态内存大小的值较小；但是，将不会创建完整状态。
Section 4.1.1 covers a simple algorithm in some detail, including the steps required to compress and decompress a SigComp message. The remaining sections cover well-known compression algorithms that can be adapted for use in SigComp with minimal modification.
第4.1.1节详细介绍了一个简单的算法，包括压缩和解压缩SigComp消息所需的步骤。剩下的部分介绍了一些众所周知的压缩算法，这些算法只需稍加修改即可用于SigComp。
This section describes how to implement a very simple compression algorithm based on LZ77 [5].
本节介绍如何基于LZ77实现一个非常简单的压缩算法[5]。
A compressed message generated by the simplified LZ77 scheme consists of a sequence of 4-byte characters, where each character contains a 2-byte position value followed by a 2-byte length value. Each pair of integers identifies a byte string in the UDVM memory; when concatenated, these byte strings form the decompressed message.
由简化LZ77方案生成的压缩消息由一个4字节字符序列组成，其中每个字符包含一个2字节的位置值，后跟一个2字节的长度值。每对整数标识UDVM内存中的一个字节字符串；连接时，这些字节字符串形成解压缩消息。
When implementing a bytecode decompressor for the simplified LZ77 scheme, the UDVM memory is partitioned into five distinct areas, as shown below:
在为简化的LZ77方案实现字节码解压器时，UDVM内存被划分为五个不同的区域，如下所示：
0 64 128 256 512
| scratch-pad | variables | bytecode | dictionary | circular buffer |
+-------------+-----------+----------+------------+-----------------+
<-----------> <---------> <--------> <----------> <--------------->
64 bytes 64 bytes 128 bytes 256 bytes 512+ bytes
0 64 128 256 512
| scratch-pad | variables | bytecode | dictionary | circular buffer |
+-------------+-----------+----------+------------+-----------------+
<-----------> <---------> <--------> <----------> <--------------->
64 bytes 64 bytes 128 bytes 256 bytes 512+ bytes
The first 128 bytes are used to hold the 2-byte variables needed by the LZ77 decompressor. Within this memory, the first 64 bytes are used as a scratch-pad, holding the 2-byte variables that can be discarded between SigComp messages. In contrast, the next 64 bytes (and in fact all of the UDVM memory starting from Address 64) should be saved after decompressing a SigComp message to improve the compression ratio of subsequent messages.
前128个字节用于保存LZ77解压器所需的2字节变量。在该内存中，前64个字节用作暂存器，保存可在SigComp消息之间丢弃的2字节变量。相反，接下来的64个字节（以及实际上从地址64开始的所有UDVM内存）应该在解压缩SigComp消息后保存，以提高后续消息的压缩比。
The bytecode for the LZ77 decompressor is stored beginning at Address 128. A total of 128 bytes are reserved for the bytecode although the LZ77 decompressor requires less; this allows room for adding additional features to the decompressor at a later stage.
LZ77解压器的字节码从地址128开始存储。虽然LZ77解压器需要的字节数更少，但字节码总共保留了128个字节；这允许在以后的阶段向解压器添加附加功能。
The next 256 bytes are initialized by the bytecode to contain the integers 0 to 255 inclusive. The purpose of this memory area is to provide a dictionary of all possible uncompressed characters; this is important to ensure that the compressor can always generate a sequence of position/length pairs that encode a given message. For example, a byte with value 0x41 (corresponding to the ASCII character "A") can be found at Address 0x0141 of the UDVM memory, so the compressed character 0x0141 0001 will decompress to give this ASCII character. Note that encoding each byte in the application message as a separate 4-byte compressed character is not recommended, however, as the resulting "compressed" message is four times as large as the original uncompressed message.
接下来的256个字节由字节码初始化，以包含0到255（含0到255）的整数。该存储区的用途是提供所有可能未压缩字符的字典；这对于确保压缩器始终能够生成编码给定消息的位置/长度对序列非常重要。例如，可以在UDVM内存的地址0x0141处找到一个值为0x41（对应于ASCII字符“a”）的字节，因此压缩字符0x0141 0001将解压缩以提供此ASCII字符。请注意，不建议将应用程序消息中的每个字节编码为单独的4字节压缩字符，但是，由于生成的“压缩”消息是原始未压缩消息的四倍大。
The compression ratio of LZ77 is improved by the remaining UDVM memory, which is used to store a history buffer containing the previously decompressed messages. Compressed characters can point to strings that have previously been decompressed and stored in the buffer, so the overall compression ratio of the LZ77 algorithm improves as the decompressor "learns" more text strings and is able to encode longer strings using a single compressed character. The buffer is circular, so older messages are overwritten by new data when the buffer becomes full.
剩余的UDVM内存提高了LZ77的压缩比，该内存用于存储包含先前解压缩消息的历史缓冲区。压缩字符可以指向先前已解压缩并存储在缓冲区中的字符串，因此LZ77算法的整体压缩比随着解压器“学习”更多文本字符串而提高，并且能够使用单个压缩字符编码更长的字符串。缓冲区是循环的，因此当缓冲区满时，旧消息会被新数据覆盖。
The steps required to implement an LZ77 compressor and decompressor are similar, although compression is more processor-intensive as it requires a searching operation to be performed. Assembly for the simplified LZ77 decompressor is given below:
实现LZ77压缩器和解压缩器所需的步骤是类似的，尽管压缩需要执行搜索操作，因此更需要处理器。简化LZ77减压器的装配如下所示：
; Variables that do not need to be stored after decompressing each ; SigComp message are stored here:
; 解压缩后不需要存储的变量；SigComp消息存储在此处：
at (32)
at（32）
:position_value pad (2) :length_value pad (2)
：位置值垫（2）：长度值垫（2）
at (42)
at（42）
set (requested_feedback_location, 0)
设置（请求的\u反馈\u位置，0）
; The UDVM registers must be stored beginning at Address 64:
; UDVM寄存器必须从地址64开始存储：
at (64)
at（64）
; Variables that should be stored after decompressing a message are
; stored here. These variables will form part of the SigComp state
; item created by the bytecode:
; Variables that should be stored after decompressing a message are
; stored here. These variables will form part of the SigComp state
; item created by the bytecode:
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:decompressed_pointer pad (2)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:decompressed_pointer pad (2)
set (returned_parameters_location, 0)
设置（返回的\u参数\u位置，0）
align (64)
对齐（64）
:initialize_memory
：初始化内存
set (udvm_memory_size, 8192) set (state_length, (udvm_memory_size - 64))
集合（udvm_内存_大小，8192）集合（状态长度，（udvm_内存_大小-64））
; The UDVM registers byte_copy_left and byte_copy_right are set to
; indicate the bounds of the circular buffer in the UDVM memory. A
; variable decompressed_pointer is also created and set pointing to
; the start of the circular buffer:
; The UDVM registers byte_copy_left and byte_copy_right are set to
; indicate the bounds of the circular buffer in the UDVM memory. A
; variable decompressed_pointer is also created and set pointing to
; the start of the circular buffer:
MULTILOAD (64, 3, circular_buffer, udvm_memory_size, circular_buffer)
多重加载（64，3，循环缓冲区，udvm内存大小，循环缓冲区）
; The "dictionary" area of the UDVM memory is initialized to contain ; the values 0 to 255 inclusive:
; UDVM内存的“字典”区域初始化为包含；值0到255（含0到255）：
MEMSET (static_dictionary, 256, 0, 1)
MEMSET（静态字典，256,0,1）
:decompress_sigcomp_message
：解压缩\u sigcomp\u消息
:next_character
：下一个字符
; The next character in the compressed message is read by the UDVM
; and the position and length integers are stored in the variables
; position_value and length_value, respectively. If no more
; compressed data is available, the decompressor jumps to the
; "end_of_message" subroutine:
; The next character in the compressed message is read by the UDVM
; and the position and length integers are stored in the variables
; position_value and length_value, respectively. If no more
; compressed data is available, the decompressor jumps to the
; "end_of_message" subroutine:
INPUT-BYTES (4, position_value, end_of_message)
输入字节（4，位置值，结束消息）
; The position_value and length_value point to a byte string in the
; UDVM memory, which is copied into the circular buffer at the
; position specified by decompressed_pointer. This allows the string
; to be referenced by later characters in the compressed message:
; The position_value and length_value point to a byte string in the
; UDVM memory, which is copied into the circular buffer at the
; position specified by decompressed_pointer. This allows the string
; to be referenced by later characters in the compressed message:
COPY-LITERAL ($position_value, $length_value, $decompressed_pointer)
复制文本（$position\u value、$length\u value、$decompressed\u指针）
; The byte string is also outputted onto the end of the decompressed ; message:
; 字节字符串也被输出到解压后的字符串的末尾；信息：
OUTPUT ($position_value, $length_value)
输出（$position\u value，$length\u value）
; The decompressor jumps back to consider the next character in the ; compressed message:
; 解压缩器跳回来考虑下一个字符；压缩信息：
JUMP (next_character)
跳转（下一个字符）
:end_of_message
：结束\u消息的\u
; The decompressor saves the UDVM memory and halts:
; 解压缩程序保存UDVM内存并停止：
END-MESSAGE (requested_feedback_location, returned_parameters_location, state_length, 64, decompress_sigcomp_message, 6, 0)
结束消息（请求的\u反馈\u位置，返回的\u参数\u位置，状态\u长度，64，解压缩\u sigcomp\u消息，6，0）
at (256)
at（256）
; Memory for the dictionary and the circular buffer are reserved by ; the following statements:
; 字典和循环缓冲区的内存由保留；以下声明：
:static_dictionary pad (256) :circular_buffer
：静态\u字典垫（256）：循环\u缓冲区
The task of an LZ77 compressor is simply to discover a sequence of 4-byte compressed characters that the above bytecode will decompress to give the desired application message. As an example, a message compressed using the simplified LZ77 algorithm is given below:
LZ77压缩器的任务只是发现一个4字节压缩字符序列，上面的字节码将对该序列进行解压缩，以给出所需的应用程序消息。作为示例，下面给出了使用简化LZ77算法压缩的消息：
0x0154 0001 0168 0001 0165 0001 0120 0001 0152 0001 0165 0001 0173 0x0002 0161 0001 0175 0001 0172 0001 0161 0001 016e 0001 0174 0001 0x0120 0001 0161 0001 020d 0002 0174 0001 0201 0003 0145 0001 016e 0x0001 0164 0001 0120 0001 016f 0001 0166 0001 0211 0005 0155 0001 0x016e 0001 0169 0001 0176 0001 0165 0001 0172 0002 0165 0001 010a 0x0001
0x0154 0001 0168 0001 0165 0001 0120 0001 0152 0001 0165 0001 0173 0x0002 0161 0001 0175 0001 0172 0001 0161 0001 016e 0001 0174 0001 0x0120 0001 0161 0001 020d 0002 0174 0001 0201 0003 0145 0001 016e 0x0001 0164 0001 0120 0001 016f 0001 0166 0001 021 0005 0155 0001 0x016e 0001 016 0001 019 0001 0176 0001 0165 0001 0172 0002 0165 0001 010a 0x0001
The uncompressed message is "The Restaurant at the End of the Universe\n".
未压缩的消息是“宇宙尽头的餐厅\n”。
The bytecode for the LZ77 decompressor can be uploaded as part of the compressed message, as specified in Section 3.3. However, in order to improve the overall compression ratio, it is important to avoid uploading bytecode in every compressed message. For this reason, SigComp allows the UDVM to save an area of its memory as a state item between compressed messages. Once a state item has been created, it can be retrieved by sending the corresponding state identifier using the following SigComp message format:
LZ77解压器的字节码可以作为压缩消息的一部分上传，如第3.3节所述。但是，为了提高整体压缩比，避免在每个压缩消息中上载字节码是很重要的。因此，SigComp允许UDVM将其内存区域保存为压缩消息之间的状态项。创建状态项后，可以通过使用以下SigComp消息格式发送相应的状态标识符来检索该状态项：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 | T | 1 |
+---+---+---+---+---+---+---+---+
| |
: returned feedback item : if T = 1
| |
+---+---+---+---+---+---+---+---+
| |
: partial state identifier :
| |
+---+---+---+---+---+---+---+---+
| |
: remaining SigComp message :
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 | T | 1 |
+---+---+---+---+---+---+---+---+
| |
: returned feedback item : if T = 1
| |
+---+---+---+---+---+---+---+---+
| |
: partial state identifier :
| |
+---+---+---+---+---+---+---+---+
| |
: remaining SigComp message :
| |
+---+---+---+---+---+---+---+---+
The partial_state_identifier field must contain the first 6 bytes of the state identifier for the state item to be accessed (see [2] for details of how state identifiers are derived).
部分_state_identifier字段必须包含要访问的状态项的状态标识符的前6个字节（有关如何派生状态标识符的详细信息，请参见[2]）。
Note that the partial_state_identifier field could be 9 or 12 bytes and that in these cases, bits 6 and 7 of the first byte of the message would be 10 or 11, respectively.
请注意，partial_state_identifier字段可以是9或12个字节，在这些情况下，消息的第一个字节的位6和7将分别是10或11。
This section provides UDVM bytecode for the simple but effective LZSS compression algorithm [6].
本节为简单但有效的LZSS压缩算法提供UDVM字节码[6]。
The principal improvement offered by LZSS over LZ77 is that each compressed character begins with a 1-bit indicator flag to specify whether the character is a literal or an offset/length pair. A literal value is simply a single uncompressed byte that is appended directly to the decompressed message.
LZSS对LZ77的主要改进是，每个压缩字符都以1位指示符标志开始，以指定字符是文字对还是偏移量/长度对。文字值只是直接附加到解压缩消息的单个未压缩字节。
An offset/length pair contains a 12-bit offset value from 1 to 4096 inclusive, followed by a 4-bit length value from 3 to 18 inclusive. Taken together, these values specify one of the previously received
偏移/长度对包含从1到4096（含）的12位偏移值，然后是从3到18（含）的4位长度值。总之，这些值指定了以前接收到的
text strings in the circular buffer, which is then appended to the end of the decompressed message.
循环缓冲区中的文本字符串，然后将其附加到解压缩消息的末尾。
Assembly for an LZSS decompressor is given below:
LZSS减压器的装配如下所示：
at (32) readonly (0)
at（32）只读（0）
:index pad (2)
:length_value pad (2)
:old_pointer pad (2)
:index pad (2)
:length_value pad (2)
:old_pointer pad (2)
at (42)
at（42）
set (requested_feedback_location, 0)
设置（请求的\u反馈\u位置，0）
at (64)
at（64）
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:decompressed_pointer pad (2)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:decompressed_pointer pad (2)
set (returned_parameters_location, 0)
设置（返回的\u参数\u位置，0）
align (64) readonly (1)
对齐（64）只读（1）
:initialize_memory
：初始化内存
set (udvm_memory_size, 8192) set (state_length, (udvm_memory_size - 64))
集合（udvm_内存_大小，8192）集合（状态长度，（udvm_内存_大小-64））
MULTILOAD (64, 4, circular_buffer, udvm_memory_size, 0, circular_buffer)
多加载（64，4，循环缓冲区，udvm内存大小，0，循环缓冲区）
:decompress_sigcomp_message
：解压缩\u sigcomp\u消息
:next_character
：下一个字符
INPUT-HUFFMAN (index, end_of_message, 2, 9, 0, 255, 16384, 4, 4096, 8191, 1) COMPARE ($index, 8192, length, end_of_message, literal)
INPUT-HUFFMAN（索引、消息结尾、2、9、0、255、16384、4、4096、8191、1）比较（$index、8192、长度、消息结尾、文字）
:literal
：文字
set (index_lsb, (index + 1))
集合（索引_lsb，（索引+1））
OUTPUT (index_lsb, 1) COPY-LITERAL (index_lsb, 1, $decompressed_pointer) JUMP (next_character)
输出（索引\u lsb，1）拷贝文本（索引\u lsb，1，$decompressed\u指针）跳转（下一个\u字符）
:length
：长度
INPUT-BITS (4, length_value, !) ADD ($length_value, 3) LOAD (old_pointer, $decompressed_pointer) COPY-OFFSET ($index, $length_value, $decompressed_pointer) OUTPUT ($old_pointer, $length_value) JUMP (next_character)
输入位（4，长度值，！）添加（$length\u value，3）加载（$old\u指针，$decompressed\u指针）复制偏移（$index，$length\u值，$decompressed\u指针）输出（$old\u指针，$length\u值）跳转（下一个字符）
:end_of_message
：结束\u消息的\u
END-MESSAGE (requested_feedback_location, returned_parameters_location, state_length, 64, decompress_sigcomp_message, 6, 0)
结束消息（请求的\u反馈\u位置，返回的\u参数\u位置，状态\u长度，64，解压缩\u sigcomp\u消息，6，0）
readonly (0) :circular_buffer
只读（0）：循环缓冲区
An example of a message compressed using the LZSS algorithm is given below:
下面给出了使用LZSS算法压缩的消息示例：
0x279a 0406 e378 b200 6074 1018 4ce6 1349 b842
0x279a 0406 e378 b200 6074 1018 4ce6 1349 b842
The uncompressed message is "Oh no, not again!".
未压缩的消息是“哦，不，不要再这样了！”。
This section provides UDVM bytecode for the well-known LZW compression algorithm LZW [7]. This algorithm is used in a number of standards including the GIF image format.
本节提供了著名的LZW压缩算法LZW[7]的UDVM字节码。该算法在许多标准中使用，包括GIF图像格式。
LZW compression operates in a similar manner to LZ77 in that it maintains a circular buffer of previously received decompressed data, and each compressed character references exactly one byte string from the circular buffer. However, LZW also maintains a "codebook" containing 1024 position/length pairs that point to byte strings that LZW believes are most likely to occur in the uncompressed data.
LZW压缩的操作方式与LZ77相似，因为它维护一个先前接收到的解压缩数据的循环缓冲区，每个压缩字符恰好引用循环缓冲区中的一个字节字符串。然而，LZW还维护一个“码本”，其中包含1024个位置/长度对，指向LZW认为最有可能出现在未压缩数据中的字节字符串。
The byte strings stored in the LZW codebook can be referenced by sending a single 10-bit value from 0 to 1023 inclusive. The UDVM extracts the corresponding text string from the codebook and appends it to the end of the decompressed message. It then creates a new codebook entry containing the current text string and the next character to occur in the decompressed message.
LZW码本中存储的字节字符串可以通过发送一个从0到1023（含0到1023）的10位值来引用。UDVM从代码本中提取相应的文本字符串，并将其附加到解压缩消息的末尾。然后，它创建一个新的码本条目，其中包含当前文本字符串和解压缩消息中出现的下一个字符。
Assembly for an LZW decompressor is given below:
LZW减压器的总成如下所示：
at (32)
at（32）
:length_value pad (2)
:position_value pad (2)
:index pad (2)
:length_value pad (2)
:position_value pad (2)
:index pad (2)
at (42)
at（42）
set (requested_feedback_location, 0)
设置（请求的\u反馈\u位置，0）
at (64)
at（64）
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:codebook_next pad (2)
:current_length pad (2)
:decompressed_pointer pad (2)
:codebook_next pad (2)
:current_length pad (2)
:decompressed_pointer pad (2)
set (returned_parameters_location, 0)
设置（返回的\u参数\u位置，0）
align (64)
对齐（64）
:initialize_memory
：初始化内存
set (udvm_memory_size, 8192) set (state_length, (udvm_memory_size - 64))
集合（udvm_内存_大小，8192）集合（状态长度，（udvm_内存_大小-64））
MULTILOAD (64, 6, circular_buffer, udvm_memory_size, 0, codebook, 1, static_dictionary)
多重加载（64，6，循环缓冲区，udvm内存大小，0，码本，1，静态字典）
:initialize_codebook
：初始化\u码本
; The following instructions are used to initialize the first 256 ; entries in the LZW codebook with single ASCII characters:
; 以下指令用于初始化前256；LZW码本中具有单个ASCII字符的条目：
set (index_lsb, (index + 1)) set (current_length_lsb, (current_length + 1))
集合（索引\u lsb，（索引+1））集合（当前长度\u lsb，（当前长度+1））
COPY-LITERAL (current_length_lsb, 3, $codebook_next) COPY-LITERAL (index_lsb, 1, $decompressed_pointer) ADD ($index, 1) COMPARE ($index, 256, initialize_codebook, next_character, 0)
COPY-LITERAL（当前长度\u lsb，3，$codebook\u next）COPY-LITERAL（索引\u lsb，1，$decompressed\u指针）ADD（$index，1）COMPARE（$index，256，初始化\u码本，下一个\u字符，0）
:decompress_sigcomp_message
：解压缩\u sigcomp\u消息
:next_character
：下一个字符
; The following INPUT-BITS instruction extracts 10 bits from the ; compressed message:
; 以下输入位指令从数据中提取10位；压缩信息：
INPUT-BITS (10, index, end_of_message)
输入位（10，索引，消息结尾）
; The following instructions interpret the received bits as an index
; into the LZW codebook and extract the corresponding
; position/length pair:
; The following instructions interpret the received bits as an index
; into the LZW codebook and extract the corresponding
; position/length pair:
set (length_value_lsb, (length_value + 1))
设置（长度值（长度值+1））
MULTIPLY ($index, 3) ADD ($index, codebook) COPY ($index, 3, length_value_lsb)
乘（$index，3）加（$index，码本）拷贝（$index，3，长度\值\ lsb）
; The following instructions append the selected text string to the
; circular buffer and create a new codebook entry pointing to this
; text string:
; The following instructions append the selected text string to the
; circular buffer and create a new codebook entry pointing to this
; text string:
LOAD (current_length, 1) ADD ($current_length, $length_value) COPY-LITERAL (current_length_lsb, 3, $codebook_next) COPY-LITERAL ($position_value, $length_value, $decompressed_pointer)
加载（当前长度，1）添加（$current长度，$length长度，$length长度，$length长度，$lsb，3，$codebook\u下一个）复制文字（$position长度，$length长度，$decompressed长度）
; The following instruction outputs the text string specified by the ; position/length pair:
; 以下指令输出由指定的文本字符串；位置/长度对：
OUTPUT ($position_value, $length_value) JUMP (next_character)
输出（$position\u value，$length\u value）跳转（下一个字符）
:end_of_message
：结束\u消息的\u
END-MESSAGE (requested_feedback_location, returned_parameters_location, state_length, 64, decompress_sigcomp_message, 6, 0)
结束消息（请求的\u反馈\u位置，返回的\u参数\u位置，状态\u长度，64，解压缩\u sigcomp\u消息，6，0）
:static_dictionary pad (256) :circular_buffer
：静态\u字典垫（256）：循环\u缓冲区
at (4492)
电话：（4492）
:codebook
：码本
An example of a message compressed using the LZW algorithm is given below:
下面给出了使用LZW算法压缩的消息示例：
0x14c6 f080 6c1b c6e1 9c20 1846 e190 201d 0684 206b 1cc2 0198 6f1c 0x9071 b06c 42c6 8195 111a 4731 a021 02bf f0
0x14c6 f080 6c1b c6e1 9c20 1846 e190 201d 0684 206b 1cc2 0198 6f1c 0x9071 b06c 42c6 8195 111a 4731 a021 02bf f0
The uncompressed message is "So long and thanks for all the fish!\n".
未压缩的消息是“再见，谢谢所有的鱼！\n”。
This section provides UDVM bytecode for the DEFLATE compression algorithm. DEFLATE is the algorithm used in the well-known "gzip" file format.
本节为DEFLATE压缩算法提供UDVM字节码。DEFLATE是众所周知的“gzip”文件格式中使用的算法。
The following bytecode will decompress the DEFLATE compressed data format [8] with the following modifications:
通过以下修改，以下字节码将解压缩DEFLATE压缩数据格式[8]：
1. The DEFLATE compressed data format separates blocks of compressed data by transmitting 7 consecutive zero bits. Each SigComp message is assumed to contain a separate block of compressed data, so the end-of-block bits are implicit and do not need to be transmitted at the end of a SigComp message.
1. DEFLATE压缩数据格式通过传输7个连续零位来分离压缩数据块。假设每个SigComp消息都包含一个单独的压缩数据块，因此块结束位是隐式的，不需要在SigComp消息的末尾传输。
2. This bytecode supports only DEFLATE block type 01 (data compressed with fixed Huffman codes).
2. 此字节码仅支持DEFLATE块类型01（使用固定哈夫曼码压缩的数据）。
Assembly for the DEFLATE decompressor is given below:
放气减压器的总成如下所示：
at (32) readonly (0)
at（32）只读（0）
:index pad (2)
:extra_length_bits pad (2)
:length_value pad (2)
:extra_distance_bits pad (2)
:distance_value pad (2)
:index pad (2)
:extra_length_bits pad (2)
:length_value pad (2)
:extra_distance_bits pad (2)
:distance_value pad (2)
at (42)
at（42）
set (requested_feedback_location, 0)
设置（请求的\u反馈\u位置，0）
at (64)
at（64）
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:decompressed_pointer pad (2)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:decompressed_pointer pad (2)
:length_table pad (116) :distance_table pad (120)
：长度\台面（116）：距离\台面（120）
set (returned_parameters_location, 0)
设置（返回的\u参数\u位置，0）
align (64)
对齐（64）
readonly (1) :initialize_memory
只读（1）：初始化\u内存
set (udvm_memory_size, 8192)
set (state_length, (udvm_memory_size - 64))
set (length_table_start, (((length_table - 4) + 65536) / 4))
set (length_table_mid, (length_table_start + 24))
set (distance_table_start, (distance_table / 4))
set (udvm_memory_size, 8192)
set (state_length, (udvm_memory_size - 64))
set (length_table_start, (((length_table - 4) + 65536) / 4))
set (length_table_mid, (length_table_start + 24))
set (distance_table_start, (distance_table / 4))
MULTILOAD (64, 122, circular_buffer, udvm_memory_size, 5, circular_buffer,
多加载（64122，循环缓冲区，udvm内存大小，5，循环缓冲区，
0, 3, 0, 4, 0, 5, 0, 6, 0, 7, 0, 8, 0, 9, 0, 10, 1, 11, 1, 13, 1, 15, 1, 17, 2, 19, 2, 23, 2, 27, 2, 31, 3, 35, 3, 43, 3, 51, 3, 59, 4, 67, 4, 83, 4, 99, 4, 115, 5, 131, 5, 163, 5, 195, 5, 227, 0, 258,
0, 3, 0, 4, 0, 5, 0, 6, 0, 7, 0, 8, 0, 9, 0, 10, 1, 11, 1, 13, 1, 15, 1, 17, 2, 19, 2, 23, 2, 27, 2, 31, 3, 35, 3, 43, 3, 51, 3, 59, 4, 67, 4, 83, 4, 99, 4, 115, 5, 131, 5, 163, 5, 195, 5, 227, 0, 258,
0, 1, 0, 2, 0, 3, 0, 4, 1, 5, 1, 7, 2, 9, 2, 13, 3, 17, 3, 25, 4, 33, 4, 49, 5, 65, 5, 97, 6, 129, 6, 193, 7, 257, 7, 385, 8, 513, 8, 769, 9, 1025, 9, 1537, 10, 2049, 10, 3073, 11, 4097, 11, 6145, 12, 8193, 12, 12289, 13, 16385, 13, 24577)
0, 1, 0, 2, 0, 3, 0, 4, 1, 5, 1, 7, 2, 9, 2, 13, 3, 17, 3, 25, 4, 33, 4, 49, 5, 65, 5, 97, 6, 129, 6, 193, 7, 257, 7, 385, 8, 513, 8, 769, 9, 1025, 9, 1537, 10, 2049, 10, 3073, 11, 4097, 11, 6145, 12, 8193, 12, 12289, 13, 16385, 13, 24577)
:decompress_sigcomp_message
：解压缩\u sigcomp\u消息
INPUT-BITS (3, extra_length_bits, !)
输入位（3，额外长度位，！）
:next_character
：下一个字符
INPUT-HUFFMAN (index, end_of_message, 4, 7, 0, 23, length_table_start, 1, 48, 191, 0, 0, 192, 199, length_table_mid, 1, 400, 511, 144) COMPARE ($index, length_table_start, literal, end_of_message, length_distance)
INPUT-HUFFMAN（索引，消息结束，4,7,0,23，长度表开始，1,48,191,0,0,192,199，长度表中间，1400,511,144）比较（$index，长度表开始，文字，消息结束，长度距离）
:literal
：文字
set (index_lsb, (index + 1))
集合（索引_lsb，（索引+1））
OUTPUT (index_lsb, 1) COPY-LITERAL (index_lsb, 1, $decompressed_pointer) JUMP (next_character)
输出（索引\u lsb，1）拷贝文本（索引\u lsb，1，$decompressed\u指针）跳转（下一个\u字符）
:length_distance
：长度与距离
; this is the length part
; 这是长度部分
MULTIPLY ($index, 4) COPY ($index, 4, extra_length_bits) INPUT-BITS ($extra_length_bits, extra_length_bits, !) ADD ($length_value, $extra_length_bits)
乘法（$index，4）复制（$index，4，额外长度\u位）输入位（$额外长度\u位，额外长度\u位，！）加（$length\u值，$额外长度\u位）
; this is the distance part
; 这是距离部分
INPUT-HUFFMAN (index, !, 1, 5, 0, 31, distance_table_start) MULTIPLY ($index, 4) COPY ($index, 4, extra_distance_bits)
INPUT-HUFFMAN（索引，！，1，5，0，31，距离表开始）乘法（$index，4）复制（$index，4，额外距离位）
INPUT-BITS ($extra_distance_bits, extra_distance_bits, !) ADD ($distance_value, $extra_distance_bits) LOAD (index, $decompressed_pointer) COPY-OFFSET ($distance_value, $length_value, $decompressed_pointer) OUTPUT ($index, $length_value) JUMP (next_character)
输入位（$extra_distance_BITS，extra_distance_BITS，！）添加（$distance_value，$extra_distance_BITS）加载（索引，$decompressed_指针）复制偏移（$distance_value，$length_值，$decompressed_指针）输出（$index，$length_值）跳转（下一个字符）
:end_of_message
：结束\u消息的\u
END-MESSAGE (requested_feedback_location, returned_parameters_location, state_length, 64, decompress_sigcomp_message, 6, 0)
结束消息（请求的\u反馈\u位置，返回的\u参数\u位置，状态\u长度，64，解压缩\u sigcomp\u消息，6，0）
readonly (0) :circular_buffer
只读（0）：循环缓冲区
An example of a message compressed using the DEFLATE algorithm is given below:
下面给出了使用DEFLATE算法压缩的消息示例：
0xf3c9 4c4b d551 28c9 4855 08cd cb2c 4b2d 2a4e 5548 cc4b 5170 0532 0x2b4b 3232 f3d2 b900
0xf3c9 4c4b d551 28c9 4855 08cd cb2c 4BD 2A4 E 5548 cc4b 5170 0532 0x2b4b 3232 f3d2 b900
The uncompressed message is "Life, the Universe and Everything\n".
未压缩的消息是“生命、宇宙和一切\n”。
This section provides UDVM bytecode for the LZJH compression algorithm. LZJH is the algorithm adopted by the International Telecommunication Union (ITU-T) Recommendation V.44 [9].
本节提供LZJH压缩算法的UDVM字节码。LZJH是国际电信联盟（ITU-T）建议V.44[9]采用的算法。
Assembly for the LZJH decompressor is given below:
LZJH减压器的装配如下所示：
at (32) readonly (0)
at（32）只读（0）
; The following 2-byte variables are stored in the scratch-pad memory
; area because they do not need to be saved after decompressing a
; SigComp message:
; The following 2-byte variables are stored in the scratch-pad memory
; area because they do not need to be saved after decompressing a
; SigComp message:
:length_value pad (2)
:position_value pad (2)
:index pad (2)
:extra_extension_bits pad (2)
:codebook_old pad (2)
:length_value pad (2)
:position_value pad (2)
:index pad (2)
:extra_extension_bits pad (2)
:codebook_old pad (2)
at (42)
at（42）
set (requested_feedback_location, 0)
设置（请求的\u反馈\u位置，0）
at (64)
at（64）
; UDVM_registers
; UDVM_寄存器
:byte_copy_left pad (2) :byte_copy_right pad (2)
：字节复制左键盘（2）：字节复制右键盘（2）
:input_bit_order pad (2)
：输入\位\命令板（2）
; The following 2-byte variables are saved as state after ; decompressing a SigComp message:
; 以下2字节变量在之后保存为状态：；解压缩SigComp消息：
:current_length pad (2)
:decompressed_pointer pad (2)
:ordinal_length pad (2)
:codeword_length pad (2)
:codebook_next pad (2)
:current_length pad (2)
:decompressed_pointer pad (2)
:ordinal_length pad (2)
:codeword_length pad (2)
:codebook_next pad (2)
set (returned_parameters_location, 0)
设置（返回的\u参数\u位置，0）
align (64) readonly (1)
对齐（64）只读（1）
:initialize_memory
：初始化内存
; The following constants can be adjusted to configure the LZJH
; decompressor. The current settings are as recommended in the V.44
; specification (given that a total of 8K UDVM memory is available):
; The following constants can be adjusted to configure the LZJH
; decompressor. The current settings are as recommended in the V.44
; specification (given that a total of 8K UDVM memory is available):
set (udvm_memory_size, 8192) ; sets the total memory for LZJH set (max_extension_length, 8) ; sets the maximum string extension set (min_ordinal_length, 7) ; sets the minimum ordinal length set (min_codeword_length, 6) ; sets the minimum codeword length
设置（udvm_内存_大小，8192）；设置LZJH集合的总内存（最大扩展长度，8）；设置最大字符串扩展集（最小序数长度，7）；设置最小序数长度集（最小码字长度，6）；设置最小码字长度
set (codebook_start, 4492) set (first_codeword, (codebook_start - 12)) set (state_length, (udvm_memory_size - 64))
set（codebook\u start，4492）set（第一个码字，（codebook\u start-12））set（状态长度，（udvm\u内存大小-64））
MULTILOAD (64, 8, circular_buffer, udvm_memory_size, 7, 0, circular_buffer, min_ordinal_length, min_codeword_length, codebook_start)
多重加载（64，8，循环缓冲区，udvm内存大小，7，0，循环缓冲区，最小顺序长度，最小码字长度，码本开始）
:decompress_sigcomp_message
：解压缩\u sigcomp\u消息
:standard_prefix
：标准前缀
; The following code decompresses the standard 1-bit LZJH prefix
; that specifies whether the next character is an ordinal or a
; codeword/control value:
; The following code decompresses the standard 1-bit LZJH prefix
; that specifies whether the next character is an ordinal or a
; codeword/control value:
INPUT-BITS (1, index, end_of_message) COMPARE ($index, 1, ordinal, codeword_control, codeword_control)
输入位（1，索引，消息结尾）比较（$index，1，序数，码字控制，码字控制）
:prefix_after_codeword
：前缀\u在\u码字之后
; The following code decompresses the special LZJH prefix that only
; occurs after a codeword. It specifies whether the next character
; is an ordinal, a codeword/control value, or a string extension:
; The following code decompresses the special LZJH prefix that only
; occurs after a codeword. It specifies whether the next character
; is an ordinal, a codeword/control value, or a string extension:
INPUT-HUFFMAN (index, end_of_message, 2, 1, 1, 1, 2, 1, 0, 1, 0) COMPARE ($index, 1, ordinal, string_extension, codeword_control)
INPUT-HUFFMAN（索引，消息结尾，2，1，1，1，2，1，0，1，0）比较（$index，1，序数，字符串扩展，码字控制）
:ordinal
：序数
; The following code decompresses an ordinal character and creates
; a new codebook entry consisting of the ordinal character and the
; next character to be decompressed:
; The following code decompresses an ordinal character and creates
; a new codebook entry consisting of the ordinal character and the
; next character to be decompressed:
set (index_lsb, (index + 1)) set (current_length_lsb, (current_length + 1))
集合（索引\u lsb，（索引+1））集合（当前长度\u lsb，（当前长度+1））
INPUT-BITS ($ordinal_length, index, !) OUTPUT (index_lsb, 1) LOAD (current_length, 2) COPY-LITERAL (current_length_lsb, 3, $codebook_next) COPY-LITERAL (index_lsb, 1, $decompressed_pointer) JUMP (standard_prefix)
输入位（$ordinal_length，index，！）输出（index_lsb，1）加载（current_length，2）拷贝文本（current_length_lsb，3，$codebook_next）拷贝文本（index_lsb，1，$decompressed_pointer）跳转（标准前缀）
:codeword_control
：码字控制
; The following code decompresses a codeword/control value:
; 以下代码解压缩码字/控制值：
INPUT-BITS ($codeword_length, index, !) COMPARE ($index, 3, control_code, initialize_memory, codeword)
输入位（$codeword\u length，index，！）比较（$index，3，control\u code，initialize\u memory，codeword）
:codeword
：码字
; The following code interprets a codeword as an index into the LZJH
; codebook. It extracts the position/length pair from the specified
; codebook entry; the position/length pair points to a byte string
; in the circular buffer, which is then copied to the end of the
; decompressed message. The code also creates a new codebook entry
; consisting of the byte string plus the next character to be
; decompressed:
; The following code interprets a codeword as an index into the LZJH
; codebook. It extracts the position/length pair from the specified
; codebook entry; the position/length pair points to a byte string
; in the circular buffer, which is then copied to the end of the
; decompressed message. The code also creates a new codebook entry
; consisting of the byte string plus the next character to be
; decompressed:
set (length_value_lsb, (length_value + 1))
设置（长度值（长度值+1））
MULTIPLY ($index, 3) ADD ($index, first_codeword) COPY ($index, 3, length_value_lsb) LOAD (current_length, 1) ADD ($current_length, $length_value) LOAD (codebook_old, $codebook_next)
乘法（$index，3）加法（$index，第一个\u码字）复制（$index，3，长度\u值\u lsb）加载（$current\u length，1）加法（$current\u length，$length\u value）加载（$codebook\u old，$codebook\u next）
COPY-LITERAL (current_length_lsb, 3, $codebook_next) COPY-LITERAL ($position_value, $length_value, $decompressed_pointer) OUTPUT ($position_value, $length_value) JUMP (prefix_after_codeword)
COPY-LITERAL（当前长度lsb，3，$codebook\u next）COPY-LITERAL（$position\u value，$length\u value，$decompressed\u指针）输出（$position\u value，$length\u value）跳转（前缀\u在\u码字之后）
:string_extension
：字符串扩展名
; The following code decompresses a Huffman-encoded string extension:
; 以下代码解压缩哈夫曼编码的字符串扩展名：
INPUT-HUFFMAN (index, !, 4, 1, 1, 1, 1, 2, 1, 3, 2, 1, 1, 1, 13, 3, 0, 7, 5) COMPARE ($index, 13, continue, extra_bits, extra_bits)
输入-哈夫曼（索引、！、4、1、1、1、1、2、1、3、2、1、1、1、13、3、0、7、5）比较（$index、13、continue、extra_位、extra_位）
:extra_bits
：额外_位
INPUT-BITS (max_extension_length, extra_extension_bits, !) ADD ($index, $extra_extension_bits)
输入位（最大扩展位、额外扩展位、！）添加（$index、$extra扩展位）
:continue
：继续
; The following code extends the most recently created codebook entry ; by the number of bits specified in the string extension:
; 下面的代码扩展了最近创建的代码本条目；按字符串扩展名中指定的位数：
COPY-LITERAL ($position_value, $length_value, $position_value) COPY-LITERAL ($position_value, $index, $decompressed_pointer) OUTPUT ($position_value, $index) ADD ($index, $length_value) COPY (index_lsb, 1, $codebook_old) JUMP (standard_prefix)
COPY-LITERAL（$position\u value，$length\u value，$position\u value）COPY-LITERAL（$position\u value，$index，$decompressed\u pointer）输出（$position\u value，$index，$length\u value）ADD（$index，$length\u value）COPY（index\u lsb，1，$codebook\u old）跳转（标准前缀）
:control_code
：控制代码
; The code can handle all of the control characters in V.44 except
; for ETM (Enter Transparent Mode), which is not required for
; message-based protocols such as SigComp.
; The code can handle all of the control characters in V.44 except
; for ETM (Enter Transparent Mode), which is not required for
; message-based protocols such as SigComp.
COMPARE ($index, 1, !, flush, stepup)
比较（$index，1，！，flush，steppup）
:flush
：齐平
; The FLUSH control character jumps to the beginning of the next ; complete byte in the compressed message:
; 刷新控制字符跳到下一个字符的开头；压缩消息中的完整字节：
INPUT-BYTES (0, 0, 0) JUMP (standard_prefix)
输入字节（0,0,0）跳转（标准前缀）
:stepup
：加强
; The STEPUP control character increases the number of bits used to ; encode an ordinal value or a codeword:
; 递增控制字符增加了用于控制的位数；对序数值或码字进行编码：
INPUT-BITS (1, index, !) COMPARE ($index, 1, stepup_ordinal, stepup_codeword, 0)
输入位（1，索引，！）比较（$index，1，递增顺序，递增码字，0）
:stepup_ordinal
：依次递增
ADD ($ordinal_length, 1) JUMP (ordinal)
添加（$ordinal_length，1）跳转（ordinal）
:stepup_codeword
：递增码
ADD ($codeword_length, 1) JUMP (codeword_control)
添加（$codeword\u长度，1）跳转（codeword\u控制）
:end_of_message
：结束\u消息的\u
END-MESSAGE (requested_feedback_location, returned_parameters_location, state_length, 64, decompress_sigcomp_message, 6, 0)
结束消息（请求的\u反馈\u位置，返回的\u参数\u位置，状态\u长度，64，解压缩\u sigcomp\u消息，6，0）
readonly (0) :circular_buffer
只读（0）：循环缓冲区
An example of a message compressed using the LZJH algorithm is given below:
下面给出了使用LZJH算法压缩的消息示例：
0x5c09 e6e0 cadc c8d2 dcce 40c2 40f2 cac2 e440 c825 c840 ccde 29e8 0xc2f0 40e0 eae4 e0de e6ca e65c 1403
0x5c09 e6e0 cadc c8d2 dcce 40c2 40f2 cac2 e440 c825 c840 ccde 29e8 0xc2f0 40e0 eae4 e6ca e65c 1403
The uncompressed message is "...spending a year dead for tax purposes.\n".
未压缩的消息是“…为税务目的花费一年时间。\n”。
Alternative algorithms can also be used with SigComp. This section shows a modified version of the DEFLATE [8] algorithm. The two-stage encoding of DEFLATE is replaced by a single step with a discrete Huffman code for each symbol. The literal/length symbol probabilities are dependent upon whether the previous symbol was a literal or a match. Bit handling is also simpler, in that all bits are input using the INPUT-HUFFMAN instruction and the value of the H bit does not change so all bits are input, read, and interpreted in the same order.
替代算法也可用于SigComp。本节显示了DEFLATE[8]算法的修改版本。DEFLATE的两阶段编码由单个步骤代替，每个符号使用离散的哈夫曼码。文字/长度符号概率取决于前一个符号是文字还是匹配。位处理也更简单，因为所有位都是使用input-HUFFMAN指令输入的，H位的值不会改变，所以所有位都是以相同的顺序输入、读取和解释的。
Assembly for the algorithm is given below. String matching rules are the same as for the other LZ-based algorithms, with the alternative encoding of the literals and length/distance pairs.
下面给出了算法的汇编。字符串匹配规则与其他基于LZ的算法相同，对文字和长度/距离对进行了替代编码。
at (32) readonly (0)
at（32）只读（0）
:index pad (2)
:distance_value pad (2)
:old_pointer pad (2)
:index pad (2)
:distance_value pad (2)
:old_pointer pad (2)
at (42)
at（42）
set (requested_feedback_location, 0)
设置（请求的\u反馈\u位置，0）
at (64)
at（64）
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:decompressed_pointer pad (2)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:decompressed_pointer pad (2)
set (returned_parameters_location, 0)
设置（返回的\u参数\u位置，0）
at (128) readonly (1)
at（128）只读（1）
:initialize_memory
：初始化内存
set (udvm_memory_size, 8192) set (state_length, (udvm_memory_size - 64))
集合（udvm_内存_大小，8192）集合（状态长度，（udvm_内存_大小-64））
MULTILOAD (64, 4, circular_buffer, udvm_memory_size, 0, circular_buffer)
多加载（64，4，循环缓冲区，udvm内存大小，0，循环缓冲区）
:decompress_sigcomp_message
：解压缩\u sigcomp\u消息
:character_after_literal
：文字后面的字符
INPUT-HUFFMAN (index, end_of_message, 16, 5, 0, 11, 46, 0, 12, 12, 256, 1, 26, 32, 257, 1, 66, 68, 32, 0, 69, 94, 97, 0, 95, 102, 264, 0, 103, 103, 511, 2, 416, 426, 35,
输入-哈夫曼（索引，消息结尾，16，5，0，11，46，0，12，12，256，1，26，32，257，1，66，68，32，0，69，94，97，0，95，102，264，0，103，103，511，2416426，35，
0, 427, 465, 58, 0, 466, 481, 272, 1, 964, 995, 288, 3, 7968, 7988, 123, 0, 7989, 8115, 384, 1, 16232, 16263, 0, 0, 16264, 16327, 320, 1, 32656, 32767, 144)
0, 427, 465, 58, 0, 466, 481, 272, 1, 964, 995, 288, 3, 7968, 7988, 123, 0, 7989, 8115, 384, 1, 16232, 16263, 0, 0, 16264, 16327, 320, 1, 32656, 32767, 144)
COMPARE ($index, 256, literal, distance, distance)
比较（$index，256，literal，distance，distance）
:character_after_match
：匹配后的字符
INPUT-HUFFMAN (index, end_of_message, 16, 4, 0, 0, 511, 1, 2, 9, 256, 1, 20, 22, 32, 0, 23, 30, 264, 1, 62, 73, 46, 0, 74, 89, 272, 2, 360, 385, 97, 0, 386, 417, 288, 1, 836, 874, 58, 0, 875, 938, 320, 1, 1878, 1888, 35, 0, 1889, 2015, 384, 1, 4032, 4052, 123, 1, 8106, 8137, 0, 1, 16276, 16379, 144, 1, 32760, 32767, 248)
输入-哈夫曼（索引，消息结尾，16，4，0，0，511，1，2，9，256，1，20，22，32，0，23，30，264，1，62，73，46，0，74，89，272，2，360，385，97，0，386，417，288，1836，874，58，0，875，938，320，1，1878，1888，35，0，1889，2015，384，1，4032，4052，123，1，8106，8137，288，836，1878，1888，1888，35，1888，35，1888，288，358，1889，288，1487，1482，148，148，287，162327，1487，767，287，287，287，287，287，287，287，287
COMPARE ($index, 256, literal, distance, distance)
比较（$index，256，literal，distance，distance）
:literal
：文字
set (index_lsb, (index + 1))
集合（索引_lsb，（索引+1））
OUTPUT (index_lsb, 1) COPY-LITERAL (index_lsb, 1, $decompressed_pointer) JUMP (character_after_literal)
输出（索引\u lsb，1）复制文本（索引\u lsb，1，$decompressed\u指针）跳转（字符\u在\u文本之后）
:distance
：距离
SUBTRACT ($index, 253) INPUT-HUFFMAN (distance_value, !, 9, 9, 0, 7, 9, 0, 8, 63, 129, 1, 128, 135, 1,
减去（$index，253）输入-哈夫曼（距离值，！，9，9，0，7，9，0，8，63，129，1，128，135，1，
0, 136, 247, 17, 0, 248, 319, 185, 1, 640, 1407, 257, 2, 5632, 6655, 1025, 1, 13312, 15359, 2049, 2, 61440, 65535, 4097)
0, 136, 247, 17, 0, 248, 319, 185, 1, 640, 1407, 257, 2, 5632, 6655, 1025, 1, 13312, 15359, 2049, 2, 61440, 65535, 4097)
LOAD (old_pointer, $decompressed_pointer) COPY-OFFSET ($distance_value, $index, $decompressed_pointer) OUTPUT ($old_pointer, $index) JUMP (character_after_match)
加载（旧指针，$decompressed指针）复制偏移（$distance指针，$index，$decompressed指针）输出（$old指针，$index）跳转（匹配后字符）
:end_of_message
：结束\u消息的\u
END-MESSAGE (requested_feedback_location, returned_parameters_location, state_length, 64, decompress_sigcomp_message, 6, 0)
结束消息（请求的\u反馈\u位置，返回的\u参数\u位置，状态\u长度，64，解压缩\u sigcomp\u消息，6，0）
readonly (0) :circular_buffer
只读（0）：循环缓冲区
An example of a message compressed using the modified DEFLATE algorithm is given below:
下面给出了使用改进的DEFLATE算法压缩的消息示例：
0xd956 b132 cd68 5424 c5a9 6215 8a70 a64d af0a 5499 3621 509b 3e4c 0x28b4 a145 b362 653a d0a6 498b 5a6d 2970 ac4c 930a a4ca 74a4 c268 0x0c
0xd956 b132 cd68 5424 c5a9 6215 8a70 a64d af0a 5499 3621 509b 3e4c 0x28b4 a145 b362 653a d0a6 498b 5a6d 2970 ac4c 930a a4ca 74a4 c268 0x0c
The uncompressed message is "Arthur leapt to his feet like an author hearing the phone ring".
未压缩的信息是“亚瑟像一个作家听到电话铃一样跳了起来”。
This section covers the additional mechanisms that can be employed by SigComp to improve the overall compression ratio, including the use of acknowledgements, dictionaries, and sharing state between two directions of a compressed message flow.
本节介绍SigComp可用于提高整体压缩比的其他机制，包括使用确认、字典和压缩消息流两个方向之间的共享状态。
An example of assembly code is provided for these mechanisms. Depending on the mechanism and basic algorithm in use, the assembly code for either the mechanism or the basic algorithm may require modification (e.g., if the algorithm uses 'no more input' to jump to end_of_message, following end_of_message with an input instruction for CRC will not work). In any case, these are examples and there may be alternative ways to make use of the mechanisms.
为这些机制提供了一个汇编代码示例。根据所使用的机制和基本算法，机制或基本算法的汇编代码可能需要修改（例如，如果算法使用“无更多输入”跳转到消息的结尾，则在消息的结尾加上CRC的输入指令将不起作用）。在任何情况下，这些都是例子，可能有其他方法来利用这些机制。
When each of the compression algorithms described in Section 4 has successfully decompressed the current SigComp message, the contents of the UDVM memory are saved as a SigComp state item. Subsequent messages can access this state item by uploading the correct state identifier to the receiving endpoint, which avoids the need to upload the bytecode for the compression algorithm on a per-message basis. However, before a state item can be accessed, the compressor must first ensure that it is available at the receiving endpoint.
当第4节中描述的每个压缩算法已成功解压缩当前SigComp消息时，UDVM内存的内容将保存为SigComp状态项。后续消息可以通过将正确的状态标识符上载到接收端点来访问此状态项，这避免了需要按每条消息上载压缩算法的字节码。但是，在可以访问状态项之前，压缩器必须首先确保它在接收端点可用。
For each SigComp compartment, the receiving endpoint maintains a list of currently available states (where the total amount of state saved does not exceed the state_memory_size for the compartment). The SigComp compressor should maintain a similar list containing the states that it has instructed the receiving endpoint to save.
对于每个SigComp隔间，接收端点维护当前可用状态的列表（其中保存的状态总量不超过隔间的状态\内存\大小）。SigComp压缩器应该维护一个类似的列表，其中包含它已指示接收端点保存的状态。
As well as tracking the list of state items that it has saved at the remote endpoint, the compressor also maintains a flag for each state item indicating whether or not the state can safely be accessed. State items should not be accessed until they have been acknowledged (e.g., by using the SigComp feedback mechanism as per Section 5.1).
除了跟踪保存在远程端点的状态项列表外，压缩器还为每个状态项维护一个标志，指示是否可以安全访问该状态。在确认状态项之前，不得访问状态项（例如，根据第5.1节使用SigComp反馈机制）。
State items are deleted from the list when adding a new piece of state when the total state_memory_size for the compartment is full. The state to be deleted is determined according to age and retention priority as discussed in SigComp [2]. The SigComp compressor should not attempt to access any state items that have been deleted in this manner, as they may no longer be available at the receiving endpoint.
当隔间的总状态\内存\大小已满时，添加新状态时，状态项将从列表中删除。根据SigComp[2]中讨论的年龄和保留优先级确定要删除的状态。SigComp压缩器不应尝试访问以这种方式删除的任何状态项，因为它们可能在接收端点不再可用。
SigComp [2] defines a feedback mechanism to allow the compressor to request feedback from the decompressor, to give the compressor indication that a message has been received and correctly decompressed and that state storage has been attempted. (Note: This mechanism cannot convey the success or failure of individual state creation requests.) In order to invoke the feedback mechanism, the following fields must be reserved in the UDVM memory:
SigComp[2]定义了一种反馈机制，以允许压缩器请求来自解压器的反馈，从而向压缩器提供消息已被接收并正确解压以及已尝试状态存储的指示。（注意：此机制无法传达单个状态创建请求的成功或失败。）为了调用反馈机制，必须在UDVM内存中保留以下字段：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| reserved | Q | S | I | requested_feedback_location
+---+---+---+---+---+---+---+---+
| 1 | requested_feedback_length | if Q = 1
+---+---+---+---+---+---+---+---+
| |
: requested_feedback_field : if Q = 1
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| reserved | Q | S | I | requested_feedback_location
+---+---+---+---+---+---+---+---+
| 1 | requested_feedback_length | if Q = 1
+---+---+---+---+---+---+---+---+
| |
: requested_feedback_field : if Q = 1
| |
+---+---+---+---+---+---+---+---+
These fields can be reserved in any of the algorithms of Section 4 by replacing the line "set (requested_feedback_location, 0)" with the following assembly:
这些字段可以在第4节的任何算法中保留，方法是将行“set（request_feedback_location，0）”替换为以下程序集：
:requested_feedback_location pad (1)
:requested_feedback_length pad (1)
:requested_feedback_field pad (12)
:hash_start pad (8)
:requested_feedback_location pad (1)
:requested_feedback_length pad (1)
:requested_feedback_field pad (12)
:hash_start pad (8)
When a SigComp message is successfully decompressed and saved as state, the following bytecode instructs the receiving endpoint to return the first 6 bytes of the corresponding state identifier. The bytecode can be added to any of the compression algorithms of Section 4 immediately following the ":end_of_message" label:
成功解压缩SigComp消息并将其保存为状态时，以下字节码指示接收端点返回相应状态标识符的前6个字节。字节码可以添加到第4节中紧跟“：end_of_message”标签之后的任何压缩算法中：
:end_of_message
：结束\u消息的\u
set (hash_length, (state_length + 8))
设置（哈希长度，（状态长度+8））
LOAD (requested_feedback_location, 1158) MULTILOAD (hash_start, 4, state_length, 64, decompress_sigcomp_message, 6) SHA-1 (hash_start, hash_length, requested_feedback_field)
加载（请求的\u反馈\u位置，1158）多加载（哈希开始，4，状态长度，64，解压缩\u sigcomp\u消息，6）SHA-1（哈希开始，哈希长度，请求的\u反馈\u字段）
The receiving endpoint then returns the state identifier in the "returned feedback field" of the next SigComp message to be transmitted in the reverse direction.
然后，接收端点在下一个要反向传输的SigComp消息的“返回的反馈字段”中返回状态标识符。
When the state identifier is returned, the compressor can set the availability flag for the corresponding state to 1.
当返回状态标识符时，压缩器可以将相应状态的可用性标志设置为1。
Certain protocols that can be compressed using SigComp offer a fixed, mandatory state item known as a static dictionary. This dictionary contains a number of text strings that commonly occur in messages generated by the protocol in question. The overall compression ratio can often be improved by accessing the text phrases from this static dictionary rather than by uploading them as part of the compressed message.
可以使用SigComp压缩的某些协议提供了一个固定的、强制的状态项，称为静态字典。此词典包含许多文本字符串，这些字符串通常出现在由相关协议生成的消息中。通过从这个静态字典访问文本短语，而不是将它们作为压缩消息的一部分上传，通常可以提高总体压缩比。
As an example, a static dictionary is provided for the protocols SIP and SDP, RFC 3485 [4]. This dictionary is designed for use by a wide range of compression algorithms including all of the ones covered in Section 4.
例如，为协议SIP和SDP RFC 3485[4]提供了一个静态字典。本词典设计用于各种压缩算法，包括第4节中介绍的所有算法。
In any of the compression algorithms of Section 4, the static dictionary can be accessed by inserting the following instruction immediately after the ":initialize_memory" label:
在第4节的任何压缩算法中，可以通过在“：initialize_memory”标签后立即插入以下指令来访问静态字典：
STATE-ACCESS (dictionary_id, 6, 0, 0, 1024, 0)
状态访问（字典id，6，0，0，1024，0）
The parameters of STATE-ACCESS instruction will depend on the compression algorithm in use.
状态访问指令的参数将取决于使用的压缩算法。
The following lines should also be inserted immediately after the END-MESSAGE instruction:
还应在结束信息指令后立即插入以下行：
:dictionary_id
：字典\u id
byte (0xfb, 0xe5, 0x07, 0xdf, 0xe5, 0xe6)
字节（0xfb、0xe5、0x07、0xdf、0xe5、0xe6）
The text strings contained in the static dictionary can then be accessed in exactly the same manner as the text strings from previously decompressed messages (see Section 5.1 for further details).
然后，静态字典中包含的文本字符串可以以与以前解压缩的消息中的文本字符串完全相同的方式进行访问（有关更多详细信息，请参阅第5.1节）。
Note that in some cases it is sufficient to load only part of the static dictionary into the UDVM memory. Further information on the contents of the SIP and SDP static dictionary can be found in the relevant document, RFC 3485 [4].
注意，在某些情况下，只将静态字典的一部分加载到UDVM内存中就足够了。有关SIP和SDP静态字典内容的更多信息，请参阅相关文档RFC 3485[4]。
The acknowledgement scheme of Section 5.1 is designed to indicate the successful decompression of a message. However, it does not guarantee that the decompressed message is identical to the original message, since decompression of a corrupted message could succeed but with some characters being incorrect. This could lead to an incorrect message being passed to the application or unexpected contents of state to be stored. In order to prevent this happening, a CRC check could be used.
第5.1节中的确认方案旨在指示消息的成功解压缩。但是，它不能保证解压缩后的消息与原始消息相同，因为解压缩损坏的消息可能会成功，但某些字符不正确。这可能会导致将不正确的消息传递给应用程序，或导致存储意外的状态内容。为了防止这种情况发生，可以使用CRC检查。
If an additional CRC check is required, then the following bytecode can be inserted after the ":end_of_message" label:
如果需要额外的CRC检查，则可以在“：end_of_message”标签后插入以下字节码：
INPUT-BYTES (2, index, !) CRC ($index, 64, state_length, !)
输入字节（2，索引，！）CRC（$index，64，状态长度，！）
The bytecode extracts a 2-byte CRC from the end of the SigComp message and compares it with a CRC calculated over the UDVM memory. Decompression failure occurs if the two CRC values do not match.
字节码从SigComp消息的末尾提取一个2字节的CRC，并将其与通过UDVM内存计算的CRC进行比较。如果两个CRC值不匹配，则会发生解压缩失败。
A definition of the CRC polynomial used by the CRC instruction can be found in SigComp [2].
CRC指令使用的CRC多项式定义见SigComp[2]。
If a particular endpoint is able to offer more processing or memory resources than the mandatory minimum, the SigComp feedback mechanism can be used to announce that these resources are available to the remote endpoint. This may help to improve the overall compression ratio between the two endpoints.
如果某个特定端点能够提供比必需的最小值更多的处理或内存资源，则可以使用SigComp反馈机制来宣布远程端点可以使用这些资源。这可能有助于提高两个端点之间的整体压缩比。
Additionally, if an endpoint has any pieces of state that may be useful for the remote endpoint to reference, it can advertise the identifiers for the states. The remote endpoint can then make use of any that it also knows about (i.e., knows the contents of), for example, a dictionary or shared mode state (see Section 5.5).
此外，如果端点具有可供远程端点引用的任何状态片段，则它可以公布这些状态的标识符。然后，远程端点可以使用它也知道的任何信息（即，知道的内容），例如字典或共享模式状态（参见第5.5节）。
The values of the following SigComp parameters can be announced using the SigComp advertisement mechanism:
可以使用SigComp播发机制宣布以下SigComp参数的值：
cycles_per_bit decompression_memory_size state_memory_size SigComp_version state identifiers
循环\u每\u位解压缩\u内存\u大小状态\u内存\u大小SigComp\u版本状态标识符
As explained in SigComp, in order to announce the values of these parameters, the following fields must be reserved in the UDVM memory:
如SigComp中所述，为了公布这些参数的值，必须在UDVM内存中保留以下字段：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| cpb | dms | sms | returned_parameters_location
+---+---+---+---+---+---+---+---+
| SigComp_version |
+---+---+---+---+---+---+---+---+
| length_of_partial_state_ID_1 |
+---+---+---+---+---+---+---+---+
| |
: partial_state_identifier_1 :
| |
+---+---+---+---+---+---+---+---+
: :
+---+---+---+---+---+---+---+---+
| length_of_partial_state_ID_n |
+---+---+---+---+---+---+---+---+
| |
: partial_state_identifier_n :
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| cpb | dms | sms | returned_parameters_location
+---+---+---+---+---+---+---+---+
| SigComp_version |
+---+---+---+---+---+---+---+---+
| length_of_partial_state_ID_1 |
+---+---+---+---+---+---+---+---+
| |
: partial_state_identifier_1 :
| |
+---+---+---+---+---+---+---+---+
: :
+---+---+---+---+---+---+---+---+
| length_of_partial_state_ID_n |
+---+---+---+---+---+---+---+---+
| |
: partial_state_identifier_n :
| |
+---+---+---+---+---+---+---+---+
These fields can be reserved in any of the algorithms of Section 4 by replacing the line "set (returned_parameters_location, 0)" with the following piece of assembly:
通过使用以下部件替换行“set（returned_parameters_location，0）”，可以在第4节的任何算法中保留这些字段：
:adverts_len pad (1)
:adverts_len_lsb pad (1)
:returned_parameters_location pad (1)
:returned_sigcomp_version pad (1)
:state_ids pad (x)
:adverts_len pad (1)
:adverts_len_lsb pad (1)
:returned_parameters_location pad (1)
:returned_sigcomp_version pad (1)
:state_ids pad (x)
where x is enough space for the number state identifiers that the endpoint wishes to advertise.
其中，x是端点希望公布的状态标识符数量的足够空间。
When a SigComp message is successfully decompressed and saved as state, the following bytecode announces to the receiving endpoint that additional resources and pieces of state are available at the sending endpoint:
当成功解压缩SigComp消息并将其另存为状态时，以下字节码向接收端点宣布，发送端点上有其他资源和状态片段可用：
:end_of_message
：结束\u消息的\u
LOAD (returned_parameters_location, N) INPUT-BYTES (1, adverts_len_lsb, done) INPUT-BYTES ($adverts_len, state_ids, done)
加载（返回的参数位置，N）输入字节（1，广告长度lsb，完成）输入字节（$广告长度，状态ID，完成）
:done
：完成
Note that the integer value "N" should be set equal to the amount of resources available at the sending endpoint. N should be expressed as a 2-byte integer with the most significant bits corresponding to the cycles_per_bit parameter and the least significant bits corresponding to the SigComp_version parameter.
请注意，整数值“N”应设置为等于发送端点处可用的资源量。N应表示为2字节整数，最高有效位对应于cycles_per_bit参数，最低有效位对应于SigComp_version参数。
The length of the state identifiers followed by the state identifiers in the format shown are appended to the end of the compressed message.
状态标识符的长度后跟所示格式的状态标识符，并附加到压缩消息的末尾。
This section provides bytecode for implementing the SigComp shared compression mechanism, RFC 3321 [3]. If two endpoints A and B are communicating via SigComp, shared compression allows the messages sent from Endpoint A to Endpoint B to be compressed relative to the messages sent from Endpoint B to Endpoint A (and vice versa). This may improve the overall compression ratio by reducing the need to transmit the same information in both directions.
本节提供了用于实现SigComp共享压缩机制RFC3321[3]的字节码。如果两个端点A和B通过SigComp进行通信，则共享压缩允许相对于从端点B发送到端点A的消息对从端点A发送到端点B的消息进行压缩（反之亦然）。这可以通过减少在两个方向上传输相同信息的需要来提高总体压缩比。
As described in RFC 3321 [3], two steps must be taken to implement shared compression at an endpoint.
如RFC3321[3]所述，必须采取两个步骤在端点实现共享压缩。
First, it is necessary to announce to the remote endpoint that shared compression is available. This is done by announcing the state identifier as an available piece of state. This can be done using the returned_parameters_location announcement as in Section 5.4.
首先，有必要向远程端点宣布共享压缩可用。这是通过将状态标识符宣布为可用状态来实现的。如第5.4节所述，可以使用返回的_参数_位置公告来完成此操作。
Second, assuming that such an announcement is received from the remote endpoint, then the state created by shared compression needs to be accessed by the message sent in the opposite direction. This can be done in a similar way to accessing the static dictionary (see Section 5.2), but using the appropriate state identifier, for example, by using the INPUT-BYTES instruction as below:
其次，假设从远程端点接收到这样的通知，则共享压缩创建的状态需要通过以相反方向发送的消息来访问。这可以通过与访问静态字典（参见第5.2节）类似的方式完成，但使用适当的状态标识符，例如，通过使用输入字节指令，如下所示：
:shared_state_id pad (6)
：共享\u状态\u id焊盘（6）
:access_shared_state
：访问共享状态
INPUT-BYTES (6, shared_state_id, !) STATE-ACCESS (shared_state_id, 6, 0, 0, $decompressed_start, 0)
输入字节（6，共享状态id，！）状态访问（共享状态id，6，0，0，$decompressed\u start，0）
This document describes implementation options for the SigComp protocol [2]. Consequently, the security considerations for this document match those of SigComp.
本文档描述了SigComp协议的实现选项[2]。因此，本文件的安全注意事项与SigComp的安全注意事项一致。
Thanks to Richard Price, Carsten Bormann, Adam Roach, Lawrence Conroy, Christian Schmidt, Max Riegel, Lars-Erik Jonsson, Jonathan Rosenberg, Stefan Forsgren, Krister Svanbro, Miguel Garcia, Christopher Clanton, Khiem Le, Ka Cheong Leung, and Zoltan Barczikay for valuable input and review.
感谢Richard Price、Carsten Bormann、Adam Roach、Lawrence Conroy、Christian Schmidt、Max Riegel、Lars Erik Jonsson、Jonathan Rosenberg、Stefan Forsgren、Krister Svanbro、Miguel Garcia、Christopher Clanton、Khiem Le、Ka Chang Leung和Zoltan Barczikay的宝贵意见和评论。
Special thanks to Pekka Pessi and Cristian Constantin, who served as committed working group document reviewers.
特别感谢Pekka Pessi和Cristian Constantin，他们是工作组文件审查员。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
[1] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[1] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[2] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.
[2] Price，R.，Bormann，C.，Christofferson，J.，Hannu，H.，Liu，Z.，和J.Rosenberg，“信号压缩（SigComp）”，RFC3320，2003年1月。
[3] Hannu, H., Christoffersson, J., Forsgren, S., Leung, K.-C., Liu, Z., and R. Price, "Signaling Compression (SigComp) - Extended Operations", RFC 3321, January 2003.
[3] Hannu，H.，Christofferson，J.，Forsgren，S.，Leung，K.-C.，Liu，Z.，和R.Price，“信号压缩（SigComp）-扩展操作”，RFC 33212003年1月。
[4] Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and A.B. Roach, "The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)", RFC 3485, February 2003.
[4] Garcia Martin，M.，Bormann，C.，Ott，J.，Price，R.，和A.B.Roach，“会话启动协议（SIP）和会话描述协议（SDP）信令压缩静态字典（SigComp）”，RFC 3485，2003年2月。
[5] Ziv, J. and A. Lempel, "A universal algorithm for sequential data compression", IEEE 23:337-343, 1977.
[5] Ziv，J.和A.Lempel，“顺序数据压缩的通用算法”，IEEE 23:337-343，1977年。
[6] Storer, J., "Data Compression: Methods and Theory", Computer Science Press ISBN 0-88175-161-8, 1998.
[6] 《数据压缩：方法与理论》，计算机科学出版社ISBN 0-88175-161-81998。
[7] Nelson, M., "LZW Data Compression", Dr Dobb's Journal, October 1989.
[7] Nelson，M.，“LZW数据压缩”，Dobb博士期刊，1989年10月。
[8] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[8] Deutsch，P.，“DEFLATE压缩数据格式规范1.3版”，RFC1951，1996年5月。
[9] "Data Compression Procedures", ITU-T Recommendation V.44, November 2000.
[9] “数据压缩程序”，ITU-T建议V.44，2000年11月。
The following sections list the UDVM bytecode generated for each compression algorithm of Section 4.
以下各节列出了为第4节的每个压缩算法生成的UDVM字节码。
Note that the different assemblers can output different bytecode for the same piece of assembly code, so a valid assembler can produce results different from those presented below. However, the following bytecode should always generate the same decompressed messages on any UDVM.
请注意，不同的汇编程序可以为同一段汇编代码输出不同的字节码，因此一个有效的汇编程序可以产生不同于下面给出的结果。但是，以下字节码应始终在任何UDVM上生成相同的解压缩消息。
0x0f86 0389 8d89 1588 8800 011c 0420 0d13 5051 2222 5051 16f5 2300 0x00bf c086 a08b 06
0x0f86 0389 8d89 1588 8800 011c 0420 0d13 5051 2222 5051 16f5 2300 0x00bf c086 a08b 06
0x0f86 04a0 c48d 00a0 c41e 2031 0209 00a0 ff8e 048c bfff 0117 508d 0x0f23 0622 2101 1321 0123 16e5 1d04 22e8 0611 030e 2463 1450 5123 0x2252 5116 9fd2 2300 00bf c086 a089 06
0x0f86 04a0 c48d 00a0 c41e 2031 0209 00a0 ff8e 048c bfff 0117 508d 0x0f23 0622 2101 1321 0123 16e5 1d04 22e8 0611 030e 2463 1450 5123 0x2252 5116 9fd2 2300 00bf c086 a089 06
0x0f86 06a1 ce8d 00b1 8f01 a0ce 13a0 4903 2313 2501 2506 1201 1752 0x88f4 079f 681d 0a24 2508 1203 0612 b18f 1252 0321 0ea0 4801 0624 0x5013 a049 0323 1351 5025 2251 5016 9fde 2300 00bf c086 a09f 06
0x0f86 06a1 ce8d 00b1 8f01 a0ce 13a0 4903 2313 2501 2506 1201 1752 0x88f4 079f 681d 0a24 2508 1203 0612 b18f 1252 0321 0ea0 4801 0624 0x5013 a049 0323 1351 5025 2251 5016 9fde 2300 00bf c086 a09f 06
0x0f86 7aa2 528d 05a2 5200 0300 0400 0500 0600 0700 0800 0900 0a01 0x0b01 0d01 0f01 1102 1302 1702 1b02 1f03 2303 2b03 3303 3b04 a043 0x04a0 5304 a063 04a0 7305 a083 05a0 a305 a0c3 05a0 e300 a102 0001 0x0002 0003 0004 0105 0107 0209 020d 0311 0319 0421 0431 05a0 4105 0xa061 06a0 8106 a0c1 07a1 0107 a181 08a2 0108 a301 09a4 0109 a601 0x0aa8 010a ac01 0bb0 010b b801 0c80 2001 0c80 3001 0d80 4001 0d80 0x6001 1d03 229f b41e 20a0 6504 0700 1780 4011 0130 a0bf 0000 a0c0 0xa0c7 8040 2901 a190 a1ff a090 1750 8040 1109 a046 1322 2101 1321 0x0123 169f d108 1004 1250 0422 1d51 229f d706 1251 1e20 9fcf 0105 0x001f 2f08 1004 1250 0426 1d53 26f6 0614 530e 2063 1454 5223 2250 0x5216 9f9e 2300 00bf c086 a1de 06
0x0f86 7aa2 528d 05a2 5200 0300 0400 0500 0600 0700 0800 0900 0a01 0x0b01 0f01 1102 1302 1702 1b02 1F02 2303 2b03 3303 3b04 a043 0x04a0 5304 a063 04a0 7305 a083 05a0 a305 a0c3 05a0 e300 a102 0001 0x0002 0003 0004 0105 0107 0209 020d 0311 0319 0421 05a0 4105 0xa061 06a0 8106 A0 07a1 0107 A10881 a301 A08 09a4 0109 A08 0Aac01 0bb0 010b b801 0c80 2001 0c80 3001 0d80 4001 0d80 0x6001 1d03 229f b41e 20a0 6504 0700 1780 4011 0130 a0bf 0000 a0c0 0xa0c7 8040 2901 a190 a1ff a090 1750 8040 1109 a046 1322 2101 1321 0x0123 169f d108 1004 1250 0422 1D706 1251 1e20 9fcf 0105 0x001f 2f08 1004 1250 0426 1d53 26f6 0614 530e 2063 1454 5223 0x5216 2300F9BFa1de 06
0x0f86 08a1 5b8d 0700 a15b 0706 b18f 1d01 24a0 c317 5201 1a31 311e 0x24a0 b802 0101 0102 0100 0100 1752 0107 a04e 1e1d 6524 f822 2501 0x0ea0 4602 13a0 4703 2713 2501 2416 9fcd 1d66 24e1 1752 03a0 639f 0xb808 0812 0306 12b1 8312 5203 210e a046 0106 2350 0e28 6713 a047 0x0327 1351 5024 2251 5016 9fa8 1e24 9fb1 0401 0101 0102 0103 0201 0x0101 0d03 0007 0517 520d 0d06 061d 0826 f706 1253 1351 5011 1351 0x5224 2251 5206 1250 1225 0154 169f 6617 5201 9fdb 070f 1c00 009e 0xce16 9f57 1d01 24fa 1752 0107 0d9e c206 2501 169f 6506 2601 169f 0x7623 0000 bfc0 86a0 8e06
0x0f86 08a1 5b8d 0700 a15b 0706 b18f 1d01 24a0 c317 5201 1a31 311e 0x24a0 b802 0101 0102 0100 1752 0107 a04e 1E 1D 6524 f822 2501 0x0ea0 4602 13a0 4703 2713 2501 2416 9fcd 1d66 24e1 1752 03a0 639f 0xb808 0812 0306 12b1 8312 5203 210e a046 0106 2350 0e28 6713 a047 0x0327 1351 5024 2251 5016 9fa8 1E0401 0102 0D0010007 0517 520d 0d06 061d 0826 f706 1253 1351 5011 1351 0x5224 2251 5206 1250 1225 0154 169f 6617 5201 9fdb 070f 1c00 009e 0xce16 9f57 1d01 24fa 1752 0107 0d9e c206 2501 169f 6506 2601 169f 0x7623 0000 bfc0 86a0 8e06
0x0f86 04a1 d38d 00a1 d31e 20a1 4010 0500 0b2e 000c 0c88 011a 20a1 0x0101 a042 a044 2000 a045 a05e a061 00a0 5fa0 66a1 0800 a067 a067 0xa1ff 02a1 a0a1 aa23 00a1 aba1 d13a 00a1 d2a1 e1a1 1001 a3c4 a3e3 0xa120 03bf 20bf 34a0 7b00 bf35 bfb3 a180 0180 3f68 803f 8700 0080 0x3f88 803f c7a1 4001 807f 9080 7fff a090 1750 88a0 79a0 83a0 831e 0x20a0 c810 0400 00a1 ff01 0209 8801 1416 2000 171e a108 013e a049 0x2e00 a04a a059 a110 02a1 68a1 81a0 6100 a182 a1a1 a120 01a3 44a3 0x6a3a 00a3 6ba3 aaa1 4001 a756 a760 2300 a761 a7df a180 01af c0af 0xd4a0 7b01 bfaa bfc9 0001 803f 9480 3ffb a090 0180 7ff8 807f ffa0 0xf817 5088 0610 1022 2101 1321 0123 169f 1107 10a0 fd1e 229f d909 0x0900 0709 0008 3fa0 8101 87a0 8701 00a0 88a0 f711 00a0 f8a1 3fa0 0xb901 a280 a57f a101 02b6 00b9 ffa4 0101 8034 0080 3bff a801 0290 0x00ff b001 0e24 6314 5150 2322 5250 169f 3b23 0000 bfc0 86a0 8906
0x0f86 04a1 d38d 00a1 d31e 20a1 4010 0500 0b2e 000c 0c88 011a 20a1 0x0101 a042 a044 2000 a045 a05e a061 00a0 5fa0 66a1 0800 a067 a067 0xa1ff 02a1 a0a1 aa23 00a1 aba1 d13a 00a1 d2a1 e1a1 1001 a3c4 a3e3 0xa120 03bf 34a0 7b00 bf35 bfb3 80 0180 3f68 803f 8700 0080 0x3f88 803f c7a1 4001 807f 9088A0 0183A0 0A0830F c8100400 00a1 ff01 0209 8801 1416 2000 171e a108 013e a049 0x2e00 a04a a059 a110 02a1 68a1 81a0 6100 a182 a120 01a3 44a3 0x6a3a 00a3 6ba3 aaa1 4001 a756 a760 2300 a761 a7df a180 01af 0xd4a0 7b01 bfaa bfc9 0001 803f 9480 3ffb a090 0180 7F 807f FFB A00 0x17 F85088 0610 1022 1321 0123 169f 1107 10A00 fd1e 229f d909 0x0900 078 080187a0 8701 00a0 88a0 f711 00a0 f8a1 3fa0 0xb901 a280 a57f a101 02b6 00b9 ffa4 0101 8034 0080 3bff a801 0290 0x00ff b001 0e24 6314 5150 2322 5250 169f 3b23 0000 bfc0 86a0 8906
Authors' Addresses
作者地址
Abigail Surtees Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
Abigail Surtees西门子/Roke Manor Research Roke Manor Research Ltd.Romsey，Hants SO51 0ZN英国
Phone: +44 (0)1794 833131
EMail: abigail.surtees@roke.co.uk
URI: http://www.roke.co.uk
Phone: +44 (0)1794 833131
EMail: abigail.surtees@roke.co.uk
URI: http://www.roke.co.uk
Mark A. West Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
Mark A.West Siemens/Roke Manor Research Roke Manor Research Ltd.Romsey，Hants SO51 0ZN英国
Phone: +44 (0)1794 833311
EMail: mark.a.west@roke.co.uk
URI: http://www.roke.co.uk
Phone: +44 (0)1794 833311
EMail: mark.a.west@roke.co.uk
URI: http://www.roke.co.uk
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。