この文書はRFC 4648の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
この文書はインターネット共同体のためのインターネット標準化中のプロト
コルを指定し、そして改良のために議論と提案を求めます。このプロトコル
と標準化状態と状況は「インターネット公式プロトコル標準」（ＳＴＤ１）
の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (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.
この文書は共通に使用するベース６４とベース３２とベース１６符号化を
記述します。また符号化されたデータでの改行の使用と、符号化されたデー
タでのパディングの使用と、符号化されたデータでの非アルファベットの
文字の使用と、異なった符号化アルファベットの使用と正規符号を論じます。
Table of Contents
目次
1. Introduction
1. はじめに
2. Conventions Used in This Document
2. この文書で使われる取り決め
3. Implementation Discrepancies
3. 実装の相違
3.1. Line Feeds in Encoded Data
3.1. 符号化データ内の改行
3.2. Padding of Encoded Data
3.2. 符号化されたデータ穴埋め
3.3. Interpretation of Non-Alphabet Characters in Encoded Data
3.3. 符号化されたデータでの非アルファベットの文字の解釈
3.4. Choosing the Alphabet
3.4. アルファベットの選択
3.5. Canonical Encoding
3.5. 正規符号化
4. Base 64 Encoding
4. べース６４符号化
5. Base 64 Encoding with URL and Filename Safe Alphabet
5. ＵＲＬとファイル名で安全なアルファベットのベース６４符号化
6. Base 32 Encoding
6. ベース３２符号化
7. Base 32 Encoding with Extended Hex Alphabet
7. 拡張１６進法アルファベットでのベース３２符号化
8. Base 16 Encoding
8. ベース１６符号化
9. Illustrations and Examples
9. イラストと例
10. Test Vectors
10. 試験ベクトル
11. ISO C99 Implementation of Base64
11. ベース６４のISO C99実装
12. Security Considerations
12. セキュリティの考察
13. Changes Since RFC 3548
13. ＲＦＣ３５４８からの変更
14. Acknowledgements
14. 謝辞
15. Copying Conditions
15. 著作状態
16. References
16. 参考文献
16.1. Normative References
16.1. 参照する参考文献
16.2. Informative References
16.2. 有益な参考文献
1. Introduction
1. はじめに
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.
データのベース符号化は、多分旧式であるため、ＵＳ−ＡＳＣＩＩ[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"を使います。多目的インターネットメール拡張（ＭＩＭＥ）
[4]は、しばしば、行のラッピングや非アルファベットの文字に関する結果
を考えずに、ベース６４の非参考文献として使われます。この仕様書の目
的は共通のアルファベットと符号化の考えを確立することです。これが、
他の文書のあいまい性を減らし、良い互換性を導く事を希望します。
2. Conventions Used in This Document
2. この文書で使われる取り決め
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"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は[2]
で記述されるように解釈されます。
3. Implementation Discrepancies
3. 実装の相違
Here we discuss the discrepancies between base encoding
implementations in the past and, where appropriate, mandate a
specific recommended behavior for the future.
ここで我々は過去におけるベース符号化実装の間の矛盾を論じ、そし
て適切な場合は、将来のために特定の推薦された行動を義務化します。
3.1. Line Feeds in Encoded Data
3.1. 符号化データ内の改行
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.
ＭＩＭＥ[4]はしばしばベース６４符号化の参考文献として使われます。
しかしながら、ＭＩＭＥは本質的に「ベース６４」を定義せず、どちらか
と言うとＭＩＭＥ内で使用するための「ベース６４コンテンツ転送符号化」
を定義します。そして、ＭＩＭＥはベース６４で符号化されたデータの行
の長さを７６文字に制限します。ＭＩＭＥは「事実上同一」と述べて、プ
ライバ拡張メール（ＰＥＭ）[3]の符号化を継承します；しかしながら、
ＰＥＭが６４文字の行長を使います。ＭＩＭＥとＰＥＭの制限は共に
ＳＭＴＰの制限のためです。
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.
この文書を参照している仕様書が明示的に特定の文字数の後に改行を加える
ようにベース符号化機に指示しないなら、実装がベース符号化されたデー
タに改行を加えてはなりません(MUST NOT)。
3.2. Padding of Encoded Data
3.2. 符号化されたデータ穴埋め
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.
この文書を参照する仕様書が明示的に他のことを言う場合を除き、実装は
符号化されたデータの終わりに適切な穴埋め文字を含めなくてはなりませ
ん(MUST)。
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.
下の４章と６章で記述されるように、ベース６４とベース３２アルファベッ
トは穴埋めを使います、しかしベース１６アルファベットはそれを必要と
しません；８章を参照してください。
3.3. Interpretation of Non-Alphabet Characters in Encoded Data
3.3. 符号化されたデータでの非アルファベットの文字の解釈
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.
この文書を参照する仕様書が明示的に他のことを述べない限り、実装はベー
ス符号化データを翻訳する時に、ベースアルファベット以外の文字を含んで
いるデータの、解読を拒絶してなければなりません(MUST)。このような指定
は、ＭＩＭＥの様に、ベース符号化アルファベット以外の文字はデータを翻
訳する時に無視されるべきと述べるかもしれません（「受信に関して寛容」）。
これは隣接したキャリッジ・リターン/ラインフィード（CRLF）文字が「非
アルファベット文字」を形成し、無視されることを意味する事に注意してく
ださい。さらに、このような指定は文字列の終り以外のパディング文字「=」
を非アルファベットのデータとして扱い無視するかもしれません(MAY)。もし
パッド文字に許された数より多くのパッド文字が文字列の終わりにあるとき
（例えばベース６４文字列が「===」で終わるなら）、余分のパッド文字が無
視されるかもしれません(MAY)。
3.4. Choosing the Alphabet
3.4. アルファベットの選択
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.)
人による処理。文字「０」と「Ｏ」がすぐ読み間違えされ、「１」と
「ｌ」と「Ｉ」も同様です。下記のベース３２アルファベットで、０
（ゼロ）と１（壱）が存在ぜず、復号機が０をOに、１を場合によって
ＩかＬと解釈するかもしれません。（しかしながら、デフォルトでそう
するべきではありません、前の章を見てください。）
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 Used as identifiers. Certain characters, notably "+" and "/" in
the base 64 alphabet, are treated as word-breaks by legacy text
search/index tools.
識別子として用いる。ある特定の文字、特にベース６４のアルファベッ
トで「+」と「/」が、旧式なテキスト捜索／インデックスツールで単語
の区切りとして扱われます。
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.
すべての必要条件を満たす広く一般に受け入れられたアルファベットがあり
ません。かなり専門化した方言の例としてＩＭＡＰ[8]を参照してください。
この文書で、我々はある現在使われたアルファベットを文書化し、命名します。
3.5. Canonical Encoding
3.5. 正規符号化
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.
ベース６４とベース３２符号化での穴埋め手順が、もし不適当に実装され
るなら、符号化データの無用な変更を発生させます。例えば、もしベース
６４符号化の入力がたった１オクテットであるなら、最初の記号のすべて
の６ビットは使われますが、次の記号は最初の２ビットだけが使われます。
これらの穴埋め部分は準拠する符号化機ではゼロが設定されなくてはなり
ません(MUST)、これは下記の詰め物の記述で記述されます。もしこの特性
が維持されないなら、ベース符号化されたデータに非正規形があり、複数
のベース符号化文字列が同じバイナリデータに解読されるできる事になり
ます。もしこの特性（そしてこの文書で論じられた他の特性）が維持され
るなら正規符号化が保証されています。
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)。これを
示している仕様書は特定の行動を要請するかもしれません。
4. Base 64 Encoding
4. べース６４符号化
The following description of base 64 is derived from [3], [4], [5],
and [6]. This encoding may be referred to as "base64".
以下のベース６４の記述は[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.
ベース６４符号化は大文字と小文字の両方を許すが人が読むことを必要と
されない任意のオクテット列を表すよう意図されます。
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.)
ＵＳ−ＡＳＣＩＩのの内の６５文字が、６ビットを印刷可能な文字に表現す
るようにするために使われます。（余分の第６５番目の文字「=」は特別な
処理機能を意味するために使われます。）
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.
符号化処理は入力ビットの２４ビットのグループを、４つの符号化文字の
出力文字列とします。左から右へ処理し、３つの８ビットの入力グループ
を連結することによって、２４ビットの入力グループが形成されます。こ
れらの２４ビットは４つの連結された６ビットのグループとして扱われ、
そしてそれぞれはベース６４のアルファベットのひとつの文字に翻訳され
ます。
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.
それぞれの６ビットのグループが６４の印刷可能文字の配列のインデックス
として用いられます。インデックスで参照された文字は出力文字列に置かれ
ます。
Table 1: The Base 64 Alphabet
表１：ベース６４アルファベット
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, 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:
もし符号化するデータの終わりに２４ビット未満しかデータがないときに
特別な処理が行われます。完全な符号化は常に一定量の終わりで完了しま
す。入力グループで２４インプットビット未満しか利用可能でない時、ゼ
ロのビットが６の整数倍のビットグループを形成するために（右手に）足
されます。データの終わりの穴埋めは「=」を使って行われます。すべての
ベース６４の入力が整数個のオクテットなので、次の場合だけが生じます：
(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) 符号化入力の最終部分は２４ビットの倍数です；ここで、符号化され
た出力の終わりは、「=」なしの４の倍数個の文字であるでしょう。
(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) 符号化入力の最終部分は正確に８ビットです；ここで、符号化された
出力の終わりは、２文字とそれに続く２つの「=」文字であるでしょう。
(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) 符号化入力の最終部分は正確に１６ビットです；ここで、符号化され
た出力の終わりは、３文字とは続１つの「=」文字であるでしょう。
5. Base 64 Encoding with URL and Filename Safe Alphabet
5. ＵＲＬとファイル名で安全なアルファベットのベース６４符号化
The Base 64 encoding with an URL and filename safe alphabet has been
used in [12].
ＵＲＬとファイル名で安全なアルファベットのベース６４符号化は[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.
６３番目のアルファベットの代わりの文字として"~"を使うのが示唆され
ました。"~"文字があるファイルシステム環境で特別な意味を持つので、
この章で記述された符号化はその代わりとして勧められます。残りの予
約なしのＵＲＩ文字は"."ですが、あるファイルシステム環境で複数の"."
は許されず、"."文字も魅力的でありません。
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.
ＵＲＩ[9]で使われるとき、穴埋め文字"="は一般にパーセント符号化さ
れますが、もしデータ長が暗黙のうちにわかるなら、穴埋めをスキップす
ることによってこれを避けれます；３.２章を見て下さい。
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"が
前章のベース６４を意味します。
This encoding is technically identical to the previous one, except
for the 62:nd and 63:rd alphabet character, as indicated in Table 2.
この符号化は、６２番目と６３番目のアルファベット文字が表２で示さ
れたものである以外は、技術的に前のものとまったく同じです。
Table 2: The "URL and Filename safe" Base 64 Alphabet
表２：「ＵＲＬとファイル名で安全な」ベース６４アルファベット
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) =
6. Base 32 Encoding
6. ベース３２符号化
The following description of base 32 is derived from [11] (with
corrections). This encoding may be referred to as "base32".
ベース３２の次の記述は[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.
ベース３２の符号化は大文字小文字の違いを無視する必要がある形式で任
意のオクテット列を表すよう意図されます、しかし人間の力で読み取り可
能である必要がありません。
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.)
ＵＳ−ＡＳＣＩＩの３３文字が、５ビットを印刷可能な文字で表すために
使われます。（余分の第３３番目の文字、「=」、は特別な処理機能を意
味するために使われます。）
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.
符号化処理は入力ビットの４０ビットのグループを８つの符号化された出
力文字列として描きます。左から右に処理して、５つの８ビット入力を連
結することによって４０ビットの入力グループが形成されます。これらの
４０ビットはそれから８つの５ビットのグループの連結として扱われ、そ
してそれぞれはベース３２のアルファベットを使ってひとつの文字として
翻訳されます。ビット列がベース３２符号化によってを符号化される時、
ビット列は最初に上位桁ビットがある順序と推測されなくてはなりません。
すなわち、列の最初のビットは最初の８ビットバイトの最上位桁であるで
しょう、そして８番目のビットは最初の８ビットバイトの最下位ビットで
あるでしょう。
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.
それぞれの５ビットのグループが３２の印刷可能文字の配列のインデック
スとして用いられます。インデックスによって参照された文字は出力文字
列に置かれます。これらの文字は、下記の表３で指定され、ＵＳ−ＡＳＣ
ＩＩの数字と大文字から選ばれます。
Table 3: The Base 32 Alphabet
表３：ベース３２アルファベット
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, 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:
もし４０ビット以下が符号化されるデータの終わりにで４０ビット未満だ
けが利用可能であるなら、特別な処理が行われます。完全な符号化が常に
本体の終わりで完了します。４０ビット未満だけが入力グループで利用可
能である時、ゼロのビットが５ビットのグループを形成するために（右手
に）足されます。データの終わりの穴埋めは「=」文字を使って行われます。
すべてのベース３２の入力が整数個のオクテットで、ただ次の場合だけが
生じます：
(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) 符号化入力の最終部分は４０ビットの倍数です；ここで、符号化され
た出力の終わりは、「=」なしの８の倍数個の文字であるでしょう。
(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) 符号化入力の最終部分は正確に８ビットです；ここで、符号化された
出力の終わりは、２文字とそれに続く６つの「=」文字であるでしょ
う。
(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) 符号化入力の最終部分は正確に１６ビットです；ここで、符号化され
た出力の終わりは、４文字とそれに続く４つの「=」文字であるでしょ
う。
(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) 符号化入力の最終部分は正確に２４ビットです；ここで、符号化され
た出力の終わりは、５文字とそれに続く３つの「=」文字であるでしょ
う。
(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) 符号化入力の最終部分は正確に３２ビットです；ここで、符号化され
た出力の終わりは、７文字とそれに続く１つの「=」文字であるでしょ
う。
7. Base 32 Encoding with Extended Hex Alphabet
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].
ベース３２の次の記述は[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.
ベース６４とベース３２アルファベットに欠けている、このアルファベッ
トの１つの特性は、符号化データをビット単位で比較する時、符号化され
たデータがソート順序を維持するということです。
This encoding is identical to the previous one, except for the
alphabet. The new alphabet is found in Table 4.
この符号化は、アルファベット以外、前ののとまったく同じです。新しい
アルファベットは表４にあります。
Table 4: The "Extended Hex" Base 32 Alphabet
表４："Extended Hex"ベース３２アルファベット
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
8. Base 16 Encoding
8. ベース１６符号化
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".
次の記述はオリジナルですが、前の記述に類似しています。本質的に、ベー
ス１６の符号化が標準的な大文字小文字の違いを無視する１６進法の符号
化であり、そして「ベース１６」あるいは「１６進法」であると述べられ
るかもしれません。
A 16-character subset of US-ASCII is used, enabling 4 bits to be
represented per printable character.
ＵＳ−ＡＳＣＩＩの１６文字が、４ビットを印刷可能文字に表すために使
われます。
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.
符号化処理は入力ビットの８ビットのグループを２つの符号化された出力
文字列として描きます。左から右に処理して、８ビットの入力が入力デー
タからとられます。これらの８ビットは２つの連結された４ビットのグルー
プとして扱われ、そしてそれぞれはベース１６のアルファベットでひとつ
の文字に翻訳されます。
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.
それぞれの４ビットのグループが１６の印刷可能文字の配列のインデック
スとして用いられます。インデックスによって参照された文字は出力文字
列に置かれます。
Table 5: The Base 16 Alphabet
表５：ベース１６アルファベット
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.
ベース３２とベース６４と異なり、全ての符号が常に利用可能なので、特
別な詰め物が必要ありません。
9. Illustrations and Examples
9. イラストと例
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].
バイナリとベース符号化の間で翻訳するために、入力は構造体に保存され、
出力はは引き抜かれます。ベース６４の場合は[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).
ベース３２の場合は[7]から借用された次の図で示されます。それぞれのベー
ス３２値の連続した文字が、オクテット列の連続した５ビットを表します。
それで、それぞれの８つの文字のグループが５つのオクテット列（４０ビッ
ト）を表します。
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.
ベース６４データの次の例は[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 +
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 =
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 = =
10. Test Vectors
10. 試験ベクトル
BASE64("") = ""
BASE64("f") = "Zg=="
BASE64("fo") = "Zm8="
BASE64("foo") = "Zm9v"
BASE64("foob") = "Zm9vYg=="
BASE64("fooba") = "Zm9vYmE="
BASE64("foobar") = "Zm9vYmFy"
BASE32("") = ""
BASE32("f") = "MY======"
BASE32("fo") = "MZXQ===="
BASE32("foo") = "MZXW6==="
BASE32("foob") = "MZXW6YQ="
BASE32("fooba") = "MZXW6YTB"
BASE32("foobar") = "MZXW6YTBOI======"
BASE32-HEX("") = ""
BASE32-HEX("f") = "CO======"
BASE32-HEX("fo") = "CPNG===="
BASE32-HEX("foo") = "CPNMU==="
BASE32-HEX("foob") = "CPNMUOG="
BASE32-HEX("fooba") = "CPNMUOJ1"
BASE32-HEX("foobar") = "CPNMUOJ1E8======"
BASE16("") = ""
BASE16("f") = "66"
BASE16("fo") = "666F"
BASE16("foo") = "666F6F"
BASE16("foob") = "666F6F62"
BASE16("fooba") = "666F6F6261"
BASE16("foobar") = "666F6F626172"
11. ISO C99 Implementation of Base64
11. ベース６４のISO C99実装
An ISO C99 implementation of Base64 encoding and decoding that is
believed to follow all recommendations in this RFC is available from:
このＲＦＣのすべての推薦に従うと信じられるベース６４符号化と復号化の
ＩＳＯ Ｃ９９実装が以下で利用可能です：
http://josefsson.org/base-encoding/
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).
コードは手続き上の理由（ＲＦＣ３９７８の５.４章）でこのＲＦＣに含め
ることができませんでした。
12. Security Considerations
12. セキュリティの考察
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 ０）を含
む場合でも、復号機は壊れないべきです。
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.
もし（推薦された）符号全体を拒否する代わりに、非アルファベットの文字
を無視するなら、情報を「漏らす」ために使える内密のチャネルが可能にな
ります。無視された文字は文字列の同一性比較を避けることや、実装バグを
引き起こすためなど、他の極悪非道な目的のために使うことができます。非
アルファベット文字を無視する事は、アプリケーションが推薦された習慣に
従わないと理解されるべきです。同様に、ベース１６あるいはベース３２ア
ルファベットが大文字小文字を無視して処理された場合、変更が情報を漏ら
したり、あるいは文字列の一致性比較を失敗させるのに使うことができます。
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.
ベース符号化は平文にエントロピーを加えませんが、利用可能な平文の量を
増やして、特有の確率分布で暗号署名を提供します。
13. Changes Since RFC 3548
13. ＲＦＣ３５４８からの変更
Added the "base32 extended hex alphabet", needed to preserve sort
order of encoded data.
符号化されたデータのソート順序を維持するための、「１６進アルファベッ
ト拡張ベース３２」を加えました。
Referenced IMAP for the special Base64 encoding used there.
特別なベース６４符号化のためにＩＭＡＰを参照しました。
Fixed the example copied from RFC 2440.
ＲＦＣ２４４０を写した例を訂正しました。
Added security consideration about providing a signature for
cryptoanalysis.
暗号署名を提供することについて、セキュリティの考察を加えました。
Added test vectors.
試験ベクトルの追加。
Fixed typos.
タイプミス修正。
14. Acknowledgements
14. 謝辞
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.
John E. HadstateとTony HansenとGordon MohrとJohn MyersとChris
NewmanとAndrew Sieberを含む数人の人々がコメントや提案として提出
しました。この文書で使われた文は様々なベース符号化の使い方を記述
する過去のＲＦＣに基づいています。著者はＲＳＡ研究所がこの文書に
導いた仕事を支持したことに感謝します。
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.
この改訂版は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と
Ben Laurieのコメントや提案の一部の基づきます。
15. Copying Conditions
15. 著作状態
Copyright (c) 2000-2006 Simon 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.
Simon Josefsson（この章の残りの「著者」）によって書かれたこの文書
の要約と１章と３章と８章と１０章と１２章と１３章と１４章に関して、
著者は保証をせずその使用に起因する損害に責任がありません。再配布が
紛らわしい著者あるいはバージョン情報を含まず、間違ってＩＥＴＦ ＲＦ
Ｃ文書であると称さない限り、著者は、全ての人の使用と修正と配布の権
利を侵害しない全ての方法での、全ての人の使用と修正と配布に対し、取
り消しできない許可を与えます。派生的な仕事が類似の条件の下で認可さ
れる必要がありません。
16. References
16. 参考文献
16.1. Normative References
16.1. 参照する参考文献
[1] Cerf, V., "ASCII format for network interchange", RFC 20,
October 1969.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
16.2. Informative References
16.2. 有益な参考文献
[3] Linn, J., "Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encryption and Authentication Procedures", RFC
1421, February 1993.
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033, March
2005.
[7] Klyne, G. and L. Masinter, "Identifying Composite Media
Features", RFC 2938, September 2000.
[8] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[10] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNSSEC Hash
Authenticated Denial of Existence", Work in Progress, June
2006.
[11] Myers, J., "SASL GSSAPI mechanisms", Work in Progress, May
2000.
[12] Wilcox-O'Hearn, B., "Post to P2P-hackers mailing list",
http://zgp.org/pipermail/p2p-hackers/2001-September/
000315.html, September 2001.
Author's Address
著者のアドレス
Simon Josefsson
SJD
EMail: simon@josefsson.org
Full Copyright Statement
完全著作権表示
Copyright (C) The Internet Society (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.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。
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.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、全ての保証を拒否します。
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.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/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-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。