[要約] RFC 3548は、Base16、Base32、およびBase64のデータエンコーディングに関する仕様を提供しています。このRFCの目的は、データの安全な転送や保存を容易にするために、効率的で一般的に使用されるエンコーディング手法を定義することです。
Network Working Group S. Josefsson, Ed.
Request for Comments: 3548 July 2003
Category: Informational
The Base16, Base32, and Base64 Data Encodings
base16、base32、およびbase64データエンコーディング
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.
Copyright（c）The Internet Society（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.
データのベースエンコーディングは、多くの状況で使用され、おそらくレガシーの理由で、米国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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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は「ベース64」自体を定義するのではなく、MIME内で使用するための「ベース64コンテンツ移動エンコード」を定義します。そのため、MIMEは、ベース64エンコードされたデータのライン長に76文字に制限を強制します。MIMEは、PEM [2]からのエンコーディングを継承します。これは「実質的に同一」であると述べていますが、PEMは64文字のラインの長さを使用します。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」と同様に簡単に交換されます。下のbase32アルファベットでは、0（ゼロ）と1（1）が存在しない場合、デコーダーは0をOとして、1はケースに依存してIまたはLとして解釈できます。（ただし、デフォルトでは、前のセクションを参照してください。）
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 識別子として使用されます。特定の文字、特に ""および "/" Base 64 Alphabetは、レガシーテキスト検索/インデックスツールによって単語の破壊として扱われます。
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ビットは、4つの連結6ビットグループとして扱われ、それぞれがベース64アルファベットの1桁に変換されます。
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
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ビットの積分倍数です。ここでは、エンコードされた出力の最終単位は、「=」パディングなしの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ビットです。ここで、エンコードされた出力の最終単位は3文字に続いて1つの「=」パディング文字が続きます。
The Base 64 encoding with an URL and filename safe alphabet has been used in [8].
[8]では、URLとファイル名のセーフアルファベットを使用したベース64エンコードが使用されています。
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.
このエンコードは、表2に示すように、62：NDおよび63：RDアルファベット文字を除き、技術的に以前のエンコードと同一です。
Table 2: The "URL and Filename safe" Base 64 Alphabet
表2：「URLおよびFILENAME SAFE」ベース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
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ビットは、8つの連結5ビットグループとして扱われ、それぞれがベース32アルファベットの1桁に変換されます。ベース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
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ビットの積分倍数です。ここでは、エンコードされた出力の最終単位は、「=」パディングなしの8文字の積分倍数になります。（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, or
(4) エンコーディング入力の最後の量は正確に24ビットです。ここで、エンコードされた出力の最終単位は5文字に続いて3つの「=」パディング文字、または
(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ビットです。ここで、エンコードされた出力の最終単位は7文字に続いて、1つの「=」パディング文字が続きます。
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」または「hex」と呼ばれる場合があります。
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ビットは、2つの連結された4ビットグループとして扱われ、それぞれがベース16アルファベットの1桁に変換されます。
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
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 +
入力データ：0x14FB9C03D97E HEX：1 4 F B 9 C |0 3 d 9 7 E 8ビット：00010100 11111011 10011100 |00000011 11011001 11111110 6ビット：000101 001111101110 011100 |000000 111101 100111 111110 10進：5 15 46 28 0 61 37 62出力：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 |00000011 11011001 00 6ビット付きパッド：000101 001111101110 011100 |000000 111101 100100 10進数：5 15 46 28 0 61 36パッド=出力：F P U C A 9 K =
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 = =
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993.
[2] Linn、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] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[4] Callas、J.、Donnerhacke、L.、Finney、H。and R. Thayer、「OpenPGPメッセージ形式」、RFC 2440、1998年11月。
[5] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[5] EastLake、D。、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。
[6] Klyne, G. and L. Masinter, "Identifying Composite Media Features", RFC 2938, September 2000.
[6] Klyne、G。and L. Masinter、「Composite Media機能の識別」、RFC 2938、2000年9月。
[7] Myers, J., "SASL GSSAPI mechanisms", Work in Progress.
[7] マイヤーズ、J。、「SASL GSSAPIメカニズム」、進行中の作業。
[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] Wilcox-o'hearn、B。、「P2P-Hackersメーリングリストへの投稿」、World Wide Web 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] Cerf、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メール：simon@josefsson.org
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。