任意の 2 つのエンコーディング間で変換する手順
- 文字列を入力欄に貼り付けます。変換元 が 自動検出 のときは、ツールが推定した形式がステータス行に「検出：Base58 · 違う場合は次の形式で読む：[Base64] …」のように表示されます。
- 推定が間違っていたら、「違う場合は次の形式で読む」のボタンのどれかをクリックするか、変換元 を自分で設定します。
- 変換先 で出力の形式を選びます。形式は、テキスト、Base64、バイト・数値、Base32、多倍長整数の基数、Base85・Base91・Base45、メール・URL・レガシーのグループに分かれています。
- 各形式のオプションはそれぞれの欄の下に表示されます。たとえば Base58 と Base62 には アルファベット、Base32 と Base64 には パディング（=） があります。
- ⇄ 入れ替え を押すと、出力が入力に移り、2 つの形式が入れ替わります。結果は 出力をコピー と ダウンロード で取り出せ、バイトを保存 でデコードしたバイト列をファイルとしてダウンロードできます。
どの変換も生のバイト列を経由します。入力をデコードし、そのバイト列を再びエンコードします。ツールの下の バイト のカウンターにはその数が表示され、鍵やハッシュが欠けていないかを確かめる最も手早い方法になることがよくあります。上に並んでいる単機能のページは、この同じ変換ツールを形式を設定済みの状態で開きます。
エンコーディングの比較
| エンコーディング | 文字数 | 出力サイズ | オーバーヘッド | 主な用途 |
|---|---|---|---|---|
| Hex / Base16 | 16 | 1 バイトあたり 2 文字 | 100% | ハッシュ、デバッグ、バイトダンプ |
| Base32 | 32 | 5 バイトあたり 8 文字 | 60% | TOTP のシークレット、onion アドレス、大文字小文字を区別しない ID |
| Base36 | 36 | 1 バイトあたり約 1.55 文字 | 約 55% | 大文字小文字を区別しない短い ID や数値 |
| Base45 | 45 | 2 バイトあたり 3 文字 | 50% | QR コード（EU のデジタル COVID 証明書） |
| Base58 | 58 | 1 バイトあたり約 1.37 文字 | 約 37% | Bitcoin、Solana、IPFS |
| Base62 | 62 | 1 バイトあたり約 1.34 文字 | 約 34% | 短縮 URL や ID |
| Base64 | 64 | 3 バイトあたり 4 文字 | 33% | メール、JSON、data URI、JWT など、ほぼあらゆる場面 |
| Ascii85 / Z85 | 85 | 4 バイトあたり 5 文字 | 25% | PDF、PostScript、Git、ZeroMQ の鍵 |
| basE91 | 91 | 1 バイトあたり約 1.23 文字 | 14〜23% | 印字可能な ASCII にデータを詰め込む |
| Uuencode / xxencode | 64 | 3 バイトあたり 4 文字と行の枠組み | 約 38% | 昔のメールや Usenet の添付ファイル |
オーバーヘッドはランダムなデータの場合の値で、多倍長整数の基数では値によって 1〜2 文字変わります。Base45 はここでは無駄が多く見えますが、QR コードの英数字モードでは 45 文字がそれぞれ 5.5 ビットで済むため、約 3% にまで近づきます。
1 つの入力で比べると、5 バイトの文字列 Hello はそれぞれ次のようになります。
| Hex | Base32 | Base36 | Base45 | Base58 | Base62 | Base64 | Ascii85 | basE91 |
|---|---|---|---|---|---|---|---|---|
48656c6c6f | JBSWY3DP | 3yud78mn | %69 VDL2 | 9Ajdvzr | 5TP3P3v | SGVsbG8= | 87cURDZ | >OwJh>A |
基数エンコーディングの 3 つの作り方
エンコーディングは 3 つのグループに分かれ、どのグループかでその振る舞いのほとんどが説明できます。
ビットグループ型：16進数、Base32、Base64、uuencode、xxencode。アルファベットの文字数が 2 のべき乗なので、1 文字が固定のビット数（4、5、6 ビット）を運びます。エンコードは高速で、ストリームとして処理でき、出力の長さは入力の長さだけで決まります。
固定ブロック型：Base45（2 バイトを 3 文字に）と Base85 系（4 バイトを 5 文字に）。アルファベットの文字数が 2 のべき乗ではないため、小さなブロックを数値として変換します。こちらも高速でストリーム処理でき、長さはやはり入力サイズで決まります。
多倍長整数型：Base36、Base58、Base62。入力全体を 1 つの数とみなし、新しい基数で書きます。アルファベットの文字数は何でもよく、出力にパディングもありませんが、どのバイトもすべての文字に影響し、先頭のゼロバイトには特別な扱いが必要で、コストはサイズの 2 乗に比例して増えます。この変換ツールは先頭のゼロを先頭のゼロの桁として保持し、これらの基数の入力を 64 KB までに制限しています。
basE91 はグループの中間に位置します。13 ビットまたは 14 ビットずつ読むため、長さが内容にわずかに左右されます。
どのエンコーディングを選ぶか
- プログラム同士のやり取り：Base64、URL やトークンの中なら Base64URL です。どの言語にも組み込まれていて、これほど広く通じるものはほかにありません。
- 人が読む、入力する、読み上げる値：Base32（できれば Crockford 版）か Base36 です。どちらも大文字と小文字を区別せず、Crockford 版は紛らわしい文字も避けています。
- URL 内の短い不透明な ID：英数字だけで最も短くしたいなら Base62、人が手で書き写す可能性があるなら
0、O、I、lを除いた Base58 です。 - QR コード：Base45 と QR の英数字モードの組み合わせです。
- 1 バイトも無駄にできず、通信路がプレーンな ASCII：固定ブロックなら Ascii85 か Z85、さらに数パーセント削るなら basE91 です。
- バイト列の調査：16進数です。サイズは 2 倍になりますが、どのバイトも読める 2 文字になります。
- レガシーシステムが要求する場合：uuencode か xxencode です。新しく使うものではありません。
Base64 と比べたトレードオフは、16進数、Base32、Base58、Base85 の比較 でさらに詳しく説明しています。
よくある質問
バイナリデータを最もコンパクトに表せるテキストエンコーディングは？
一般的なものの中では basE91（ランダムなデータでオーバーヘッド約 23%）が最も小さく、次が Base85 系（25%）、その次が Base64（33%）です。よりコンパクトなエンコーディングは JSON、HTML、シェルでエスケープが必要な記号を使うので、結局 Base64 のほうが得策になることがよくあります。
URL に最適なエンコーディングはどれですか？
機械が生成するトークンなら、短く標準化されている Base64URL です。英数字だけにしたいなら Base62 か Base58、大文字と小文字が変わっても壊れてはいけないなら Base32 か Base36 を使います。Base45 と Base85 にはパーセントエンコードが必要な文字が含まれます。
Base58、Base62、Base36 の出力の長さが一定しないのはなぜですか？
入力を 1 つの大きな数として扱うため、長さがバイト数だけでなくその値にも左右されるからです。Base64、Base32、16進数は固定のビットグループを対応させるので、同じバイト数なら常に同じ長さになります。
自動検出はどうやって文字列の形式を判断していますか？
入力を各形式のルールと照らし合わせます。最も特徴的なもの（<~ や begin 644 のような区切り）から最も一般的なものへと順に調べ、最初に一致した形式でデコードします。短い文字列は複数の形式で有効なことがあるので、「違う場合は次の形式で読む」のボタンで別の読み方を選べます。
これらのエンコーディングでデータは保護されますか？
いいえ。どれも鍵なしで誰でも元に戻せます。バイト列を印字可能にするだけです。エンコードと暗号化の違い をご覧ください。