RFC4506 日本語訳
4506 XDR: External Data Representation Standard. M. Eisler, Ed.. May 2006. (Format: TXT=55477 bytes) (Obsoletes RFC1832) (Also STD0067) (Status: STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Eisler, Ed. Request for Comments: 4506 Network Appliance, Inc. STD: 67 May 2006 Obsoletes: 1832 Category: Standards Track
ワーキンググループのM.アイスラー、エドをネットワークでつないでください。コメントのために以下を要求してください。 4506は器具Inc.STDをネットワークでつなぎます: 67 2006年5月は以下を時代遅れにします。 1832年のカテゴリ: 標準化過程
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
それを現在、配備して、受け入れるとき、このドキュメントはExternal Data Representation Standard(XDR)プロトコルについて説明します。 このドキュメントはRFC1832を時代遅れにします。
Eisler Standards Track [Page 1] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[1ページ]: 標準の外部データ表現2006年5月
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. 序論…3 2. RFC1832からの変化…3 3. 文節サイズ…3 4. XDRデータ型…4 4.1. 整数…4 4.2. 符号のない整数…4 4.3. 列挙…5 4.4. 論理演算子…5 4.5. 超-整数と無記名の超-整数…5 4.6. 浮動小数点…6 4.7. 倍精度浮動小数点…7 4.8. 4倍精度浮動小数点…8 4.9. 固定長の不明瞭なデータ…9 4.10. 可変長の不明瞭なデータ…9 4.11. 結びます。10 4.12. 固定長アレイ…11 4.13. 可変長のアレイ…11 4.14. 構造…12 4.15. 組合を差別します…12 4.16. 欠如します。13 4.17. 定数…13 4.18. Typedef…13 4.19. 任意のデータ…14 4.20. 今後の増進のための領域…16 5. 議論…16 6. XDR言語仕様…17 6.1. 記号法のコンベンション…17 6.2. 語彙注意…18 6.3. 構文情報…18 6.4. 構文注意…20 7. XDRデータ記述に関する例…21 8. セキュリティ問題…22 9. IANA問題…23 10. 商標と所有者…23 11. ANSI/IEEE規格754-1985…24 12. 標準の参照…25 13. 有益な参照…25 14. 承認…26
Eisler Standards Track [Page 2] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[2ページ]: 標準の外部データ表現2006年5月
1. Introduction
1. 序論
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は記述とデータの記号化の規格です。 異なったコンピュータ・アーキテクチャの間にデータを移すことの役に立ちます、そして、それは、サンワークステーション*、VAX*、IBM PC*、およびクレイ*のようなさまざまのマシンの間のデータを伝えるのに使用されました。XDRはISOプレゼンテーション層に収まって、目的でX.409におよそ類似しています、ISOの抽象的なSyntax Notation。 これらの2の主要な違いは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は、データ形式について説明するのに言語を使用します。 言語を使用できますが、データについて説明します。 それはプログラミング言語ではありません。 この言語で、1つは簡潔に複雑なデータ形式について説明できます。 複雑さが直面されていると、すぐに、グラフ表示(正式でない言語自体)を使用する代替手段は不可解になります。 ちょうどCourier[COUR]がMesaと同様であるようにXDR言語自体はC言語[カーン]と同様です。 ONC RPC(リモートProcedure Call)や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規格は以下の仮定をします: 1バイトが8ビットのデータと定義されるところでバイト(または、八重奏)は携帯用です。 与えられたハードウェアデバイスは他のハードウェアデバイスが意味の損失なしでバイトを解読するかもしれないような方法で様々なメディアにバイトをコード化するはずです。 例えば、イーサネット*規格は、バイトが最初に「リトルエンディアン」スタイル[COHE]、または最下位ビットでコード化されるのを示します。
2. Changes from RFC 1832
2. RFC1832からの変化
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.
このドキュメントは、RFC1832への技術変化を全く作らないで、IANA問題に注意する目的のために発表されます、有益な参照による標準のセキュリティ問題、および区別を増大させて。
3. Basic Block Size
3. 文節サイズ
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.
すべての項目の表現は4バイト(32ビット)のデータの倍数を必要とします。 バイトはn-1を通した番号付の0です。 バイトが何らかのバイト・ストリームに読み込まれるか、または書かれているので、バイトmはいつもバイトm+1に先行します。 r、データを含むのに必要であるnバイトが倍数でないなら、4、その時では、nバイトに続かれている十分な(0〜3)残差がバイトのゼロに合って、総バイトを作るために、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つの角、縦棒、およびダッシュのときに区切られる)は1バイトについて表現します。
Eisler Standards Track [Page 3] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[3ページ]: 標準の外部データ表現2006年5月
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)>----------->|
+--------+--------+...+--------+--------+...+--------+ | バイト0| バイト1|...|バイトn-1| 0 |...| 0 | ブロック+--------+--------+...+--------+--------+...+--------+ | <、-、-、-、-、-、-、-、-、-、--nバイト---------->| <、-、-、-、-、--rバイト------>| | <、-、-、-、-、-、-、-、-、-、--n+r、(どこ(n+r)モッズ4 = 0)>。----------->|
4. XDR Data Types
4. XDRデータ型
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データ記述に関する例」にあります。
4.1. Integer
4.1. 整数
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はサインしました。整数は範囲[-2147483648、2147483647]で整数をコード化する32ビットのデータです。 整数は2の補数記法で表されます。 最も多くて最も重要でないバイトは、それぞれ0と3です。 整数は以下の通りであると宣言されます:
int identifier;
int識別子。
(MSB) (LSB)
+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 | INTEGER
+-------+-------+-------+-------+
<------------32 bits------------>
(MSB) (LSB)+-------+-------+-------+-------+ |バイト0|バイト1|バイト2|バイト3| 整数+-------+-------+-------+-------+ <。------------32ビット------------>。
4.2. Unsigned Integer
4.2. 符号のない整数
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、符号のない整数は範囲[0、4294967295]で非負の整数をコード化する32ビットのデータです。 それはだいたいの、そして、最も重要でないバイトがそれぞれ0と3である無記名の2進の数によって表されます。 符号のない整数は以下の通りであると宣言されます:
Eisler Standards Track [Page 4] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[4ページ]: 標準の外部データ表現2006年5月
unsigned int identifier;
無記名のint識別子。
(MSB) (LSB)
+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 | UNSIGNED INTEGER
+-------+-------+-------+-------+
<------------32 bits------------>
(MSB) (LSB)+-------+-------+-------+-------+ |バイト0|バイト1|バイト2|バイト3| 符号のない整数+-------+-------+-------+-------+ <。------------32ビット------------>。
4.3. Enumeration
4.3. 列挙
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する、識別子。
For example, the three colors red, yellow, and blue could be described by an enumerated type:
例えば、3は赤、黄色を着色します、そして、列挙型は青について説明できました:
enum { RED = 2, YELLOW = 3, BLUE = 5 } colors;
RED=2、YELLOW=3、BLUE=5が着色するenum。
It is an error to encode as an enum any integer other than those that have been given assignments in the enum declaration.
enum宣言における課題を与えたのは、enumとしてそれら以外のどんな整数にもコード化する誤りです。
4.4. Boolean
4.4. 論理演算子
Booleans are important enough and occur frequently enough to warrant their own explicit type in the standard. Booleans are declared as follows:
論理演算子は、十分重要であり、規格でそれら自身の明白なタイプを保証できるくらいの頻繁に起こります。 論理演算子は以下の通りであると宣言されます:
bool identifier;
bool識別子。
This is equivalent to:
これは以下に同等です。
enum { FALSE = 0, TRUE = 1 } identifier;
FALSE=0、TRUE=1をenumする、識別子。
4.5. Hyper Integer and Unsigned Hyper Integer
4.5. 超-整数と無記名の超-整数
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バイト)の数を定義します。 彼らの表現は上で定義された整数と符号のない整数の明白な拡大です。 それらは2の補数記法で表されます。 最も多くて最も重要でないバイトは、それぞれ0と7です。 彼らの宣言:
hyper identifier; unsigned hyper identifier;
超-識別子。 無記名の超-識別子。
Eisler Standards Track [Page 5] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[5ページ]: 標準の外部データ表現2006年5月
(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)+-------+-------+-------+-------+-------+-------+-------+-------+ |バイト0|バイト1|バイト2|バイト3|バイト4|バイト5|バイト6|バイト7| +-------+-------+-------+-------+-------+-------+-------+-------+ <。----------------------------64ビット---------------------------->の超-整数の無記名の超-整数
4.6. Floating-Point
4.6. 浮動小数点
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:
規格は「浮遊物」(32ビットか4バイト)という浮動小数点のデータ型を定義します。 使用されるコード化は正常にされた単精度浮動小数点の番号[IEEE]のIEEE規格です。 以下の3つの分野が単精度の浮動小数点の番号について説明します:
S: The sign of the number. Values 0 and 1 represent positive and
negative, respectively. One bit.
S: 数のサイン。 値0と1はそれぞれ正数とネガを表します。 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**(電子バイアス)*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------------>
+-------+-------+-------+-------+ |バイト0|バイト1|バイト2|バイト3| 単精度S| E| F| 浮動小数点の数+-------+-------+-------+-------+ 1| <、- 8 ->| <、-、-、-、-、-、--23ビット------>| <、-、-、-、-、-、-、-、-、-、-、--32ビット------------>。
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です。 これらの数がそれらの実際の物理的な位置ではなく、ビットの数学の位置(媒体によって異なる)について言及することに注意してください。
Eisler Standards Track [Page 6] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[6ページ]: 標準の外部データ表現2006年5月
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"(数でない)にシステムに依存していて、"NaN"以外の何としてもXDRの中で解釈するべきではありません。
4.7. Double-Precision Floating-Point
4.7. 倍精度浮動小数点です。
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:
規格は「倍増する」という倍精度の浮いているポイントデータ型(64ビットか8バイト)のためのコード化を定義します。 使用されるコード化は正常にされた倍精度浮動小数点の番号[IEEE]のIEEE規格です。 規格は以下の3つの分野をコード化します:(分野は倍精度の浮動小数点の番号について説明します)。
S: The sign of the number. Values 0 and 1 represent positive and
negative, respectively. One bit.
S: 数のサイン。 値0と1はそれぞれ正数とネガを表します。 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**(電子バイアス)*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
+------+------+------+------+------+------+------+------+ |バイト0|バイト1|バイト2|バイト3|バイト4|バイト5|バイト6|バイト7| S| E| F| +------+------+------+------+------+------+------+------+ 1| <--11-->| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--52ビット------------------->| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--64ビット------------------------->、倍精度浮動小数点
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です。 これらの数がそれらの実際の物理的な位置ではなく、ビットの数学の位置(媒体によって異なる)について言及することに注意してください。
Eisler Standards Track [Page 7] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[7ページ]: 標準の外部データ表現2006年5月
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"(数でない)にシステムに依存していて、"NaN"以外の何としてもXDRの中で解釈するべきではありません。
4.8. Quadruple-Precision Floating-Point
4.8. 4倍精度浮動小数点です。
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:
規格は「4倍」(128ビットか16バイト)という4倍精度の浮動小数点のデータ型のためのコード化を定義します。 使用されるコード化は、シングルに使用されるコード化と倍精度の浮動小数点の番号の簡単なアナログになるように1つのフォームのIEEEの二重拡大精度を使用することで設計されています。 規格は以下の3つの分野をコード化します:(分野は4倍精度の浮動小数点の番号について説明します)。
S: The sign of the number. Values 0 and 1 represent positive and
negative, respectively. One bit.
S: 数のサイン。 値0と1はそれぞれ正数とネガを表します。 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**(電子バイアス)*1.F
It is declared as follows:
それは以下の通りであると宣言されます:
quadruple identifier;
識別子を4倍にしてください。
+------+------+------+------+------+------+-...--+------+
|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
+------+------+------+------+------+------+-...--+------+ |バイト0|バイト1|バイト2|バイト3|バイト4|バイト5| ... |byte15| S| E| F| +------+------+------+------+------+------+-...--+------+ 1| <、-、-、--15---->| <、-、-、-、-、-、-、-、-、-、-、-、--112ビット------------------>| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--128ビット------------------------>4倍精度浮動小数点です。
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であるように、4倍精度の浮動小数点の番号の大部分と最下位ビットは、0と127です。 S、E、およびFの始めのビット(そして、最上位ビット)オフセットは、それぞれ0と、1と、16です。 これらの数がそれらの実際の物理的な位置ではなく、ビットの数学の位置(媒体によって異なる)について言及することに注意してください。
Eisler Standards Track [Page 8] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[8ページ]: 標準の外部データ表現2006年5月
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]のためにencodingsされます。 それが4倍精度の浮いているポイント番号に適用されるとき、"NaN"コード化にシステムに依存していて、"NaN"以外の何としてもXDRの中で解釈するべきではありません。
4.9. Fixed-Length Opaque Data
4.9. 固定長の不明瞭なデータ
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が不明瞭な物の総バイト・カウントを4の倍数にするためには4の倍数、次に、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 ... +--------+--------+...+--------+--------+...+--------+ | バイト0| バイト1|...|バイトn-1| 0 |...| 0 | +--------+--------+...+--------+--------+...+--------+ | <、-、-、-、-、-、-、-、-、-、--nバイト---------->| <、-、-、-、-、--rバイト------>| | <、-、-、-、-、-、-、-、-、-、--n+r、(どこ、(n+r)モッズ4 = 0)------------>| 固定長不透明なもの
4.10. Variable-Length Opaque Data
4.10. 可変長の不明瞭なデータ
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バイトがいうことになったNo.nになるように任意のn(n-1を通して0に達する)バイトの系列と定義された可変長(数えられる)の不明瞭なデータに備えます。
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はいつもスィーケンスの長さに続きます(数えてください)。 r、nが倍数でないなら、4、その時では、nバイトが続かれている十分な(0〜3)残差がバイトのゼロに合って、総バイトを作るために、4の倍数を数えてください。 可変長の不明瞭なデータは以下の方法で宣言されます:
opaque identifier<m>;
or
opaque identifier<>;
識別子<m>について不透明にしてください。 または、識別子<>について不透明にしてください。
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が2番目の宣言のように指定されないなら、それは(2**32)であると思われます--1、最大の長さ。
Eisler Standards Track [Page 9] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[9ページ]: 標準の外部データ表現2006年5月
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>;
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 ... +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+ | 長さn|byte0|byte1|...| n-1| 0 |...| 0 | +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+ | <、-、-、-、-、-、--4バイト------->| <、-、-、-、-、--nバイト------>| <、-、--rバイト--->| | <、-、-、--n+r、(どこ、(n+r)モッズ4 = 0)---->| 可変長の不透明なもの
It is an error to encode a length greater than the maximum described in the specification.
それは仕様で説明された最大より大きい長さにコード化する誤りです。
4.11. String
4.11. ストリング
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バイトがいうことになったNo.nになるように一連のn(n-1を通して0に達する)ASCIIバイトを定義します。 ストリングのバイトmはいつもストリングのバイトm+1に先行します、そして、ストリングのバイト0はいつもストリングの長さに続きます。 r、nが倍数でないなら、4、その時では、nバイトが続かれている十分な(0〜3)残差がバイトのゼロに合って、総バイトを作るために、4の倍数を数えてください。 数えられたバイトストリングは以下の通りであると申告されます:
string object<m>;
or
string object<>;
物の<m>を結んでください。 または、物の<>を結んでください。
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が2番目の宣言のように指定されないなら、それは(2**32)であると思われます--1、最大の長さ。 通常、一定のmはプロトコル仕様で見つけられるでしょう。 例えば、ファイリングプロトコルは、ファイル名がもう255バイトよりそうであることができると以下の通り述べるかもしれません:
string filename<255>;
ファイル名<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 ... +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+ | 長さn|byte0|byte1|...| n-1| 0 |...| 0 | +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+ | <、-、-、-、-、-、--4バイト------->| <、-、-、-、-、--nバイト------>| <、-、--rバイト--->| | <、-、-、--n+r、(どこ、(n+r)モッズ4 = 0)---->| ストリング
Eisler Standards Track [Page 10] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[10ページ]: 標準の外部データ表現2006年5月
It is an error to encode a length greater than the maximum described in the specification.
それは仕様で説明された最大より大きい長さにコード化する誤りです。
4.12. Fixed-Length Array
4.12. 固定長アレイ
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.
n-1を通した要素のアレイが付番した固定長0は、それらの自然界の秩序、n-1を通した0で個別にアレイの要素をコード化することによって、コード化されます。 各要素のサイズは4バイトの倍数です。 同じタイプにはすべての要素がありますが、要素では、異なったサイズがあるかもしれません。 例えば、すべての要素がストリングの固定長アレイに、タイプ「ストリング」であります、しかし、各要素は長さにおいて異なるでしょう。
+---+---+---+---+---+---+---+---+...+---+---+---+---+
| element 0 | element 1 |...| element n-1 |
+---+---+---+---+---+---+---+---+...+---+---+---+---+
|<--------------------n elements------------------->|
+---+---+---+---+---+---+---+---+...+---+---+---+---+ | 要素0| 要素1|...| 要素n-1| +---+---+---+---+---+---+---+---+...+---+---+---+---+ | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--n要素------------------->|
FIXED-LENGTH ARRAY
固定長アレイ
4.13. Variable-Length Array
4.13. 可変長のアレイ
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<>;
型名識別子<m>。 型名識別子<>。
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が2番目の宣言のように指定されないなら、それは(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| 要素0| 要素1|...|要素n-1| +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+ | <、-4 バイト>| <、-、-、-、-、-、-、-、-、-、-、-、-、--n要素------------->| 数えられたアレイ
Eisler Standards Track [Page 11] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[11ページ]: 標準の外部データ表現2006年5月
It is an error to encode a value of n that is greater than the maximum described in the specification.
仕様で説明された最大よりすばらしいのは、nの値をコード化する誤りです。
4.14. Structure
4.14. 構造
Structures are declared as follows:
構造は以下の通りであると申告されます:
struct {
component-declaration-A;
component-declaration-B;
...
} identifier;
コンポーネント宣言A; コンポーネント宣言B; …をstructする、識別子。
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.
構造の部品は構造の彼らの宣言の注文でコード化されます。 コンポーネントは異なったサイズであるかもしれませんが、各コンポーネントのサイズは4バイトの倍数です。
+-------------+-------------+...
| component A | component B |... STRUCTURE
+-------------+-------------+...
+-------------+-------------+... | コンポーネントA| コンポーネントB|... 構造+-------------+-------------+...
4.15. Discriminated Union
4.15. 差別された組合
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:
差別された組合は判別式の値に従って1セットの根回しされたタイプから選ばれたタイプによって従われた判別式で構成されたタイプです。 判別式のタイプは、"int"、「未署名のint」か"bool"などの列挙型のどちらかです。 コンポーネント型を組合の「兵器」と呼ばれて、それらのコード化を含意する判別式の値は先行します。 差別された組合は以下の通りであると宣言されます:
union switch (discriminant-declaration) {
case discriminant-value-A:
arm-declaration-A;
case discriminant-value-B:
arm-declaration-B;
...
default: default-declaration;
} identifier;
組合スイッチ、(判別式宣言) 判別式値のA:アーム宣言Aをケースに入れてください; 判別式値B: アーム宣言B; デフォルトをケースに入れてください: デフォルト宣言、識別子。
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.
判別式の正当な値はそれぞれの「ケース」キーワードのあとに続いています。 デフォルトアームは任意です。 それが指定されないなら、組合の有効なコード化は不特定の判別式値を呈することができません。 いつも暗示しているアームのサイズは4バイトの倍数です。
The discriminated union is encoded as its discriminant followed by the encoding of the implied arm.
暗示しているアームのコード化で判別式が従って、差別された組合はコード化されます。
Eisler Standards Track [Page 12] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[12ページ]: 標準の外部データ表現2006年5月
0 1 2 3
+---+---+---+---+---+---+---+---+
| discriminant | implied arm | DISCRIMINATED UNION
+---+---+---+---+---+---+---+---+
|<---4 bytes--->|
0 1 2 3 +---+---+---+---+---+---+---+---+ | 判別式| 暗示しているアーム| 差別された組合+---+---+---+---+---+---+---+---+ | <、-、--4バイト--->|
4.16. Void
4.16. 空間
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空間は0バイトの量です。 空間は入力されるようにデータを全く取らない操作について説明しますが、出力されるようにどんなデータも説明しないことの役に立ちます。 また、それらも組合で役に立ちます、そして、他のものは役に立ちません。(そこでは、いくつかの兵器がデータを含むかもしれません)。 宣言は単に以下の通りです:
void;
空間。
Voids are illustrated as follows:
空間は以下の通り例証されます:
++
|| VOID
++
--><-- 0 bytes
++ || VOID++--><--0バイト
4.17. Constant
4.17. 定数
The data declaration for a constant follows this form:
定数のためのデータ宣言はこのフォームに続きます:
const name-identifier = n;
const名前識別子は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と等しいシンボリックな一定のDOZENを定義します。
const DOZEN = 12;
const DOZEN=12。
4.18. Typedef
4.18. Typedef
"typedef" does not declare any data either, but serves to define new identifiers for declaring data. The syntax is:
"typedef"は、少しのデータも宣言しませんが、データを宣言するための新しい識別子を定義するのに役立ちます。 構文は以下の通りです。
typedef declaration;
typedef宣言。
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の宣言部分の変数名です。 例えば、以下は「卵」と呼ばれる既存のタイプを使用することで"eggbox"と呼ばれる新しいタイプを定義します:
typedef egg eggbox[DOZEN];
typedef卵のeggbox[DOZEN]。
Eisler Standards Track [Page 13] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[13ページ]: 標準の外部データ表現2006年5月
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に持っている新しい型名を使用することで宣言しました、それが変数であると考えられたなら。 例えば、以下の2つの宣言が可変"fresheggs"を宣言するのにおいて同等です:
eggbox fresheggs; egg fresheggs[DOZEN];
eggbox fresheggs。 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がstruct、enum、または組合定義にかかわるとき、同じタイプを定義するのに使用されるかもしれない別の(都合のよい)の構文があります。 一般に、以下のtypedefは形成されます:
typedef <<struct, union, or enum definition>> identifier;
typedef<<struct、組合、またはenum定義>>識別子。
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"、「組合」、または"enum"キーワードの後に識別子を置きます。 例えば、ここに、タイプ"bool"を定義する2つの方法があります:
typedef enum { /* using typedef */
FALSE = 0,
TRUE = 1
} bool;
typedef enum、typedef*/FALSE=0、TRUE=1を使用する/*がboolされます。
enum bool { /* preferred alternative */
FALSE = 0,
TRUE = 1
};
enum bool、/*都合のよい代替の*/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.
1つが新しいタイプの名前を理解する宣言の終わりまで待つ必要はないので、この構文は好まれます。
4.19. Optional-Data
4.19. 任意のデータ
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:
任意のデータは私たちがそれを宣言するためにそれ自身の特別な構文をそれに与えるくらいの頻繁に起こる1種類の組合です。 それは以下の通りであると宣言されます:
type-name *identifier;
型名*識別子。
This is equivalent to the following union:
これは以下の組合に同等です:
union switch (bool opted) {
case TRUE:
type-name element;
case FALSE:
void;
} identifier;
組合がケースTRUE: 型名要素ケースFALSE: (空間)を切り換える、(boolに選ばれます)識別子。
Eisler Standards Track [Page 14] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[14ページ]: 標準の外部データ表現2006年5月
It is also equivalent to the following variable-length array declaration, since the boolean "opted" can be interpreted as the length of the array:
また、それも以下の可変長の配列の宣言に同等です、配列の長さとして「選ばれた」論理演算子は解釈できるので:
type-name identifier<1>;
型名識別子<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は項目<>(次のstringentry*)を結びます。
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;
};
組合stringlistはケースTRUE: structストリング項目<>; 次のstringlist;要素ケースFALSE: (空間)を切り換えます(boolは選ばれました)。
or as a variable-length array:
または、可変長の配列として:
struct stringentry {
string item<>;
stringentry next<1>;
};
struct stringentryは項目<>(stringentry次の<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タイプの意志をあいまいにするので、任意のデータ宣言はそれらの両方より好まれます。 また、任意のデータ型は再帰的なデータ構造がパスカルかCなどの高位言語でどう指針の使用で表されるかに密接な相関関係を持っています。 事実上、指針に、構文はC言語のものと同じです。
Eisler Standards Track [Page 15] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[15ページ]: 標準の外部データ表現2006年5月
4.20. Areas for Future Enhancement
4.20. 今後の増進のための領域
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規格の意図が人々が今までに送ったことがあるあらゆる種類のデータについて説明したくなかったことであるまたは今までに、マシンからマシンまで発信したくなるでしょう。 むしろ、それは、これらの言語で書かれたアプリケーションが媒体の上で容易に交信できるように、パスカルか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ファミリーの4バイトのビッグエンディアンメンバーであるとここで議論したXDRを考えることができました。
5. Discussion
5. 議論
(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かパスカルなどの高位言語の間には、厳密な類推があります。 これはXDRコード化と解読モジュールの実装をより簡単なタスクにします。 最終的に、言語仕様自体は飛行中のデータ解釈を実行するためにマシンからマシンまで渡すことができるASCIIストリングです。
(2) Why is there only one byte-order for an XDR unit?
(2) XDRユニット1つのバイトオーダーしかなぜありませんか?
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.
2つのバイト順をサポートするのは、データがどのバイトオーダーにコード化されるかを決定するために上位レベル・プロトコルを必要とします。 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バイトオーダービッグエンディアンがなぜリトルエンディアンの代わりにありますか? これはVAX(r)などのリトルエンディアンマシンに不公平ではありませんか?(VAX(r)は1つのフォームからもう片方まで変換しなければなりません)。
Eisler Standards Track [Page 16] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[16ページ]: 標準の外部データ表現2006年5月
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.
はい、それは不公平ですが、1つのバイトオーダーしか持っていないのは、あなたがだれかのに対しフェアである必要はないことを意味します。 モトローラ68000*やIBM370*などの多くのアーキテクチャがビッグエンディアンバイトオーダーをサポートします。
(4) Why is the XDR unit four bytes wide?
(4) XDRユニットはなぜ幅4バイトですか?
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ユニットサイズを選ぶのにおいて見返りがあります。 2などの小型を選ぶと、これらの境界で並べられないマシンのために、コード化されたデータが小さくされますが、問題は整列に引き起こされます。 8などの大判は、データによって実際にはあらゆるマシンに並べられますが、コード化されたデータが大きくなり過ぎることを意味します。 私たちは感染として4を選びました。 4は効率的にほとんどのアーキテクチャをサポートできるくらい大きいです、8バイトが並んでいるクレイ*などのまれなマシンを除いて。また、コード化されたデータを妥当なサイズに制限し続けることができるくらい4もわずかです。
(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.
それはすべてのマシンの上の同じものへのそんなに同じ望ましいデータエンコードです、コード化されたデータを意味深長に比較するか、またはchecksummedすることができるように。 そっと歩いているバイトがゼロであることを強制するのがこれを確実にします。
(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.
データ型定義には、それがどんな小さい利点を持つことができるように比較的高い費用があるか。 1つの費用は挿入されたタイプ分野によるデータの拡張です。 別のものはこれらのタイプ分野を解釈して、善処する加えられた費用です。 そして、ほとんどのプロトコルが、彼らがどんなタイプを予想するかを既に知るので、データ型定義は余分な情報だけを提供します。 しかしながら、1つは、XDRを使用することでまだデータ型定義の恩恵を得ることができます。One道は2つのものをコード化することです: 1番目、コード化されたデータのXDRデータ記述であるストリング、およびそして、コード化されたデータ自体。 別の方法はそれがXDRのすべてのタイプに値を割り当てて、次に、普遍的なタイプを定義するために、判別式と各値にこの値を取って、対応するデータ型について説明するということです。
6. The XDR Language Specification
6. XDR言語仕様
6.1. Notational Conventions
6.1. 記号法のコンベンション
This specification uses an extended Back-Naur Form notation for describing the XDR language. Here is a brief description of the notation:
この仕様は、XDR言語を説明するのに拡張Back-ナウアForm記法を使用します。 ここに、記法の簡単な説明があります:
(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) 代替品目は縦棒によって切り離されます。
Eisler Standards Track [Page 17] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[17ページ]: 標準の外部データ表現2006年5月
("|"). (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")
そして、「まさしくその」(「」、「まさしくその」) *、[「寒さ」、「」、]、「雨」(「日」| 「夜」)
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"
「非常に非常に冷たくて雨の夜」の「非常に冷たくて雨の日」の「非常に雨の日」の「非常に雨の日」
6.2. Lexical Notes
6.2. 語彙注意
(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) 識別子は手紙、ケタ、またはunderbar('_')の任意の系列がいうことになった手紙です。 識別子に関するケースは無視されません。 (4) 10進定数をベース10の中に数を表して、1つ以上の10進数字の系列であり、マイナス記号('--')は任意に先行します。(そこでは、最初のケタがゼロではありません)。 (5) '16進定数は、ベース16の中に数を表して、'0x'は先行しなければならなくて、1か16進数字で従いました。('A'、'B'、'C''D'、E'、'F'、'a'、'b'、'c'はそうするでしょう''、e''、f、''0''、1、''2''、3、''4''、5、''6''、7、''8''、9') (6) 8進定数は、ベース8の中に数を表して、いつもケタ0を始めて、1つ以上の8進数字('0'、'1'、'2'、'3'、'4'、'5'、'6'、'7')の系列です。
6.3. Syntax Information
6.3. 構文情報
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
値: 定数| 識別子
Eisler Standards Track [Page 18] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[18ページ]: 標準の外部データ表現2006年5月
constant:
decimal-constant | hexadecimal-constant | octal-constant
定数: 10進定数| 16進定数| 8進定数
type-specifier:
[ "unsigned" ] "int"
| [ "unsigned" ] "hyper"
| "float"
| "double"
| "quadruple"
| "bool"
| enum-type-spec
| struct-type-spec
| union-type-spec
| identifier
型指定子: [「未署名」]の"int"| [「未署名」]、「超-、」| 「浮いてください」| 「倍増してください」| 「4倍になってください」| "bool"| enumタイプ仕様| structタイプ仕様| 組合タイプ仕様| 識別子
enum-type-spec:
"enum" enum-body
enumタイプ仕様: "enum"enum-ボディー
enum-body:
"{"
( identifier "=" value )
( "," identifier "=" value )*
"}"
enum-ボディー: 「「(識別子「=」価値)、(「」、識別子が「」 値) *と等しい」、」
struct-type-spec:
"struct" struct-body
structタイプ仕様: "struct"struct-ボディー
struct-body:
"{"
( declaration ";" )
( declaration ";" )*
"}"
struct-ボディー: 「「「(宣言、」、;、」、)、(宣言、」、;、」、)、*、」、」
union-type-spec:
"union" union-body
組合タイプ仕様: 「組合」組合団体
union-body:
"switch" "(" declaration ")" "{"
case-spec
case-spec *
[ "default" ":" declaration ";" ]
"}"
組合団体: 「「スイッチ」「(「宣言」)」、「「ケース仕様ケース仕様*、[「デフォルト、」 」 : 」 宣言、」、;、」、]、」、」
case-spec:
( "case" value ":")
( "case" value ":") *
declaration ";"
ケース仕様: (「「」 値をケースに入れてください」:、」、) (「「」 値をケースに入れてください」:、」、) * 「宣言」;、」
Eisler Standards Track [Page 19] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[19ページ]: 標準の外部データ表現2006年5月
constant-def:
"const" identifier "=" constant ";"
一定にクール: 「"const"識別子は「」 定数と等しいです」」
type-def:
"typedef" declaration ";"
| "enum" identifier enum-body ";"
| "struct" identifier struct-body ";"
| "union" identifier union-body ";"
タイプクール: 「"typedef"宣言」;、」 | 「「」 識別子がenumに具体化させるenum」」 | 「「」 識別子がstructに具体化させるstruct」」 | 「「」 識別子が組合で具体化させる組合」」
definition:
type-def
| constant-def
定義: タイプクールです。| 一定にクールです。
specification:
definition *
仕様: 定義*
6.4. Syntax Notes
6.4. 構文注意
(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"、「ケース」、"const"、「デフォルト」、「二重で」、「4倍」の"enum"が「浮動する」、「超-、」 「intに」「不透明であること」で、「ストリング」、"struct"は「typedefに」「未署名」の、そして、「空」の「組合」を「切り換えます」。
(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) 同様に、変数名はstructと組合宣言の範囲の中でユニークでなければなりません。 入れ子にされたstructと組合宣言は新しい範囲を作成します。
(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) それが整数に評価するタイプには組合の判別式があるに違いありません。 それがこれらの1つに評価するすなわち、"int"、「未署名のint」、"bool"、列挙型、またはどんなtypedefedタイプも法的です。 また、ケース値は判別式の正当な値の1つでなければなりません。 最終的に、ケース値は組合宣言の範囲の中の一度より指定されないかもしれません。
Eisler Standards Track [Page 20] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[20ページ]: 標準の外部データ表現2006年5月
7. An Example of an XDR Data Description
7. XDRデータ記述に関する例
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.
ここに、1台のマシンから別のマシンまでファイルを移すのに使用されるかもしれない「ファイル」と呼ばれることの短い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。 ユーザ名前*/const MAXFILELEN=65535の/*最大の長さ。 ファイル*/const MAXNAMELEN=255の/*最大の長さ。 ファイル名*/の/*最大の長さ
/*
* Types of files:
*/
enum filekind {
TEXT = 0, /* ascii data */
DATA = 1, /* raw data */
EXEC = 2 /* executable */
};
ファイルの/**タイプ: */enum filekind、TEXT=0、/*ASCIIデータ*/DATA=1、/*未加工データ*/EXECは2/*実行可能な*/と等しいです。
/*
* 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 */
};
ファイルの種類あたりの/**ファイル情報: */組合filetypeはケースTEXT: 空間; クリエイター<MAXNAMELEN>; クリエイター*/ケースEXEC: /*いいえ、その他の情報*/ケースDATA: ストリング/*データストリングinterpretor<MAXNAMELEN>; /*プログラムinterpretor*/を切り換えます(filekind種類)。
/*
* 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完全なファイル: */structファイルストリングファイル名<MAXNAMELEN>; ファイル*/filetypeタイプの/*名前; ファイル*/ストリング所有者<MAXUSERNAME>に関する/*インフォメーション; ファイル*/不透明なデータ<MAXFILELEN>の/*所有者;/*ファイルデータ*/。
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:
まさしくデータを含む"sillyprog"という彼の舌足らずプログラムを保存したがっている"john"というユーザがいるので「(やめてください)」という、思ってください。 彼のファイルは以下の通りコード化されるでしょう:
Eisler Standards Track [Page 21] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[21ページ]: 標準の外部データ表現2006年5月
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
ASCIIが論評する十六進法バイトを相殺してください。------ --------- ----- -------- 0 00 00 00 09 .... -- ファイル名の長さは9 4 73 69 6c 6c土台(ファイル名キャラクタ8 79 70 72 6f ypro)、および、より多くのキャラクタと等しいです… 12 67 00 00 00、g.。 -- …と中詰め16 00 00 00 02の3無バイト… -- filekindはEXEC=2 20 00 00 00 04です… -- interpretorの長さは4 24 6c69 73 70舌足らずと等しいです--interpretorキャラクタ28 00 00 00 04。 -- 所有者の長さは4 32 6a 6f68 6e johnと等しいです--所有者キャラクタ36 00 00 00 06。 -- ファイルデータ=6 40 28 71 75 69(qui--ファイルデータバイト... 44 74 29 00 00t)の長さ。 -- …と2無バイトの中詰め
8. Security Considerations
8. セキュリティ問題
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はプロトコルではなく、データ記述言語です、そして、したがって、それは本来どんな特定のセキュリティ問題ももたらしません。 NFSv4などのXDR-フォーマット済みデータを運ぶプロトコルはそれらが輸送するデータを保証するためにどんな必要なセキュリティー・サービスも提供するのに原因となります。
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八重奏の位置まで数えて、1つを加えることによって、おそらくストリングのサイズを決定するでしょう。 この食い違いはメモリ漏出をもたらすことができます(実際に割り当てるよりさらに少ないメモリを無料のプールに返すので)、システム障害とサービス不能攻撃に通じて。
* 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文字であるストリングにもかかわらず、不法です。 '例えば、いくつかのオペレーティングシステムが'/'を扱います。
Eisler Standards Track [Page 22] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[22ページ]: 標準の外部データ表現2006年5月
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*)。
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」要素の長い繋がっているリストを構成できました。(次に、それは、デコーダかエンコーダでスタックオーバーフローを引き起こします)。 デコーダとエンコーダは、非再帰的に書かれているはずであるか、またはリストの長さで指し値するはずです。
9. IANA Considerations
9. IANA問題
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と共にタイプする標準化過程を通って新しいタイプを加えるためのプロセスがあります。 このドキュメントをアップデートするか、または置き換える標準化過程RFCsはRFC EditorのRFCsに関するデータベースにそういうものとして記録されるべきです。
10. Trademarks and Owners
10. 商標と所有者
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
サンワークステーションサン・マイクロシステムズ・インクVAXヒューレット・パッカード会社IBM-PC IBM社ザリガニザリガニ株式会社NFSサン・マイクロシステムズ・インクイーサネットゼロックス社。 モトローラ68000モトローラIBM370IBM社
Eisler Standards Track [Page 23] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[23ページ]: 標準の外部データ表現2006年5月
11. ANSI/IEEE Standard 754-1985
11. ANSI/IEEE規格754-1985
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].
NaNsの定義であり、サインされて、[IEEE]からのゼロと無限の、そして、反正常にされた数は便宜のためにここで再生します。 4倍精度浮動小数点のための定義は、シングルと倍精度浮動小数点のためのそれらのアナログであり、[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).
'以下では、'符号ビットのためのスタンド、解説者のための'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
S(1ビット)E(8ビット)F(23ビット)をタイプしてください。---- --------- ---------- ----------- NaN u255(最大).0uuuuuに合図します。---u(少なくとも1が噛み付いたものがある)静かなNaN u255(最大).1uuuuu---u
negative infinity 1 255 (max) .000000---0
負の無限1 255(最大限にする).000000---0
positive infinity 0 255 (max) .000000---0
陽の無限0 255(最大限にする).000000---0
negative zero 1 0 .000000---0
ネガが1 0のゼロに合っている、.000000---0
positive zero 0 0 .000000---0
正数が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
S(1ビット)E(11ビット)F(52ビット)をタイプしてください。---- --------- ----------- ----------- NaN u2047(最大).0uuuuuに合図します。---u(少なくとも1が噛み付いたものがある)静かなNaN u2047(最大).1uuuuu---u
negative infinity 1 2047 (max) .000000---0
負の無限1 2047(最大限にする).000000---0
positive infinity 0 2047 (max) .000000---0
陽の無限0 2047(最大限にする).000000---0
negative zero 1 0 .000000---0
ネガが1 0のゼロに合っている、.000000---0
positive zero 0 0 .000000---0
正数が0 0のゼロに合っている、.000000---0
Eisler Standards Track [Page 24] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[24ページ]: 標準の外部データ表現2006年5月
For quadruple-precision floating point numbers:
4倍精度浮動小数点のために:
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
S(1ビット)E(15ビット)F(112ビット)をタイプしてください。---- --------- ----------- ------------ NaN u32767(最大).0uuuuuに合図します。---u(少なくとも1が噛み付いたものがある)静かなNaN u32767(最大).1uuuuu---u
negative infinity 1 32767 (max) .000000---0
負の無限1 32767(最大限にする).000000---0
positive infinity 0 32767 (max) .000000---0
陽の無限0 32767(最大限にする).000000---0
negative zero 1 0 .000000---0
ネガが1 0のゼロに合っている、.000000---0
positive zero 0 0 .000000---0
正数が0 0のゼロに合っている、.000000---0
Subnormal numbers are represented as follows:
低能な数は以下の通り表されます:
Precision Exponent Value
--------- -------- -----
Single 0 (-1)**S * 2**(-126) * 0.F
精度解説者価値--------- -------- ----- 単一の0(-1)**S*2**(-126)*0.F
Double 0 (-1)**S * 2**(-1022) * 0.F
二重0(-1)**S*2**(-1022)*0.F
Quadruple 0 (-1)**S * 2**(-16382) * 0.F
4倍0(-1) **S*2**(-16382)*0.F
12. Normative References
12. 引用規格
[IEEE] "IEEE Standard for Binary Floating-Point Arithmetic",
ANSI/IEEE Standard 754-1985, Institute of Electrical and
Electronics Engineers, August 1985.
[IEEE] 「2進の浮動小数点の演算のIEEE規格」、ANSI/IEEE規格754-1985、米国電気電子技術者学会、1985年8月。
13. Informative References
13. 有益な参照
[KERN] Brian W. Kernighan & Dennis M. Ritchie, "The C Programming
Language", Bell Laboratories, Murray Hill, New Jersey, 1978.
[凝結核]ブライアン・W.カーニハンとデニス・M.リッチー、「Cプログラミング言語」、ベル研究所、マリー・ヒル(ニュージャージー)1978。
[COHE] Danny Cohen, "On Holy Wars and a Plea for Peace", IEEE
Computer, October 1981.
[COHE]ダニー・コーエン、IEEEコンピュータ、「平和のための聖戦と請願」の10月1981
[COUR] "Courier: The Remote Procedure Call Protocol", XEROX
Corporation, XSIS 038112, December 1981.
[COUR]、「急使:」 「遠隔手続き呼び出しプロトコル」、ゼロックス社、XSIS038112、1981年12月。
[SPAR] "The SPARC Architecture Manual: Version 8", Prentice Hall,
ISBN 0-13-825001-4.
[練習試合をします]、「SPARC構造マニュアル:」 バージョン8インチ、新米のホール、ISBN0-13-825001-4。
[HPRE] "HP Precision Architecture Handbook", June 1987, 5954-9906.
1987年6月、5954-9906に[HPRE]「hp精度構造ハンドブック。」
Eisler Standards Track [Page 25] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[25ページ]: 標準の外部データ表現2006年5月
14. Acknowledgements
14. 承認
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.
ボブリヨンは1980年代のONC RPCの後ろのSunの目に見える力でした。 サン・マイクロシステムズ・インクはRFC1014の作者として記載されています。 主権Srinivasanと古いONC RPCワーキンググループの残りはRFC1832にRFC1014を編集しました。(このドキュメントはRFCから引き出されます)。 マイク・アイスラーとビル・ジャンセンはこの規格のための実現レポートを提出しました。 ケビン・コフマン、ベニー・アレビ、およびジョン・ピーターソンは、このドキュメントを再検討して、フィードバックしました。 ピーターAstrandとブライアン・オルソンは本書では修正されるRFC1832のいくつかの誤りを指摘しました。
Editor's Address
エディタのアドレス
Mike Eisler 5765 Chase Point Circle Colorado Springs, CO 80919 USA
マイク・アイスラー5765・チェイス・ポイント円のコロラド・スプリングス、CO80919米国
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
Eisler Standards Track [Page 26] RFC 4506 XDR: External Data Representation Standard May 2006
アイスラーStandardsはRFC4506XDRを追跡します[26ページ]: 標準の外部データ表現2006年5月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Eisler Standards Track [Page 27]
アイスラー標準化過程[27ページ]
一覧
スポンサーリンク
