学ぶ · ガイド
Base64 详解:エンコードであって、暗号化ではない
Base64 が何をしているのか、URL にセーフな変種がなぜ必要なのか、そして「エンコード」が「秘匿」と同じものにならない理由。
Base64 とは結局何のことか
Base64 はバイナリのバイト列を、表示可能な 64 個の ASCII 文字(A–Z、a–z、0–9、+、/)と = のパディングに写像します。そうすれば、任意のバイナリ内容でも、テキストしか扱えないシステム(メール、JSON、URL)を通じて送信できます。これは表現形式のひとつにすぎません。数の 10 を「10」と書くように、並んだ傷の代わりに文字列で表すだけです。
エンコードは暗号化ではない
覚えておきたいのはこの一文だけです。誰でも数秒で Base64 を元に戻せます。 任意のオンラインツール、任意の開発者、偶然目にした人誰でもデコードできます。機密情報の前に「エンコード済み」と一文添えることは、安全性の助けにはまったくなりません。秘匿させたいなら鍵付きの本物の暗号化を、篡改を防ぎたいなら署名かハッシュを使ってください。
標準版と URL セーフ版
ふつうの Base64 は +、/、= を使いますが、これらの文字は URL の中で意味を持ちます。URL セーフ版は + を -、/ を _ に置き換え、末尾の = パディングを取り除きます。JWT がその例で、3 つのセグメントはすべて Base64 URL エンコードです。JWT の中にリテラルの + が現れないのはこのためです。
UTF-8 の落とし穴
古典的なバグがひとつあります。Latin-1 と仮定するツールで日本語をエンコードすると、デコードしても無意味な文字列が返ってきます。正しいツールは、まず文字列を UTF-8 のバイト列に変換し(TextEncoder)、次に UTF-8 のバイト列からデコードします(TextDecoder)。ToolsKit の Base64 ツールは両方向でそうしているので、日本語も絵文字もアクセント付きの文字も、そのまま往復できます。
どこで出逢うか
- JWT の header セグメントと payload セグメント。
- HTML や CSS に
data:URI として埋め込む小さな画像やフォント。 - MIME として存在するメール添付。
- テキストしか対応していない列やキャッシュにバイナリデータを格納する場面。
往復を試してみる
5Lit5paH を ToolsKit の Base64 デコーダー に貼り付けると、UTF-8 として読むと日本語になります。自分のテキストをエンコードしてからデコードし、元と一字も違わないことを確認してみてください。「Base64 にすれば安全だ」と同僚が言った日があれば、返せる言葉がもう一つ増えます。