Base64エンコーダー・デコーダー

Base64が存在するのは、テキストを中心に構築されたインフラの多く — メール、JSON、XML、URL — が任意のバイナリバイトを信頼できる形で運べないためです。制御文字、ヌルバイト、文字列を早期に終わらせたりパーサーを直接壊したりするバイト列を含みうるためです。Base64は任意のバイナリデータの3バイトごとを、どんなテキストベースのシステムでも安全に扱える固定64種類の集合から取った4文字にマッピングします — 文字、数字、2つの記号です。これにより、符号化された結果をJSONに埋め込んだり、メール添付として送信したり、下流の何かがそれを平文以外の何かと誤解することなく文書に含めたりできます。

その安全性のオーバーヘッドは固定で避けられません: 入力3バイトごとに出力4文字、約33%の膨張で、基礎となるデータが何であっても変わりません。それはテキストのみのチャネルを通じた確実な安全な通過のために支払われる代償であり、特定の実装固有の欠陥ではありません。

ブラウザに組み込まれた`btoa`関数は、多くの手早いBase64実装が直接頼っているものですが、コードポイントU+00FFを超える文字に出会った瞬間にエラーになります — これには実質的にすべての絵文字、中国語、日本語、韓国語、キリル文字、ギリシャ語、アラビア語、そしてフランス語、ドイツ語、スペイン語などで使われるかなりの数のアクセント付きラテン文字が含まれます。これは珍しい入力に影響する曖昧なエッジケースではありません。本物の実世界のテキストの非常に大きな割合に影響し、これが手作りのBase64ツールの多くが平文の英語入力のテストでは完璧に動作し、ユーザーが絵文字や非ラテン文字の名前を含む何かを貼り付けた最初の瞬間に失敗する理由です。

修正は、先にテキストをUTF-8バイトとしてエンコードし、それからそのバイトをBase64にエンコードすることです — 正しく構築されたエンコーダーが行っていることであり、このツールが行っていることです — 256未満のバイト列向けに設計されたエンコーディングに、Unicodeのコードポイントを直接押し込もうとするのではなくです。

標準Base64の文字集合には`+`と`/`が含まれ、どちらもURLの中で意味を持ちます — `+`は時々スペースとして解釈され、`/`はパスの区切り文字です — そのため標準のBase64文字列をクエリ文字列やファイル名に直接貼り付けると、それを解析する何かによって黙って破損したり切り詰められたりすることがあります。Base64URLはその2つの文字を`-`と`_`に置き換え、どちらもURLの中で特別な意味を持ちません。また、末尾の`=`パディング文字も通常取り除きます。これらは純粋に長さを示すために存在し、デコーダーがすでにそれを予期している場合は不要です。

JSON Web Tokenはまさにこの理由でBase64URLを使います: JWTはHTTPのAuthorizationヘッダー内、時にはURLの中を移動するよう設計されており、標準Base64の予約文字がそれを信頼できないものにしてしまうためです。

この仮定はよく現れるため、明確に言う価値があります: Base64はゼロの機密性しか提供しません。プロセスのどの時点にも秘密鍵は関与しないため、Base64文字列を入手した誰でも、標準的なライブラリ呼び出しやまさにこのようなツールを使って瞬時に元のデータにデコードし直せます。パスワードやAPIキーを保存や送信の前にBase64でエンコードしても、まったく保護は提供されません — 何気ない一瞥から値を隠すだけであり、これは本物のセキュリティとは非常に異なる性質です。