Network Working Group S. Josefsson, Ed.
Request for Comments: 3548 July 2003
Category: Informational
The Base16, Base32, and Base64 Data Encodings
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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, and use of different encoding alphabets.
この文書は、一般的に使用されるベース64、ベース32、ベース16符号化方式を記載しています。また、符号化データ、符号化データにパディングを使用する、符号化データ中の非アルファベット文字の使用、および異なる符号化アルファベットの使用でラインフィードの使用を論じています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Implementation discrepancies . . . . . . . . . . . . . . . . . 2
2.1. Line feeds in encoded data . . . . . . . . . . . . . . . 2
2.2. Padding of encoded data . . . . . . . . . . . . . . . . 3
2.3. Interpretation of non-alphabet characters in encoded
data . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4. Choosing the alphabet . . . . . . . . . . . . . . . . . 3
3. Base 64 Encoding . . . . . . . . . . . . . . . . . . . . . . . 4
4. Base 64 Encoding with URL and Filename Safe Alphabet . . . . . 6
5. Base 32 Encoding . . . . . . . . . . . . . . . . . . . . . . . 6
6. Base 16 Encoding . . . . . . . . . . . . . . . . . . . . . . . 8
7. Illustrations and examples . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
11. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 12
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
Base encoding of data is used in many situations to store or transfer data in environments that, perhaps for legacy reasons, are restricted to only US-ASCII [9] 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 [9]のデータに制限され、環境にデータを格納または転送するために、多くの状況で使用されています。ベースエンコーディングは、テキストエディタでオブジェクトを操作することが可能になるという理由だけで、従来の制限はありません新しいアプリケーションでも使用することができます。
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. MIME [3] 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 [3]は、多くの場合、行の折り返しや非アルファベット文字の影響を考慮せずに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 RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
Here we discuss the discrepancies between base encoding implementations in the past, and where appropriate, mandate a specific recommended behavior for the future.
ここでは、過去にベースエンコーディング実装間の矛盾を議論し、適切な場合には、将来のための具体的な推奨行動を義務付けます。
MIME [3] 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 PEM [2] stating 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 [3]は、多くの場合、ベース64符号化のための基準として使用されます。しかし、MIMEは、MIME内で使用するための「ベース64」自体ではなく、「ベース64コンテンツ転送エンコード」を定義していません。このように、MIMEは、76文字までベース64符号化されたデータの行の長さに制限を強制します。 MIMEは、しかし、PEMは、64文字の行の長さを使用し、それは「実質的に同一」である旨PEM [2]からエンコーディングを継承します。 MIMEとPEMの制限は、両方のSMTP内の限界によるものです。
Implementations MUST NOT 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 nor used. In the general case, when assumptions on 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.
この文書を参照する仕様が明示的に述べない限り、実装は、符号化データの終了時に適切なパッドの文字を含まなければなりません。
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 encoding 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, as MIME does, instead state 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 CRLF constitute "non alphabet characters" and are ignored. Furthermore, such specifications may consider the pad character, "=", as not part of the base alphabet until the end of the string. If more than the allowed number of pad characters are found at the end of the string, e.g., a base 64 string terminated with "===", the excess pad characters could 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. Characters "0", "O" are easily interchanged, as well "1", "l" and "I". In the base32 alphabet below, where 0 (zero) and 1 (one) is 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.)
O人間で扱います。文字 "0"、 "O" 容易も、交換される "1"、 "L" および "I"。 0（ゼロ）と1（1）は存在しない以下アルファベットbase32において、デコーダは、I又はLは場合に応じて、Oとして0、及び1を解釈することができます。 （ただし、デフォルトでは、前のセクションは表示されません。）
o Encoded into structures that place 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. In this document, we document and name some currently used alphabets.
すべての要件を満たし全く普遍的に受け入れアルファベットはありません。この文書では、我々は文書化し、いくつかの現在使用されてアルファベットを名前を付けます。
The following description of base 64 is due to [2], [3], [4] and [5].
ベース64の以下の説明は、によるものである[2]、[3]、[4]、[5]。
The Base 64 encoding is designed to represent arbitrary sequences of octets in a form that requires case sensitivity but need not be humanly 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 digit 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, zero bits 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, or
（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 [8].
URLとファイル名安全なアルファベットとベース64符号化は、[8]に使用されてきました。
An alternative alphabet has been suggested that used "~" as the 63rd character. Since the "~" character has special meaning in some file system environments, the encoding described in this section is recommended instead.
代替アルファベットは63番目の文字として「〜」を使用することが示唆されています。 「〜」の文字がいくつかのファイルシステム環境では特別な意味を持っているので、このセクションで説明するエンコーディングが代わりにお勧めします。
This encoding should not be regarded as the same as the "base64" encoding, and should not be referred to as only "base64". Unless made clear, "base64" refer to the base 64 in the previous section.
この符号化は、「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.
ND 63：RDアルファベット文字、表2に示すように、この符号化は62を除いて、以前のものと技術的に同一です。
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 _ (understrike) 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 63 _（understrike）13 N 30（パッド）= 15 P 32グラム49 X 16 Q 33 H 50 Y、W 48 F E 47、V 14 O 31
The following description of base 32 is due to [7] (with corrections).
ベース32の以下の説明は、[7]（訂正を伴う）に起因するものです。
The Base 32 encoding is designed to represent arbitrary sequences of octets in a form that needs to be case insensitive but need not be humanly 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 digit in the base 32 alphabet. When encoding a bit stream 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, and 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 2, below, are selected from US-ASCII digits and uppercase letters.
各5ビット群は、32印刷可能文字の配列へのインデックスとして使用されます。インデックスで参照される文字は、出力文字列に配置されます。表2で特定これらの文字は、以下の、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, zero bits 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, (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,
（1）入力をコードする最終量子は、40ビットの整数倍です。ここで、符号化された出力の最終のユニット（2）符号化入力の最終量子が正確に8ビットであり、NO「=」パディング8つの文字の整数倍であろう。ここで、符号化された出力の最終的な単位は、6「=」パディング文字に続く2つの文字となり、
(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, or
（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 is original but analogous to previous descriptions. Essentially, Base 16 encoding is the standard 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, a 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 digit 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 [4].
バイナリベースのエンコーディングの間で翻訳するために、入力は、構造体に格納され、出力が抽出されます。基部64のためのケースから借用し、次の図に表示されている[4]。
+--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 [6]. 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のためのケースから借用し、次の図に示されている[6]。ベース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 [4].
Base64でデータの次の例では、[4]です。
Input data: 0x14fb9c03d97e
Hex: 1 4 f b 9 c | 0 3 d 9 7 e
8-bit: 00010100 11111011 10011100 | 00000011 11011001
11111110
6-bit: 000101 001111 101110 011100 | 000000 111101 100111
111110
Decimal: 5 15 46 28 0 61 37 62
Output: F P u c A 9 l +
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 =
When implementing Base encoding and decoding, 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 implications of this 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.
非アルファベット文字は、代わりに（推奨されるように）全体の符号化の拒絶を引き起こすのに無視されている場合、使用することができる隠れチャネルは、「リーク」情報が可能となることができます。これの意味はお勧めに従わないアプリケーションでは理解されるべきです。ベース16とベース32アルファベットは鈍感ケースを取り扱われる場合も同様に、ケースの変更は、情報を漏洩するのに使用することができます。
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.
ベースエンコーディングは、視覚的にパスワードなどのそれ以外の場合は容易に認識情報を、非表示になりますが、任意の計算機密性を提供していません。これは、例えば、ユーザがネットワークプロトコル交換の詳細を報告します（おそらく他のいくつかの問題を説明するため）と、彼女はベースエンコーディングは、パスワードを保護していないことを認識していないため、誤ったパスワードを明らかにしたときに、セキュリティインシデントを引き起こすことが知られています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993.
[2]リン、J.、 "インターネット電子メールのためのプライバシー増進：パートI：メッセージの暗号化と認証手順"、RFC 1421、1993年2月。
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[3]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[4]カラス、J.、Donnerhacke、L.、フィニー、H.及びR.セイヤー、 "OpenPGPのメッセージフォーマット"、RFC 2440、1998年11月。
[5] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[5]イーストレイク、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。
[6] Klyne, G. and L. Masinter, "Identifying Composite Media Features", RFC 2938, September 2000.
[6] Klyne、G.とL. Masinterは、RFC 2938、2000年9月 "複合メディア機能の識別します"。
[7] Myers, J., "SASL GSSAPI mechanisms", Work in Progress.
[7]マイヤーズ、J.、 "SASL GSSAPIメカニズム"、ProgressのWork。
[8] Wilcox-O'Hearn, B., "Post to P2P-hackers mailing list", World Wide Web http://zgp.org/pipermail/p2p-hackers/2001- September/000315.html, September 2001.
[8]ウィルコックス・O'Hearn、B.、 "P2P-ハッカーメーリングリストへのポスト"、ワールド・ワイド・ウェブhttp://zgp.org/pipermail/p2p-hackers/2001- 9月/ 000315.html、2001年9月。
[9] Cerf, V., "ASCII format for Network Interchange", RFC 20, October 1969.
[9]サーフ、V.、 "ネットワークの交換のためのASCIIフォーマット"、RFC 20、1969年10月。
Several people offered comments and suggestions, including Tony Hansen, Gordon Mohr, John Myers, Chris Newman, and Andrew Sieber. Text used in this document is 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.
いくつかの人々はトニーハンセン、ゴードン・モーア、ジョン・マイヤーズ、クリス・ニューマン、そしてアンドリュー・シーバーを含め、コメントや提案を提供しました。本書で使用されるテキストは、種々のベースエンコーディングの特定の用途を説明する以前のRFCに基づいています。著者は、この文書につながった仕事をサポートするためのRSA研究所を認めています。
Simon Josefsson EMail: simon@josefsson.org
Simon Josefsson氏のEメール：simon@josefsson.org
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。