Base64 デコードとエンコード: セキュリティではなく転送用

アルファベットとパディング

標準のアルファベットは `A–Z`、`a–z`、`0–9`、`+`、`/` で、入力長が 3 の倍数でない場合は、最後のグループに `=` が埋め込まれます。このパディングは装飾的なものではなく、最後のグループが何バイト運ぶかをデコーダに伝えます。 URL ではこれを削除するのが一般的で、デコーダーが長さを推論するため機能しますが、厳密な実装ではパディングされていない形式が拒否されます。

                "YamlBox"  →  WWFtbEJveA==
"YamlBo"   →  WWFtbEJv
              

base64url: トークンになるバリアント

URLの扱い`+`、`/`そして`=`重要であるため、base64url バリアントはそれらを次のように置き換えます。`-`そして`_`そして多くの場合、パディングを完全に省略します。すべての JSON Web トークンはこのアルファベットを使用するため、厳密な Base64 デコーダーに貼り付けられた JWT ペイロードは、まったく普通に見える文字で失敗する可能性があります。文字列が解読可能に近いものにデコードされた場合、通常は、アルファベットを 1 つ入れ替えるだけで答えが得られます。

実際に出会う場所

• データ URI — 小さな画像やフォントを CSS または HTML に `data:image/png;base64,…` として直接埋め込みます。
• JSON Web トークン — 3 つのセグメントはそれぞれ、base64url でエンコードされています。
• HTTP 基本認証 - `Authorization: Basic` は `user:password` の Base64 を伝送するため、常に TLS 経由で送信する必要があります。
• 電子メールの添付ファイル — MIME は 1980 年代以来、バイナリ部分に Base64 を使用してきました。
• バイナリ、つまりテキストのみのフィールドに配置された画像ペイロードとキーを受け入れることができない API。

Base64 デコード出力がゴミのように見える理由

典型的な失敗は Unicode です。 JavaScript は古い`btoa`そして`atob`文字ごとに 1 バイトを処理するため、次の文字列が含まれます。`é`、`₹`または、任意の絵文字は文字化けをスローまたは生成します。修正するには、最初に UTF-8 バイトをエンコードします。`TextEncoder`ブラウザで、`Buffer.from(str, "utf8")`Node内 — そしてbase64のもの。デコードで一見もっともらしいが間違った文字が返された場合、最も考えられる原因は、エンコーダーがテキストを UTF-8 バイトにまったく変換していないことです。

Base64 は機密性や完全性を提供しません。エンコードされたシークレットは、生のシークレットとまったく同じように扱ってください。それが本来の性質だからです。

ローカルでデコードする理由

Basic-auth ヘッダー、トークン、データ URI はすべて資格情報またはプライベート データにデコードされるため、それらをサーバー側デコーダーに貼り付けることは情報開示となります。 YamlBox Base64 エンコーダ/デコーダは、UTF-8 処理が正しく行われたページ内で動作し、標準アルファベットと URL セーフ アルファベットの両方をサポートし、オフラインで機能します。