Base32 と Base58 とは何か？
これらは 1 つの問いへの 2 つの答えです：テキストを運ぶ経路がバイトの運搬を求められた。Base32 と Base58 は暗号化でもハッシュでもありません — 何も隠さず、何も短くもしません。バイト列を固定の読める文字集合で書き直すだけで、どの集合が使われたかを知る者は誰でもそれをそのまま戻せます。一方を他方より好む唯一の理由は、受け側がその文字をどう扱うかです。
2 つのファミリーがこの書き直しをまったく別の方法で行い、その違いがこのページのほぼすべての驚きを説明します：
- ビットパッキング — Base32、Base32 Hex、Crockford Base32、z-base-32。バイトは固定グループに切られ、5 ビットごとに 1 文字になります。出力長は入力長から予測可能で、最後の部分的に埋まったグループはパディング文字で示されるか、短いまま残されます。
- 大数変換 — すべての Base58。バイト列全体が base 256 の巨大な 1 つの数として読まれ、base 58 で書き出されます。グループもパディングもなく、長さは何でも割り切れず、先頭の各ゼロバイトが先頭のゼロシンボル 1 個になります。
データを運ぶ 6 ビットがどこへ行くか：Base32 は 1 文字に 5 ビットを使うため、入力 5 バイトごとに 8 文字必要です — 約 60% 増。Base58 は 1 文字あたり約 5.86 ビットで、約 37% 増に収まります。Base64 は 1 文字 6 ビットで 33%。アルファベットが大きいほど短く、口頭で読みにくくなります — それぞれがまさにこの交換をしています。
このページの 7 つのアルファベット
すべてのアルファベットは説明ではなく全文を掲載しています。同じ名前で違う文字を表示する 2 つのツールは、ラベルが何であれ一致しないからです。RFC 4648 の行は規定です。Crockford と z-base-32 の行は形式の作者が公表したものに従い、3 つの Base58 行は標準ではなく広く普及した慣習なので、別々に列挙しています。
Crockford Base32 と mod 37 チェックシンボル
Crockford のアルファベットは、どのシンボルも別のシンボルと読まれないよう I、L、O、U を落としています。残りは入力時には大文字小文字を区別しません：i と l は数字 1、o は数字 0 として読まれ、ハイフンは長い文字列を読みやすくするためだけに存在します。さらに形式は任意のチェックシンボルを定義します。シンボル列を base 32 の数として読んだ値を 37 で割った余りで、値 32〜36 のために 5 つの追加シンボルで書かれます。
チェックシンボルはバイトではなくシンボル列に対して計算されます：エンコーダーが最終グループをゼロ拡張するため、同じ文字をデコードすれば常に同じ値に戻るからです。だから表のチェック値は、エンコード列だけから手計算で再現できます。5 つの追加シンボルは値 32〜36 に対する *、~、$、=、U で、チェックシンボルは常に数字か文字とは限りません。
z-base-32
z-base-32 は RFC 4648 Base32 の 5 ビットパッキングを保ち、32 文字の並び順だけを変えています。この順序は、人が書き留める可能性が最も高い文字が、最も書きやすく最も混同しにくいものになるよう選ばれています。パディングがないため、読み手は値が何シンボルのはずかを知っている必要があります — 手で読むために設計された形式の代償です。
Base58Check：バージョンバイト 1 個、ペイロード、チェックサム 4 バイト
Base58 単体には、打ち間違えた文字列と正しい文字列を区別する方法がありません。58 文字のほぼ任意の組み合わせが有効な数だからです。Base58Check はデータをラッパーに入れることでこれを直します：バージョンバイト 1 個、ペイロード、そして前 2 つに SHA-256 を 2 回連続で適用した先頭 4 バイト。受け側のプログラムはこの 4 バイトを再計算し、異なれば文字列を拒否します。バージョンバイトが、ウォレットに対してそれが支払いアドレス、スクリプトアドレス、秘密鍵のどれかを教えます。
コンバーターの下の生成器はバージョンバイトとペイロードを 16 進で受け取り Base58Check 文字列を書き出します。検証器は 1 つを読み戻し、チェックサム 4 バイトを切り離し、再計算して、見つけたものと期待されるものの両方を報告します。チェックサム不一致は、文字列が打ち間違えられるか改変されたことを意味します — ペイロード自体は解釈されないので、ペイロードが間違っていることを意味することは決してありません。
よくある誤解
- 「Base64 は暗号化だ」 違います。鍵も秘密もなく、出力は誰でも元に戻せます。Base32 と Base58 も同じ立場で、値を 3 つ全部に通しても保護は加わりません。
- 「Base58 文字列は Bitcoin アドレスだ」 Base58Check のチェックサムを通り、受け側ソフトウェアが認識するバージョンバイトを運ぶときだけです。Base58 文字列は、チェックサムをまったく持たない単なる識別子など、他の多くの場所にも現れます。
- 「3 つの Base58 アルファベットは交換可能」 同じ 58 文字を 3 つの異なる順序で使うため、同じバイトが 3 つの異なる文字列を生みます。ツールにはどれを使うか伝えなければならず、このページは常にどれを使ったかを明示します。
- 「パディングは値の一部」
= 文字は最終グループを示すだけです。パディングだけが違う 2 つの Base32 文字列は同じバイトを表すため、デコーダーはパディングを切り落とした文字列も受け付けます。
- 「どんな文字でも動く」 各アルファベットは固定集合です。外の文字には値がないため、デコーダーは推測せず、停止してその文字と位置を指摘します。
よく出る質問
Base32 が 0-9 でなく 2-7 を使うのはなぜ？ RFC 4648 が、ドメイン名に含めることができる文字内に収まり、かつ読み上げやすいようにアルファベットを選んだからです。自然なソートがより重要な場合は Base32 Hex が 0-9 A-V を使います。
Base58 文字列がよく 1 で始まるのはなぜ？ 入力の先頭の各ゼロバイトが、先頭の 1（Bitcoin と Flickr アルファベットの最初の文字）1 個になるためです。バージョンバイト 0x00 はゼロバイト 1 個なので、大半の Bitcoin メインネット アドレスはちょうど 1 個の 1 で始まります。
サンプルボタンは何を読み込む？ 現在画面にある方式と方向に対応する例であり、決して固定テキストではありません。エンコーダーには方式固有の例のテキストが（Base32 と Base32 Hex には RFC 4648 第 10 節のベクトル、Crockford には 12345、z-base-32 には上記の行）、デコーダーには選択中アルファベットのエンコード済み文字列が与えられます — だからサンプルは両方向で使えます。3 つの Base58 行は意図的に同じテキストを運び、方式を切り替えてサンプルをもう一度押すと、同じ 58 文字の 3 つの並びが並んで見えます。Crockford チェックシンボルにチェックがあるとき、デコーダーには末尾にシンボルの付いた値が渡され、検証器が受け入れる様子を見られる唯一の方法になっています。
このページはデータをどこかに送る？ 送りません。すべての変換はこのブラウザータブ内で行われ、ページにはいかなる種類のネットワーク呼び出しも含まれません。だからディスクから直接開いても動くのです。
秘密にはどれを使うべき？ TOTP と HOTP のシークレットは、手入力されるため通常 RFC 4648 アルファベットの Base32 です。受け側ソフトウェアが求めるものを使い、エンコーディング自体を秘密保持のために当てにしてはいけません。
