URL-safe Base64エンコード

標準のBase64では +、/、= という文字を使用しますが、これらはURLやファイル名で特別な意味を持ちます。URL-safe Base64（Base64urlとも呼ばれ、RFC 4648 Section 5で定義）は、これらの問題のある文字を置き換えることで解決します：

標準Base64	Base64url
+	-（ハイフン）
/	_（アンダースコア）
=（パディング）	省略されることが多い

これが重要な理由： 標準Base64をURLのクエリパラメータに含めると、+ 文字はスペースとして解釈され、/ はパス区切り文字として解釈されます。URLエンコード（%2B、%2F）すれば回避できますが、文字列が長くなり読みにくくなります。Base64urlはこれらの問題を完全に回避します。

JavaScriptでのフォーマット変換：

// Standard Base64 to Base64url
function toBase64url(base64) {
  return base64
    .replace(/\+/g, "-")
    .replace(/\//g, "_")
    .replace(/=+$/, "");
}

// Base64url to Standard Base64
function fromBase64url(base64url) {
  let base64 = base64url.replace(/-/g, "+").replace(/_/g, "/");
  while (base64.length % 4 !== 0) {
    base64 += "=";
  }
  return base64;
}

Base64urlでのパディング： パディング文字 = はBase64urlでは省略されることが多いです。デコーダーは文字列の長さから元の長さを推測できるためです。長さ n のBase64url文字列が有効な標準Base64になるには (4 - n % 4) % 4 個のパディング文字が必要です。多くの実装（JWTライブラリなど）は常にパディングを除去しますが、保持するものもあります。デコーダーが何を期待しているか注意しましょう。

Base64urlが使用される場面：

• JSON Web Token（JWT）のヘッダーとペイロードセグメント
• OAuth 2.0 PKCEのコードベリファイアとチャレンジ
• URL短縮やリンクセーフな識別子
• Amazon S3のETagなどクラウドサービスの識別子

よくある間違い： Base64urlと標準Base64の混同。JWTセグメントを atob() でデコードする際に、- と _ を + と / に戻さないと、デコード結果が不正になるか失敗します。