オンラインで Base64 をデコードする方法 (および結果の意味)

一見ランダムな文字と数字の文字列があり、おそらく 1 つまたは 2 つの等号で終わっているので、それが何を言っているのかを知る必要があります。これはほぼ間違いなく Base64 であり、デコードすると元のテキストまたはデータが明らかになります。ここでは、Base64 をデコードする方法、結果からわかること、およびデコーダが失敗する原因となる 2 つの亜種について説明します。

デコード方法

Base64 のデコードは瞬時に行われます。エンコードされた文字列をデコーダに貼り付けると、元のテキストに変換されます。 Base64 は完全に元に戻すことができ、暗号化ではなくエンコードであるため、キーは必要なく、誰でも Base64 文字列をすぐにデコードできます。結果が読み取れるテキストであれば、答えは得られます。結果がバイナリ ガベージのように見える場合、元のデータはテキストではなく、Base64 でエンコードされた画像、ファイル、または暗号化データである可能性があります。この場合、デコードされたバイトはテキストとして読み取られることを意図していません。

Base64をデコードする必要がある理由

Base64 は、検査が必要なさまざまな場所に出現します。 JWT 認証トークンのヘッダーとペイロードは Base64 でエンコードされており、デコードすると内部のクレームが明らかになります。 HTTP Basic 認証資格情報は、Authorization ヘッダーの Base64 です。データ URL には、Base64 でエンコードされた画像が埋め込まれます。電子メールのソースには、Base64 でエンコードされた添付ファイルが表示されます。構成ファイルと API 応答には、Base64 データが含まれる場合があります。これらのいずれかをデバッグする場合、デコードすると、エンコードされた文字の壁ではなく、実際にそこにあるものを確認できます。

Unicode の落とし穴

デコードされたテキストで、アクセント記号や英語以外の文字があるはずの場所が文字化けしている場合は、Unicode の処理に問題があります。 Base64 はバイトをエンコードするため、テキストは最初に UTF-8 などのエンコードを介してバイトに変換する必要があります。プレーン ASCII を想定したデコーダは、アクセント付き文字、絵文字、および非ラテン文字を破壊します。適切なデコーダはバイトを UTF-8 として解釈するため、「café」と「こんにちは」は正しくデコードされます。文字化け、文字化けが発生する場合は、エンコーダまたはデコーダが Unicode ステップを誤って処理したことになります。

URL セーフなバリアント

デコーダーが文字列を拒否するか、間違った出力を生成する場合、それは URL セーフなバリアントである Base64url である可能性があります。標準の Base64 では + 文字と / 文字が使用されますが、これらは URL で問題を引き起こすため、Base64url では + を - に、/ を _ に置き換え、多くの場合 = パディングを削除します。 JWT はこのバリアントを使用します。厳密な標準デコーダは、- と _ またはパディングの欠落でチョークする可能性があります。修正するには、- を + に、_ を / に戻し、デコードする前にパディングを復元するか、両方のバリアントを自動的に処理するツールを使用します。

覚えておいてください: デコードは復号化ではありません

重要な点が 1 つあります。 Base64 をデコードすると、キーを必要とせずにエンコードされた内容が明らかになります。つまり、Base64 ではセキュリティがまったく提供されません。あなたがそれを解読できれば、他の誰でも解読できます。このため、パスワードやシークレットは隠されていると考えて Base64 として保存しないでください。それらは簡単に読むことができます。 JWT ペイロードをデコードするとクレームは表示されますが、トークンは検証されないため、別の手順で秘密キーを使用して署名を確認する必要があります。 Base64 は表現を目的とするものであり、保護を目的とするものではありません。