Base64 文字列のデコード方法（および JWT ペイロード）

Base64 は可逆エンコーディングであり、暗号化ではありません。1 ステップでデコードし、Unicode を正しく扱い、Base64url を使う JWT セクションを読み取ります。

Base64 とは結局なに

Base64 はバイナリデータを 64 個の印字可能な ASCII 文字に対応づけます。鍵を使わずに完全に可逆なので、暗号化ではなくエンコードです —— 秘密を「隠す」用途には絶対に使わないでください。

エンコードとデコード

ブラウザでは btoa でエンコード、atob でデコードします。非 ASCII テキストの場合は UTF-8 を経由してラウンドトリップしてください。そうしないと é・ü・你のような文字が壊れたバイト列になります。

JWT を読む

JWT はピリオドで連結された 3 つの Base64url セクション（header、payload、signature）から成ります。前者の 2 つをデコードすれば claim を読めます。signature はバイナリで、人間が読むことを想定したものではありません。

Base64 と Base64url の違い

標準の Base64 は + と /、そして = によるパディングを使います。URL セーフな Base64url はそれを - と _ に置き換え、パディングを省くので、その値を URL や JWT の中に安全に入れられます。

デコードは検証ではない

JWT をデコードすると claim は見えますが、真正性は何も保証しません。誰でも payload に "role":"admin" と書かれた token を偽造できます。token が本物だと示せるのは発行者の鍵で検証された署名だけです。未検証の token に基づいて信頼判断を下してはいけません。

よくある JWT クレームとその意味

iss は発行者、sub は主体（ユーザー ID）、aud は想定オーディエンス、exp は有効期限（Unix 秒）、iat は発行時刻、nbf は「not before」、jti は一意な ID です。カスタム claim はこれらと並びます。exp と aud は必ずクライアントだけでなくサーバー側でも検証してください。

パディングと URL セーフ版

Base64url はしばしば = パディングなしで届きます。コードでデコードするときは、= を足して長さを 4 の倍数にしたうえで、- を +、_ を / に戻してから、通常の Base64 デコーダにかけます。ブラウザの atob は Base64url を直接受け取れないので、その変換を先に済ませる必要があります。

Open JSON Fix Compare JSON changes