Network Working Group S. Josefsson
Request for Comments: 4648 SJD
Obsoletes: 3548 October 2006
Category: Standards Track
The Base16, Base32, and Base64 Data Encodings
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings.
この文書は、一般的に使用されるベース64、ベース32、ベース16符号化方式を記載しています。また、符号化データにおけるラインフィード、符号化データにパディングを使用する、符号化データ中の非アルファベット文字の使用、異なる符号化アルファベットの使用、および正規の符号化の使用を論じています。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Implementation Discrepancies ....................................3
3.1. Line Feeds in Encoded Data .................................3
3.2. Padding of Encoded Data ....................................4
3.3. Interpretation of Non-Alphabet Characters in Encoded Data ..4
3.4. Choosing the Alphabet ......................................4
3.5. Canonical Encoding .........................................5
4. Base 64 Encoding ................................................5
5. Base 64 Encoding with URL and Filename Safe Alphabet ............7
6. Base 32 Encoding ................................................8
7. Base 32 Encoding with Extended Hex Alphabet ....................10
8. Base 16 Encoding ...............................................10
9. Illustrations and Examples .....................................11
10. Test Vectors ..................................................12
11. ISO C99 Implementation of Base64 ..............................14
12. Security Considerations .......................................14
13. Changes Since RFC 3548 ........................................15
14. Acknowledgements ..............................................15
15. Copying Conditions ............................................15
16. References ....................................................16
16.1. Normative References .....................................16
16.2. Informative References ...................................16
Base encoding of data is used in many situations to store or transfer data in environments that, perhaps for legacy reasons, are restricted to US-ASCII [1] data. Base encoding can also be used in new applications that do not have legacy restrictions, simply because it makes it possible to manipulate objects with text editors.
データのベース符号化は、おそらく、レガシー上の理由から、US-ASCII [1]のデータに制限され、環境にデータを保存または転送するために多くの状況で使用されています。ベースエンコーディングは、テキストエディタでオブジェクトを操作することが可能になるという理由だけで、従来の制限はありません新しいアプリケーションでも使用することができます。
In the past, different applications have had different requirements and thus sometimes implemented base encodings in slightly different ways. Today, protocol specifications sometimes use base encodings in general, and "base64" in particular, without a precise description or reference. Multipurpose Internet Mail Extensions (MIME) [4] is often used as a reference for base64 without considering the consequences for line-wrapping or non-alphabet characters. The purpose of this specification is to establish common alphabet and encoding considerations. This will hopefully reduce ambiguity in other documents, leading to better interoperability.
過去には、異なるアプリケーションは異なる要件を持っていたので、時々少し異なる方法でベースエンコーディングを実装しました。今日では、プロトコル仕様は、時々、正確な記述または参照することなく、ベース一般にエンコーディング、特に「BASE64」を使用します。 MIME（Multipurpose Internet Mail Extensions）の[4]は、多くの場合、行の折り返しや非アルファベット文字の影響を考慮せずにbase64のための基準として使用されます。この仕様の目的は、共通のアルファベットとエンコーディングの考慮を確立することです。これがうまくいけば、より良い相互運用性につながる、他の文書に曖昧さを軽減します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[2]で説明されるように解釈されます。
Here we discuss the discrepancies between base encoding implementations in the past and, where appropriate, mandate a specific recommended behavior for the future.
ここでは、適切な、将来のための具体的な推奨行動を義務付けるベースエンコーディング、過去の実装と、間の相違を議論します。
MIME [4] is often used as a reference for base 64 encoding. However, MIME does not define "base 64" per se, but rather a "base 64 Content-Transfer-Encoding" for use within MIME. As such, MIME enforces a limit on line length of base 64-encoded data to 76 characters. MIME inherits the encoding from Privacy Enhanced Mail (PEM) [3], stating that it is "virtually identical"; however, PEM uses a line length of 64 characters. The MIME and PEM limits are both due to limits within SMTP.
MIME [4]は、多くの場合、ベース64符号化のための基準として使用されます。しかし、MIMEは、MIME内で使用するための「ベース64」自体ではなく、「ベース64コンテンツ転送エンコード」を定義していません。このように、MIMEは、76文字までベース64符号化されたデータの行の長さに制限を強制します。 MIMEは、「実質的に同一」であることを示す、[3]プライバシー強化メール（PEM）からエンコーディングを継承します。しかし、PEMは、64文字の行の長さを使用しています。 MIMEとPEMの制限は、両方のSMTP内の限界によるものです。
Implementations MUST NOT add line feeds to base-encoded data unless the specification referring to this document explicitly directs base encoders to add line feeds after a specific number of characters.
実装は、この文書を参照する仕様は明示的に文字の特定の番号の後にフィードの行を追加するために、ベースエンコーダを指示しない限り、基本符号化されたデータへのフィードの行を追加してはなりません。
In some circumstances, the use of padding ("=") in base-encoded data is not required or used. In the general case, when assumptions about the size of transported data cannot be made, padding is required to yield correct decoded data.
いくつかの状況では、ベース符号化データでパディングの使用は、（「=」）が必要または使用されていません。一般的な場合では、転送されるデータのサイズに関する仮定を行うことができない場合、パディングは、復号データを正しい得るために必要とされます。
Implementations MUST include appropriate pad characters at the end of encoded data unless the specification referring to this document explicitly states otherwise.
この文書を参照する仕様が明示的に述べない限り、実装は、符号化データの終了時に適切なパッドの文字を含まなければなりません。
The base64 and base32 alphabets use padding, as described below in sections 4 and 6, but the base16 alphabet does not need it; see section 8.
セクション4と6で以下に説明するようにBASE64とbase32アルファベットは、パディングを使用するが、base16のアルファベットは、それを必要としません。セクション8を参照してください。
Base encodings use a specific, reduced alphabet to encode binary data. Non-alphabet characters could exist within base-encoded data, caused by data corruption or by design. Non-alphabet characters may be exploited as a "covert channel", where non-protocol data can be sent for nefarious purposes. Non-alphabet characters might also be sent in order to exploit implementation errors leading to, e.g., buffer overflow attacks.
ベースエンコーディングは、バイナリデータを符号化するために特定、縮小アルファベットを使用します。非アルファベット文字は、データの破損によって、または設計によって引き起こされるベース符号化されたデータ内に存在する可能性があります。非アルファベット文字は、非プロトコル・データが不正な目的のために送ることができる「隠れチャネル」として利用することができます。非アルファベット文字はまた、例えば、バッファオーバーフロー攻撃につながる実装エラーを利用するために送信されることがあります。
Implementations MUST reject the encoded data if it contains characters outside the base alphabet when interpreting base-encoded data, unless the specification referring to this document explicitly states otherwise. Such specifications may instead state, as MIME does, that characters outside the base encoding alphabet should simply be ignored when interpreting data ("be liberal in what you accept"). Note that this means that any adjacent carriage return/ line feed (CRLF) characters constitute "non-alphabet characters" and are ignored. Furthermore, such specifications MAY ignore the pad character, "=", treating it as non-alphabet data, if it is present before the end of the encoded data. If more than the allowed number of pad characters is found at the end of the string (e.g., a base 64 string terminated with "==="), the excess pad characters MAY also be ignored.
ベース符号化されたデータを解釈する際には、ベースのアルファベット以外の文字が含まれている場合、このドキュメントを参照する仕様は明示的に述べない限り、実装は、符号化されたデータを拒絶しなければなりません。このような仕様ではなく、状態、MIMEがするように、データを解釈する際のベースエンコーディングアルファベット以外の文字は単に無視されるべきであること（「あなたが受け入れるものにリベラルこと」）があります。これは、任意の隣接するキャリッジリターン/ラインフィード（CRLF）文字が「非アルファベット文字」を構成し、無視されることを意味することに留意されたいです。それは、符号化データの終了前に存在する場合にはさらに、そのような仕様は、非アルファベットデータとして扱い、「=」、パッドの文字を無視してもよいです。パッド文字の許容数よりも多くは、文字列の最後に発見された場合、過剰なパッド文字も無視することができる（例えば、ベース64文字列は「===」で終了します）。
Different applications have different requirements on the characters in the alphabet. Here are a few requirements that determine which alphabet should be used: o Handled by humans. The characters "0" and "O" are easily confused, as are "1", "l", and "I". In the base32 alphabet below, where 0 (zero) and 1 (one) are not present, a decoder may interpret 0 as O, and 1 as I or L depending on case. (However, by default it should not; see previous section.)
異なるアプリケーションは、アルファベットの文字に異なる要件を持っています。人間で扱う○：ここで使用されるべきアルファベット決定いくつかの要件があります。 「1」、「L」、及び「I」であるとして文字「0」と「O」は、容易に混乱しています。 I又はLは、場合に応じて、0（ゼロ）と1（1）は存在しない以下アルファベットbase32において、デコーダは、Oとして0と1を解釈することができます。 （ただし、デフォルトではすべきではありません。前のセクションを参照してください。）
o Encoded into structures that mandate other requirements. For base 16 and base 32, this determines the use of upper- or lowercase alphabets. For base 64, the non-alphanumeric characters (in particular, "/") may be problematic in file names and URLs.
Oその他の要件を義務付ける構造にエンコードされました。ベース16とベース32の場合、これは、大文字または小文字のアルファベットを使用することを決定します。ベース64は、英数字以外の文字（特に、「/」）ファイル名やURLで問題となり得ます。
o Used as identifiers. Certain characters, notably "+" and "/" in the base 64 alphabet, are treated as word-breaks by legacy text search/index tools.
O識別子として使用されます。特定の文字、特に「+」と「/」ベース64アルファベットで、レガシーテキスト検索/インデックスツールによって語ブレークとして扱われます。
There is no universally accepted alphabet that fulfills all the requirements. For an example of a highly specialized variant, see IMAP [8]. In this document, we document and name some currently used alphabets.
すべての要件を満たし全く普遍的に受け入れアルファベットはありません。専門性の高い変異体、例えば、IMAP [8]を参照してください。この文書では、我々は文書化し、いくつかの現在使用されてアルファベットを名前を付けます。
The padding step in base 64 and base 32 encoding can, if improperly implemented, lead to non-significant alterations of the encoded data. For example, if the input is only one octet for a base 64 encoding, then all six bits of the first symbol are used, but only the first two bits of the next symbol are used. These pad bits MUST be set to zero by conforming encoders, which is described in the descriptions on padding below. If this property do not hold, there is no canonical representation of base-encoded data, and multiple base-encoded strings can be decoded to the same binary data. If this property (and others discussed in this document) holds, a canonical encoding is guaranteed.
ベース64とベース32符号化におけるパディングステップは、不適切に実装されている場合、符号化データの非有意な変化をもたらすことができます。入力は、ベース64符号化のための唯一の1オクテットである場合、例えば、最初のシンボルのすべての6つのビットが使用されるが、次のシンボルの最初の2ビットが使用されています。これらのパッドビットは、以下のパディングに説明に記載されている適合エンコーダによってゼロに設定しなければなりません。このプロパティが保持されない場合は、そこにベース符号化データのない正規表現ではなく、複数のベース・エンコードされた文字列が同一のバイナリデータに復号化することができます。 （本書で論じなど）このプロパティが保持している場合、正規の符号化が保証されます。
In some environments, the alteration is critical and therefore decoders MAY chose to reject an encoding if the pad bits have not been set to zero. The specification referring to this may mandate a specific behaviour.
いくつかの環境では、変化は重要であり、したがって、MAY、パッドビットがゼロに設定されていない場合の符号化を拒否することを選択したデコーダ。これに言及する仕様は、特定の動作を義務付けることがあります。
The following description of base 64 is derived from [3], [4], [5], and [6]. This encoding may be referred to as "base64".
ベース64の以下の説明は、以下から誘導される[3]、[4]、[5]、及び[6]。この符号化は、「BASE64」と呼ぶことができます。
The Base 64 encoding is designed to represent arbitrary sequences of octets in a form that allows the use of both upper- and lowercase letters but that need not be human readable.
ベース64符号化は、両方の大文字と小文字の使用を可能にする形でオクテットの任意のシーケンスを表すように設計されているが、それは人間可読である必要はありません。
A 65-character subset of US-ASCII is used, enabling 6 bits to be represented per printable character. (The extra 65th character, "=", is used to signify a special processing function.)
US-ASCIIの65文字サブセットは、印刷可能な文字ごとに表現する6ビットを可能に用いられます。 （余分な65番目の文字は、「=」、特別な処理機能を意味するために使用されます。）
The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right, a 24-bit input group is formed by concatenating 3 8-bit input groups. These 24 bits are then treated as 4 concatenated 6-bit groups, each of which is translated into a single character in the base 64 alphabet.
符号化プロセスは、4つのエンコードされた文字の出力列として入力ビットの24ビットのグループを表します。左から右に進むと、24ビットの入力グループは3〜8ビットの入力グループを連結することによって形成されています。これらの24ビットは、ベース64アルファベットの単一文字に変換されそれぞれが4連結された6ビットのグループとして扱われます。
Each 6-bit group is used as an index into an array of 64 printable characters. The character referenced by the index is placed in the output string.
各6ビットグループは64の印刷可能文字の配列へのインデックスとして使用されます。インデックスで参照される文字は、出力文字列に配置されます。
Table 1: The Base 64 Alphabet
表1：ベース64アルファベット
Value Encoding Value Encoding Value Encoding Value Encoding 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y
値エンコーディング値エンコーディング値エンコーディング値34 I 51 Z 1 B 18 S 35 J 52 0 2 C 19 T 36 K 53 1 3 D 20 U 37リットル54 2 4 E 21、V 38メートル55 3 5 F 17 R 0エンコーディング22 W 39 N 56 4 6 G 23 X 40 O 57 5 7 H 24 Y 41、P 58 6 8 I 25、Z 42、Q 59 7 9 26 J 43 R 60 8 10 K 27、B 44、S 61 9 11 L 28 C 45トン62 + 12 M 29、D 46、U 13分の63 N 30、E 47、V 14 O 31 48 F（パッド）= 15 P 32グラム49 X 16 Q 33 H 50 Y、W
Special processing is performed if fewer than 24 bits are available at the end of the data being encoded. A full encoding quantum is always completed at the end of a quantity. When fewer than 24 input bits are available in an input group, bits with value zero are added (on the right) to form an integral number of 6-bit groups. Padding at the end of the data is performed using the '=' character. Since all base 64 input is an integral number of octets, only the following cases can arise:
未満の24ビットは符号化されたデータの最後に利用可能である場合、特別な処理が行われます。フルエンコードの量子は、常に量の年末に完成されます。 24個の未満の入力ビットが入力グループに利用可能である場合、値がゼロのビットが6ビットグループの整数を形成する（右側）を添加します。データの終わりにパディングが「=」文字を使用して行われます。すべてのベース64の入力は、オクテットの整数倍であるため、次の場合のみが発生することができます。
(1) The final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding.
（1）入力をコードする最終量子は、24ビットの整数倍です。ここで、符号化された出力の最終的なユニットは、NO「=」パディングと4つの文字の整数倍であろう。
(2) The final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters.
（2）コーディング入力の最終部分は正確に8ビットです。ここで、符号化された出力の最終的なユニットは、2つの文字が2つの「=」パディング文字が続くであろう。
(3) The final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character.
（3）をコード入力の最終的な量子は正確に16ビットです。ここでは、エンコードされた出力の最終単位は1「=」パディング文字が続く3つの文字になります。
The Base 64 encoding with an URL and filename safe alphabet has been used in [12].
URLとファイル名安全なアルファベットとベース64符号化は[12]で用いられてきました。
An alternative alphabet has been suggested that would use "~" as the 63rd character. Since the "~" character has special meaning in some file system environments, the encoding described in this section is recommended instead. The remaining unreserved URI character is ".", but some file system environments do not permit multiple "." in a filename, thus making the "." character unattractive as well.
代替アルファベットは、それが第63回キャラクターとして「〜」使用することが提案されています。 「〜」の文字がいくつかのファイルシステム環境では特別な意味を持っているので、このセクションで説明するエンコーディングが代わりにお勧めします。残りの予約されていないURI文字は「 『であるが、いくつかのファイルシステム環境では、複数のを許可しません』。」ファイル名には、このようになって「」キャラクターにも魅力がありません。
The pad character "=" is typically percent-encoded when used in an URI [9], but if the data length is known implicitly, this can be avoided by skipping the padding; see section 3.2.
URIで使用されるとき、パッド文字は「=」は、[9]一般的にパーセント符号化されるが、データ長が暗黙的に知られている場合、これはパディングをスキップすることによって回避することができます。セクション3.2を参照してください。
This encoding may be referred to as "base64url". This encoding should not be regarded as the same as the "base64" encoding and should not be referred to as only "base64". Unless clarified otherwise, "base64" refers to the base 64 in the previous section.
この符号化は、「base64url」と呼ぶことができます。この符号化は、「BASE64」エンコーディングと同じとみなされるべきではないとだけ「BASE64」と呼ばれるべきではありません。別段明らかにしない限り、「BASE64」は、前のセクションのベース64を指します。
This encoding is technically identical to the previous one, except for the 62:nd and 63:rd alphabet character, as indicated in Table 2.
この符号化は62を除いて、以前のものと技術的に同一である：NDと63：RDアルファベット文字、表2に示されるように。
Table 2: The "URL and Filename safe" Base 64 Alphabet
表2：「URLやファイル名安全な」ベース64アルファベット
Value Encoding Value Encoding Value Encoding Value Encoding 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 - (minus) 12 M 29 d 46 u 63 _ 13 N 30 e 47 v (underline) 14 O 31 f 48 w 15 P 32 g 49 x 16 Q 33 h 50 y (pad) =
値エンコーディング値エンコーディング値エンコーディング値34 I 51 Z 1 B 18 S 35 J 52 0 2 C 19 T 36 K 53 1 3 D 20 U 37リットル54 2 4 E 21、V 38メートル55 3 5 F 17 R 0エンコーディング22 W 39 N 56 4 6 G 23 X 40 O 57 5 7 H 24 Y 41、P 58 6 8 I 25、Z 42、Q 59 7 9 26 J 43 R 60 8 10 K 27、B 44、S 61 9 11 L 28 C 45トン62 - （マイナス）12、M 29、D 46、U 63 _ 13 N 30、E 47、V（下線）14 O 31 F 48 15 P 32グラム49 X 16 Q 33 H 50 Y（パッド）W =
The following description of base 32 is derived from [11] (with corrections). This encoding may be referred to as "base32".
ベース32の以下の説明は、[11]（訂正を伴う）に由来します。この符号化は「base32」と呼ぶことができます。
The Base 32 encoding is designed to represent arbitrary sequences of octets in a form that needs to be case insensitive but that need not be human readable.
ベース32符号化は、大文字と小文字を区別する必要がある形でオクテットの任意のシーケンスを表すように設計されているが、それは人間可読である必要はありません。
A 33-character subset of US-ASCII is used, enabling 5 bits to be represented per printable character. (The extra 33rd character, "=", is used to signify a special processing function.)
US-ASCIIの33文字サブセットは、印刷可能な文字ごとに表現する5ビットを可能に用いられます。 （余分な第33の文字は、「=」、特別な処理機能を意味するために使用されます。）
The encoding process represents 40-bit groups of input bits as output strings of 8 encoded characters. Proceeding from left to right, a 40-bit input group is formed by concatenating 5 8bit input groups. These 40 bits are then treated as 8 concatenated 5-bit groups, each of which is translated into a single character in the base 32 alphabet. When a bit stream is encoded via the base 32 encoding, the bit stream must be presumed to be ordered with the most-significant-bit first. That is, the first bit in the stream will be the high-order bit in the first 8bit byte, the eighth bit will be the low-order bit in the first 8bit byte, and so on.
符号化プロセスは、8つのエンコードされた文字の出力列として入力ビットの40ビットのグループを表します。左から右に進むと、40ビットの入力グループは5つの8ビットの入力グループを連結することによって形成されています。これらの40ビットは、ベース32アルファベットの単一文字に変換され、それぞれが8連結5ビットのグループとして扱われます。ビットストリームはベース32符号化を介して符号化されるとき、ビットストリームはまず最上位ビットで注文すると推定されなければなりません。すなわち、ストリームの最初のビットが最初の8ビットバイトの上位ビットになり、8番目のビットがそうで最初の8ビットバイトの下位ビットである、とし、です。
Each 5-bit group is used as an index into an array of 32 printable characters. The character referenced by the index is placed in the output string. These characters, identified in Table 3, below, are selected from US-ASCII digits and uppercase letters.
各5ビット群は、32印刷可能文字の配列へのインデックスとして使用されます。インデックスで参照される文字は、出力文字列に配置されます。表3で特定これらの文字は、以下の、US-ASCIIの数字と大文字から選択されています。
Table 3: The Base 32 Alphabet
表3：ベース32アルファベット
Value Encoding Value Encoding Value Encoding Value Encoding 0 A 9 J 18 S 27 3 1 B 10 K 19 T 28 4 2 C 11 L 20 U 29 5 3 D 12 M 21 V 30 6 4 E 13 N 22 W 31 7 5 F 14 O 23 X 6 G 15 P 24 Y (pad) = 7 H 16 Q 25 Z 8 I 17 R 26 2
値エンコーディング値エンコーディング値エンコーディング値は0 A 9 J 18 S 27 3 1 B 10 K 19 T 28 4 2 C 11 L 20 U 29 5 3 D 12 M 21 V 30 6 4 E 13 N 22 W 31 7 5 Fをコードします14 O 23 X 6 G 15 P 24 Y 8 I 17 R 26 2（パッド）= 7 H 16 Q 25 Z
Special processing is performed if fewer than 40 bits are available at the end of the data being encoded. A full encoding quantum is always completed at the end of a body. When fewer than 40 input bits are available in an input group, bits with value zero are added (on the right) to form an integral number of 5-bit groups. Padding at the end of the data is performed using the "=" character. Since all base 32 input is an integral number of octets, only the following cases can arise:
未満の40ビットが符号化されたデータの最後に利用可能である場合、特別な処理が行われます。フルエンコードの量子は、常に体の年末に完成されます。未満の40個の入力ビットが入力グループに利用可能である場合、値がゼロのビットが5ビットグループの整数を形成する（右側）を添加します。データの終わりにパディングが「=」文字を使用して行われます。全てのベース32の入力は、オクテットの整数倍であるため、次の場合のみが発生することができます。
(1) The final quantum of encoding input is an integral multiple of 40 bits; here, the final unit of encoded output will be an integral multiple of 8 characters with no "=" padding.
（1）入力をコードする最終量子は、40ビットの整数倍です。ここで、符号化された出力の最終的なユニットは、NO「=」パディング8つの文字の整数倍であろう。
(2) The final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by six "=" padding characters.
（2）コーディング入力の最終部分は正確に8ビットです。ここで、符号化された出力の最終的なユニットは、2つの文字が6「=」パディング文字が続くであろう。
(3) The final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be four characters followed by four "=" padding characters.
（3）をコード入力の最終的な量子は正確に16ビットです。ここで、符号化された出力の最終的なユニットは、4つの文字は、4「=」パディング文字が続くであろう。
(4) The final quantum of encoding input is exactly 24 bits; here, the final unit of encoded output will be five characters followed by three "=" padding characters.
（4）コーディング入力の最終部分は正確に24ビットです。ここで、符号化された出力の最終的なユニットは、三つの「=」パディング文字が続く5つの文字であろう。
(5) The final quantum of encoding input is exactly 32 bits; here, the final unit of encoded output will be seven characters followed by one "=" padding character.
（5）をコード入力の最終的な量子は正確に32ビットです。ここでは、エンコードされた出力の最終単位は1「=」パディング文字が続く7つの文字になります。
The following description of base 32 is derived from [7]. This encoding may be referred to as "base32hex". This encoding should not be regarded as the same as the "base32" encoding and should not be referred to as only "base32". This encoding is used by, e.g., NextSECure3 (NSEC3) [10].
ベース32の以下の説明は、[7]に由来します。この符号化は、「base32hex」と呼ぶことができます。この符号化は「base32」符号化と同じとみなされるべきではないとだけ「base32」と呼ばれるべきではありません。この符号化は、例えば、NextSECure3（NSEC3）[10]で使用されます。
One property with this alphabet, which the base64 and base32 alphabets lack, is that encoded data maintains its sort order when the encoded data is compared bit-wise.
BASE64とbase32のアルファベットにはないこのアルファベット、と1つの特性は、符号化されたデータは、ビット単位の比較されたときに符号化されたデータは、そのソート順を維持することです。
This encoding is identical to the previous one, except for the alphabet. The new alphabet is found in Table 4.
このエンコーディングは、アルファベットを除いて、以前のものと同じです。新しいアルファベットを表4に発見されました。
Table 4: The "Extended Hex" Base 32 Alphabet
表4：「拡張六角」ベース32アルファベット
Value Encoding Value Encoding Value Encoding Value Encoding 0 0 9 9 18 I 27 R 1 1 10 A 19 J 28 S 2 2 11 B 20 K 29 T 3 3 12 C 21 L 30 U 4 4 13 D 22 M 31 V 5 5 14 E 23 N 6 6 15 F 24 O (pad) = 7 7 16 G 25 P 8 8 17 H 26 Q
値エンコーディング値エンコーディング値エンコーディング値R 1 1 10 19 J 28 S 2 2 11 B 20 K 29 T 3 3 12 C 21 L 30 U 4 4 13 D 22 M 31 V 5 0 0 9 9 18 I 27エンコーディング14 E 23 N 6 6 15 F 24 O（パッド）= 7 7 16 G 25 P 8 8 17 H 26 Q
The following description is original but analogous to previous descriptions. Essentially, Base 16 encoding is the standard case-insensitive hex encoding and may be referred to as "base16" or "hex".
以下の説明では、元のが、前の記述に類似しています。本質的に、ベース16符号化は、標準的な大文字小文字を区別しない進符号化であり、「base16」又は「進」と呼ぶことができます。
A 16-character subset of US-ASCII is used, enabling 4 bits to be represented per printable character.
US-ASCIIの16文字のサブセットは、印刷可能な文字ごとに表現する4ビットを有効に使用されます。
The encoding process represents 8-bit groups (octets) of input bits as output strings of 2 encoded characters. Proceeding from left to right, an 8-bit input is taken from the input data. These 8 bits are then treated as 2 concatenated 4-bit groups, each of which is translated into a single character in the base 16 alphabet.
符号化プロセスは、2つのエンコードされた文字の出力列として入力ビットの8ビットのグループ（オクテット）を表します。左から右に進むと、8ビットの入力は、入力データから取られます。これらの8ビットは、ベース16アルファベットの単一文字に変換されそれぞれが2連結4ビットのグループとして扱われます。
Each 4-bit group is used as an index into an array of 16 printable characters. The character referenced by the index is placed in the output string.
各4ビットのグループは、16印刷可能文字の配列へのインデックスとして使用されます。インデックスで参照される文字は、出力文字列に配置されます。
Table 5: The Base 16 Alphabet
表5：ベース16アルファベット
Value Encoding Value Encoding Value Encoding Value Encoding 0 0 4 4 8 8 12 C 1 1 5 5 9 9 13 D 2 2 6 6 10 A 14 E 3 3 7 7 11 B 15 F
値エンコーディング値エンコーディング値エンコーディング値3 3 7 7 11 B 15 F 2 2 6 6 10 14 E D 1 1 5 10 10 13 C 0 0 4 4 8 8 12エンコーディング
Unlike base 32 and base 64, no special padding is necessary since a full code word is always available.
完全なコードワードが常に利用可能であるので、ベース32とベース64とは異なり、特別なパディングは不要です。
To translate between binary and a base encoding, the input is stored in a structure, and the output is extracted. The case for base 64 is displayed in the following figure, borrowed from [5].
バイナリベースのエンコーディングの間で翻訳するために、入力は、構造体に格納され、出力が取り出されます。基部64のためのケースから借用し、次の図に表示されている[5]。
+--first octet--+-second octet--+--third octet--+
|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
+-----------+---+-------+-------+---+-----------+
|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
+--1.index--+--2.index--+--3.index--+--4.index--+
The case for base 32 is shown in the following figure, borrowed from [7]. Each successive character in a base-32 value represents 5 successive bits of the underlying octet sequence. Thus, each group of 8 characters represents a sequence of 5 octets (40 bits).
基部32のためのケースから借用し、次の図に示されている[7]。ベース32値で連続する各文字は、基礎となるオクテット配列の5つの連続ビットを表します。このように、8つの文字の各グループは、5つのオクテット（40ビット）の配列を表します。
1 2 3
01234567 89012345 67890123 45678901 23456789
+--------+--------+--------+--------+--------+
|< 1 >< 2| >< 3 ><|.4 >< 5.|>< 6 ><.|7 >< 8 >|
+--------+--------+--------+--------+--------+
<===> 8th character
<====> 7th character
<===> 6th character
<====> 5th character
<====> 4th character
<===> 3rd character
<====> 2nd character
<===> 1st character
The following example of Base64 data is from [5], with corrections.
Base64でデータの次の例では、修正して、[5]です。
Input data: 0x14fb9c03d97e Hex: 1 4 f b 9 c | 0 3 d 9 7 e 8-bit: 00010100 11111011 10011100 | 00000011 11011001 01111110 6-bit: 000101 001111 101110 011100 | 000000 111101 100101 111110 Decimal: 5 15 46 28 0 61 37 62 Output: F P u c A 9 l +
入力データ：0x14fb9c03d97e六角：1つの4 F bの9個のC | 0 3 D 9 7 E 8ビット：00010100 11111011 10011100 | 00000011 11011001 01111110 6ビット：000101 001111 101110 011100 | 000000 111101 100101 111110進数：5 15 46 28 0 61 37 62出力：9のL + C F PのU
Input data: 0x14fb9c03d9 Hex: 1 4 f b 9 c | 0 3 d 9 8-bit: 00010100 11111011 10011100 | 00000011 11011001 pad with 00 6-bit: 000101 001111 101110 011100 | 000000 111101 100100 Decimal: 5 15 46 28 0 61 36 pad with = Output: F P u c A 9 k =
入力データ：0x14fb9c03d9六角：1つの4 F bの9個のC | 0 3 D 9 8ビット：00010100 11111011 10011100 | 00 6ビットで00000011 11011001パッド：000101 001111 101110 011100 | 000000 111101 100100進：=出力と5 15 46 28 0 61 36パッド：9 K C F PのU =
Input data: 0x14fb9c03 Hex: 1 4 f b 9 c | 0 3 8-bit: 00010100 11111011 10011100 | 00000011 pad with 0000 6-bit: 000101 001111 101110 011100 | 000000 110000 Decimal: 5 15 46 28 0 48 pad with = = Output: F P u c A w = =
入力データ：0x14fb9c03六角：1つの4 F bの9 C | 0 3 8ビット：00010100 11111011 10011100 | 0000 6ビットで00000011パッド：000101 001111 101110 011100 | 000000 110000進数：5 15 46 28 0 48 = =出力とパッド：F P U C A = W =
BASE64("") = ""
Base64で（ ""）= ""
BASE64("f") = "Zg=="
BASE64（ "F"）= "ZG =="
BASE64("fo") = "Zm8="
BASE64（ "FO"）= "Zm8 ="
BASE64("foo") = "Zm9v"
BASE64（ "foo" という）= "Zm9v"
BASE64("foob") = "Zm9vYg=="
BASE64（ "被告"）= "Zm9vYg =="
BASE64("fooba") = "Zm9vYmE="
BASE64（ "foova"）= "= ZmyavYtE"
BASE64("foobar") = "Zm9vYmFy"
BASE64（ "foobarに"）= "Zm9vYmFy"
BASE32("") = ""
Basaa（ ""）= ""
BASE32("f") = "MY======"
BASE32（ "F"）= "MY ======"
BASE32("fo") = "MZXQ===="
BASE32（ "FO"）= "MZXQ ===="
BASE32("foo") = "MZXW6==="
BASE32（ "foo" という）= "MZXW6 ==="
BASE32("foob") = "MZXW6YQ="
BASE32（ "被告"）= "MZXW6YQ ="
BASE32("fooba") = "MZXW6YTB"
BASE32（ "fooba"）= "MZXW6YTB"
BASE32("foobar") = "MZXW6YTBOI======"
BASE32（ "foobarに"）= "MZXW6YTBOI ======"
BASE32-HEX("") = ""
BASE32-HEX（ ""）= ""
BASE32-HEX("f") = "CO======"
"====== CO" BASE32-HEX（ "F"）=
BASE32-HEX("fo") = "CPNG===="
BASE32-HEX（ "FO"）= "CPNG ===="
BASE32-HEX("foo") = "CPNMU==="
BASE32-HEX（ "foo" という）= "CPNMU ==="
BASE32-HEX("foob") = "CPNMUOG="
BASE32-ヘックス（ "被告"）= "CPNMUOG ="
BASE32-HEX("fooba") = "CPNMUOJ1"
BASE32-HEX（ "fooba"）= "CPNMUOJ1"
BASE32-HEX("foobar") = "CPNMUOJ1E8======"
BASE32-HEX（ "foobarに"）= "CPNMUOJ1E8 ======"
BASE16("") = ""
BASE16（ ""）= ""
BASE16("f") = "66"
BASE16（ "F"）= "66"
BASE16("fo") = "666F"
BASE16（ "FO"）= "666F"
BASE16("foo") = "666F6F"
BASE16（ "foo" という）= "666F6F"
BASE16("foob") = "666F6F62"
BASE16（ "被告"）= "666F6F62"
BASE16("fooba") = "666F6F6261"
BASE16（ "fooba"）= "666F6F6261"
BASE16("foobar") = "666F6F626172"
BASE16（ "foobarに"）= "666F6F626172"
An ISO C99 implementation of Base64 encoding and decoding that is believed to follow all recommendations in this RFC is available from:
このRFCのすべての勧告に従うと考えられているBase64でエンコードおよびデコードのISO C99の実装は、から入手できます。
http://josefsson.org/base-encoding/
ｈっｔｐ：／／じょせｆっそん。おｒｇ／ばせーえんこぢんｇ／
This code is not normative.
このコードは、規範的ではありません。
The code could not be included in this RFC for procedural reasons (RFC 3978 section 5.4).
コードは、手続きの理由（RFC 3978のセクション5.4）のために、このRFCに含めることができませんでした。
When base encoding and decoding is implemented, care should be taken not to introduce vulnerabilities to buffer overflow attacks, or other attacks on the implementation. A decoder should not break on invalid input including, e.g., embedded NUL characters (ASCII 0).
ベース符号化及び復号化が実装されている場合、注意がオーバーフロー攻撃、または実装上の他の攻撃をバッファリングする脆弱性を導入しないように注意すべきです。デコーダは、例えば、埋め込まれたNUL文字（ASCII 0）を含む無効な入力に壊れてはなりません。
If non-alphabet characters are ignored, instead of causing rejection of the entire encoding (as recommended), a covert channel that can be used to "leak" information is made possible. The ignored characters could also be used for other nefarious purposes, such as to avoid a string equality comparison or to trigger implementation bugs. The implications of ignoring non-alphabet characters should be understood in applications that do not follow the recommended practice. Similarly, when the base 16 and base 32 alphabets are handled case insensitively, alteration of case can be used to leak information or make string equality comparisons fail.
非アルファベット文字は、代わりに（推奨されるように）全体の符号化の拒絶を引き起こすのに無視されている場合、使用することができる隠れチャネルは、「リーク」情報が可能となることができます。無視された文字は、文字列の等価比較を避けるために、または実装のバグをトリガするなど、他の極悪非道な目的のために使用することができます。非アルファベット文字を無視した場合の影響は、お勧めに従わないアプリケーションでは理解されるべきです。ベース16とベース32アルファベットは鈍感ケースを取り扱われる場合も同様に、ケースの変更は、情報を漏洩または文字列等価比較が失敗するために使用することができます。
When padding is used, there are some non-significant bits that warrant security concerns, as they may be abused to leak information or used to bypass string equality comparisons or to trigger implementation problems.
詰め物が使用されている場合、彼らは情報をリークし虐待したり、文字列の等価比較をバイパスするか、実装上の問題をトリガするために使用することができるよう、セキュリティ上の懸念を正当いくつかの非上位ビットがあります。
Base encoding visually hides otherwise easily recognized information, such as passwords, but does not provide any computational confidentiality. This has been known to cause security incidents when, e.g., a user reports details of a network protocol exchange (perhaps to illustrate some other problem) and accidentally reveals the password because she is unaware that the base encoding does not protect the password.
ベースエンコーディングは、視覚的にパスワードなどのそれ以外の場合は容易に認識情報を、非表示になりますが、任意の計算機密性を提供していません。これは、例えば、ユーザがネットワークプロトコル交換の詳細を報告します（おそらく他のいくつかの問題を説明するため）と、彼女はベースエンコーディングは、パスワードを保護していないことを認識していないため、誤ったパスワードを明らかにしたときに、セキュリティインシデントを引き起こすことが知られています。
Base encoding adds no entropy to the plaintext, but it does increase the amount of plaintext available and provide a signature for cryptanalysis in the form of a characteristic probability distribution.
ベース符号化は、平文へのエントロピーを追加していないが、それは、利用可能な平文の量を増加させ、特性の確率分布の形で暗号解読のための署名を提供しません。
Added the "base32 extended hex alphabet", needed to preserve sort order of encoded data.
符号化データのソート順序を維持するために必要な「base32延長進アルファベット」を、追加しました。
Referenced IMAP for the special Base64 encoding used there.
そこに使用される特殊なBase64エンコーディングのために参照IMAP。
Fixed the example copied from RFC 2440.
RFC 2440からコピーした例を修正しました。
Added security consideration about providing a signature for cryptoanalysis.
暗号解読のための署名を提供するに関するセキュリティ上の考慮事項を追加しました。
Added test vectors.
追加しましたテストベクトル。
Fixed typos.
固定タイプミス。
Several people offered comments and/or suggestions, including John E. Hadstate, Tony Hansen, Gordon Mohr, John Myers, Chris Newman, and Andrew Sieber. Text used in this document are based on earlier RFCs describing specific uses of various base encodings. The author acknowledges the RSA Laboratories for supporting the work that led to this document.
いくつかの人々はジョン・E. Hadstate、トニー・ハンセン、ゴードン・モーア、ジョン・マイヤーズ、クリス・ニューマン、そしてアンドリュー・シーバーを含め、コメントおよび/または提案を提供しました。本書で使用されるテキストは、様々なベースエンコーディングの特定の用途を説明する以前のRFCに基づいています。著者は、この文書につながった仕事をサポートするためのRSA研究所を認めています。
This revised version is based in parts on comments and/or suggestions made by Roy Arends, Eric Blake, Brian E Carpenter, Elwyn Davies, Bill Fenner, Sam Hartman, Ted Hardie, Per Hygum, Jelte Jansen, Clement Kent, Tero Kivinen, Paul Kwiatkowski, and Ben Laurie.
この改訂版は、ロイ・アレンズ、エリック・ブレイク、ブライアン・E・カーペンター、エルウィン・デイヴィス、ビルフェナー、サム・ハートマン、テッドハーディー、パーHygum、Jelteヤンセン、クレメントケント、TERO Kivinen、ポールによって行われたコメントおよび/または提案の一部に基づいていますKwiatkowski、そしてベン・ローリー。
Copyright (c) 2000-2006 Simon Josefsson
著作権（C）2000から2006サイモンJosefsson氏
Regarding the abstract and sections 1, 3, 8, 10, 12, 13, and 14 of this document, that were written by Simon Josefsson ("the author", for the remainder of this section), the author makes no guarantees and is not responsible for any damage resulting from its use. The author grants irrevocable permission to anyone to use, modify, and distribute it in any way that does not diminish the rights of anyone else to use, modify, and distribute it, provided that redistributed derivative works do not contain misleading author or version information and do not falsely purport to be IETF RFC documents. Derivative works need not be licensed under similar terms.
（このセクションの残りは、「著者」、）サイモンJosefsson氏によって書かれたこの文書の要約とセクション1、3、8、10、12、13、及び14に関して、著者は保証しませんし、ありますその使用から生じるいかなる損害についても責任を負いません。派生作品は誤解を招く作者やバージョン情報が含まれていません再配布提供、使用、変更、および、使用する他の誰の権利を減少変更し、それを配布していない任意の方法でそれを配布する人には、著者の補助金取消不能の許可、および誤ってIETF RFC文書であることを趣旨ではありません。派生作品は、同様の条件の下でライセンスされる必要はありません。
[1] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
[1]サーフ、V.、 "ネットワークの交換のためのASCIIフォーマット"、RFC 20、1969年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993.
[3]リン、J.、 "インターネット電子メールのためのプライバシー増進：パートI：メッセージの暗号化と認証手順"、RFC 1421、1993年2月。
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[4]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[5]カラス、J.、Donnerhacke、L.、フィニー、H.、およびR.セイヤー、 "OpenPGPのメッセージフォーマット"、RFC 2440、1998年11月。
[6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[6]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[7] Klyne, G. and L. Masinter, "Identifying Composite Media Features", RFC 2938, September 2000.
[7] Klyne、G.とL. Masinterは、RFC 2938、2000年9月 "複合メディア機能の識別します"。
[8] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[8]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[9]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[10] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNSSEC Hash Authenticated Denial of Existence", Work in Progress, June 2006.
[10]ローリー、B.、シッソン、G.、アレンズ、R.、およびD. Blacka、 "存在のDNSSECハッシュ認証拒否"、進歩、2006年6月での作業。
[11] Myers, J., "SASL GSSAPI mechanisms", Work in Progress, May 2000.
[11]マイヤーズ、J.、 "SASL GSSAPIメカニズム"、進歩、2000年5月に働いています。
[12] Wilcox-O'Hearn, B., "Post to P2P-hackers mailing list", http://zgp.org/pipermail/p2p-hackers/2001-September/ 000315.html, September 2001.
[12]ウィルコックス・O'Hearn、B.、 "P2P-ハッカーメーリングリストへのポスト"、http://zgp.org/pipermail/p2p-hackers/2001-September/ 000315.html、2001年9月。
Author's Address
著者のアドレス
Simon Josefsson SJD EMail: simon@josefsson.org
サイモンJosefsson氏SJD Eメール：simon@josefsson.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。