RFC3548 日本語訳

Network Working Group                                  S. Josefsson, Ed.
Request for Comments: 3548                                     July 2003
Category: Informational

ワーキンググループS.Josefsson、エドをネットワークでつないでください。コメントのために以下を要求してください。 3548 2003年7月のカテゴリ: 情報

             The Base16, Base32, and Base64 Data Encodings

Base16、Base32、およびBase64データEncodings

Status of this Memo

この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)インターネット協会(2003)。 All rights reserved。

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

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 実現食い違い. . . . . . . . . . . . . . . . . 2 2.1。 コード化されたデータ. . . . . . . . . . . . . . . 2 2.2における改行。 コード化されたデータ. . . . . . . . . . . . . . . . 3 2.3の詰め物。 コード化されたデータ. . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.4における、非アルファベットキャラクタの解釈。 アルファベット. . . . . . . . . . . . . . . . . 3 3を選びます。 .4 4をコード化する64を基礎づけてください。 URLとファイル名で安全なアルファベット. . . . . 6 5をコード化する64を基礎づけてください。 .6 6をコード化する32を基礎づけてください。 .8 7をコード化する16を基礎づけてください。 イラストと例. . . . . . . . . . . . . . . . . . 9 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 10 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1。 引用規格. . . . . . . . . . . . . . . . . . 11 9.2。 有益な参照. . . . . . . . . . . . . . . . . 11 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 11 11。 エディタのアドレス. . . . . . . . . . . . . . . . . . . . . . . 12 12。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 13

Josefsson                    Informational                      [Page 1]

RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003

Josefssonの情報[1ページ]のRFC3548Base16、Base32、およびBase64データEncodings2003年7月

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 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.

過去に、異なったアプリケーションは、異なった要件を持って、その結果、時々わずかに異なった方法でベースencodingsを実行しました。 今日、プロトコル仕様は時々一般に、ベースencodings、および「特に正確な記述も参照のないbase64"」を使用します。 線を包装しているか、非アルファベットのキャラクタのために結果を考えないで、MIME[3]はbase64の参照としてしばしば使用されます。 この仕様の目的は一般的なアルファベットとコード化問題を確立することです。 より良い相互運用性に通じると、これは希望をいだいて他のドキュメントのあいまいさを減少させるでしょう。

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?

2.  Implementation discrepancies

2. 実現食い違い

   Here we discuss the discrepancies between base encoding
   implementations in the past, and where appropriate, mandate a
   specific recommended behavior for the future.

ここで、私たちは過去、および適切であるところでベースコード化実現の間の食い違いについて議論して、命令は未来の特定のお勧めの振舞いです。

2.1.  Line feeds in encoded data

2.1. コード化されたデータにおける改行

   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の中の使用のためのむしろ「ベース64Content転送コード化」」を定義しません。 そういうものとして、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.

実現は、明らかにこのドキュメントを参照する仕様が、特定の数のキャラクタの後に改行を加えるようベースエンコーダに指示しない場合基礎づける改行がデータを暗号化したと言い足さなければなりません。

Josefsson                    Informational                      [Page 2]

RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003

Josefssonの情報[2ページ]のRFC3548Base16、Base32、およびBase64データEncodings2003年7月

2.2.  Padding of encoded data

2.2. コード化されたデータの詰め物

   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.

実現がコード化されたデータの終わりに適切なパッド文字を含まなければならない、明らかにこのドキュメントを参照すると別の方法で述べられる仕様。

2.3.  Interpretation of non-alphabet characters in encoded data

2.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.

基地のencodingsは、2進のデータをコード化するのに特定の、そして、減少しているアルファベットを使用します。 キャラクタが存在できた非アルファベットベースはデータの汚染かデザインによって引き起こされたデータをコード化しました。 「ひそかなチャンネル」として非アルファベットキャラクタを搾取するかもしれません。そこでは、邪悪な目的のために非プロトコルデータを送ることができます。 また、主な状態で実現誤りを利用するために非アルファベットキャラクタを送るかもしれません、例えば、バッファオーバーフローは攻撃されます。

   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ストリングと終わったベースの端で見つけられるなら」===「余分なパッド文字を無視できました」

2.4.  Choosing the alphabet

2.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.  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 人間によって扱われます。 キャラクター、「「O」によるまた、「1インチ、「l」、および「I」。」という容易に交換されていて、何0インチも、ことです。 以下のbase32アルファベットかケースによるLで。(0(ゼロ)と1(1つ)が存在していない、そこでは、デコーダが私のようにOとしての0、および1を解釈するかもしれません)。 (前項は、しかしながら、デフォルトで、それがそうするべきでないのを見ます。)

Josefsson                    Informational                      [Page 3]

RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003

