Network Working Group M. Eisler, Ed.
Request for Comments: 4506 Network Appliance, Inc.
STD: 67 May 2006
Obsoletes: 1832
Category: Standards Track
Network Working Group M. Eisler, Ed.
Request for Comments: 4506 Network Appliance, Inc.
STD: 67 May 2006
Obsoletes: 1832
Category: Standards Track
XDR: External Data Representation Standard
XDR：外部数据表示标准
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. This document obsoletes RFC 1832.
本文档描述了当前部署和接受的外部数据表示标准（XDR）协议。本文件废除了RFC 1832。
Table of Contents
目录
1. Introduction ....................................................3
2. Changes from RFC 1832 ...........................................3
3. Basic Block Size ................................................3
4. XDR Data Types ..................................................4
4.1. Integer ....................................................4
4.2. Unsigned Integer ...........................................4
4.3. Enumeration ................................................5
4.4. Boolean ....................................................5
4.5. Hyper Integer and Unsigned Hyper Integer ...................5
4.6. Floating-Point .............................................6
4.7. Double-Precision Floating-Point ............................7
4.8. Quadruple-Precision Floating-Point .........................8
4.9. Fixed-Length Opaque Data ...................................9
4.10. Variable-Length Opaque Data ...............................9
4.11. String ...................................................10
4.12. Fixed-Length Array .......................................11
4.13. Variable-Length Array ....................................11
4.14. Structure ................................................12
4.15. Discriminated Union ......................................12
4.16. Void .....................................................13
4.17. Constant .................................................13
4.18. Typedef ..................................................13
4.19. Optional-Data ............................................14
4.20. Areas for Future Enhancement .............................16
5. Discussion .....................................................16
6. The XDR Language Specification .................................17
6.1. Notational Conventions ....................................17
6.2. Lexical Notes .............................................18
6.3. Syntax Information ........................................18
6.4. Syntax Notes ..............................................20
7. An Example of an XDR Data Description ..........................21
8. Security Considerations ........................................22
9. IANA Considerations ............................................23
10. Trademarks and Owners .........................................23
11. ANSI/IEEE Standard 754-1985 ...................................24
12. Normative References ..........................................25
13. Informative References ........................................25
14. Acknowledgements ..............................................26
1. Introduction ....................................................3
2. Changes from RFC 1832 ...........................................3
3. Basic Block Size ................................................3
4. XDR Data Types ..................................................4
4.1. Integer ....................................................4
4.2. Unsigned Integer ...........................................4
4.3. Enumeration ................................................5
4.4. Boolean ....................................................5
4.5. Hyper Integer and Unsigned Hyper Integer ...................5
4.6. Floating-Point .............................................6
4.7. Double-Precision Floating-Point ............................7
4.8. Quadruple-Precision Floating-Point .........................8
4.9. Fixed-Length Opaque Data ...................................9
4.10. Variable-Length Opaque Data ...............................9
4.11. String ...................................................10
4.12. Fixed-Length Array .......................................11
4.13. Variable-Length Array ....................................11
4.14. Structure ................................................12
4.15. Discriminated Union ......................................12
4.16. Void .....................................................13
4.17. Constant .................................................13
4.18. Typedef ..................................................13
4.19. Optional-Data ............................................14
4.20. Areas for Future Enhancement .............................16
5. Discussion .....................................................16
6. The XDR Language Specification .................................17
6.1. Notational Conventions ....................................17
6.2. Lexical Notes .............................................18
6.3. Syntax Information ........................................18
6.4. Syntax Notes ..............................................20
7. An Example of an XDR Data Description ..........................21
8. Security Considerations ........................................22
9. IANA Considerations ............................................23
10. Trademarks and Owners .........................................23
11. ANSI/IEEE Standard 754-1985 ...................................24
12. Normative References ..........................................25
13. Informative References ........................................25
14. Acknowledgements ..............................................26
XDR is a standard for the description and encoding of data. It is useful for transferring data between different computer architectures, and it has been used to communicate data between such diverse machines as the SUN WORKSTATION*, VAX*, IBM-PC*, and Cray*. XDR fits into the ISO presentation layer and is roughly analogous in purpose to X.409, ISO Abstract Syntax Notation. The major difference between these two is that XDR uses implicit typing, while X.409 uses explicit typing.
XDR是数据描述和编码的标准。它对于在不同的计算机体系结构之间传输数据非常有用，并且已用于在诸如SUN WORKSTATION*、VAX*、IBM-PC*和Cray*等不同机器之间进行数据通信。XDR适合ISO表示层，在用途上大致类似于X.409，ISO抽象语法表示法。这两者之间的主要区别在于XDR使用隐式类型，而X.409使用显式类型。
XDR uses a language to describe data formats. The language can be used only to describe data; it is not a programming language. This language allows one to describe intricate data formats in a concise manner. The alternative of using graphical representations (itself an informal language) quickly becomes incomprehensible when faced with complexity. The XDR language itself is similar to the C language [KERN], just as Courier [COUR] is similar to Mesa. Protocols such as ONC RPC (Remote Procedure Call) and the NFS* (Network File System) use XDR to describe the format of their data.
XDR使用一种语言来描述数据格式。语言只能用于描述数据；它不是一种编程语言。这种语言允许人们以简洁的方式描述复杂的数据格式。当面对复杂性时，使用图形表示（本身是一种非正式语言）的替代方案很快变得难以理解。XDR语言本身类似于C语言[KERN]，就像Courier[COUR]类似于Mesa一样。诸如ONC-RPC（远程过程调用）和NFS*（网络文件系统）之类的协议使用XDR来描述其数据的格式。
The XDR standard makes the following assumption: that bytes (or octets) are portable, where a byte is defined as 8 bits of data. A given hardware device should encode the bytes onto the various media in such a way that other hardware devices may decode the bytes without loss of meaning. For example, the Ethernet* standard suggests that bytes be encoded in "little-endian" style [COHE], or least significant bit first.
XDR标准做出以下假设：字节（或八位字节）是可移植的，其中一个字节定义为8位数据。给定的硬件设备应将字节编码到各种媒体上，以便其他硬件设备可以在不丢失意义的情况下解码字节。例如，Ethernet*标准建议以“little endian”样式[COHE]对字节进行编码，或先对最低有效位进行编码。
This document makes no technical changes to RFC 1832 and is published for the purposes of noting IANA considerations, augmenting security considerations, and distinguishing normative from informative references.
本文件未对RFC 1832进行任何技术更改，其发布目的在于说明IANA注意事项，增强安全注意事项，并区分规范性参考和信息性参考。
The representation of all items requires a multiple of four bytes (or 32 bits) of data. The bytes are numbered 0 through n-1. The bytes are read or written to some byte stream such that byte m always precedes byte m+1. If the n bytes needed to contain the data are not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of 4.
所有项目的表示都需要四字节（或32位）数据的倍数。字节编号为0到n-1。字节被读或写到某个字节流中，使得字节m始终位于字节m+1之前。如果包含数据所需的n个字节不是4的倍数，那么n个字节后面会有足够的（0到3）剩余零字节r，以使总字节数为4的倍数。
We include the familiar graphic box notation for illustration and comparison. In most illustrations, each box (delimited by a plus sign at the 4 corners and vertical bars and dashes) depicts a byte.
我们使用熟悉的图形框符号进行说明和比较。在大多数插图中，每个框（由4个角处的加号、竖线和破折号分隔）表示一个字节。
Ellipses (...) between boxes show zero or more additional bytes where required.
方框之间的省略号（…）在需要时显示零个或多个附加字节。
+--------+--------+...+--------+--------+...+--------+
| byte 0 | byte 1 |...|byte n-1| 0 |...| 0 | BLOCK
+--------+--------+...+--------+--------+...+--------+
|<-----------n bytes---------->|<------r bytes------>|
|<-----------n+r (where (n+r) mod 4 = 0)>----------->|
+--------+--------+...+--------+--------+...+--------+
| byte 0 | byte 1 |...|byte n-1| 0 |...| 0 | BLOCK
+--------+--------+...+--------+--------+...+--------+
|<-----------n bytes---------->|<------r bytes------>|
|<-----------n+r (where (n+r) mod 4 = 0)>----------->|
Each of the sections that follow describes a data type defined in the XDR standard, shows how it is declared in the language, and includes a graphic illustration of its encoding.
下面的每一节都描述了XDR标准中定义的数据类型，展示了如何用该语言声明该数据类型，并包括其编码的图形说明。
For each data type in the language we show a general paradigm declaration. Note that angle brackets (< and >) denote variable-length sequences of data and that square brackets ([ and ]) denote fixed-length sequences of data. "n", "m", and "r" denote integers. For the full language specification and more formal definitions of terms such as "identifier" and "declaration", refer to Section 6, "The XDR Language Specification".
对于语言中的每种数据类型，我们都显示了一个通用的范例声明。请注意，尖括号（<和>）表示可变长度的数据序列，方括号（[和]）表示固定长度的数据序列。“n”、“m”和“r”表示整数。有关完整的语言规范和更正式的术语定义，如“标识符”和“声明”，请参阅第6节“XDR语言规范”。
For some data types, more specific examples are included. A more extensive example of a data description is in Section 7, "An Example of an XDR Data Description".
对于某些数据类型，包含了更具体的示例。更广泛的数据描述示例见第7节“XDR数据描述示例”。
An XDR signed integer is a 32-bit datum that encodes an integer in the range [-2147483648,2147483647]. The integer is represented in two's complement notation. The most and least significant bytes are 0 and 3, respectively. Integers are declared as follows:
XDR有符号整数是一个32位数据，它对[-21474836482147483647]范围内的整数进行编码。整数用2的补码表示法表示。最高有效字节和最低有效字节分别为0和3。整数声明如下：
int identifier;
int标识符；
(MSB) (LSB)
+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 | INTEGER
+-------+-------+-------+-------+
<------------32 bits------------>
(MSB) (LSB)
+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 | INTEGER
+-------+-------+-------+-------+
<------------32 bits------------>
An XDR unsigned integer is a 32-bit datum that encodes a non-negative integer in the range [0,4294967295]. It is represented by an unsigned binary number whose most and least significant bytes are 0 and 3, respectively. An unsigned integer is declared as follows:
XDR无符号整数是对范围[04294967295]内的非负整数进行编码的32位数据。它由无符号二进制数表示，其最高和最低有效字节分别为0和3。无符号整数声明如下：
unsigned int identifier;
无符号整数标识符；
(MSB) (LSB)
+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 | UNSIGNED INTEGER
+-------+-------+-------+-------+
<------------32 bits------------>
(MSB) (LSB)
+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 | UNSIGNED INTEGER
+-------+-------+-------+-------+
<------------32 bits------------>
Enumerations have the same representation as signed integers. Enumerations are handy for describing subsets of the integers. Enumerated data is declared as follows:
枚举与有符号整数具有相同的表示形式。枚举对于描述整数的子集很方便。枚举数据声明如下：
enum { name-identifier = constant, ... } identifier;
enum { name-identifier = constant, ... } identifier;
For example, the three colors red, yellow, and blue could be described by an enumerated type:
例如，红色、黄色和蓝色三种颜色可以用枚举类型来描述：
enum { RED = 2, YELLOW = 3, BLUE = 5 } colors;
enum { RED = 2, YELLOW = 3, BLUE = 5 } colors;
It is an error to encode as an enum any integer other than those that have been given assignments in the enum declaration.
将任何整数编码为枚举，而不是在枚举声明中指定的整数，这是一个错误。
Booleans are important enough and occur frequently enough to warrant their own explicit type in the standard. Booleans are declared as follows:
布尔值非常重要，并且经常出现，足以保证它们在标准中的显式类型。布尔值声明如下：
bool identifier;
布尔标识符；
This is equivalent to:
这相当于：
enum { FALSE = 0, TRUE = 1 } identifier;
enum { FALSE = 0, TRUE = 1 } identifier;
The standard also defines 64-bit (8-byte) numbers called hyper integers and unsigned hyper integers. Their representations are the obvious extensions of integer and unsigned integer defined above. They are represented in two's complement notation. The most and least significant bytes are 0 and 7, respectively. Their declarations:
该标准还定义了称为超整数和无符号超整数的64位（8字节）数字。它们的表示是上面定义的整数和无符号整数的明显扩展。它们用二的补码表示法表示。最高有效字节和最低有效字节分别为0和7。他们的声明：
hyper identifier; unsigned hyper identifier;
超标识符；无符号超标识符；
(MSB) (LSB)
+-------+-------+-------+-------+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 |byte 4 |byte 5 |byte 6 |byte 7 |
+-------+-------+-------+-------+-------+-------+-------+-------+
<----------------------------64 bits---------------------------->
HYPER INTEGER
UNSIGNED HYPER INTEGER
(MSB) (LSB)
+-------+-------+-------+-------+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 |byte 4 |byte 5 |byte 6 |byte 7 |
+-------+-------+-------+-------+-------+-------+-------+-------+
<----------------------------64 bits---------------------------->
HYPER INTEGER
UNSIGNED HYPER INTEGER
The standard defines the floating-point data type "float" (32 bits or 4 bytes). The encoding used is the IEEE standard for normalized single-precision floating-point numbers [IEEE]. The following three fields describe the single-precision floating-point number:
该标准定义了浮点数据类型“float”（32位或4字节）。使用的编码是标准化单精度浮点数的IEEE标准[IEEE]。以下三个字段描述单精度浮点数：
S: The sign of the number. Values 0 and 1 represent positive and negative, respectively. One bit.
S:数字的符号。值0和1分别表示正和负。一点。
E: The exponent of the number, base 2. 8 bits are devoted to this field. The exponent is biased by 127.
E：数字的指数，以2为底。8位用于此字段。指数有127的偏差。
F: The fractional part of the number's mantissa, base 2. 23 bits are devoted to this field.
F：数字尾数的小数部分，以2为底。23位用于此字段。
Therefore, the floating-point number is described by:
因此，浮点数的描述如下：
(-1)**S * 2**(E-Bias) * 1.F
(-1)**S * 2**(E-Bias) * 1.F
It is declared as follows:
声明如下：
float identifier;
浮点标识符；
+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 | SINGLE-PRECISION
S| E | F | FLOATING-POINT NUMBER
+-------+-------+-------+-------+
1|<- 8 ->|<-------23 bits------>|
<------------32 bits------------>
+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 | SINGLE-PRECISION
S| E | F | FLOATING-POINT NUMBER
+-------+-------+-------+-------+
1|<- 8 ->|<-------23 bits------>|
<------------32 bits------------>
Just as the most and least significant bytes of a number are 0 and 3, the most and least significant bits of a single-precision floating-point number are 0 and 31. The beginning bit (and most significant bit) offsets of S, E, and F are 0, 1, and 9, respectively. Note that these numbers refer to the mathematical positions of the bits, and NOT to their actual physical locations (which vary from medium to medium).
正如数字的最高和最低有效字节是0和3一样，单精度浮点数字的最高和最低有效位是0和31。S、E和F的起始位（和最高有效位）偏移量分别为0、1和9。请注意，这些数字指的是位的数学位置，而不是它们的实际物理位置（因介质而异）。
The IEEE specifications should be consulted concerning the encoding for signed zero, signed infinity (overflow), and denormalized numbers (underflow) [IEEE]. According to IEEE specifications, the "NaN" (not a number) is system dependent and should not be interpreted within XDR as anything other than "NaN".
关于符号零、符号无穷大（溢出）和非规范化数字（下溢）的编码，应参考IEEE规范[IEEE]。根据IEEE规范，“NaN”（不是数字）取决于系统，在XDR中不应解释为“NaN”以外的任何内容。
The standard defines the encoding for the double-precision floating-point data type "double" (64 bits or 8 bytes). The encoding used is the IEEE standard for normalized double-precision floating-point numbers [IEEE]. The standard encodes the following three fields, which describe the double-precision floating-point number:
该标准定义了双精度浮点数据类型“double”（64位或8字节）的编码。所使用的编码是标准化双精度浮点数的IEEE标准[IEEE]。该标准对以下三个字段进行编码，这三个字段描述双精度浮点数：
S: The sign of the number. Values 0 and 1 represent positive and negative, respectively. One bit.
S:数字的符号。值0和1分别表示正和负。一点。
E: The exponent of the number, base 2. 11 bits are devoted to this field. The exponent is biased by 1023.
E：数字的指数，以2为底。11位专用于该字段。指数有1023的偏差。
F: The fractional part of the number's mantissa, base 2. 52 bits are devoted to this field.
F：数字尾数的小数部分，以2为底。52位用于此字段。
Therefore, the floating-point number is described by:
因此，浮点数的描述如下：
(-1)**S * 2**(E-Bias) * 1.F
(-1)**S * 2**(E-Bias) * 1.F
It is declared as follows:
声明如下：
double identifier;
双重标识符；
+------+------+------+------+------+------+------+------+
|byte 0|byte 1|byte 2|byte 3|byte 4|byte 5|byte 6|byte 7|
S| E | F |
+------+------+------+------+------+------+------+------+
1|<--11-->|<-----------------52 bits------------------->|
<-----------------------64 bits------------------------->
DOUBLE-PRECISION FLOATING-POINT
+------+------+------+------+------+------+------+------+
|byte 0|byte 1|byte 2|byte 3|byte 4|byte 5|byte 6|byte 7|
S| E | F |
+------+------+------+------+------+------+------+------+
1|<--11-->|<-----------------52 bits------------------->|
<-----------------------64 bits------------------------->
DOUBLE-PRECISION FLOATING-POINT
Just as the most and least significant bytes of a number are 0 and 3, the most and least significant bits of a double-precision floating-point number are 0 and 63. The beginning bit (and most significant bit) offsets of S, E, and F are 0, 1, and 12, respectively. Note that these numbers refer to the mathematical positions of the bits, and NOT to their actual physical locations (which vary from medium to medium).
正如数字的最高和最低有效字节是0和3一样，双精度浮点数字的最高和最低有效位是0和63。S、E和F的起始位（和最高有效位）偏移量分别为0、1和12。请注意，这些数字指的是位的数学位置，而不是它们的实际物理位置（因介质而异）。
The IEEE specifications should be consulted concerning the encoding for signed zero, signed infinity (overflow), and denormalized numbers (underflow) [IEEE]. According to IEEE specifications, the "NaN" (not a number) is system dependent and should not be interpreted within XDR as anything other than "NaN".
关于符号零、符号无穷大（溢出）和非规范化数字（下溢）的编码，应参考IEEE规范[IEEE]。根据IEEE规范，“NaN”（不是数字）取决于系统，在XDR中不应解释为“NaN”以外的任何内容。
The standard defines the encoding for the quadruple-precision floating-point data type "quadruple" (128 bits or 16 bytes). The encoding used is designed to be a simple analog of the encoding used for single- and double-precision floating-point numbers using one form of IEEE double extended precision. The standard encodes the following three fields, which describe the quadruple-precision floating-point number:
该标准定义了四倍精度浮点数据类型“四倍”（128位或16字节）的编码。所使用的编码设计为使用一种形式的IEEE双扩展精度对单精度和双精度浮点数进行编码的简单模拟。标准对以下三个字段进行编码，这三个字段描述四精度浮点数：
S: The sign of the number. Values 0 and 1 represent positive and negative, respectively. One bit.
S:数字的符号。值0和1分别表示正和负。一点。
E: The exponent of the number, base 2. 15 bits are devoted to this field. The exponent is biased by 16383.
E：数字的指数，以2为底。15位用于此字段。指数有16383的偏差。
F: The fractional part of the number's mantissa, base 2. 112 bits are devoted to this field.
F：数字尾数的小数部分，以2为底。112位专用于该字段。
Therefore, the floating-point number is described by:
因此，浮点数的描述如下：
(-1)**S * 2**(E-Bias) * 1.F
(-1)**S * 2**(E-Bias) * 1.F
It is declared as follows:
声明如下：
quadruple identifier;
四重标识符；
+------+------+------+------+------+------+-...--+------+
|byte 0|byte 1|byte 2|byte 3|byte 4|byte 5| ... |byte15|
S| E | F |
+------+------+------+------+------+------+-...--+------+
1|<----15---->|<-------------112 bits------------------>|
<-----------------------128 bits------------------------>
QUADRUPLE-PRECISION FLOATING-POINT
+------+------+------+------+------+------+-...--+------+
|byte 0|byte 1|byte 2|byte 3|byte 4|byte 5| ... |byte15|
S| E | F |
+------+------+------+------+------+------+-...--+------+
1|<----15---->|<-------------112 bits------------------>|
<-----------------------128 bits------------------------>
QUADRUPLE-PRECISION FLOATING-POINT
Just as the most and least significant bytes of a number are 0 and 3, the most and least significant bits of a quadruple-precision floating-point number are 0 and 127. The beginning bit (and most significant bit) offsets of S, E , and F are 0, 1, and 16, respectively. Note that these numbers refer to the mathematical positions of the bits, and NOT to their actual physical locations (which vary from medium to medium).
正如数字的最高和最低有效字节是0和3一样，四精度浮点数字的最高和最低有效位是0和127。S、E和F的起始位（和最高有效位）偏移量分别为0、1和16。请注意，这些数字指的是位的数学位置，而不是它们的实际物理位置（因介质而异）。
The encoding for signed zero, signed infinity (overflow), and denormalized numbers are analogs of the corresponding encodings for single and double-precision floating-point numbers [SPAR], [HPRE]. The "NaN" encoding as it applies to quadruple-precision floating-point numbers is system dependent and should not be interpreted within XDR as anything other than "NaN".
有符号零、有符号无穷大（溢出）和非规范化数字的编码类似于单精度和双精度浮点数字[SPAR]、[HPRE]的相应编码。适用于四精度浮点数的“NaN”编码取决于系统，在XDR中不应解释为“NaN”以外的任何内容。
At times, fixed-length uninterpreted data needs to be passed among machines. This data is called "opaque" and is declared as follows:
有时，需要在机器之间传递固定长度的未解释数据。该数据称为“不透明”，声明如下：
opaque identifier[n];
不透明标识符[n]；
where the constant n is the (static) number of bytes necessary to contain the opaque data. If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count of the opaque object a multiple of four.
其中常数n是包含不透明数据所需的（静态）字节数。如果n不是四的倍数，那么n个字节后面会有足够的（0到3）剩余零字节r，以使不透明对象的总字节数为四的倍数。
0 1 ...
+--------+--------+...+--------+--------+...+--------+
| byte 0 | byte 1 |...|byte n-1| 0 |...| 0 |
+--------+--------+...+--------+--------+...+--------+
|<-----------n bytes---------->|<------r bytes------>|
|<-----------n+r (where (n+r) mod 4 = 0)------------>|
FIXED-LENGTH OPAQUE
0 1 ...
+--------+--------+...+--------+--------+...+--------+
| byte 0 | byte 1 |...|byte n-1| 0 |...| 0 |
+--------+--------+...+--------+--------+...+--------+
|<-----------n bytes---------->|<------r bytes------>|
|<-----------n+r (where (n+r) mod 4 = 0)------------>|
FIXED-LENGTH OPAQUE
The standard also provides for variable-length (counted) opaque data, defined as a sequence of n (numbered 0 through n-1) arbitrary bytes to be the number n encoded as an unsigned integer (as described below), and followed by the n bytes of the sequence.
该标准还规定了可变长度（计数）不透明数据，定义为n个（编号为0到n-1）任意字节的序列，将n个字节编码为无符号整数（如下所述），然后是序列的n个字节。
Byte m of the sequence always precedes byte m+1 of the sequence, and byte 0 of the sequence always follows the sequence's length (count). If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four. Variable-length opaque data is declared in the following way:
序列的字节m始终位于序列的字节m+1之前，序列的字节0始终位于序列的长度（计数）之后。如果n不是四的倍数，那么n个字节后面有足够的（0到3）剩余零字节r，以使总字节数为四的倍数。可变长度不透明数据的声明方式如下：
opaque identifier<m>;
or
opaque identifier<>;
opaque identifier<m>;
or
opaque identifier<>;
The constant m denotes an upper bound of the number of bytes that the sequence may contain. If m is not specified, as in the second declaration, it is assumed to be (2**32) - 1, the maximum length.
常数m表示序列可能包含的字节数的上限。如果未指定m，如第二次声明中所述，则假定m为（2**32）-1，即最大长度。
The constant m would normally be found in a protocol specification. For example, a filing protocol may state that the maximum data transfer size is 8192 bytes, as follows:
常数m通常可以在协议规范中找到。例如，归档协议可以规定最大数据传输大小为8192字节，如下所示：
opaque filedata<8192>;
opaque filedata<8192>;
0 1 2 3 4 5 ...
+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
| length n |byte0|byte1|...| n-1 | 0 |...| 0 |
+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
|<-------4 bytes------->|<------n bytes------>|<---r bytes--->|
|<----n+r (where (n+r) mod 4 = 0)---->|
VARIABLE-LENGTH OPAQUE
0 1 2 3 4 5 ...
+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
| length n |byte0|byte1|...| n-1 | 0 |...| 0 |
+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
|<-------4 bytes------->|<------n bytes------>|<---r bytes--->|
|<----n+r (where (n+r) mod 4 = 0)---->|
VARIABLE-LENGTH OPAQUE
It is an error to encode a length greater than the maximum described in the specification.
编码长度大于规范中描述的最大长度是错误的。
The standard defines a string of n (numbered 0 through n-1) ASCII bytes to be the number n encoded as an unsigned integer (as described above), and followed by the n bytes of the string. Byte m of the string always precedes byte m+1 of the string, and byte 0 of the string always follows the string's length. If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four. Counted byte strings are declared as follows:
该标准将n（编号为0到n-1）ASCII字节的字符串定义为编码为无符号整数（如上所述）的数字n，后跟字符串的n字节。字符串的字节m始终位于字符串的字节m+1之前，字符串的字节0始终位于字符串的长度之后。如果n不是四的倍数，那么n个字节后面有足够的（0到3）剩余零字节r，以使总字节数为四的倍数。计数字节字符串声明如下：
string object<m>;
or
string object<>;
string object<m>;
or
string object<>;
The constant m denotes an upper bound of the number of bytes that a string may contain. If m is not specified, as in the second declaration, it is assumed to be (2**32) - 1, the maximum length. The constant m would normally be found in a protocol specification. For example, a filing protocol may state that a file name can be no longer than 255 bytes, as follows:
常数m表示字符串可能包含的字节数的上限。如果未指定m，如第二次声明中所述，则假定m为（2**32）-1，即最大长度。常数m通常可以在协议规范中找到。例如，归档协议可能规定文件名不能超过255字节，如下所示：
string filename<255>;
string filename<255>;
0 1 2 3 4 5 ...
+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
| length n |byte0|byte1|...| n-1 | 0 |...| 0 |
+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
|<-------4 bytes------->|<------n bytes------>|<---r bytes--->|
|<----n+r (where (n+r) mod 4 = 0)---->|
STRING
0 1 2 3 4 5 ...
+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
| length n |byte0|byte1|...| n-1 | 0 |...| 0 |
+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
|<-------4 bytes------->|<------n bytes------>|<---r bytes--->|
|<----n+r (where (n+r) mod 4 = 0)---->|
STRING
It is an error to encode a length greater than the maximum described in the specification.
编码长度大于规范中描述的最大长度是错误的。
Declarations for fixed-length arrays of homogeneous elements are in the following form:
同质元素的固定长度数组的声明采用以下形式：
type-name identifier[n];
类型名称标识符[n]；
Fixed-length arrays of elements numbered 0 through n-1 are encoded by individually encoding the elements of the array in their natural order, 0 through n-1. Each element's size is a multiple of four bytes. Though all elements are of the same type, the elements may have different sizes. For example, in a fixed-length array of strings, all elements are of type "string", yet each element will vary in its length.
编号为0到n-1的元素的固定长度数组通过按其自然顺序（0到n-1）单独编码数组元素进行编码。每个元素的大小是四个字节的倍数。虽然所有图元的类型相同，但图元的大小可能不同。例如，在固定长度的字符串数组中，所有元素都是“string”类型，但每个元素的长度都会有所不同。
+---+---+---+---+---+---+---+---+...+---+---+---+---+
| element 0 | element 1 |...| element n-1 |
+---+---+---+---+---+---+---+---+...+---+---+---+---+
|<--------------------n elements------------------->|
+---+---+---+---+---+---+---+---+...+---+---+---+---+
| element 0 | element 1 |...| element n-1 |
+---+---+---+---+---+---+---+---+...+---+---+---+---+
|<--------------------n elements------------------->|
FIXED-LENGTH ARRAY
定长阵列
Counted arrays provide the ability to encode variable-length arrays of homogeneous elements. The array is encoded as the element count n (an unsigned integer) followed by the encoding of each of the array's elements, starting with element 0 and progressing through element n-1. The declaration for variable-length arrays follows this form:
计数数组提供了对同质元素的可变长度数组进行编码的能力。数组被编码为元素计数n（一个无符号整数），然后是每个数组元素的编码，从元素0开始，一直到元素n-1。可变长度数组的声明如下所示：
type-name identifier<m>;
or
type-name identifier<>;
type-name identifier<m>;
or
type-name identifier<>;
The constant m specifies the maximum acceptable element count of an array; if m is not specified, as in the second declaration, it is assumed to be (2**32) - 1.
常量m指定数组的最大可接受元素计数；如果未指定m，如第二个声明中所述，则假定m为（2**32）-1。
0 1 2 3
+--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
| n | element 0 | element 1 |...|element n-1|
+--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
|<-4 bytes->|<--------------n elements------------->|
COUNTED ARRAY
0 1 2 3
+--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
| n | element 0 | element 1 |...|element n-1|
+--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
|<-4 bytes->|<--------------n elements------------->|
COUNTED ARRAY
It is an error to encode a value of n that is greater than the maximum described in the specification.
对大于规范中所述最大值的n值进行编码是错误的。
Structures are declared as follows:
结构声明如下：
struct {
component-declaration-A;
component-declaration-B;
...
} identifier;
struct {
component-declaration-A;
component-declaration-B;
...
} identifier;
The components of the structure are encoded in the order of their declaration in the structure. Each component's size is a multiple of four bytes, though the components may be different sizes.
结构的组件按照其在结构中的声明顺序进行编码。每个组件的大小是四个字节的倍数，尽管组件的大小可能不同。
+-------------+-------------+...
| component A | component B |... STRUCTURE
+-------------+-------------+...
+-------------+-------------+...
| component A | component B |... STRUCTURE
+-------------+-------------+...
A discriminated union is a type composed of a discriminant followed by a type selected from a set of prearranged types according to the value of the discriminant. The type of discriminant is either "int", "unsigned int", or an enumerated type, such as "bool". The component types are called "arms" of the union and are preceded by the value of the discriminant that implies their encoding. Discriminated unions are declared as follows:
判别并集是由一个判别式和一个根据该判别式的值从一组预先安排好的类型中选择的类型组成的类型。判别式的类型可以是“int”、“unsigned int”或枚举类型，如“bool”。组件类型称为联合的“arms”，前面是表示其编码的判别式的值。受歧视的工会声明如下：
union switch (discriminant-declaration) {
case discriminant-value-A:
arm-declaration-A;
case discriminant-value-B:
arm-declaration-B;
...
default: default-declaration;
} identifier;
union switch (discriminant-declaration) {
case discriminant-value-A:
arm-declaration-A;
case discriminant-value-B:
arm-declaration-B;
...
default: default-declaration;
} identifier;
Each "case" keyword is followed by a legal value of the discriminant. The default arm is optional. If it is not specified, then a valid encoding of the union cannot take on unspecified discriminant values. The size of the implied arm is always a multiple of four bytes.
每个“case”关键字后面都跟有判别式的法律值。默认臂是可选的。如果未指定，则union的有效编码不能采用未指定的鉴别值。隐含arm的大小始终是四个字节的倍数。
The discriminated union is encoded as its discriminant followed by the encoding of the implied arm.
被鉴别的并集被编码为其判别式，随后是隐含臂的编码。
0 1 2 3
+---+---+---+---+---+---+---+---+
| discriminant | implied arm | DISCRIMINATED UNION
+---+---+---+---+---+---+---+---+
|<---4 bytes--->|
0 1 2 3
+---+---+---+---+---+---+---+---+
| discriminant | implied arm | DISCRIMINATED UNION
+---+---+---+---+---+---+---+---+
|<---4 bytes--->|
An XDR void is a 0-byte quantity. Voids are useful for describing operations that take no data as input or no data as output. They are also useful in unions, where some arms may contain data and others do not. The declaration is simply as follows:
XDR void是一个0字节的数量。空洞用于描述不以数据作为输入或不以数据作为输出的操作。它们在工会中也很有用，有些部门可能包含数据，而另一些部门则不包含数据。声明内容如下：
void;
无效的
Voids are illustrated as follows:
空隙如下图所示：
++
|| VOID
++
--><-- 0 bytes
++
|| VOID
++
--><-- 0 bytes
The data declaration for a constant follows this form:
常数的数据声明如下所示：
const name-identifier = n;
常量名称标识符=n；
"const" is used to define a symbolic name for a constant; it does not declare any data. The symbolic constant may be used anywhere a regular constant may be used. For example, the following defines a symbolic constant DOZEN, equal to 12.
“const”用于定义常量的符号名；它不声明任何数据。符号常量可以在任何可以使用常规常量的地方使用。例如，下面定义了一个符号常量，等于12。
const DOZEN = 12;
常数=12；
"typedef" does not declare any data either, but serves to define new identifiers for declaring data. The syntax is:
“typedef”也不声明任何数据，但用于定义用于声明数据的新标识符。语法是：
typedef declaration;
类型定义声明；
The new type name is actually the variable name in the declaration part of the typedef. For example, the following defines a new type called "eggbox" using an existing type called "egg":
新类型名实际上是typedef声明部分中的变量名。例如，下面使用名为“egg”的现有类型定义了一个名为“egggbox”的新类型：
typedef egg eggbox[DOZEN];
蛋盒[打]；
Variables declared using the new type name have the same type as the new type name would have in the typedef, if it were considered a variable. For example, the following two declarations are equivalent in declaring the variable "fresheggs":
使用新类型名声明的变量的类型与typedef中的新类型名的类型相同（如果将其视为变量）。例如，以下两个声明在声明变量“freshGGS”时是等效的：
eggbox fresheggs; egg fresheggs[DOZEN];
鸡蛋盒；鲜鸡蛋[打]；
When a typedef involves a struct, enum, or union definition, there is another (preferred) syntax that may be used to define the same type. In general, a typedef of the following form:
当typedef涉及结构、枚举或联合定义时，可以使用另一种（首选）语法来定义相同的类型。通常情况下，typedef的格式如下：
typedef <<struct, union, or enum definition>> identifier;
typedef <<struct, union, or enum definition>> identifier;
may be converted to the alternative form by removing the "typedef" part and placing the identifier after the "struct", "union", or "enum" keyword, instead of at the end. For example, here are the two ways to define the type "bool":
可以通过删除“typedef”部分并将标识符放在“struct”、“union”或“enum”关键字之后（而不是放在末尾）来转换为替代形式。例如，以下是定义类型“bool”的两种方法：
typedef enum { /* using typedef */
FALSE = 0,
TRUE = 1
} bool;
typedef enum { /* using typedef */
FALSE = 0,
TRUE = 1
} bool;
enum bool { /* preferred alternative */
FALSE = 0,
TRUE = 1
};
enum bool { /* preferred alternative */
FALSE = 0,
TRUE = 1
};
This syntax is preferred because one does not have to wait until the end of a declaration to figure out the name of the new type.
这种语法是首选的，因为人们不必等到声明结束后才知道新类型的名称。
Optional-data is one kind of union that occurs so frequently that we give it a special syntax of its own for declaring it. It is declared as follows:
我们经常为它声明一种特殊的并集，所以我们给它一种可选的语法。声明如下：
type-name *identifier;
类型名称*标识符；
This is equivalent to the following union:
这相当于以下接头：
union switch (bool opted) {
case TRUE:
type-name element;
case FALSE:
void;
} identifier;
union switch (bool opted) {
case TRUE:
type-name element;
case FALSE:
void;
} identifier;
It is also equivalent to the following variable-length array declaration, since the boolean "opted" can be interpreted as the length of the array:
它还等效于以下可变长度数组声明，因为布尔值“opted”可以解释为数组的长度：
type-name identifier<1>;
type-name identifier<1>;
Optional-data is not so interesting in itself, but it is very useful for describing recursive data-structures such as linked-lists and trees. For example, the following defines a type "stringlist" that encodes lists of zero or more arbitrary length strings:
可选数据本身并不那么有趣，但它对于描述递归数据结构（如链表和树）非常有用。例如，以下定义了一种类型“stringlist”，它对零个或多个任意长度字符串的列表进行编码：
struct stringentry {
string item<>;
stringentry *next;
};
struct stringentry {
string item<>;
stringentry *next;
};
typedef stringentry *stringlist;
typedef stringentry*stringlist；
It could have been equivalently declared as the following union:
它可以被等价地宣布为以下联盟：
union stringlist switch (bool opted) {
case TRUE:
struct {
string item<>;
stringlist next;
} element;
case FALSE:
void;
};
union stringlist switch (bool opted) {
case TRUE:
struct {
string item<>;
stringlist next;
} element;
case FALSE:
void;
};
or as a variable-length array:
或作为可变长度数组：
struct stringentry {
string item<>;
stringentry next<1>;
};
struct stringentry {
string item<>;
stringentry next<1>;
};
typedef stringentry stringlist<1>;
typedef stringentry stringlist<1>;
Both of these declarations obscure the intention of the stringlist type, so the optional-data declaration is preferred over both of them. The optional-data type also has a close correlation to how recursive data structures are represented in high-level languages such as Pascal or C by use of pointers. In fact, the syntax is the same as that of the C language for pointers.
这两种声明都模糊了stringlist类型的意图，因此可选数据声明优于这两种声明。可选数据类型还与递归数据结构在高级语言（如Pascal或C）中如何通过指针表示密切相关。实际上，指针的语法与C语言的语法相同。
The XDR standard lacks representations for bit fields and bitmaps, since the standard is based on bytes. Also missing are packed (or binary-coded) decimals.
XDR标准缺少位字段和位图的表示，因为该标准基于字节。还缺少压缩（或二进制编码）小数。
The intent of the XDR standard was not to describe every kind of data that people have ever sent or will ever want to send from machine to machine. Rather, it only describes the most commonly used data-types of high-level languages such as Pascal or C so that applications written in these languages will be able to communicate easily over some medium.
XDR标准的目的不是描述人们曾经发送或将要从一台机器发送到另一台机器的每一种数据。相反，它只描述高级语言（如Pascal或C）中最常用的数据类型，以便用这些语言编写的应用程序能够通过某种介质轻松通信。
One could imagine extensions to XDR that would let it describe almost any existing protocol, such as TCP. The minimum necessary for this is support for different block sizes and byte-orders. The XDR discussed here could then be considered the 4-byte big-endian member of a larger XDR family.
可以想象XDR的扩展可以让它描述几乎任何现有的协议，比如TCP。这方面的最低要求是支持不同的块大小和字节顺序。这里讨论的XDR可以被认为是更大XDR家族中的4字节big-endian成员。
(1) Why use a language for describing data? What's wrong with diagrams?
(1) 为什么要使用语言来描述数据？图表有什么问题？
There are many advantages in using a data-description language such as XDR versus using diagrams. Languages are more formal than diagrams and lead to less ambiguous descriptions of data. Languages are also easier to understand and allow one to think of other issues instead of the low-level details of bit encoding. Also, there is a close analogy between the types of XDR and a high-level language such as C or Pascal. This makes the implementation of XDR encoding and decoding modules an easier task. Finally, the language specification itself is an ASCII string that can be passed from machine to machine to perform on-the-fly data interpretation.
与使用图表相比，使用XDR等数据描述语言有许多优势。语言比图表更正式，对数据的描述也不那么模棱两可。语言也更容易理解，并允许人们思考其他问题，而不是位编码的低级细节。此外，XDR的类型与高级语言（如C或Pascal）之间有着密切的相似性。这使得XDR编码和解码模块的实现变得更容易。最后，语言规范本身是一个ASCII字符串，可以从一台机器传递到另一台机器，以执行动态数据解释。
(2) Why is there only one byte-order for an XDR unit?
(2) 为什么XDR单元只有一个字节顺序？
Supporting two byte-orderings requires a higher-level protocol for determining in which byte-order the data is encoded. Since XDR is not a protocol, this can't be done. The advantage of this, though, is that data in XDR format can be written to a magnetic tape, for example, and any machine will be able to interpret it, since no higher-level protocol is necessary for determining the byte-order.
支持双字节排序需要更高级别的协议来确定数据编码的字节顺序。因为XDR不是一个协议，所以不能这样做。不过，这样做的好处是，例如，XDR格式的数据可以写入磁带，任何机器都可以对其进行解释，因为确定字节顺序不需要更高级别的协议。
(3) Why is the XDR byte-order big-endian instead of little-endian? Isn't this unfair to little-endian machines such as the VAX(r), which has to convert from one form to the other?
(3) 为什么XDR字节顺序是big-endian而不是little-endian？这对像VAX（r）这样必须从一种形式转换到另一种形式的小终端机器不公平吗？
Yes, it is unfair, but having only one byte-order means you have to be unfair to somebody. Many architectures, such as the Motorola 68000* and IBM 370*, support the big-endian byte-order.
是的，这是不公平的，但是只有一个字节顺序意味着你必须对某人不公平。许多体系结构，如摩托罗拉68000*和IBM 370*，都支持大端字节顺序。
(4) Why is the XDR unit four bytes wide?
(4) 为什么XDR单元有四个字节宽？
There is a tradeoff in choosing the XDR unit size. Choosing a small size, such as two, makes the encoded data small, but causes alignment problems for machines that aren't aligned on these boundaries. A large size, such as eight, means the data will be aligned on virtually every machine, but causes the encoded data to grow too big. We chose four as a compromise. Four is big enough to support most architectures efficiently, except for rare machines such as the eight-byte-aligned Cray*. Four is also small enough to keep the encoded data restricted to a reasonable size.
在选择XDR单元大小时需要权衡。选择较小的大小（如两个）会使编码数据变小，但会导致未在这些边界上对齐的机器出现对齐问题。大尺寸（如8）意味着数据将在几乎每台机器上对齐，但会导致编码数据增长过大。我们选择了四个作为折衷方案。4足够大，可以有效地支持大多数体系结构，但罕见的机器除外，如8字节对齐的Cray*。四还足够小，可以将编码数据限制在合理的大小。
(5) Why must variable-length data be padded with zeros?
(5) 为什么可变长度数据必须用零填充？
It is desirable that the same data encode into the same thing on all machines, so that encoded data can be meaningfully compared or checksummed. Forcing the padded bytes to be zero ensures this.
希望在所有机器上将相同的数据编码成相同的内容，以便对编码的数据进行有意义的比较或校验和。强制填充字节为零可以确保这一点。
(6) Why is there no explicit data-typing?
(6) 为什么没有明确的数据类型？
Data-typing has a relatively high cost for what small advantages it may have. One cost is the expansion of data due to the inserted type fields. Another is the added cost of interpreting these type fields and acting accordingly. And most protocols already know what type they expect, so data-typing supplies only redundant information. However, one can still get the benefits of data-typing using XDR. One way is to encode two things: first, a string that is the XDR data description of the encoded data, and then the encoded data itself. Another way is to assign a value to all the types in XDR, and then define a universal type that takes this value as its discriminant and for each value, describes the corresponding data type.
数据类型可能有一些小的优势，但成本相对较高。一个成本是由于插入类型字段而导致的数据扩展。另一个是解释这些类型字段并采取相应行动的额外成本。而且大多数协议已经知道它们期望的类型，所以数据类型只提供冗余信息。但是，使用XDR仍然可以获得数据类型化的好处。一种方法是编码两件事：首先，一个字符串是编码数据的XDR数据描述，然后是编码数据本身。另一种方法是为XDR中的所有类型分配一个值，然后定义一个通用类型，该类型将该值作为其判别式，并为每个值描述相应的数据类型。
This specification uses an extended Back-Naur Form notation for describing the XDR language. Here is a brief description of the notation:
本规范使用扩展的Back-Naur形式表示法来描述XDR语言。以下是符号的简要说明：
(1) The characters '|', '(', ')', '[', ']', '"', and '*' are special. (2) Terminal symbols are strings of any characters surrounded by double quotes. (3) Non-terminal symbols are strings of non-special characters. (4) Alternative items are separated by a vertical bar
(1) 字符“|”、“（“，”）”、“[”、“]”、““””和“*”是特殊的。（2）终端符号是由双引号包围的任何字符组成的字符串。（3）非终端符号是由非特殊字符组成的字符串。（4）可选项由竖线分隔
("|"). (5) Optional items are enclosed in brackets. (6) Items are grouped together by enclosing them in parentheses. (7) A '*' following an item means 0 or more occurrences of that item.
("|"). （5） 可选项目用括号括起来。（6） 通过将项目括在括号中将其分组在一起。（7） 项目后面的“*”表示该项目出现0次或多次。
For example, consider the following pattern:
例如，考虑以下模式：
"a " "very" (", " "very")* [" cold " "and "] " rainy "
("day" | "night")
"a " "very" (", " "very")* [" cold " "and "] " rainy "
("day" | "night")
An infinite number of strings match this pattern. A few of them are:
无限多的字符串与此模式匹配。其中一些是：
"a very rainy day" "a very, very rainy day" "a very cold and rainy day" "a very, very, very cold and rainy night"
“非常下雨的一天”“非常非常下雨的一天”“非常寒冷和下雨的一天”“非常非常寒冷和下雨的夜晚”
(1) Comments begin with '/*' and terminate with '*/'. (2) White space serves to separate items and is otherwise ignored. (3) An identifier is a letter followed by an optional sequence of letters, digits, or underbar ('_'). The case of identifiers is not ignored. (4) A decimal constant expresses a number in base 10 and is a sequence of one or more decimal digits, where the first digit is not a zero, and is optionally preceded by a minus-sign ('-'). (5) A hexadecimal constant expresses a number in base 16, and must be preceded by '0x', followed by one or hexadecimal digits ('A', 'B', 'C', 'D', E', 'F', 'a', 'b', 'c', 'd', 'e', 'f', '0', '1', '2', '3', '4', '5', '6', '7', '8', '9'). (6) An octal constant expresses a number in base 8, always leads with digit 0, and is a sequence of one or more octal digits ('0', '1', '2', '3', '4', '5', '6', '7').
(1) 注释以“/*”开头，以“*/”结尾。（2） 空白用于分隔项目，否则将被忽略。（3） 标识符是一个字母，后跟一系列可选的字母、数字或下划线（“UZ”）。标识符的情况不会被忽略。（4） 十进制常数表示以10为基数的数字，是一个由一个或多个十进制数字组成的序列，其中第一个数字不是零，可以选择前面加减号（'-'）。（5） 十六进制常数以16为基数表示一个数字，前面必须加上“0x”，后跟一个或十六进制数字（“A”、“B”、“C”、“D”、“E”、“F”、“A”、“B”、“C”、“D”、“E”、“F”、“0”、“1”、“2”、“3”、“4”、“5”、“6”、“7”、“8”、“9”）。（6） 八进制常数表示基数为8的数字，总是以数字0开头，是一个或多个八进制数字的序列（“0”、“1”、“2”、“3”、“4”、“5”、“6”、“7”）。
declaration:
type-specifier identifier
| type-specifier identifier "[" value "]"
| type-specifier identifier "<" [ value ] ">"
| "opaque" identifier "[" value "]"
| "opaque" identifier "<" [ value ] ">"
| "string" identifier "<" [ value ] ">"
| type-specifier "*" identifier
| "void"
declaration:
type-specifier identifier
| type-specifier identifier "[" value "]"
| type-specifier identifier "<" [ value ] ">"
| "opaque" identifier "[" value "]"
| "opaque" identifier "<" [ value ] ">"
| "string" identifier "<" [ value ] ">"
| type-specifier "*" identifier
| "void"
value: constant | identifier
值：常数|标识符
constant: decimal-constant | hexadecimal-constant | octal-constant
常数：十进制常数|十六进制常数|八进制常数
type-specifier:
[ "unsigned" ] "int"
| [ "unsigned" ] "hyper"
| "float"
| "double"
| "quadruple"
| "bool"
| enum-type-spec
| struct-type-spec
| union-type-spec
| identifier
type-specifier:
[ "unsigned" ] "int"
| [ "unsigned" ] "hyper"
| "float"
| "double"
| "quadruple"
| "bool"
| enum-type-spec
| struct-type-spec
| union-type-spec
| identifier
enum-type-spec: "enum" enum-body
枚举类型规范：“枚举”枚举体
enum-body: "{" ( identifier "=" value ) ( "," identifier "=" value )* "}"
枚举正文：“{”（标识符“=”值）（“，”标识符“=”值）*“}”
struct-type-spec: "struct" struct-body
结构类型规范：“结构”结构体
struct-body: "{" ( declaration ";" ) ( declaration ";" )* "}"
结构体：“{”（声明“；”）（声明“；”*“}”
union-type-spec: "union" union-body
活接头类型规范：“活接头”活接头主体
union-body: "switch" "(" declaration ")" "{" case-spec case-spec * [ "default" ":" declaration ";" ] "}"
联合体：“开关”“（“声明”）“{”案例规范案例规范*[“默认值”“：“声明”]“}”
case-spec: ( "case" value ":") ( "case" value ":") * declaration ";"
案例规范：（“案例”值）：（“案例”值：）*声明
constant-def: "const" identifier "=" constant ";"
常量定义：“常量”标识符“=“常量”
type-def:
"typedef" declaration ";"
| "enum" identifier enum-body ";"
| "struct" identifier struct-body ";"
| "union" identifier union-body ";"
type-def:
"typedef" declaration ";"
| "enum" identifier enum-body ";"
| "struct" identifier struct-body ";"
| "union" identifier union-body ";"
definition: type-def | constant-def
定义：类型def |常量def
specification: definition *
规范：定义*
(1) The following are keywords and cannot be used as identifiers: "bool", "case", "const", "default", "double", "quadruple", "enum", "float", "hyper", "int", "opaque", "string", "struct", "switch", "typedef", "union", "unsigned", and "void".
(1) 以下是关键字，不能用作标识符：“bool”、“case”、“const”、“default”、“double”、“quartle”、“enum”、“float”、“hyper”、“int”、“不透明”、“string”、“struct”、“switch”、“typedef”、“union”、“unsigned”和“void”。
(2) Only unsigned constants may be used as size specifications for arrays. If an identifier is used, it must have been declared previously as an unsigned constant in a "const" definition.
(2) 只有无符号常量可以用作数组的大小规格。如果使用了标识符，则必须在“const”定义中将其声明为无符号常量。
(3) Constant and type identifiers within the scope of a specification are in the same name space and must be declared uniquely within this scope.
(3) 规范范围内的常量标识符和类型标识符位于相同的名称空间中，并且必须在此范围内唯一声明。
(4) Similarly, variable names must be unique within the scope of struct and union declarations. Nested struct and union declarations create new scopes.
(4) 类似地，变量名在结构和联合声明的范围内必须是唯一的。嵌套的结构和联合声明创建新的作用域。
(5) The discriminant of a union must be of a type that evaluates to an integer. That is, "int", "unsigned int", "bool", an enumerated type, or any typedefed type that evaluates to one of these is legal. Also, the case values must be one of the legal values of the discriminant. Finally, a case value may not be specified more than once within the scope of a union declaration.
(5) 联合的判别式必须是计算结果为整数的类型。也就是说，“int”、“unsigned int”、“bool”、枚举类型或任何计算为其中一种类型的typedefed类型都是合法的。此外，案例值必须是歧视性的法律值之一。最后，在联合声明的范围内，不能多次指定case值。
Here is a short XDR data description of a thing called a "file", which might be used to transfer files from one machine to another.
下面是一个称为“文件”的东西的简短XDR数据描述，它可能用于将文件从一台机器传输到另一台机器。
const MAXUSERNAME = 32; /* max length of a user name */
const MAXFILELEN = 65535; /* max length of a file */
const MAXNAMELEN = 255; /* max length of a file name */
const MAXUSERNAME = 32; /* max length of a user name */
const MAXFILELEN = 65535; /* max length of a file */
const MAXNAMELEN = 255; /* max length of a file name */
/*
* Types of files:
*/
enum filekind {
TEXT = 0, /* ascii data */
DATA = 1, /* raw data */
EXEC = 2 /* executable */
};
/*
* Types of files:
*/
enum filekind {
TEXT = 0, /* ascii data */
DATA = 1, /* raw data */
EXEC = 2 /* executable */
};
/*
* File information, per kind of file:
*/
union filetype switch (filekind kind) {
case TEXT:
void; /* no extra information */
case DATA:
string creator<MAXNAMELEN>; /* data creator */
case EXEC:
string interpretor<MAXNAMELEN>; /* program interpretor */
};
/*
* File information, per kind of file:
*/
union filetype switch (filekind kind) {
case TEXT:
void; /* no extra information */
case DATA:
string creator<MAXNAMELEN>; /* data creator */
case EXEC:
string interpretor<MAXNAMELEN>; /* program interpretor */
};
/*
* A complete file:
*/
struct file {
string filename<MAXNAMELEN>; /* name of file */
filetype type; /* info about file */
string owner<MAXUSERNAME>; /* owner of file */
opaque data<MAXFILELEN>; /* file data */
};
/*
* A complete file:
*/
struct file {
string filename<MAXNAMELEN>; /* name of file */
filetype type; /* info about file */
string owner<MAXUSERNAME>; /* owner of file */
opaque data<MAXFILELEN>; /* file data */
};
Suppose now that there is a user named "john" who wants to store his lisp program "sillyprog" that contains just the data "(quit)". His file would be encoded as follows:
假设现在有一个名为“john”的用户想要存储他的lisp程序“sillyprog”，该程序只包含数据（quit）。他的档案编码如下：
OFFSET HEX BYTES ASCII COMMENTS
------ --------- ----- --------
0 00 00 00 09 .... -- length of filename = 9
4 73 69 6c 6c sill -- filename characters
8 79 70 72 6f ypro -- ... and more characters ...
12 67 00 00 00 g... -- ... and 3 zero-bytes of fill
16 00 00 00 02 .... -- filekind is EXEC = 2
20 00 00 00 04 .... -- length of interpretor = 4
24 6c 69 73 70 lisp -- interpretor characters
28 00 00 00 04 .... -- length of owner = 4
32 6a 6f 68 6e john -- owner characters
36 00 00 00 06 .... -- length of file data = 6
40 28 71 75 69 (qui -- file data bytes ...
44 74 29 00 00 t).. -- ... and 2 zero-bytes of fill
OFFSET HEX BYTES ASCII COMMENTS
------ --------- ----- --------
0 00 00 00 09 .... -- length of filename = 9
4 73 69 6c 6c sill -- filename characters
8 79 70 72 6f ypro -- ... and more characters ...
12 67 00 00 00 g... -- ... and 3 zero-bytes of fill
16 00 00 00 02 .... -- filekind is EXEC = 2
20 00 00 00 04 .... -- length of interpretor = 4
24 6c 69 73 70 lisp -- interpretor characters
28 00 00 00 04 .... -- length of owner = 4
32 6a 6f 68 6e john -- owner characters
36 00 00 00 06 .... -- length of file data = 6
40 28 71 75 69 (qui -- file data bytes ...
44 74 29 00 00 t).. -- ... and 2 zero-bytes of fill
XDR is a data description language, not a protocol, and hence it does not inherently give rise to any particular security considerations. Protocols that carry XDR-formatted data, such as NFSv4, are responsible for providing any necessary security services to secure the data they transport.
XDR是一种数据描述语言，而不是一种协议，因此它本身不会引起任何特定的安全考虑。承载XDR格式数据的协议（如NFSv4）负责提供任何必要的安全服务，以保护其传输的数据的安全。
Care must be take to properly encode and decode data to avoid attacks. Known and avoidable risks include:
必须注意正确编码和解码数据，以避免攻击。已知和可避免的风险包括：
* Buffer overflow attacks. Where feasible, protocols should be defined with explicit limits (via the "<" [ value ] ">" notation instead of "<" ">") on elements with variable-length data types. Regardless of the feasibility of an explicit limit on the variable length of an element of a given protocol, decoders need to ensure the incoming size does not exceed the length of any provisioned receiver buffers.
* 缓冲区溢出攻击。在可行的情况下，协议应在具有可变长度数据类型的元素上定义明确的限制（通过“<”[值]“>”符号而不是“<”>”）。不管对给定协议元素的可变长度进行明确限制的可行性如何，解码器都需要确保传入大小不超过任何已配置接收器缓冲区的长度。
* Nul octets embedded in an encoded value of type string. If the decoder's native string format uses nul-terminated strings, then the apparent size of the decoded object will be less than the amount of memory allocated for the string. Some memory deallocation interfaces take a size argument. The caller of the deallocation interface would likely determine the size of the string by counting to the location of the nul octet and adding one. This discrepancy can cause memory leakage (because less memory is actually returned to the free pool than allocated), leading to system failure and a denial of service attack.
* 嵌入字符串类型编码值中的Nul八位字节。如果解码器的本机字符串格式使用nul终止的字符串，则解码对象的外观大小将小于为该字符串分配的内存量。某些内存释放接口采用大小参数。释放接口的调用者可能会通过计算nul八位字节的位置并添加一个来确定字符串的大小。这种差异可能会导致内存泄漏（因为实际返回到可用池的内存少于分配的内存），从而导致系统故障和拒绝服务攻击。
* Decoding of characters in strings that are legal ASCII characters but nonetheless are illegal for the intended application. For example, some operating systems treat the '/'
* 解码字符串中的字符，这些字符串是合法的ASCII字符，但对于预期的应用来说是非法的。例如，某些操作系统处理“/”字符
character as a component separator in path names. For a protocol that encodes a string in the argument to a file creation operation, the decoder needs to ensure that '/' is not inside the component name. Otherwise, a file with an illegal '/' in its name will be created, making it difficult to remove, and is therefore a denial of service attack.
作为路径名中的组件分隔符的字符。对于将参数中的字符串编码为文件创建操作的协议，解码器需要确保“/”不在组件名称内。否则，将创建名称中包含非法“/”的文件，使其难以删除，因此属于拒绝服务攻击。
* Denial of service caused by recursive decoder or encoder subroutines. A recursive decoder or encoder might process data that has a structured type with a member of type optional data that directly or indirectly refers to the structured type (i.e., a linked list). For example,
* 由递归解码器或编码器子例程引起的拒绝服务。递归解码器或编码器可能会处理具有结构化类型的数据，其中包含直接或间接引用结构化类型（即链表）的可选数据类型的成员。例如
struct m {
int x;
struct m *next;
};
struct m {
int x;
struct m *next;
};
An encoder or decoder subroutine might be written to recursively call itself each time another element of type "struct m" is found. An attacker could construct a long linked list of "struct m" elements in the request or response, which then causes a stack overflow on the decoder or encoder. Decoders and encoders should be written non-recursively or impose a limit on list length.
每次找到另一个“struct m”类型的元素时，编码器或解码器子例程可能会被编写为递归地调用自身。攻击者可以在请求或响应中构造“struct m”元素的长链表，从而在解码器或编码器上造成堆栈溢出。解码器和编码器应以非递归方式写入，或对列表长度施加限制。
It is possible, if not likely, that new data types will be added to XDR in the future. The process for adding new types is via a standards track RFC and not registration of new types with IANA. Standards track RFCs that update or replace this document should be documented as such in the RFC Editor's database of RFCs.
将来有可能（如果不太可能）向XDR添加新的数据类型。添加新类型的过程是通过标准跟踪RFC，而不是向IANA注册新类型。更新或替换本文件的标准跟踪RFC应记录在RFC编辑器的RFC数据库中。
SUN WORKSTATION Sun Microsystems, Inc. VAX Hewlett-Packard Company IBM-PC International Business Machines Corporation Cray Cray Inc. NFS Sun Microsystems, Inc. Ethernet Xerox Corporation. Motorola 68000 Motorola, Inc. IBM 370 International Business Machines Corporation
SUN工作站SUN Microsystems，Inc.VAX惠普公司IBM-PC国际商用机器公司Cray Cray Inc.NFS SUN Microsystems，Inc.以太网施乐公司。摩托罗拉68000摩托罗拉公司IBM 370国际商用机器公司
The definition of NaNs, signed zero and infinity, and denormalized numbers from [IEEE] is reproduced here for convenience. The definitions for quadruple-precision floating point numbers are analogs of those for single and double-precision floating point numbers and are defined in [IEEE].
为了方便起见，此处复制了[IEEE]中的NaN、有符号零和无穷大以及非规范化数字的定义。四精度浮点数的定义与单精度和双精度浮点数的定义类似，定义见[IEEE]。
In the following, 'S' stands for the sign bit, 'E' for the exponent, and 'F' for the fractional part. The symbol 'u' stands for an undefined bit (0 or 1).
在下文中，“S”代表符号位，“E”代表指数，“F”代表小数部分。符号“u”表示未定义的位（0或1）。
For single-precision floating point numbers:
对于单精度浮点数：
Type S (1 bit) E (8 bits) F (23 bits)
---- --------- ---------- -----------
signalling NaN u 255 (max) .0uuuuu---u
(with at least
one 1 bit)
quiet NaN u 255 (max) .1uuuuu---u
Type S (1 bit) E (8 bits) F (23 bits)
---- --------- ---------- -----------
signalling NaN u 255 (max) .0uuuuu---u
(with at least
one 1 bit)
quiet NaN u 255 (max) .1uuuuu---u
negative infinity 1 255 (max) .000000---0
negative infinity 1 255 (max) .000000---0
positive infinity 0 255 (max) .000000---0
positive infinity 0 255 (max) .000000---0
negative zero 1 0 .000000---0
negative zero 1 0 .000000---0
positive zero 0 0 .000000---0
positive zero 0 0 .000000---0
For double-precision floating point numbers:
对于双精度浮点数：
Type S (1 bit) E (11 bits) F (52 bits)
---- --------- ----------- -----------
signalling NaN u 2047 (max) .0uuuuu---u
(with at least
one 1 bit)
quiet NaN u 2047 (max) .1uuuuu---u
Type S (1 bit) E (11 bits) F (52 bits)
---- --------- ----------- -----------
signalling NaN u 2047 (max) .0uuuuu---u
(with at least
one 1 bit)
quiet NaN u 2047 (max) .1uuuuu---u
negative infinity 1 2047 (max) .000000---0
negative infinity 1 2047 (max) .000000---0
positive infinity 0 2047 (max) .000000---0
positive infinity 0 2047 (max) .000000---0
negative zero 1 0 .000000---0
negative zero 1 0 .000000---0
positive zero 0 0 .000000---0
positive zero 0 0 .000000---0
For quadruple-precision floating point numbers:
对于四精度浮点数：
Type S (1 bit) E (15 bits) F (112 bits)
---- --------- ----------- ------------
signalling NaN u 32767 (max) .0uuuuu---u
(with at least
one 1 bit)
quiet NaN u 32767 (max) .1uuuuu---u
Type S (1 bit) E (15 bits) F (112 bits)
---- --------- ----------- ------------
signalling NaN u 32767 (max) .0uuuuu---u
(with at least
one 1 bit)
quiet NaN u 32767 (max) .1uuuuu---u
negative infinity 1 32767 (max) .000000---0
negative infinity 1 32767 (max) .000000---0
positive infinity 0 32767 (max) .000000---0
positive infinity 0 32767 (max) .000000---0
negative zero 1 0 .000000---0
negative zero 1 0 .000000---0
positive zero 0 0 .000000---0
positive zero 0 0 .000000---0
Subnormal numbers are represented as follows:
低于正常值的数字表示如下：
Precision Exponent Value
--------- -------- -----
Single 0 (-1)**S * 2**(-126) * 0.F
Precision Exponent Value
--------- -------- -----
Single 0 (-1)**S * 2**(-126) * 0.F
Double 0 (-1)**S * 2**(-1022) * 0.F
Double 0 (-1)**S * 2**(-1022) * 0.F
Quadruple 0 (-1)**S * 2**(-16382) * 0.F
Quadruple 0 (-1)**S * 2**(-16382) * 0.F
[IEEE] "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985, Institute of Electrical and Electronics Engineers, August 1985.
[IEEE]“二进制浮点运算的IEEE标准”，ANSI/IEEE标准754-1985，电气和电子工程师协会，1985年8月。
[KERN] Brian W. Kernighan & Dennis M. Ritchie, "The C Programming Language", Bell Laboratories, Murray Hill, New Jersey, 1978.
Brian W.Kernighan和Dennis M.Ritchie，“C编程语言”，贝尔实验室，新泽西州默里山，1978年。
[COHE] Danny Cohen, "On Holy Wars and a Plea for Peace", IEEE Computer, October 1981.
丹尼·科恩，“关于圣战与和平的呼吁”，IEEE计算机，1981年10月。
[COUR] "Courier: The Remote Procedure Call Protocol", XEROX Corporation, XSIS 038112, December 1981.
[COUR]“信使：远程过程调用协议”，施乐公司，XSIS 038112，1981年12月。
[SPAR] "The SPARC Architecture Manual: Version 8", Prentice Hall, ISBN 0-13-825001-4.
[SPAR]“SPARC体系结构手册：第8版”，普伦蒂斯大厅，ISBN 0-13-825001-4。
[HPRE] "HP Precision Architecture Handbook", June 1987, 5954-9906.
[HPRE]《HP精密结构手册》，1987年6月，5954-9906。
Bob Lyon was Sun's visible force behind ONC RPC in the 1980s. Sun Microsystems, Inc., is listed as the author of RFC 1014. Raj Srinivasan and the rest of the old ONC RPC working group edited RFC 1014 into RFC 1832, from which this document is derived. Mike Eisler and Bill Janssen submitted the implementation reports for this standard. Kevin Coffman, Benny Halevy, and Jon Peterson reviewed this document and gave feedback. Peter Astrand and Bryan Olson pointed out several errors in RFC 1832 which are corrected in this document.
20世纪80年代，鲍勃·里昂（Bob Lyon）是太阳在ONC RPC背后的可见力量。Sun Microsystems，Inc.被列为RFC 1014的作者。Raj Srinivasan和旧ONC RPC工作组的其他成员将RFC 1014编辑成RFC 1832，本文件就是从中衍生出来的。Mike Eisler和Bill Janssen提交了本标准的实施报告。Kevin Coffman、Benny Halevy和Jon Peterson审查了这份文件并给出了反馈。彼得·阿斯特兰（Peter Astrand）和布莱恩·奥尔森（Bryan Olson）指出了RFC 1832中的几个错误，这些错误在本文件中已更正。
Editor's Address
编辑地址
Mike Eisler 5765 Chase Point Circle Colorado Springs, CO 80919 USA
迈克·艾斯勒5765美国科罗拉多州科罗拉多斯普林斯蔡斯角环线，邮编：80919
Phone: 719-599-9026 EMail: email2mre-rfc4506@yahoo.com
电话：719-599-9026电子邮件：email2mre-rfc4506@yahoo.com
Please address comments to: nfsv4@ietf.org
请将意见发送至：nfsv4@ietf.org
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）提供。