URL と data URI における Base64

URL、クエリ文字列、Cookie 近傍チャネルは + と / を扱いにくく — = パディングは雑な連結ロジックと相性が悪い。専用 Base64URL 方言はエスケープ需要を減らすためアルファベットを並べ替えます。

このレッスンは MIME Base64、RFC 4648 URL-safe、実用的な data: パターンを分けます。

標準 vs URL-safe アルファベット

古典 Base64 は 62 → '+'、63 → '/'。

URL-safe 実装（通称 base64url）は通常:

• +' → '-' に再マップ
• /' → '_' に再マップ
• 従う仕様で許されるときパディング省略（JWT の JWS はセグメントにパディングなし base64url）

方言を変換なしでエンコーダーとデコーダーを混在させない。+// で生成したトークンは、percent-encode かアルファベットを一貫して切り替えない限りパスセグメントに貼ると壊れます。

percent-encoding は依然発生

URL-safe Base64 でも厳格 URL パーサーコンテキストではエンコードが必要な文字があり得ます — ハイフンとアンダースコアは plus と slash よりマシですが、層ルールを完全には消しません。生 payload を脆い文字列テンプレートで囲むより、型付きビルダー API（URLSearchParams、フレームワークヘルパー）で URL を組み立ててください。

JWT クイック確認

学習目的の手動デコードは問題ありません — JWT header/payload は JSON UTF-8 バイト → パディングなし base64url です。+ が見えたら PEM や MIME 出力を見ている可能性があります。

data: URI

小さなアセットをインライン埋め込み:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...

構成:

部分	意味
MIME タイプヒント	ブラウザがバイトを解釈する助け
;base64, センチネル	続くものが Base64 エンコードバイト
payload	連結された（しばしば長い）ASCII チャンク

利点: プロトタイピング中の極小アイコンで HTTP リクエスト削減。

欠点:

• スタイルシートバンドル効率とは別キャッシュ
• HTML/CSS ソースを急激に肥大（gzip 前に約 33% 膨張）
• CSP やメールクライアントが禁止する場合

本番はハッシュ付き静的ファイル/CDN を好むことが多い — Base64 が失敗するからではなく、エンジニアリングトレードオフがキャッシュと分離を favor するから。

非常に大きな payload

巨大 data: URI はエディタ性能と DOM メモリを悪化させます。Web プラットフォームでは大バイナリにストリーム、blob、object URL（URL.createObjectURL）が適します。

要点

URL コンテキストは 文字セットの扱いやすさ と パディングの人間工学 の 2 軸に圧力をかけます。仕様が要求する variant（JWT vs PEM vs MIME）を選び、エッジバイトを忘れる ad hoc 文字列置換ではなく実績あるライブラリで変換を通してください。