Josefssonの情報[3ページ]のRFC3548Base16、Base32、およびBase64データEncodings2003年7月

   o   Encoded into structures that place other requirements.  For base
       16 and base 32, this determines the use of upper- or lowercase
       alphabets.  For base 64, the non-alphanumeric characters (in
       particular "/") may be problematic in file names and URLs.

o 他の要件を置く構造にコード化されます。 ベース16とベース32と、これは上側の、または、小文字のアルファベットの使用を決定します。 「ベース64、非英数字、(」 特に/、」、)、ファイル名とURLで問題が多いかもしれません。

   o   Used as identifiers.  Certain characters, notably "+" and "/" in
       the base 64 alphabet, are treated as word-breaks by legacy text
       search/index tools.

o 識別子として、使用されています。 遺産テキストによる単語中断がツールに捜すか、または索引をつけるとき、ベース64アルファベットの「」 確信しているキャラクタ、著しく「+」、および/」は扱われます。

   There is no universally accepted alphabet that fulfills all the
   requirements.  In this document, we document and name some currently
   used alphabets.

すべての要件を実現させる一般に受け入れられたアルファベットが全くありません。 本書では、私たちは、いくつかの現在中古のアルファベットを記録して、命名します。

3.  Base 64 Encoding

3. 基地64のコード化

   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.)

6ビットが印刷可能なキャラクタ単位で表されるのを可能にして、米国-ASCIIの65文字サブセットが使用されています。 (「=」という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ビットの入力グループを連結することによって、結成されます。 そして、4が6ビットのグループ(それのそれぞれがベース64アルファベットの一桁に翻訳される)を連結したので、これらの24ビットは扱われます。

   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の印刷可能なキャラクタのアレイに使用されます。 インデックスによって参照をつけられるキャラクタは出力ストリングに置かれます。

Josefsson                    Informational                      [Page 4]

RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003

Josefssonの情報[4ページ]のRFC3548Base16、Base32、およびBase64データEncodings2003年7月

                   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

評価..18秒間..C..44秒間..パッド..33時間

   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ビットです。 ここで、コード化された出力の最終的なユニットは1人の「=」暫定記号によっていうことになられた3つのキャラクタになるでしょう。

Josefsson                    Informational                      [Page 5]

RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003

Josefssonの情報[5ページ]のRFC3548Base16、Base32、およびBase64データEncodings2003年7月

4.  Base 64 Encoding with URL and Filename Safe Alphabet

4. URLとの基地64のコード化とファイル名の安全なアルファベット

   The Base 64 encoding with an URL and filename safe alphabet has been
   used in [8].

URLとファイル名の安全なアルファベットによる基地64のコード化は[8]で使用されました。

   An alternative alphabet has been suggested that used "~" as the 63rd
   character.  Since the "~" character has special meaning in some file
   system environments, the encoding described in this section is
   recommended instead.

63番目のキャラクタとして「~」を使用した代替のアルファベットは示されました。 「~」キャラクタにはいくつかのファイルシステム環境における特別な意味があるので、このセクションで説明されたコード化は代わりにお勧めです。

   This encoding should not be regarded as the same as the "base64"
   encoding, and should not be referred to as only "base64".  Unless
   made clear, "base64" refer to the base 64 in the previous section.

同じくらい同じようにこのコード化を見なすべきでない、「base64"はコード化して、"base64""だけと呼ぶべきではありません。 明らかにされない場合、「base64"は前項のベース64について言及します」。

   This encoding is technically identical to the previous one, except
   for the 62:nd and 63:rd alphabet character, as indicated in table 2.

第そして、このコード化は前のものと技術的に同じです、62を除いて:、63:、テーブル2にみられるようにアルファベット第キャラクタ

         Table 2: The "URL and Filename safe" Base 64 Alphabet

テーブル2: 「URLとFilename金庫」基地の64Alphabet

    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

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

5.  Base 32 Encoding

5. 基地32のコード化

   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コード化は、大文字と小文字を区別しないのが必要な、しかし、人間的に読み込み可能である必要はないフォームでの八重奏の気紛れな順番を表すように設計されています。

Josefsson                    Informational                      [Page 6]

RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003

Josefssonの情報[6ページ]のRFC3548Base16、Base32、およびBase64データEncodings2003年7月

   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.)

