Base64デコーダー

実際に見つかるBase64文字列は、標準Base64 — メール添付、データURI、設定ファイルなど — であることも、より一般的にはJWTの3つのピリオド区切りセグメントの1つからのBase64URLであることもあります。この2つの変種は3文字だけ異なるため、正確に1つの形式だけを受け付けるデコーダーは、トークンのセグメントを受け付ける前に手動で`-`を`+`に、`_`を`/`に交換することを強制します。これは単純な貼り付けにしてはやや面倒な余分なステップです。両方の変種を受け付けることで、JWTのペイロードセグメントを、どちらのBase64変種になるか事前に知る必要も気にする必要もなく直接貼り付けられます。

そもそもBase64でエンコードされたものすべてがテキストというわけではありません — 画像、暗号鍵、その他のバイナリデータも、同じテキスト安全性の理由でよくBase64エンコードされます。それらの1つをデコードすると、テキストとして解釈すると歪んだ判読不能な文字として表示される生のバイトが生成されます。これはデコードが失敗した兆候ではなく想定通りです: 操作は正しくエンコーディングを元に戻しましたが、基礎となるバイトはそもそもUTF-8テキストとして読まれることを意図していませんでした。

Base64らしき未知の文字列をここに貼り付けて読みやすい何かにデコードされるかを確認することは、それが実際に何であるか — 設定値、クッキー、予期しない場所で見つかったトークンの断片 — を調査する最初の素早いステップです。読みやすいJSONやプレーンテキストにきれいにデコードされる文字列は、それが本当にBase64エンコードされたデータであることを確認します。デコードで文字化けが生成される、あるいはそもそもBase64ではない文字列は、テキストではなくバイナリデータがBase64エンコードされているということであり、どちらのケースでも次に調査すべきことが絞り込まれます。