ベース32

Base32 は、 32進数表記法に基づくエンコード方式です。32桁のアルファベットを使用し、各数字は 5ビット(2 ⁵ ) の異なる組み合わせを表します。Base32 はあまり広く採用されていないため、表記法の問題 (32 桁を表すためにどの文字を使用するか)は、 RFCや非公式および事実上の標準は存在しますが、よりよく知られている数値システム ( 16 進数など)の場合ほど決まっていません。Base32 の数値を人間が読める形式で表す 1 つの方法は、0 から 9 の数字に続いて 22 個の大文字の A から V を使用することです。ただし、さまざまなコンテキストで他の多くのバリエーションが使用されています。歴史的に、Baudot コードは修正された (ステートフルな) Base32 コードと考えることができます。

32 個の記号は 0、1、2、3、4、5、6、7、8、9、A、B、C、D、E、F、G、H、I、J、K、L、M、N、O、P、Q、R、S、T、U、V です。

この記事では、Base64の形成方法と同様に、符号なし整数ではなくバイト文字列を表すためのBase32の使用に焦点を当てています。

G は 16、H は 17、I は 18、J は 19、K は 20、L は 21、M は 22、N は 23、O は 24、P は 25、Q は 26、R は 27、S は 28、T は 29、U は 30、V は 31、10 は 32

2006 年 10 月に提案されたインターネット標準^[1] RFC  4648 では、base16、base32、および base64 エンコーディングが文書化されています。base32 には 2 つのスキームが含まれていますが、一方を他方よりも推奨しています。さらに、前例に関わらず、セクション 6 で定義するアルファベットのみを実際に base32 と呼ぶことを推奨し、セクション 7 のもう 1 つの同様のアルファベットは base32hex と呼ぶことを推奨しています。^[a]これらの推奨事項への同意は普遍的ではありません。base32 と呼ばれるシステムを使用する場合は注意が必要です。これらのシステムは、RFC 4648 §6 または §7 (後者のより簡単な名前が RFC で非推奨になっていることは無視される可能性があります) に従って base32 である可能性があり、さらに別のエンコーディングのバリアントである可能性もあります (以下を参照)。

最も広く使用されている^{[引用が必要]} base32アルファベットは、RFC 4648 §6および以前のRFC  3548 (2003)で定義されています。このスキームは、もともと2000年にJohn MyersによってSASL / GSSAPI用に設計されました。[ 2 ] A ^～Zのアルファベットを使用し、その後に2～7が続きます。数字0、1、8は、文字O、I、Bと類似しているためスキップされます（したがって、「2」の10進値は26です）。

状況によっては、パディングは不要または使用されません (パディングは、文字列の長さを 8 で割ったものから推測できます)。RFC 4648 では、標準の仕様 (RFC を参照) で明示的に指定されていない限り、パディングを使用する必要があると規定されています。パディングを除外することは、パディング文字が問題を引き起こす可能性がある URL トークンまたはファイル名で Base32 でエンコードされたデータを使用する場合に便利です。

これは、前述の 32 文字セット ( Base32 大文字エンコードのIPFS CIDv1)を使用した Base32 表現の例です。BAFYBEICZSSCDSBS7FFQZ55ASQDF3SMV6KLCW3GOFSZVWLYARCI47BGF354

「拡張16進数」基数32またはbase32hex ^[3]は、RFC 4648 §7に基づく基数32の別の方式であり、16進数をより自然な方法で拡張します。その下半分は16進数と同じで、それを超えると、base32hexはアルファベットを文字Vまで単純に継続します。

この方式は、 Sage softwareのプログラマーである Christian Lanctot が、1999 年 3 月にDr. Dobb's誌に宛てた手紙の中で、Y2K バグの解決策の一部として初めて提案しました^[4]。Lanctot はこれを「Double Hex」と呼びました。同じアルファベットは、2000 年にRFC 2938 で「Base-32」という名前で説明されました。RFC 4648 は、 NSEC3 でこのバージョンが既に使用されていることを認めながらも、これを base32hex と呼び、「base32」のみで参照することを推奨していません。