5ビットが印刷可能なキャラクタ単位で表されるのを可能にして、米国-ASCIIの33文字サブセットが使用されています。 (「=」という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ビットの入力グループを連結することによって、結成されます。 そして、8が5ビットのグループ(それのそれぞれがベース32アルファベットの一桁に翻訳される)を連結したので、これらの40ビットは扱われます。 ベース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の印刷可能なキャラクタのアレイに使用されます。 インデックスによって参照をつけられるキャラクタは出力ストリングに置かれます。 これらの以下のTable2で特定されたキャラクタは米国-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

値、9J18秒間27 3 1B10K19T28 4 2C11L20U29 5 3D12M21V30 6 4E13あたり0をコード化する値をコード化する値をコード化する値をコード化して、N22W31 7 5F14O23X6G15P24Y(パッド)が7時間16Q25Z8と等しい、I17R26 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,

(1) 入力をコード化する最終的な量子は40ビットの不可欠の倍数です。 ここで、コード化された出力の最終的なユニットは「=」が全くそっと歩いていない8つのキャラクタの不可欠の倍数になるでしょう。

Josefsson                    Informational                      [Page 7]

RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003

Josefssonの情報[7ページ]のRFC3548Base16、Base32、およびBase64データEncodings2003年7月

   (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ビットです。 ここで、コード化された出力の最終的なユニットは6人の「=」暫定記号によっていうことになられた2つのキャラクタになるでしょう。

   (3) the final quantum of encoding input is exactly 16 bits; here, the
   final unit of encoded output will be four characters followed by four
   "=" padding characters,

(3) 入力をコード化する最終的な量子はちょうど16ビットです。 ここで、コード化された出力の最終的なユニットは4人の「=」暫定記号によっていうことになられた4つのキャラクタになるでしょう。

   (4) the final quantum of encoding input is exactly 24 bits; here, the
   final unit of encoded output will be five characters followed by
   three "=" padding characters, or

(4) 入力をコード化する最終的な量子はちょうど24ビットです。 またはここで、コード化された出力の最終的なユニットが3人の「=」暫定記号によっていうことになられた5つのキャラクタになる。

   (5) the final quantum of encoding input is exactly 32 bits; here, the
   final unit of encoded output will be seven characters followed by one
   "=" padding character.

(5) 入力をコード化する最終的な量子はちょうど32ビットです。 ここで、コード化された出力の最終的なユニットは1人の「=」暫定記号によっていうことになられた7つのキャラクタになるでしょう。

6.  Base 16 Encoding

6. 基地16のコード化

   The following description is original but analogous to previous
   descriptions.  Essentially, Base 16 encoding is the standard standard
   case insensitive hex encoding, and may be referred to as "base16" or
   "hex".

以下の記述は、前の記述にオリジナルですが、類似しています。 本質的には、基地の16コード化は、標準の標準の大文字と小文字を区別しない十六進法コード化であり、「base16"か「十六進法」」と呼ばれるかもしれません。

   A 16-character subset of US-ASCII is used, enabling 4 bits to be
   represented per printable character.

4ビットが印刷可能なキャラクタ単位で表されるのを可能にして、米国-ASCIIの16文字サブセットが使用されています。

   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ビットの入力は入力データから抜粋されます。 そして、2が4ビットのグループ(それのそれぞれがベース16アルファベットの一桁に翻訳される)を連結したので、これらの8ビットは扱われます。

   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

値コード化0 0 4 4 8 8 12コード化値のコード化値のコード化値のC1 1 5 5 9 9 13のD2 2 6 6 10 14 3 3 7 7 11B15E F

   Unlike base 32 and base 64, no special padding is necessary since a
   full code word is always available.

ベース32とベース64と異なって、完全な婉曲的表現がいつも利用可能であるので、どんな特別な詰め物も必要ではありません。

Josefsson                    Informational                      [Page 8]

RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003

Josefssonの情報[8ページ]のRFC3548Base16、Base32、およびBase64データEncodings2003年7月

7.  Illustrations and examples

7. イラストと例

   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].

バイナリーとベースコード化の間で翻訳するために、入力は構造に格納されます、そして、出力は抽出されます。 [4]から借りられた以下の図にベース64へのケースを表示します。

         +--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--+

+--最初の八重奏--+-第2八重奏--+--3番目の八重奏--+|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

1 2 3 01234567 89012345 67890123 45678901 23456789 +--------+--------+--------+--------+--------+ |1>の<<2| ><3><|.4><5.| ><6><| 7><8>| +--------+--------+--------+--------+--------+ <。===>8番目のキャラクタ<。====>7番目のキャラクタ<。===>6番目のキャラクタ<。====>5番目のキャラクタ<。====>4番目のキャラクタ<。===>3番目のキャラクタ<。====>2番目のキャラクタ<。===>最初のキャラクタ

Josefsson                    Informational                      [Page 9]

RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003

Josefssonの情報[9ページ]のRFC3548Base16、Base32、およびBase64データEncodings2003年7月

   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十六進法: 1 4、f b9c| 0 3、d eの9 7 8ビット: 00010100 11111011 10011100 | 00000011 11011001 11111110 6ビット: 000101 001111 101110 011100 | 000000 111101 100111 111110小数: 5、15 46 28、0 61 37 62出力: F P u c A9l+

       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 b9c| 0 3、d9 8ビット: 00010100 11111011 10011100 | 00000011 11011001は00 6ビットでそっと歩きます: 000101 001111 101110 011100 | 000000 111101 100100小数: 5、15 46 28、0 61 36は=出力でそっと歩きます: F P u c A9k=

       Input data:  0x14fb9c03
       Hex:     1   4    f   b    9   c     | 0   3
       8-bit:   00010100 11111011 10011100  | 00000011
                                              pad with 0000
       6-bit:   000101 001111 101110 011100 | 000000 110000
       Decimal: 5      15     46     28       0      48
                                                   pad with =      =
       Output:  F      P      u      c        A      w      =      =

データを入力してください: 0x14fb9c03十六進法: 1 4、f b9c| 0 3 8ビット: 00010100 11111011 10011100 | 00000011 0000 6ビットで、そっと歩いてください: 000101 001111 101110 011100 | 000000 110000小数: 5 =がある15 46 28 0 48パッドは出力と等しいです: F P u c A wは=と等しいです。

8.  Security Considerations

8. セキュリティ問題

   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キャラクタ(ASCII0)の上で壊れるはずがありません。

   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

そうでなければ目視により獣皮をコード化する基地が、容易にパスワードなどの情報を認識しますが、少しのコンピュータの秘密性も提供しません。 例えば、ユーザがネットワーク・プロトコル交換の詳細を報告するとき、これがセキュリティインシデントを引き起こすのが知られています。

Josefsson                    Informational                     [Page 10]

RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003

Josefssonの情報[10ページ]のRFC3548Base16、Base32、およびBase64データEncodings2003年7月

   (perhaps to illustrate some other problem) and accidentally reveals
   the password because she is unaware that the base encoding does not
   protect the password.

そして、(恐らくある他の問題を例証する)、彼女がベースコード化がパスワードを保護しないのを気づかないので、偶然パスワードを明らかにします。

9.  References

9. 参照

9.1.  Normative References

9.1. 引用規格

   [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

9.2.  Informative References

9.2. 有益な参照

   [2] Linn, J., "Privacy Enhancement for Internet Electronic Mail:
       Part I: Message Encryption and Authentication Procedures", RFC
       1421, February 1993.

[2] リン、J.、「インターネット電子メールのためのプライバシー増進:」 部分I: 「メッセージ暗号化と認証手順」、RFC1421、2月1993日

   [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
       Extensions (MIME) Part One: Format of Internet Message Bodies",
       RFC 2045, November 1996.

解放された[3]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。

   [4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
       Message Format", RFC 2440, November 1998.

[4] カラスとJ.とDonnerhackeとL.とフィニーとH.とR.セイヤー、「OpenPGPメッセージ・フォーマット」、RFC2440、1998年11月。

   [5] Eastlake, D., "Domain Name System Security Extensions", RFC 2535,
       March 1999.

[5] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。

   [6] Klyne, G. and L. Masinter, "Identifying Composite Media
       Features", RFC 2938, September 2000.

[6]KlyneとG.とL.Masinter、「合成メディア機能を特定します」、RFC2938、2000年9月。

   [7] Myers, J., "SASL GSSAPI mechanisms", Work in Progress.

[7] マイアーズ、J.、「SASL GSSAPIメカニズム」、ProgressのWork。

   [8] Wilcox-O'Hearn, B., "Post to P2P-hackers mailing list", World
       Wide Web http://zgp.org/pipermail/p2p-hackers/2001-
       September/000315.html, September 2001.

ウィルコックス-O'Hearn(B.)が「P2P-ハッカーメーリングリストに掲示する」[8]、WWW http://zgp.org/pipermail/p2p-hackers/2001- 9月/000315.html、2001年9月。

   [9] Cerf, V., "ASCII format for Network Interchange", RFC 20, October
       1969.

[9] サーフ、V.、「Network InterchangeのためのASCII書式」、RFC20、1969年10月。

10.  Acknowledgements

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.

数人はトニー・ハンセン、ゴードン・モーア、ジョン・マイアーズ、クリス・ニューマン、およびアンドリュー・ジーバーを含むコメントと提案を提供しました。 本書では使用されるテキストは様々なベースencodingsの特定の用途について説明する以前のRFCsに基づいています。 作者は、このドキュメントにつながった仕事を支持するためにRSA研究所を承認します。

Josefsson                    Informational                     [Page 11]

RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003

Josefssonの情報[11ページ]のRFC3548Base16、Base32、およびBase64データEncodings2003年7月

11.  Editor's Address

11. エディタのアドレス

   Simon Josefsson
   EMail: simon@josefsson.org

サイモンJosefssonはメールします: simon@josefsson.org

Josefsson                    Informational                     [Page 12]

RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003

Josefssonの情報[12ページ]のRFC3548Base16、Base32、およびBase64データEncodings2003年7月

12.  Full Copyright Statement

12. 完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Josefsson                    Informational                     [Page 13]

Josefsson情報です。[13ページ]