HEX vs Base64 vs Base58 — バイナリをテキストで表現するならどれ?

バイナリをテキストにする 4 つの判断軸

バイナリデータ (ハッシュ、暗号鍵、画像、トークン) をテキストで持ち運ぶときに使うのが「バイナリ → テキスト」のエンコーディングです。代表格は HEX (Base16) / Base64 / Base58 の 3 つで、選び方は サイズ効率 (何倍に膨らむか)、文字集合 (どの文字が出てくるか)、URL 安全性 (URL や JSON に直接埋められるか)、可読性 (人間が読み上げ・書き写しできるか) の 4 軸で決まります。

「Base64 が一番」「最近は Base58 が流行り」みたいな単純な序列はありません。SHA-256 ハッシュをログに残すなら HEX、メールに画像を添付するなら Base64、Bitcoin アドレスを QR コードで配るなら Base58、というように、扱うバイナリの長さ・運搬経路・受け取り手によって最適解が変わります。サイズだけ見れば Base64 が最良ですが、URL に乗せると + / = が壊れる、人間に読み上げてもらうと 0 と O を間違える、といった現実の摩擦が選択を左右します。

3 種類のエンコーディングを並べる

項目	HEX (Base16)	Base64	Base58
文字集合のサイズ	16	64	58
使う文字	0-9, a-f	A-Z, a-z, 0-9, +, /	A-Z, a-z, 1-9 (0, O, I, l 除外)
パディング	不要	= (4 文字境界)	不要
1 文字あたりのビット数	4 bit	6 bit	約 5.86 bit
サイズ膨張率	200% (2 倍)	約 133% (4/3 倍)	約 137% (1.37 倍)
URL 安全	安全	不安全 (+ / =)	安全
紛らわしい文字	なし	+ と / が記号	意図的に除外済み
大文字小文字	区別なしで運用可	区別あり	区別あり
代表的な用途	ハッシュ表示、MAC アドレス、メモリダンプ	メール (RFC 2045)、data URI、JWT	Bitcoin アドレス、IPFS CID v0、Solana
標準化	RFC 4648	RFC 4648	de facto (Bitcoin 由来)

サイズ膨張率は 元のバイナリ N バイトを文字列にしたときに何バイトになるか の目安です。32 バイトの SHA-256 ハッシュなら HEX で 64 文字、Base64 で 44 文字 (パディング込み)、Base58 で約 44 文字になります。Base64 の = パディングは入力長を 3 バイト単位に丸めるためのもので、改行を入れる MIME 用 (76 文字ごと折り返し) と PEM 用 (64 文字ごと折り返し) で挙動が違う点に注意してください。Base58 は 0 (ゼロ)、大文字 O (オー)、大文字 I (アイ)、小文字 l (エル)、それと記号 + / を意図的に除外しているため、人間が紙に書き写したり電話口で読み上げたりしても誤認しにくい設計です。

ユースケース別の推奨

ファイルハッシュ・MAC アドレス・バイナリダンプ: HEX。サイズは 2 倍に増えますが、人間が「a3 b5 7f…」と区切って読みやすく、md5sum や sha256sum などの既存ツールの出力もすべて HEX です。xxd や hexdump で見るときの可読性は他のエンコーディングでは出せません。

API トークン・メール添付・data URI: Base64。最もサイズ効率が良く、SMTP / HTTP ヘッダー / JSON フィールドにそのまま乗せられます。JWT (header.payload.signature) も Base64URL でエンコードされた 3 つのパーツで構成されます。注意点は Base64 と Base64URL は別物 であること。標準 Base64 の + / = は URL クエリパラメータでは別の意味を持つため、URL に乗せるときは - _ (パディング省略) を使う Base64URL に切り替える必要があります。

ユーザーに短い URL で共有 / 二重クリックで選択させたい識別子: Base64URL または Base58。Base58 はハイフンやアンダースコアすら含まないため、テキストエディタやブラウザのアドレスバーで二重クリックすると 1 トークン全体が選択されます (- を含む Base64URL は途中で選択が切れます)。

暗号通貨アドレス・コンテンツ識別子: Base58。Bitcoin アドレスや IPFS の CID v0 (Qm... で始まる) はチェックサム付きの Base58Check 派生を採用しています。Base58Check は末尾 4 バイトに SHA-256 の二重ハッシュ先頭を付けて、1 文字でも書き間違えると検出できるようになっています。Solana のアカウントアドレスも Base58 (チェックサムなし) です。

ブラウザで完結する変換と落とし穴

実際の作業では「サーバーログにある Base64 文字列を iv: ... の HEX に直したい」「JWT の payload を Base64URL でデコードしたい」のような変換が頻発します。シンプルに Base64 のエンコード / デコードだけ済ませたいなら base64 が最短経路で、Base16 / Base32 / Base58 / Base64 のあいだを切り替えながら相互変換したいときは base-codec を使ってください。どちらもブラウザ内で完結し、秘密鍵や API トークンを貼り付けても外部サーバーへ送信されません。実装は GitHub で確認でき、DevTools の Network タブで送信ゼロを目視できます。

代表的な落とし穴を 3 つ。1 つ目、Base64 文字列を URL に直接埋め込むと壊れる: + がスペースに、/ がパス区切りに解釈され、= がフォーム値として奪われます。URL に乗せるなら最初から Base64URL を生成するか、encodeURIComponent を通すかを徹底してください。2 つ目、HEX の大文字小文字を機械的に揃えない: 多くの API は 0xDEADBEEF と 0xdeadbeef を同一視しますが、SHA-256 ハッシュの一致比較を文字列で行うと一方が小文字、もう一方が大文字で偽陰性になります。比較前にバイト列に戻すか、両者を toLowerCase() してから比較してください。3 つ目、Base58 を 0 (ゼロ) なしの BTC アルファベットで運用しているライブラリと、Ripple 系の別アルファベットを混ぜない: 同じ「Base58」を名乗っていてもアルファベットが違うとデコード結果が壊れます。受信側のアルファベットを必ず仕様書で確認してください。