この表記法は0～9の数字の後にアルファベットの連続文字を使用するため、 10より大きい基数（16や32など）が指定された場合、 JavaScript parseInt()関数^[5]やPython int()コンストラクタ^[6]で使用される数字と一致します。また、RFC 4648の§6 base32やbase64とは異なり、表現されたデータのビット単位のソート順序を保持する16進数の特性も保持します。^[3]

他の多くの 32 進表記システムとは異なり、base32hex では 9 を超える数字は連続しています。ただし、その数字セットには視覚的に競合する可能性のある文字が含まれています。適切なフォントを使用すれば、0、O と 1、I を視覚的に区別できますが、他のフォントは不適切である可能性があります。これらの文字は、特に英語が通常提供するコンテキストが数字のみを表す表記システムに存在しない場合は、人間が区別するのが難しい場合があります。^[b] フォントの選択は表記やエンコードによって制御されませんが、base32hex では影響を受けるフォントの欠点を補う試みは行われません。^[c]

Base32 アルファベットを変更すると、すべての代替標準には同様の英数字記号の組み合わせが存在します。

z-base-32 ^[7]は、 Zooko Wilcox-O'Hearnが人間が使いやすくコンパクトになるように設計した Base32 エンコーディングです。 1、8、9が含まれますが、l、v、0、2は含まれません。また、アルファベットの順序を変えて、より簡単な文字がより頻繁に使用されるようにします。^[要説明]ビット長が 8 の倍数でないビット文字列をコンパクトにエンコードし^[要説明]、末尾のパディング文字を省略します。 z-base-32 は Mnet オープンソース プロジェクトで使用され、現在はPhil ZimmermannのZRTPプロトコルとTahoe-LAFSオープンソース プロジェクトで使用されています。

Base32の別の代替設計はDouglas Crockfordによって作成され、mod-37チェックサムに追加の文字を使用することを提案しています。^[8]数字との混同を避けるために、文字I、L、およびOが除外されています。また、偶発的な猥褻さの可能性を減らすために、文字Uも除外されています。

Crockford の Base32 でバイナリ データをエンコードするライブラリは、さまざまな言語で利用できます。

32 進表記法の以前の形式は、Electrologica X1で作業するプログラマーがマシン アドレスを表すために使用していました。「数字」は 0 から 31 までの 10 進数で表されました。たとえば、12-16 はマシン アドレス400 (= 12 × 32 + 16)を表します。

ジオハッシュアルゴリズムを参照してください。これは、緯度と経度の値を1つの（ビットインターレース）正の整数で表すために使用されます。^[9]ジオハッシュのbase32表現では、次の文字マップに示すように、すべての10進数（0〜9）と、文字「a」、「i」、「l」、「o」を除くほぼすべての小文字のアルファベットが使用されます。

NVRAM が普及する前、任天堂プラットフォームのいくつかのビデオゲームでは、パスワードに 31 進数の数字が使用されていました。これらのシステムでは、ゲームが誤って卑猥なパスワードを入力しないように、母音 (Y 以外) が省略されています。したがって、文字は通常、次のセットのわずかなバリエーションになります: 0～9、B、C、D、F、G、H、J、K、L、M、N、P、Q、R、S、T、V、W、X、Y、Z、および一部の句読点。このようなシステムを使用していることが知られているゲームには、 Mario Is Missing!、Mario's Time Machine、Tetris Blast、およびThe Lord of the Rings (Super NES) などがあります。

単語セーフな Base32 アルファベットは、Open Location Code Base20アルファベットの拡張版です。このアルファベットは、誤って単語を形成しないように選択された 8 桁の数字と 12 桁の大文字と小文字を区別する文字を使用します。アルファベットを大文字と小文字を区別して扱うと、32 桁 (8+12+12) のセットが生成されます。

