Base64とHexの違い

同じバイト列、2つのアルファベット

どちらのエンコーディングも1つの問題を解決します。バイトは8ビットの値ですが、テキストで運ぶ経路――URL、ヘッダー、XML、JSON、メール――は印字可能なASCIIを最も好む、ということです。Hexは0-9とa-fの16文字を、base64はA-Z、a-z、0-9、+、/を使います。どちらも暗号化も圧縮もしません。仕様は公開され、鍵は不要で、即座に逆変換できます。base64文字列は輸送の安全であって、セキュリティではありません。

算術：1/3と2倍

Hexはニブル単位に整列します。バイトは2つの4ビットの半分に分かれ、それぞれが1文字として描画されるため、長さは予測可能です。nバイトの値は常に2n文字で、パディングも例外もありません。Base64はビットを6ビットの塊に組み替えます。24ビットはバイトの世界とbase64の世界が最初に整列する地点であり、3バイトが4文字になります。残りが1バイトなら==に、2バイトなら1つの=にパディングされます。

計算例の1組が比率を具体的にします。Hiのバイト列はhexでは48 69（4文字）、base64ではSGk=（これもパディング込みで4文字）です。実規模になると差が支配的になります。1メガバイトのデータは、パディング付きbase64では約1.33 MB、hexでは正確に2 MBです。大量輸送がbase64に標準化され、短い値はhexのまま残ったのはこのためです。

それぞれの棲み分け

Base64の領分は大量と輸送です。MIMEはメール添付に使い、HTTP Basic認証は資格情報をこれでエンコードし、JWTはヘッダー、ペイロード、署名をbase64urlにし、data: URIは画像やフォントをページやスタイルシートに直接埋め込み、クッキーはbase64url値を運びます――+と/はURLやヘッダーの中で問題を起こすためです。バイナリがテキスト専用のパイプを最小コストで生き延びなければならない場所では、どこでも答えはbase64です。

Hexの領分は小さな値と、人間が目で確認するものです。暗号学的ダイジェストは慣例でhex表示されます――SHA-256の出力、gitのコミット識別子――幅が固定で、パディングがなく、バイト単位に揃ったペアは、目視でも口頭でも比較が簡単だからです。MACアドレス、UUIDのテキスト形式、#RRGGBBのようなCSSの色はすべてhexです。hexエディタ、メモリダンプ、プロトコルデバッガがhexを使うのは、すべてのバイトが自己完結した単位として読めるからです。

落とし穴と、どちらを選ぶか

Base64の落とし穴はすべてアルファベットの中にあります。標準とURLセーフの変種は2文字違いで、決して混ぜてはいけません。パディングは厳格なデコーダーには必須なのに、JWTの慣例では剥ぎ取られます。出力は大文字小文字を区別します。そしてMIMEは76文字で行を折り返します。Hexの落とし穴は1つだけです。大文字小文字です。小文字が慣例で、大文字を使うツールもありますが、混在しても見た目の問題――どの厳格なデコーダーもどちらでも受け付けます。

つまり、ボリュームが問題になるか、プロトコルが要求するときはbase64――添付、トークン、埋め込みバイナリです。人間が比較、コピー、デバッグする短い値にはhex――ダイジェスト、識別子、色です。実際のシステムでは選択は絶えず入れ替わります。JWTはbase64urlで届き、そのSHA-256フィンガープリントはhexです。下のコンバーターが、この渡りをブラウザ内で処理します。