この文書はRFC 4648の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


Network Working Group                                       S. Josefsson
Request for Comments: 4648                                           SJD
Obsoletes: 3548                                             October 2006
Category: Standards Track


             The Base16, Base32, and Base64 Data Encodings
               ベース64とベース32とベース16符号化

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.
   この文書はインターネット共同体のためのインターネット標準化中のプロト
   コルを指定し、そして改良のために議論と提案を求めます。このプロトコル
   と標準化状態と状況は「インターネット公式プロトコル標準」(STD1)
   の最新版を参照してください。このメモの配布は無制限です。

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.
   この文書は共通に使用するベース64とベース32とベース16符号化を
   記述します。また符号化されたデータでの改行の使用と、符号化されたデー
   タでのパディングの使用と、符号化されたデータでの非アルファベットの
   文字の使用と、異なった符号化アルファベットの使用と正規符号を論じます。


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. べース64符号化
   5. Base 64 Encoding with URL and Filename Safe Alphabet
   5. URLとファイル名で安全なアルファベットのベース64符号化
   6. Base 32 Encoding
   6. ベース32符号化
   7. Base 32 Encoding with Extended Hex Alphabet
   7. 拡張16進法アルファベットでのベース32符号化
   8. Base 16 Encoding
   8. ベース16符号化
   9. Illustrations and Examples
   9. イラストと例
   10. Test Vectors
   10. 試験ベクトル
   11. ISO C99 Implementation of Base64
   11. ベース64のISO C99実装
   12. Security Considerations
   12. セキュリティの考察
   13. Changes Since RFC 3548
   13. RFC3548からの変更
   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.
   データのベース符号化は、多分旧式であるため、US−ASCII[1]に
   制限されている環境での保存やデータ転送の多くの状況で使われます。
   ベース符号化が旧式な制限を持っていない新しいアプリケーションで、
   テキストエディタでオブジェクトを編集できるという理由で、使うこと
   ができます。

   In the past, different applications have had different requirements
   and thus sometimes implemented base encodings in slightly different
   ways.  Today, protocol specifications sometimes use base encodings in
   general, and "base64" in particular, without a precise description or
   reference.  Multipurpose Internet Mail Extensions (MIME) [4] is often
   used as a reference for base64 without considering the consequences
   for line-wrapping or non-alphabet characters.  The purpose of this
   specification is to establish common alphabet and encoding
   considerations.  This will hopefully reduce ambiguity in other
   documents, leading to better interoperability.
   過去に、異なったアプリケーションが異なった必要条件のため、それでわ
   ずかに異なった方法でベース符号化を実装しました。今日、プロトコル仕
   様書がしばしば一般的にベース符号化を、特に、正確な記述や参考文献な
   しで"base64"を使います。多目的インターネットメール拡張(MIME)
   [4]は、しばしば、行のラッピングや非アルファベットの文字に関する結果
   を考えずに、ベース64の非参考文献として使われます。この仕様書の目
   的は共通のアルファベットと符号化の考えを確立することです。これが、
   他の文書のあいまい性を減らし、良い互換性を導く事を希望します。

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.
   MIME[4]はしばしばベース64符号化の参考文献として使われます。
   しかしながら、MIMEは本質的に「ベース64」を定義せず、どちらか
   と言うとMIME内で使用するための「ベース64コンテンツ転送符号化」
   を定義します。そして、MIMEはベース64で符号化されたデータの行
   の長さを76文字に制限します。MIMEは「事実上同一」と述べて、プ
   ライバ拡張メール(PEM)[3]の符号化を継承します;しかしながら、
   PEMが64文字の行長を使います。MIMEとPEMの制限は共に
   SMTPの制限のためです。

   Implementations MUST NOT add line feeds to base-encoded data unless
   the specification referring to this document explicitly directs base
   encoders to add line feeds after a specific number of characters.
   この文書を参照している仕様書が明示的に特定の文字数の後に改行を加える
   ようにベース符号化機に指示しないなら、実装がベース符号化されたデー
   タに改行を加えてはなりません(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.
   下の4章と6章で記述されるように、ベース64とベース32アルファベッ
   トは穴埋めを使います、しかしベース16アルファベットはそれを必要と
   しません;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)。このような指定
   は、MIMEの様に、ベース符号化アルファベット以外の文字はデータを翻
   訳する時に無視されるべきと述べるかもしれません(「受信に関して寛容」)。
   これは隣接したキャリッジ・リターン/ラインフィード(CRLF)文字が「非
   アルファベット文字」を形成し、無視されることを意味する事に注意してく
   ださい。さらに、このような指定は文字列の終り以外のパディング文字「=」
   を非アルファベットのデータとして扱い無視するかもしれません(MAY)。もし
   パッド文字に許された数より多くのパッド文字が文字列の終わりにあるとき
   (例えばベース64文字列が「===」で終わるなら)、余分のパッド文字が無
   視されるかもしれません(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.)
      人による処理。文字「0」と「O」がすぐ読み間違えされ、「1」と
      「l」と「I」も同様です。下記のベース32アルファベットで、0
      (ゼロ)と1(壱)が存在ぜず、復号機が0をOに、1を場合によって
      IかLと解釈するかもしれません。(しかしながら、デフォルトでそう
      するべきではありません、前の章を見てください。)

   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.
      他の必要条件がある構造の中に符号化する。ベース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.
      識別子として用いる。ある特定の文字、特にベース64のアルファベッ
      トで「+」と「/」が、旧式なテキスト捜索/インデックスツールで単語
      の区切りとして扱われます。

   There is no universally accepted alphabet that fulfills all the
   requirements.  For an example of a highly specialized variant, see
   IMAP [8].  In this document, we document and name some currently used
   alphabets.
   すべての必要条件を満たす広く一般に受け入れられたアルファベットがあり
   ません。かなり専門化した方言の例としてIMAP[8]を参照してください。
   この文書で、我々はある現在使われたアルファベットを文書化し、命名します。

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.
   ベース64とベース32符号化での穴埋め手順が、もし不適当に実装され
   るなら、符号化データの無用な変更を発生させます。例えば、もしベース
   64符号化の入力がたった1オクテットであるなら、最初の記号のすべて
   の6ビットは使われますが、次の記号は最初の2ビットだけが使われます。
   これらの穴埋め部分は準拠する符号化機ではゼロが設定されなくてはなり
   ません(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.  べース64符号化

   The following description of base 64 is derived from [3], [4], [5],
   and [6].  This encoding may be referred to as "base64".
   以下のベース64の記述は[3]と[4]と[5]と[6]から得られます。この符号
   化は"base64"と述べられるかもしれません。

   The Base 64 encoding is designed to represent arbitrary sequences of
   octets in a form that allows the use of both upper- and lowercase
   letters but that need not be human readable.
   ベース64符号化は大文字と小文字の両方を許すが人が読むことを必要と
   されない任意のオクテット列を表すよう意図されます。

   A 65-character subset of US-ASCII is used, enabling 6 bits to be
   represented per printable character.  (The extra 65th character, "=",
   is used to signify a special processing function.)
   US−ASCIIのの内の65文字が、6ビットを印刷可能な文字に表現す
   るようにするために使われます。(余分の第65番目の文字「=」は特別な
   処理機能を意味するために使われます。)

   The encoding process represents 24-bit groups of input bits as output
   strings of 4 encoded characters.  Proceeding from left to right, a
   24-bit input group is formed by concatenating 3 8-bit input groups.
   These 24 bits are then treated as 4 concatenated 6-bit groups, each
   of which is translated into a single character in the base 64
   alphabet.
   符号化処理は入力ビットの24ビットのグループを、4つの符号化文字の
   出力文字列とします。左から右へ処理し、3つの8ビットの入力グループ
   を連結することによって、24ビットの入力グループが形成されます。こ
   れらの24ビットは4つの連結された6ビットのグループとして扱われ、
   そしてそれぞれはベース64のアルファベットのひとつの文字に翻訳され
   ます。

   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, bits with value zero are added
   (on the right) to form an integral number of 6-bit groups.  Padding
   at the end of the data is performed using the '=' character.  Since
   all base 64 input is an integral number of octets, only the following
   cases can arise:
   もし符号化するデータの終わりに24ビット未満しかデータがないときに
   特別な処理が行われます。完全な符号化は常に一定量の終わりで完了しま
   す。入力グループで24インプットビット未満しか利用可能でない時、ゼ
   ロのビットが6の整数倍のビットグループを形成するために(右手に)足
   されます。データの終わりの穴埋めは「=」を使って行われます。すべての
   ベース64の入力が整数個のオクテットなので、次の場合だけが生じます:

   (1) The final quantum of encoding input is an integral multiple of 24
       bits; here, the final unit of encoded output will be an integral
       multiple of 4 characters with no "=" padding.
   (1) 符号化入力の最終部分は24ビットの倍数です;ここで、符号化され
       た出力の終わりは、「=」なしの4の倍数個の文字であるでしょう。

   (2) The final quantum of encoding input is exactly 8 bits; here, the
       final unit of encoded output will be two characters followed by
       two "=" padding characters.
   (2) 符号化入力の最終部分は正確に8ビットです;ここで、符号化された
       出力の終わりは、2文字とそれに続く2つの「=」文字であるでしょう。

   (3) The final quantum of encoding input is exactly 16 bits; here, the
       final unit of encoded output will be three characters followed by
       one "=" padding character.
   (3) 符号化入力の最終部分は正確に16ビットです;ここで、符号化され
       た出力の終わりは、3文字とは続1つの「=」文字であるでしょう。

5.  Base 64 Encoding with URL and Filename Safe Alphabet
5.  URLとファイル名で安全なアルファベットのベース64符号化

   The Base 64 encoding with an URL and filename safe alphabet has been
   used in [12].
   URLとファイル名で安全なアルファベットのベース64符号化は[12]で
   使われました。

   An alternative alphabet has been suggested that would use "~" as the
   63rd character.  Since the "~" character has special meaning in some
   file system environments, the encoding described in this section is
   recommended instead.  The remaining unreserved URI character is ".",
   but some file system environments do not permit multiple "." in a
   filename, thus making the "." character unattractive as well.
   63番目のアルファベットの代わりの文字として"~"を使うのが示唆され
   ました。"~"文字があるファイルシステム環境で特別な意味を持つので、
   この章で記述された符号化はその代わりとして勧められます。残りの予
   約なしのURI文字は"."ですが、あるファイルシステム環境で複数の"."
   は許されず、"."文字も魅力的でありません。

   The pad character "=" is typically percent-encoded when used in an
   URI [9], but if the data length is known implicitly, this can be
   avoided by skipping the padding; see section 3.2.
   URI[9]で使われるとき、穴埋め文字"="は一般にパーセント符号化さ
   れますが、もしデータ長が暗黙のうちにわかるなら、穴埋めをスキップす
   ることによってこれを避けれます;3.2章を見て下さい。

   This encoding may be referred to as "base64url".  This encoding
   should not be regarded as the same as the "base64" encoding and
   should not be referred to as only "base64".  Unless clarified
   otherwise, "base64" refers to the base 64 in the previous section.
   この符号化は"base64url"と述べられるかもしれません。この符号化は
   "base64"符号化と同じと見なされるべきではなくて、単純に「ベース6
   4」と述べるべきではありません。他に明示されない限り、"base64"が
   前章のベース64を意味します。

   This encoding is technically identical to the previous one, except
   for the 62:nd and 63:rd alphabet character, as indicated in Table 2.
   この符号化は、62番目と63番目のアルファベット文字が表2で示さ
   れたものである以外は、技術的に前のものとまったく同じです。

         Table 2: The "URL and Filename safe" Base 64 Alphabet
         表2:「URLとファイル名で安全な」ベース64アルファベット

     Value Encoding  Value Encoding  Value Encoding  Value Encoding
         0 A            17 R            34 i            51 z
         1 B            18 S            35 j            52 0
         2 C            19 T            36 k            53 1
         3 D            20 U            37 l            54 2
         4 E            21 V            38 m            55 3
         5 F            22 W            39 n            56 4
         6 G            23 X            40 o            57 5
         7 H            24 Y            41 p            58 6
         8 I            25 Z            42 q            59 7
         9 J            26 a            43 r            60 8
        10 K            27 b            44 s            61 9
        11 L            28 c            45 t            62 - (minus)
        12 M            29 d            46 u            63 _
        13 N            30 e            47 v           (underline)
        14 O            31 f            48 w
        15 P            32 g            49 x
        16 Q            33 h            50 y         (pad) =

6.  Base 32 Encoding
6.  ベース32符号化

   The following description of base 32 is derived from [11] (with
   corrections).  This encoding may be referred to as "base32".
   ベース32の次の記述は[11]から得られます(訂正あり)。この符号化は
   "base32"と述べられるかもしれません。

   The Base 32 encoding is designed to represent arbitrary sequences of
   octets in a form that needs to be case insensitive but that need not
   be human readable.
   ベース32の符号化は大文字小文字の違いを無視する必要がある形式で任
   意のオクテット列を表すよう意図されます、しかし人間の力で読み取り可
   能である必要がありません。

   A 33-character subset of US-ASCII is used, enabling 5 bits to be
   represented per printable character.  (The extra 33rd character, "=",
   is used to signify a special processing function.)
   US−ASCIIの33文字が、5ビットを印刷可能な文字で表すために
   使われます。(余分の第33番目の文字、「=」、は特別な処理機能を意
   味するために使われます。)

   The encoding process represents 40-bit groups of input bits as output
   strings of 8 encoded characters.  Proceeding from left to right, a
   40-bit input group is formed by concatenating 5 8bit input groups.
   These 40 bits are then treated as 8 concatenated 5-bit groups, each
   of which is translated into a single character in the base 32
   alphabet.  When a bit stream is encoded via the base 32 encoding, the
   bit stream must be presumed to be ordered with the most-significant-
   bit first.  That is, the first bit in the stream will be the high-
   order bit in the first 8bit byte, the eighth bit will be the low-
   order bit in the first 8bit byte, and so on.
   符号化処理は入力ビットの40ビットのグループを8つの符号化された出
   力文字列として描きます。左から右に処理して、5つの8ビット入力を連
   結することによって40ビットの入力グループが形成されます。これらの
   40ビットはそれから8つの5ビットのグループの連結として扱われ、そ
   してそれぞれはベース32のアルファベットを使ってひとつの文字として
   翻訳されます。ビット列がベース32符号化によってを符号化される時、
   ビット列は最初に上位桁ビットがある順序と推測されなくてはなりません。
   すなわち、列の最初のビットは最初の8ビットバイトの最上位桁であるで
   しょう、そして8番目のビットは最初の8ビットバイトの最下位ビットで
   あるでしょう。

   Each 5-bit group is used as an index into an array of 32 printable
   characters.  The character referenced by the index is placed in the
   output string.  These characters, identified in Table 3, below, are
   selected from US-ASCII digits and uppercase letters.
   それぞれの5ビットのグループが32の印刷可能文字の配列のインデック
   スとして用いられます。インデックスによって参照された文字は出力文字
   列に置かれます。これらの文字は、下記の表3で指定され、US−ASC
   IIの数字と大文字から選ばれます。

                     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, bits with value zero are added (on
   the right) to form an integral number of 5-bit groups.  Padding at
   the end of the data is performed using the "=" character.  Since all
   base 32 input is an integral number of octets, only the following
   cases can arise:
   もし40ビット以下が符号化されるデータの終わりにで40ビット未満だ
   けが利用可能であるなら、特別な処理が行われます。完全な符号化が常に
   本体の終わりで完了します。40ビット未満だけが入力グループで利用可
   能である時、ゼロのビットが5ビットのグループを形成するために(右手
   に)足されます。データの終わりの穴埋めは「=」文字を使って行われます。
   すべてのベース32の入力が整数個のオクテットで、ただ次の場合だけが
   生じます:

   (1) The final quantum of encoding input is an integral multiple of 40
       bits; here, the final unit of encoded output will be an integral
       multiple of 8 characters with no "=" padding.
   (1) 符号化入力の最終部分は40ビットの倍数です;ここで、符号化され
       た出力の終わりは、「=」なしの8の倍数個の文字であるでしょう。

   (2) The final quantum of encoding input is exactly 8 bits; here, the
       final unit of encoded output will be two characters followed by
       six "=" padding characters.
   (2) 符号化入力の最終部分は正確に8ビットです;ここで、符号化された
       出力の終わりは、2文字とそれに続く6つの「=」文字であるでしょ
       う。

   (3) The final quantum of encoding input is exactly 16 bits; here, the
       final unit of encoded output will be four characters followed by
       four "=" padding characters.
   (3) 符号化入力の最終部分は正確に16ビットです;ここで、符号化され
       た出力の終わりは、4文字とそれに続く4つの「=」文字であるでしょ
       う。

   (4) The final quantum of encoding input is exactly 24 bits; here, the
       final unit of encoded output will be five characters followed by
       three "=" padding characters.
   (4) 符号化入力の最終部分は正確に24ビットです;ここで、符号化され
       た出力の終わりは、5文字とそれに続く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つの「=」文字であるでしょ
       う。

7.  Base 32 Encoding with Extended Hex Alphabet
7.  拡張16進法アルファベットでのベース32符号化

   The following description of base 32 is derived from [7].  This
   encoding may be referred to as "base32hex".  This encoding should not
   be regarded as the same as the "base32" encoding and should not be
   referred to as only "base32".  This encoding is used by, e.g.,
   NextSECure3 (NSEC3) [10].
   ベース32の次の記述は[7]から得られます。この符号化は"base32hex"と
   述べられるかもしれません。この符号化は"base32"符号化と同じと見なさ
   れるべきではなく、そして"base32"として参照されるべきではありません。
   この符号化は例えば、例えばNextSECure3(NSEC3)[10]で使われます。

   One property with this alphabet, which the base64 and base32
   alphabets lack, is that encoded data maintains its sort order when
   the encoded data is compared bit-wise.
   ベース64とベース32アルファベットに欠けている、このアルファベッ
   トの1つの特性は、符号化データをビット単位で比較する時、符号化され
   たデータがソート順序を維持するということです。

   This encoding is identical to the previous one, except for the
   alphabet.  The new alphabet is found in Table 4.
   この符号化は、アルファベット以外、前ののとまったく同じです。新しい
   アルファベットは表4にあります。

                 Table 4: The "Extended Hex" Base 32 Alphabet
                 表4:"Extended Hex"ベース32アルファベット

         Value Encoding  Value Encoding  Value Encoding  Value Encoding
             0 0             9 9            18 I            27 R
             1 1            10 A            19 J            28 S
             2 2            11 B            20 K            29 T
             3 3            12 C            21 L            30 U
             4 4            13 D            22 M            31 V
             5 5            14 E            23 N
             6 6            15 F            24 O         (pad) =
             7 7            16 G            25 P
             8 8            17 H            26 Q

8.  Base 16 Encoding
8.  ベース16符号化

   The following description is original but analogous to previous
   descriptions.  Essentially, Base 16 encoding is the standard case-
   insensitive hex encoding and may be referred to as "base16" or "hex".
   次の記述はオリジナルですが、前の記述に類似しています。本質的に、ベー
   ス16の符号化が標準的な大文字小文字の違いを無視する16進法の符号
   化であり、そして「ベース16」あるいは「16進法」であると述べられ
   るかもしれません。

   A 16-character subset of US-ASCII is used, enabling 4 bits to be
   represented per printable character.
   US−ASCIIの16文字が、4ビットを印刷可能文字に表すために使
   われます。

   The encoding process represents 8-bit groups (octets) of input bits
   as output strings of 2 encoded characters.  Proceeding from left to
   right, an 8-bit input is taken from the input data.  These 8 bits are
   then treated as 2 concatenated 4-bit groups, each of which is
   translated into a single character in the base 16 alphabet.
   符号化処理は入力ビットの8ビットのグループを2つの符号化された出力
   文字列として描きます。左から右に処理して、8ビットの入力が入力デー
   タからとられます。これらの8ビットは2つの連結された4ビットのグルー
   プとして扱われ、そしてそれぞれはベース16のアルファベットでひとつ
   の文字に翻訳されます。

   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と異なり、全ての符号が常に利用可能なので、特
   別な詰め物が必要ありません。

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].
   バイナリとベース符号化の間で翻訳するために、入力は構造体に保存され、
   出力はは引き抜かれます。ベース64の場合は[5]から借用した下図で示
   されます。

            +--first octet--+-second octet--+--third octet--+
            |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
            +-----------+---+-------+-------+---+-----------+
            |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
            +--1.index--+--2.index--+--3.index--+--4.index--+

   The case for base 32 is shown in the following figure, borrowed from
   [7].  Each successive character in a base-32 value represents 5
   successive bits of the underlying octet sequence.  Thus, each group
   of 8 characters represents a sequence of 5 octets (40 bits).
   ベース32の場合は[7]から借用された次の図で示されます。それぞれのベー
   ス32値の連続した文字が、オクテット列の連続した5ビットを表します。
   それで、それぞれの8つの文字のグループが5つのオクテット列(40ビッ
   ト)を表します。

                        1          2          3
             01234567 89012345 67890123 45678901 23456789
            +--------+--------+--------+--------+--------+
            |< 1 >< 2| >< 3 ><|.4 >< 5.|>< 6 ><.|7 >< 8 >|
            +--------+--------+--------+--------+--------+
                                                    <===> 8th character
                                              <====> 7th character
                                         <===> 6th character
                                   <====> 5th character
                             <====> 4th character
                        <===> 3rd character
                  <====> 2nd character
             <===> 1st character

   The following example of Base64 data is from [5], with corrections.
   ベース64データの次の例は[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. ベース64のISO C99実装

   An ISO C99 implementation of Base64 encoding and decoding that is
   believed to follow all recommendations in this RFC is available from:
   このRFCのすべての推薦に従うと信じられるベース64符号化と復号化の
   ISO C99実装が以下で利用可能です:

      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).
   コードは手続き上の理由(RFC3978の5.4章)でこのRFCに含め
   ることができませんでした。

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 0)を含
   む場合でも、復号機は壊れないべきです。

   If non-alphabet characters are ignored, instead of causing rejection
   of the entire encoding (as recommended), a covert channel that can be
   used to "leak" information is made possible.  The ignored characters
   could also be used for other nefarious purposes, such as to avoid a
   string equality comparison or to trigger implementation bugs.  The
   implications of ignoring non-alphabet characters should be understood
   in applications that do not follow the recommended practice.
   Similarly, when the base 16 and base 32 alphabets are handled case
   insensitively, alteration of case can be used to leak information or
   make string equality comparisons fail.
   もし(推薦された)符号全体を拒否する代わりに、非アルファベットの文字
   を無視するなら、情報を「漏らす」ために使える内密のチャネルが可能にな
   ります。無視された文字は文字列の同一性比較を避けることや、実装バグを
   引き起こすためなど、他の極悪非道な目的のために使うことができます。非
   アルファベット文字を無視する事は、アプリケーションが推薦された習慣に
   従わないと理解されるべきです。同様に、ベース16あるいはベース32ア
   ルファベットが大文字小文字を無視して処理された場合、変更が情報を漏ら
   したり、あるいは文字列の一致性比較を失敗させるのに使うことができます。

   When padding is used, there are some non-significant bits that
   warrant security concerns, as they may be abused to leak information
   or used to bypass string equality comparisons or to trigger
   implementation problems.
   詰め物が使われるとき、情報を漏らすために悪用されるか、文字列の一致性
   比較を回避するか、実装問題を引き起こすために使われるかもしれない、セ
   キュリティ上の懸念となる重要でないビットがあります。

   Base encoding visually hides otherwise easily recognized information,
   such as passwords, but does not provide any computational
   confidentiality.  This has been known to cause security incidents
   when, e.g., a user reports details of a network protocol exchange
   (perhaps to illustrate some other problem) and accidentally reveals
   the password because she is unaware that the base encoding does not
   protect the password.
   ベース符号化が、パスワードのような情報を、視覚的に容易に認識されない
   ように隠しますが、計算的な機密性を供給しません。これは、例えば、ユー
   ザが(多分何か他の問題を示すために)ネットワークプロトコル交換の細部
   を報告し、彼女がベース符号化がパスワードを保護しないことに気付かない
   事で、偶然にパスワードを明らかにする時に、セキュリティ問題を起こすと
   知られています。

   Base encoding adds no entropy to the plaintext, but it does increase
   the amount of plaintext available and provide a signature for
   cryptanalysis in the form of a characteristic probability
   distribution.
   ベース符号化は平文にエントロピーを加えませんが、利用可能な平文の量を
   増やして、特有の確率分布で暗号署名を提供します。

