RFC1832 日本語訳
1832 XDR: External Data Representation Standard. R. Srinivasan. August 1995. (Format: TXT=47418 bytes) (Obsoleted by RFC4506) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Srinivasan Request for Comments: 1832 Sun Microsystems Category: Standards Track August 1995
Srinivasanがコメントのために要求するワーキンググループR.をネットワークでつないでください: 1832年のサン・マイクロシステムズカテゴリ: 標準化過程1995年8月
XDR: External Data Representation Standard
XDR: 外部データ表現規格
Status of this Memo
この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)の現行版を参照してください。 このメモの分配は無制限です。
ABSTRACT
要約
This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted.
それを現在、配備して、受け入れるとき、このドキュメントはExternal Data Representation Standard(XDR)プロトコルについて説明します。
TABLE OF CONTENTS
目次
1. INTRODUCTION 2 2. BASIC BLOCK SIZE 2 3. XDR DATA TYPES 3 3.1 Integer 3 3.2 Unsigned Integer 4 3.3 Enumeration 4 3.4 Boolean 4 3.5 Hyper Integer and Unsigned Hyper Integer 4 3.6 Floating-point 5 3.7 Double-precision Floating-point 6 3.8 Quadruple-precision Floating-point 7 3.9 Fixed-length Opaque Data 8 3.10 Variable-length Opaque Data 8 3.11 String 9 3.12 Fixed-length Array 10 3.13 Variable-length Array 10 3.14 Structure 11 3.15 Discriminated Union 11 3.16 Void 12 3.17 Constant 12 3.18 Typedef 13 3.19 Optional-data 14 3.20 Areas for Future Enhancement 15 4. DISCUSSION 15 5. THE XDR LANGUAGE SPECIFICATION 17 5.1 Notational Conventions 17
1. 序論2 2。 文節サイズ2 3。 XDRデータ型3 3.1整数3 3.2符号のない整数3.3の列挙4 3.4論理演算子4 3.5超-整数と4の無記名の超-整数4 3.6、浮動小数点、5 3.7 倍精度浮動小数点の6 3.8に、4倍精度浮動小数点の7 3.9固定長はデータ8 3について不透明にします; 10の可変長の不明瞭なデータ8 3.11ストリング9 3.12の固定長のアレイの10 3.13の可変長のアレイ10 3.14構造11 3.15の差別された組合11 3.16が今後の増進のための任意のデータ14 3.20の12 3.17の一定の12 3.18Typedef13 3.19領域を欠如させる、15、4 議論15 5。 XDR言語仕様17 5.1の記号法のコンベンション17
Srinivasan Standards Track [Page 1] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[1ページ]: 標準の外部データ表現1995年8月
5.2 Lexical Notes 17 5.3 Syntax Information 18 5.4 Syntax Notes 19 6. AN EXAMPLE OF AN XDR DATA DESCRIPTION 20 7. TRADEMARKS AND OWNERS 21 APPENDIX A: ANSI/IEEE Standard 754-1985 22 APPENDIX B: REFERENCES 24 Security Considerations 24 Author's Address 24
5.2 語彙注意17 5.3構文情報18 5.4構文注意19 6。 XDRデータ記述20 7に関する例。 商標と所有者21付録A: ANSI/IEEEの標準の754-1985 22付録B: 参照24セキュリティ問題24作者のアドレス24
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 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 only 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 [1], just as Courier [4] 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[4]がMesaと同様であるようにXDR言語自体はC言語[1]と同様です。 ONC RPC(リモートProcedure Call)やNFS*(ネットワークファイルシステム)などのプロトコルは、彼らのデータの形式について説明するのにXDRを使用します。
The XDR standard makes the following assumption: that bytes (or octets) are portable, where a byte is defined to be 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 [2], or least significant bit first.
XDR規格は以下の仮定をします: 1バイトが8ビットのデータになるように定義されるところでバイト(または、八重奏)は携帯用です。 与えられたハードウェアデバイスは他のハードウェアデバイスが意味の損失なしでバイトを解読するかもしれないような方法で様々なメディアにバイトをコード化するはずです。 例えば、イーサネット*規格は、バイトが最初に「リトルエンディアン」スタイル[2]、または最下位ビットでコード化されるのを示します。
2. BASIC BLOCK SIZE
2. 文節サイズ
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の倍数を数えてください。
Srinivasan Standards Track [Page 2] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[2ページ]: 標準の外部データ表現1995年8月
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. Ellipses (...) between boxes show zero or more additional bytes where required.
私たちはイラストと比較のための身近なグラフィック箱の記法を入れます。 ほとんどのイラストでは、各箱(プラスサインで、4つの角、縦棒、およびダッシュのときに区切られる)は1バイトについて表現します。 楕円(…)が箱の間にゼロを示しているか、またはどこが、より多くの追加バイト、必要であるか。
+--------+--------+...+--------+--------+...+--------+
| 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)>。----------->|
3. XDR DATA TYPES
3. 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 variablelength sequences of data and 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 5: "The XDR Language Specification".
言語の各データ型に関しては、私たちは一般的なパラダイム宣言を示しています。 角ブラケット(<と>)がデータと角括弧のvariablelength系列を指示することに注意してください、([そして])、データの固定長系列を指示してください。 「n」、「m」、および「r」は整数を指示します。 「識別子」や「宣言」などの用語の完全な言語仕様と、より正式な定義について、セクション5を参照してください: 「XDR言語仕様。」
For some data types, more specific examples are included. A more extensive example of a data description is in section 6: "An Example of an XDR Data Description".
いくつかのデータ型に関しては、より特定の例は含まれています。 データ記述の、より大規模な例がセクション6にあります: 「XDRデータ記述に関する例。」
3.1 Integer
3.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ビット------------>。
Srinivasan Standards Track [Page 3] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[3ページ]: 標準の外部データ表現1995年8月
3.2. Unsigned Integer
3.2. 符号のない整数
An XDR unsigned integer is a 32-bit datum that encodes a nonnegative 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進の数によって表されます。 符号のない整数は以下の通りであると宣言されます:
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ビット------------>。
3.3 Enumeration
3.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 other integer than those that have been given assignments in the enum declaration.
enum宣言における課題を与えたのは、それらよりいかなる他の整数のenumとしてもコード化する誤りです。
3.4 Boolean
3.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する、識別子。
3.5 Hyper Integer and Unsigned Hyper Integer
3.5 超-整数と無記名の超-整数
The standard also defines 64-bit (8-byte) numbers called hyper integer and unsigned hyper integer. Their representations are the obvious extensions of integer and unsigned integer defined above.
また、規格は超-整数と無記名の超-整数と呼ばれる64ビット(8バイト)の数を定義します。 彼らの表現は上で定義された整数と符号のない整数の明白な拡大です。
Srinivasan Standards Track [Page 4] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[4ページ]: 標準の外部データ表現1995年8月
They are represented in two's complement notation. The most and least significant bytes are 0 and 7, respectively. Their declarations:
それらは2の補数記法で表されます。 最も多くて最も重要でないバイトは、それぞれ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)+-------+-------+-------+-------+-------+-------+-------+-------+ |バイト0|バイト1|バイト2|バイト3|バイト4|バイト5|バイト6|バイト7| +-------+-------+-------+-------+-------+-------+-------+-------+ <。----------------------------64ビット---------------------------->の超-整数の無記名の超-整数
3.6 Floating-point
3.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 [3]. The following three fields describe the single-precision floating-point number:
規格は「浮遊物」(32ビットか4バイト)という浮動小数点のデータ型を定義します。 使用されるコード化は正常にされた単精度浮動小数点の番号[3]の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
ちょうど、数の最も多くて最も重要でないバイトが0と3であるように、単精度の浮いているポイント番号の大部分と最下位ビットは、0と31です。 始めのビット、(最も重要
Srinivasan Standards Track [Page 5] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[5ページ]: 標準の外部データ表現1995年8月
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).
ビット) 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) [3]. 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仕様がコード化に関して相談されるべきである、サインされたゼロ、サインされた無限(オーバーフロー)、および反正常にされた数の(アンダーフロー。)[3] IEEE仕様に従って、"NaN"(数でない)にシステムに依存していて、"NaN"以外の何としてもXDRの中で解釈するべきではありません。
3.7 Double-precision Floating-point
3.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 [3]. The standard encodes the following three fields, which describe the double-precision floating-point number:
規格は「倍増する」という倍精度の浮いているポイントデータ型(64ビットか8バイト)のためのコード化を定義します。 使用されるコード化は正常にされた倍精度浮動小数点の番号[3]の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
ちょうど、数の最も多くて最も重要でないバイトが0と3であるように、倍精度の浮いているポイント番号の大部分と最下位ビットは、0と63です。 S、E、およびFの始めのビット(そして、最上位ビット)オフセットは、それぞれ0と、1と、12です。 注意
Srinivasan Standards Track [Page 6] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[6ページ]: 標準の外部データ表現1995年8月
that these numbers refer to the mathematical positions of the bits, and NOT to their actual physical locations (which vary from medium to medium).
これらの数はそれらの実際の物理的な位置ではなく、ビットの数学の位置(媒体によって異なる)について言及します。
The IEEE specifications should be consulted concerning the encoding for signed zero, signed infinity (overflow), and denormalized numbers (underflow) [3]. 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仕様がコード化に関して相談されるべきである、サインされたゼロ、サインされた無限(オーバーフロー)、および反正常にされた数の(アンダーフロー。)[3] IEEE仕様に従って、"NaN"(数でない)にシステムに依存していて、"NaN"以外の何としてもXDRの中で解釈するべきではありません。
3.8 Quadruple-precision Floating-point
3.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 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
ちょうど、数の最も多くて最も重要でないバイトが0と3であるように、4倍精度の浮動小数点の番号の大部分と最下位ビットは、0と127です。 始めのビット、(大部分
Srinivasan Standards Track [Page 7] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[7ページ]: 標準の外部データ表現1995年8月
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).
重要なビット) 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 [5], [6]. 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".
コード化は、ゼロ、サインされた無限(オーバーフロー)にサインして、反正常にされて、数が対応のアナログであるので、シングルと倍精度の浮動小数点の番号[5]、[6]のためにencodingsされます。 それが4倍精度の浮動小数点の番号に適用されるとき、"NaN"コード化にシステムに依存していて、"NaN"以外の何としてもXDRの中で解釈するべきではありません。
3.9 Fixed-length Opaque Data
3.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)------------>| 固定長不透明なもの
3.10 Variable-length Opaque Data
3.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に達する)バイトの系列と定義された可変長(数えられる)の不明瞭なデータに備えます。
Srinivasan Standards Track [Page 8] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[8ページ]: 標準の外部データ表現1995年8月
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. 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は系列が含むかもしれないバイト数の上限を指示します。 mが2番目の宣言のように指定されないなら、それは(2**32)であると思われます--1、最大の長さ。 通常、一定の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.
それは仕様で説明された最大より大きい長さにコード化する誤りです。
3.11 String
3.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
一定のmはストリングが含むかもしれないバイト数の上限を指示します。 mが2番目のように指定されないなら
Srinivasan Standards Track [Page 9] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[9ページ]: 標準の外部データ表現1995年8月
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:
宣言、それは(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)---->| ストリング
It is an error to encode a length greater than the maximum described in the specification.
それは仕様で説明された最大より大きい長さにコード化する誤りです。
3.12 Fixed-length Array
3.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
固定長アレイ
3.13 Variable-length Array
3.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から始まって、要素を通してn1を進行して。 可変長のアレイのための宣言はこのフォームに続きます:
Srinivasan Standards Track [Page 10] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[10ページ]: 標準の外部データ表現1995年8月
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要素------------->| 数えられたアレイ
It is an error to encode a value of n that is greater than the maximum described in the specification.
仕様で説明された最大よりすばらしいのは、nの値をコード化する誤りです。
3.14 Structure
3.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|... 構造+-------------+-------------+...
3.15 Discriminated Union
3.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 which implies their encoding. Discriminated unions are declared as follows:
差別された組合は判別式の値に従って1セットの根回しされたタイプから選ばれたタイプによって従われた判別式で構成されたタイプです。 判別式のタイプは、"int"、「未署名のint」か"bool"などの列挙型のどちらかです。 コンポーネント型を組合の「兵器」と呼ばれて、それらのコード化を含意する判別式の値は先行します。 差別された組合は以下の通りであると宣言されます:
union switch (discriminant-declaration) {
case discriminant-value-A:
組合スイッチ(判別式宣言)、判別式値A:をケースに入れてください。
Srinivasan Standards Track [Page 11] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[11ページ]: 標準の外部データ表現1995年8月
arm-declaration-A;
case discriminant-value-B:
arm-declaration-B;
...
default: default-declaration;
} identifier;
アーム宣言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.
暗示しているアームのコード化で判別式が従って、差別された組合はコード化されます。
0 1 2 3
+---+---+---+---+---+---+---+---+
| discriminant | implied arm | DISCRIMINATED UNION
+---+---+---+---+---+---+---+---+
|<---4 bytes--->|
0 1 2 3 +---+---+---+---+---+---+---+---+ | 判別式| 暗示しているアーム| 差別された組合+---+---+---+---+---+---+---+---+ | <、-、--4バイト--->|
3.16 Void
3.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バイト
3.17 Constant
3.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を定義します。
Srinivasan Standards Track [Page 12] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[12ページ]: 標準の外部データ表現1995年8月
const DOZEN = 12;
const DOZEN=12。
3.18 Typedef
3.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]。
Variables declared using the new type name have the same type as the new type name would have in the typedef, if it was 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。
The reason this syntax is preferred is one does not have to wait until the end of a declaration to figure out the name of the new type.
この構文が好まれているのが、1であるということである理由は新しいタイプの名前を理解する宣言の終わりまで待つ必要はありません。
Srinivasan Standards Track [Page 13] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[13ページ]: 標準の外部データ表現1995年8月
3.19 Optional-data
3.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に選ばれます)識別子。
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 arbitrary length strings:
任意のデータは本来それほどおもしろくはありませんが、それは非常に繋がっているリストや木などの再帰的なデータ構造について説明することの役に立ちます。 例えば、以下は任意の長さのストリングのリストをコード化するタイプ"stringlist"を定義します:
struct *stringlist {
string item<>;
stringlist next;
};
struct*stringlistは項目<>(次の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 stringlist<1> {
struct stringlist<1>。
Srinivasan Standards Track [Page 14] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[14ページ]: 標準の外部データ表現1995年8月
string item<>;
stringlist next;
};
項目<>を結んでください。 次のstringlist。 };
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言語のものと同じです。
3.20 Areas for Future Enhancement
3.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 are 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を考えることができました。
4. DISCUSSION
4. 議論
(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ストリングです。
Srinivasan Standards Track [Page 15] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[15ページ]: 標準の外部データ表現1995年8月
(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つのフォームからもう片方まで変換しなければなりません)。
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 which 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 which takes this value as its discriminant and for each value, describes the corresponding data type.
データ型定義には、それがどんな小さい利点を持つことができるように比較的高い費用があるか。 1つの費用は挿入されたタイプ分野によるデータの拡張です。 別のものはこれらのタイプ分野を解釈して、善処する加えられた費用です。 そして、ほとんどのプロトコルが、彼らがどんなタイプを予想するかを既に知るので、データ型定義は余分な情報だけを提供します。 しかしながら、1つは、XDRを使用することでまだデータ型定義の恩恵を得ることができます。One道は2つのものをコード化することです: 最初に、コード化されたデータのXDRデータ記述と、次にコード化されたデータ自体であるストリング。 別の方法がXDRのすべてのタイプに値を割り当てることであり、次に、判別式と各値にこの値を取って、対応するデータ型について説明する普遍的なタイプを定義してください。
Srinivasan Standards Track [Page 16] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[16ページ]: 標準の外部データ表現1995年8月
5. THE XDR LANGUAGE SPECIFICATION
5. XDR言語仕様
5.1 Notational Conventions
5.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
("|"). (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.
'(1) キャラクタ'|'、'、('、'、)、'、'、['、'、]、''「''*'は特別'です」。 (2) 終端記号は二重引用符によって囲まれたどんなキャラクタのストリングです。 (3) 非終端記号は非特殊文字のストリングです。 (4) 代替品目が縦棒によって切り離される、(「|」、) (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"
「非常に非常に冷たくて雨の夜」の「非常に冷たくて雨の日」の「非常に雨の日」の「非常に雨の日」
5.2 Lexical Notes
5.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 constant is a sequence of one or more decimal digits,
optionally preceded by a minus-sign ('-').
'(1) コメントは、'/*'で始まって、'*/'で終わります。 (2) 商品を切り離すのに役立ちます。別の方法で、余白は、無視されます。 (3) 識別子は手紙、ケタまたはunderbar('_')の任意の系列がいうことになった手紙です。 識別子に関するケースは無視されません。 (4) 定数はマイナス記号('--')が任意に先行した1つ以上の10進数字の系列です。
Srinivasan Standards Track [Page 17] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[17ページ]: 標準の外部データ表現1995年8月
5.3 Syntax Information
5.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
値: 定数| 識別子
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
組合タイプ仕様: 「組合」組合団体
Srinivasan Standards Track [Page 18] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[18ページ]: 標準の外部データ表現1995年8月
union-body:
"switch" "(" declaration ")" "{"
( "case" value ":" declaration ";" )
( "case" value ":" declaration ";" )*
[ "default" ":" declaration ";" ]
"}"
組合団体: 「「スイッチ」「(「宣言」)」、「「(「ケース」が」 : 」 宣言を評価する、」、;、」、)、(「ケース」が」 : 」 宣言を評価する、」、;、」、)、*、[「デフォルト、」 」 : 」 宣言、」、;、」、]、」、」
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 *
仕様: 定義*
5.4 Syntax Notes
5.4 構文注意
(1) The following are keywords and cannot be used as identifiers: "bool", "case", "const", "default", "double", "quadruple", "enum", "float", "hyper", "opaque", "string", "struct", "switch", "typedef", "union", "unsigned" and "void".
(1) 以下は、キーワードであり、識別子として使用できません: "bool"、「ケース」、"const"、「デフォルト」、「二重で」、「4倍」の"enum"が「浮く」、「超-、」、「不透明なもの」、「ストリング」、"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つでなければなりません。 最終的に、ケース値は組合宣言の範囲の中の一度より指定されないかもしれません。
Srinivasan Standards Track [Page 19] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[19ページ]: 標準の外部データ表現1995年8月
6. AN EXAMPLE OF AN XDR DATA DESCRIPTION
6. 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>の/*所有者;/*ファイルデータ*/。
Srinivasan Standards Track [Page 20] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[20ページ]: 標準の外部データ表現1995年8月
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"というユーザがいるので「(やめてください)」という、思ってください。 彼のファイルは以下の通りコード化されるでしょう:
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無バイトの中詰め
7. TRADEMARKS AND OWNERS
7. 商標と所有者
SUN WORKSTATION Sun Microsystems, Inc.
VAX Digital Equipment Corporation
IBM-PC International Business Machines Corporation
Cray Cray Research
NFS Sun Microsystems, Inc.
Ethernet Xerox Corporation.
Motorola 68000 Motorola, Inc.
IBM 370 International Business Machines Corporation
サンワークステーションサン・マイクロシステムズ・インクVAX DEC IBM-PC IBM社ザリガニクレイリサーチNFSサン・マイクロシステムズ・インクイーサネットゼロックス社。 モトローラ68000モトローラIBM370IBM社
Srinivasan Standards Track [Page 21] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[21ページ]: 標準の外部データ表現1995年8月
APPENDIX A: ANSI/IEEE Standard 754-1985
付録A: ANSI/IEEE規格754-1985
The definition of NaNs, signed zero and infinity, and denormalized numbers from [3] 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 [3].
ゼロと無限であると署名されるNaNsと[3]からの反正常にされた数の定義は便宜のためにここで再生します。 4倍精度浮動小数点のための定義は、シングルと倍精度浮動小数点のためのそれらのアナログであり、[3]で定義されます。
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
Srinivasan Standards Track [Page 22] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[22ページ]: 標準の外部データ表現1995年8月
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
Srinivasan Standards Track [Page 23] RFC 1832 XDR: External Data Representation Standard August 1995
Srinivasan規格はRFC1832XDRを追跡します[23ページ]: 標準の外部データ表現1995年8月
APPENDIX B: REFERENCES
付録B: 参照
[1] Brian W. Kernighan & Dennis M. Ritchie, "The C Programming
Language", Bell Laboratories, Murray Hill, New Jersey, 1978.
[1] ブライアンW.カーニハンとデニス・M.リッチー、「Cプログラミング言語」、ベル研究所、マリー・ヒル(ニュージャージー)1978。
[2] Danny Cohen, "On Holy Wars and a Plea for Peace", IEEE Computer,
October 1981.
[2] ダニー・コーエン、IEEEコンピュータ、「平和のための聖戦と請願」の10月1981
[3] "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE
Standard 754-1985, Institute of Electrical and Electronics
Engineers, August 1985.
[3] 「2進の浮動小数点の演算のIEEE規格」、ANSI/IEEE規格754-1985、米国電気電子技術者学会、1985年8月。
[4] "Courier: The Remote Procedure Call Protocol", XEROX
Corporation, XSIS 038112, December 1981.
[4]、「急使:」 「遠隔手続き呼び出しプロトコル」、ゼロックス社、XSIS038112、1981年12月。
[5] "The SPARC Architecture Manual: Version 8", Prentice Hall,
ISBN 0-13-825001-4.
[5]、「SPARCアーキテクチャマニュアル:」 バージョン8インチ、新米のホール、ISBN0-13-825001-4。
[6] "HP Precision Architecture Handbook", June 1987, 5954-9906.
[6] 1987年6月、5954-9906に「hp精度アーキテクチャハンドブック。」
[7] Srinivasan, R., "Remote Procedure Call Protocol Version 2",
RFC 1831, Sun Microsystems, Inc., August 1995.
[7]Srinivasan、R.、「遠隔手続き呼び出しプロトコルバージョン2インチ、RFC1831、サン・マイクロシステムズ・インク、1995年8月。」
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Raj Srinivasan Sun Microsystems, Inc. ONC Technologies 2550 Garcia Avenue M/S MTV-5-40 Mountain View, CA 94043 USA
主権Srinivasanサン・マイクロシステムズ・インクONC Technologies2550ガルシアアベニューS MTV-5-40カリフォルニア94043M/マウンテンビュー(米国)
Phone: 415-336-2478 Fax: 415-336-6015 EMail: raj@eng.sun.com
以下に電話をしてください。 415-336-2478 Fax: 415-336-6015 メールしてください: raj@eng.sun.com
Srinivasan Standards Track [Page 24]
Srinivasan標準化過程[24ページ]
一覧
スポンサーリンク
