Base64

3バイト24ビットを、6ビットずつ4個へ分け直す文字だけの経路を通した後、同じバイトへ復元する

3バイトを4文字へ組み替える

パディングは末尾の不足を示す

入力長が3の倍数でなければ最後の組が足りません。1バイト余ると通常==、2バイト余ると=を末尾へ付け、最後に有効な情報がどこまであるかを示します。

仕様によっては長さが別に分かるためパディングを省略できます。受信側がパディング必須か省略可かを取り決めずに削除すると、厳格なデコーダーで拒否されます。

標準Base64とBase64url

base64url（ベース64ユーアールエル）は、URLやファイル名で扱いにくい+と/を、それぞれ-と_へ置き換えた字母です。JWTなどで使われます。パディングを省略する仕様もあります。

二つは似ていますが、字母とパディング規則を黙って混在させません。「Base64」とだけ記録せず、標準かURL-安全か、改行とパディングをどう扱うかを明示します。

容量は増え、圧縮にはならない

3バイトが4文字になるため、本体はおおむね4/3倍になります。さらにJSONの引用符、メールの改行、データURLの接頭辞が加わります。巨大ファイルをAPIのJSONへ埋め込むと、メモリ使用量と転送量が増えます。

大きなファイルはマルチパート送信、オブジェクトストレージへの直接アップロード、ストリーミングなどを検討します。圧縮するなら、Base64化する前にバイナリを圧縮します。

改行と不要文字の扱い

RFC 4648の基本規則では、参照する上位仕様が指示しない限り、エンコーダーが勝手に改行を挿入しません。MIMEメールでは歴史的な行長規則に従って折り返す場合があります。

デコーダーが空白や字母以外の文字を無視するか、厳格に拒否するかも用途で違います。署名値や認証情報では、許容範囲の差によって別の文字列が同一視されないよう、canonical form（カノニカル・フォーム／正規形）を決めます。

暗号化・ハッシュ・圧縮との違い

Base64文字列は復号鍵なしで元へ戻せます。パスワード、APIキー、個人情報をBase64にしただけでは保護になりません。通信はHTTPSなどで暗号化し、保存時も目的に合う暗号化とアクセス制御を使います。

ハッシュは通常元へ戻せない一方向の要約、圧縮は情報を保ったままサイズを減らす処理です。Base64は「バイト列を限定した文字集合で表し直す」可逆の符号化です。

使われる場所

メール添付では、MIMEのContent-Transfer-Encodingとしてバイナリを安全な文字列へします。JSONの文字列へ小さなバイナリを入れる場合や、データURL、Basic認証の資格情報表現にも現れます。

用途ごとに「何をBase64化したか」が違います。文字列なら先にUTF-8などでバイト列へし、そのバイトをBase64化します。復号後も、どの文字エンコーディングで文字へ戻すかが必要です。

Base64は3バイトを4文字へ表し直す可逆の符号化です。標準とBase64url、パディング、改行規則を区別し、暗号化や圧縮の代わりには使いません。

字母・padding・改行・canonical encoding：RFC 4648