13.  Changes Since RFC 3548
13.  RFC3548からの変更

   Added the "base32 extended hex alphabet", needed to preserve sort
   order of encoded data.
   符号化されたデータのソート順序を維持するための、「16進アルファベッ
   ト拡張ベース32」を加えました。

   Referenced IMAP for the special Base64 encoding used there.
   特別なベース64符号化のためにIMAPを参照しました。

   Fixed the example copied from RFC 2440.
   RFC2440を写した例を訂正しました。

   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を含む数人の人々がコメントや提案として提出
   しました。この文書で使われた文は様々なベース符号化の使い方を記述
   する過去のRFCに基づいています。著者はRSA研究所がこの文書に
   導いた仕事を支持したことに感謝します。

   This revised version is based in parts on comments and/or suggestions
   made by Roy Arends, Eric Blake, Brian E Carpenter, Elwyn Davies, Bill
   Fenner, Sam Hartman, Ted Hardie, Per Hygum, Jelte Jansen, Clement
   Kent, Tero Kivinen, Paul Kwiatkowski, and Ben Laurie.
   この改訂版は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(この章の残りの「著者」)によって書かれたこの文書
   の要約と1章と3章と8章と10章と12章と13章と14章に関して、
   著者は保証をせずその使用に起因する損害に責任がありません。再配布が
   紛らわしい著者あるいはバージョン情報を含まず、間違ってIETF RF
   C文書であると称さない限り、著者は、全ての人の使用と修正と配布の権
   利を侵害しない全ての方法での、全ての人の使用と修正と配布に対し、取
   り消しできない許可を与えます。派生的な仕事が類似の条件の下で認可さ
   れる必要がありません。

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).
   著作権(C)インターネット社会(2006)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.
   この文書はBCP78に含まれる権利と許可と制限の適用を受け、そして
   この中に明らかにされる以外は著者がすべての権利を維持します。

   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.
   この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
   正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
   可能かの範囲について、IETFは何の立場もとりません;この様な権利を
   認識する独立の調査をしたとは述べません。RFC文書の権利に関する手続
   きの情報はBCP78とBCP79を見てください。

   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.
   IETF事務局に公開されたIPRの写しと、利用可能な許可証と、仕様書
   の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
   試みの結果は、http://www.ietf.org/iprにあるIETFオンラインIPR
   貯蔵庫で得られます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.
   IETFは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
   バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
   めます。どうかietf-ipr@ietf.orgのIETFに情報を伝えてください。

Acknowledgement
謝辞

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).
   RFCエディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So