Base58 / Base62 / Base100 のエンコードとデコード

機能

• 4つの方式：Base58（Bitcoin）・Base58（Flickr）・Base62・Base100
• Base58 は2つのアルファベットに対応 —— 互換性がなく、同じデータでもまったく別の文字列になります
• Base100 は stek29 の仕様に準拠：各バイトが U+1F3F7〜U+1F4F6 の emoji 1文字に対応
• 日本語や emoji は UTF-8 バイトとして処理し、Bitcoin ウォレットなどの実装と一致します
• 先頭の 0x00 バイトを正しく保持します —— Bitcoin アドレスのバージョンバイトがまさにそれです
• アルファベット外の文字は、どの文字かを示してエラーにします（黙って捨てません）
• ⚠️ 形式の正しいBitcoin アドレスをまとめて生成もできます（メインネット／テストネット、P2PKH／P2SH）。テストデータ用です —— これらのアドレスの秘密鍵は誰も持っていません

使い方

1. 方向を選びます：エンコード、デコード、または「Bitcoin アドレスを生成」
2. エンコード／デコードでは方式を選びます（Base58 はアルファベットが2種類あるので注意してください）
3. 入力欄に内容を貼り付けると、結果がリアルタイムで表示されます
4. 「コピー」で結果を取り出せます

よくある質問

Base58 が 0・O・I・l を外しているのはなぜですか？

想定しているのが「画面と見比べている人間」だからです。多くのフォントで 0 と O、l と I は判別しづらく、Bitcoin アドレスで1文字読み違えると、存在しないか他人のアドレスへ送金され、取り戻せません。4文字減らす代償は長さ約 3% ですが、人的ミスの一大カテゴリが消えます。Bitcoin アドレスにこれらの数字と文字が決して現れないのはこのためです。

Bitcoin と Flickr の Base58 アルファベットは何が違いますか？

大文字がどの位置に来るかだけです。Bitcoin は先頭（123456789ABC…abc…）、Flickr は末尾（123456789abc…ABC…）に置きます。どちらも 0・O・I・l を含みません。両者は互換性がなく、誤った表でデコードすると全く別のバイト列が出てきます —— しかもエラーは出ません。相手の実装がどちらの表を使っているか、先に確認してください。

Base100 とは何ですか？なぜ結果が長くなるのですか？

Base100 は各バイトを固定の emoji に対応させます（n 番目のバイトがコードポイント U+1F3F7 + n）。進数変換を行わない、1バイト対1文字の固定長符号化です。したがって体積は必ず増えます：1バイトは UTF-8 で 3〜4 バイトを占め、そこに emoji 自身のバイト数が加わります。圧縮でも暗号化でもなく、「印刷可能文字しか見ないフィルター」の前でデータを絵文字の列に見せるためのものです。

「有効な UTF-8 テキストではありません」と出るのはなぜですか？

その文字列が文字ではなくバイナリを運んでいるためです。Base58 の主な用途はバイナリデータの符号化です —— Bitcoin アドレスにはバージョンバイト、公開鍵ハッシュ、チェックサムが入っており、人が読むテキストではありません。本ツールの出力はテキスト欄なのでバイナリは表示できません。文字化けを返すより、明確にエラーを出すほうが親切だと考えています。

「1」で始まる Base58 をデコードすると余分なバイトが出るのはなぜですか？

Base58 は「大きな整数」の表現で、その表記は先頭の 0x00 バイトを自然に飲み込んでしまいます —— [0x00, 0x41] と [0x41] は数値として完全に同じです。正しく往復させるため、先頭の 0x00 バイトはそれぞれアルファベットの先頭文字（Bitcoin の表では「1」）として書くという約束になっています。つまり先頭の「1」はそれぞれ実在の 0x00 バイトであり、パディングではありません。Bitcoin アドレスがバージョンバイトを保っているのはこの仕組みによるものです。

生成した Bitcoin アドレスで送金を受け取れますか？

いいえ。そしてこれは明確にしておく必要があります：これらのアドレスへ送ったコインは失われ、誰も取り戻せません。 実際の Bitcoin アドレスは「公開鍵の HASH160」ですが、ここでは 20 バイトの乱数をそのまま HASH160 として使っています。統計的には本物のアドレスと区別がつきませんが、対応する秘密鍵は一度も生成されておらず、誰も持っていません。したがって用途はただ一つ、テストデータです。デモ、スクリーンショット、ドキュメント、テストのフィクスチャに正しい形式のアドレスが必要なとき、本物のアドレスを使えば第三者の受取アドレスを公開してしまいますが、ここで出るのはランダムで所有者のいないアドレスです。ブロックチェーンに現れることもありません —— 形式が正しいだけの文字列です。

SegWit の bc1 アドレスが無いのはなぜですか？

bech32 は Base58 ではないからです。`bc1q…` はまったく別のアルゴリズムを使います：別のアルファベット（32 文字、すべて小文字）と別のチェックサム（BCH 符号。最大4文字の書き間違いを*訂正*できますが、Base58Check のチェックサムは誤りを*検出*するだけです）。Base58 の変種に紛れ込ませると、符号化方式が自由に interchange できるかのような誤解を生みます —— 実際には表を替えれば全く別のものになります。SegWit には専用の bech32 ツールをお使いください。なお、このページが生成するのは Base58Check のアドレス（P2PKH／P2SH）で、ニーモニックも秘密鍵も含みません —— アドレスであってウォレットではありません。