本文へスキップ

学ぶ · ガイド

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 にすれば安全だ」と同僚が言った日があれば、返せる言葉がもう一つ増えます。