Base32 にはBase64に比べて多くの利点があります。

1. 結果として得られる文字セットはすべて 1 つの大文字と小文字で構成され、大文字と小文字を区別しない ファイルシステム、DNS名、話し言葉、または人間の記憶を使用する場合に役立つことがよくあります。
2. 結果は、Unix パス区切り記号である '/' 記号を含めることができないため、ファイル名として使用できます。
3. アルファベットを選択すると、見た目が似ている異なる記号のペアを避けることができるため、文字列を手動で正確に転記できます。(たとえば、RFC  4648 §6 の記号セットでは、1、8、0 の数字が省略されています。これは、これらの数字が文字「I」、「B」、「O」と混同される可能性があるためです。)
4. パディングを除外した結果は、文字をエンコードせずにURLに含めることができます。

Base32 には16 進数/ Base16に比べて次のような利点があります。

1. Base32 表現では、必要なスペースが 20% 少なくなります。(1000 ビットでは 200 文字、Base16 では 250 文字)

8 ビット ベースのエンコーディングと比較して、5 ビット システムは文字の伝送に使用する場合に次のような利点もあります。

1. 完全なアルファベットを備えた RFC 4648 §6 Base32 スキームおよび類似のスキームでは、32 ビット整数ごとにさらに 2 文字をエンコードできるため (合計 4 文字ではなく 6 文字になり、2 ビットの余裕があります)、無線メッシュなどの制約のあるドメインで帯域幅を節約できます。

Base32 表現は、 Base64よりも約 20% 多くのスペースを必要とします。また、3 つの 8 ビット バイト (24 ビット) を 4 つの 6 ビット base64 文字にエンコードするのではなく、5 つの 8 ビット バイト (40 ビット) を 8 つの 5 ビット base32 文字にエンコードするため、8 文字境界へのパディングは短いメッセージでは大きな負担となります (これが、RFC  4648 のオプションであるパディングを省略する理由になる場合があります)。

Base32 は16 進数よりも約 20% 少ないスペースしか必要としませんが、Base32 の使用頻度ははるかに低いです。16 進数は 2 桁で 1 バイトなので、16 進数は簡単にバイトにマッピングできます。Base32 は個々のバイトにマッピングしません。ただし、Base32 の 2 桁は 10 ビットに対応し、(32 × 32 =) 1,024 の値をエンコードできます。これは、 1,024 の累乗で表す複数バイト単位の桁数に明らかに適用できます。

16 進数は、6 つの追加記号 (A ～ F) の数値を記憶するだけで済むため、学習や記憶が簡単です。また、すぐに思い出せなくても、いくつかの値を数える方が簡単です。

Base32プログラムは、人間が便利に使用でき、コンピューターで処理できる制限されたシンボルのセットを使用して任意のバイト データをエンコードするのに適しています。

Base32 実装では、少なくとも 32 の異なる文字 (場合によってはパディング用に 33 文字目) で構成されるシンボル セットと、任意の 8 ビット バイト シーケンスを Base32 アルファベットにエンコードするアルゴリズムを使用します。各 8 ビット入力バイトを表すには 1 つ以上の 5 ビット Base32 文字が必要なため、入力が 5 バイト (40 ビット) の倍数でない場合は、5 ビット Base32 文字に正確には収まりません。その場合、一部の仕様ではパディング文字の追加が求められ、一部の仕様では 5 ビットの倍数にするためにゼロ ビットの追加が求められます。これと密接に関連する Base64 システムでは、64 個のシンボル セット (パディングを使用する場合は 65 個のシンボル) が使用されます。

^{C/C++、 [10] [11]} Perl、^[12] Java、^[13] JavaScript ^[14] Python、^[15] Go ^[16] Ruby ^[17]のBase32実装が利用可能です。 ^[18]

• RFC  4648