Base64 エンコードの解説：役に立つとき、害になるとき

Base64 は任意のバイト列をプレーンテキストとして書き表す標準的な方法です。A–Z、a–z、0–9 に + と / を加えた 64 の印字可能文字が 6 ビットのグループを表し、入力 3 バイトがちょうど出力 4 文字になります。この対応に秘密はなく、元データより小さくなることもありません。

• 公開アルファベットアルファベットは固定で公開されています。どの言語でも 1 行のコードで Base64 文字列をデコードでき、それこそが相互運用性の源泉です。
• 秘匿性なし暗号ではありません。鍵も秘匿性もアクセス制御もなく、デコードしたメッセージはデコーダーに貼り付けた誰にでも読めます。
• 必ず大きい圧縮でもありません。6 ビットのデータが 8 ビットの文字に入って運ばれるため、出力は常に入力より大きく、小さくなることはありません。

3 バイトが 4 文字になるため、Base64 の出力は常に入力の 4/3——パディング前で約 33% 増しです。900 KB の画像は約 1.2 MB のテキストになり、その膨張はデータの行く先すべてに付いて回ります。

• 回線上転送コスト：HTML や CSS に埋め込まれた Data URL はテキストとしてダウンロード・解析・キャッシュされるため、ページを読み込むたびに余分な 3 分の 1 を支払います。
• メモリ内メモリとストレージのコスト：Base64 フィールドを含む JSON や XML のペイロードは文字列として保持され、パイプラインによってはエンコード済みとデコード済みの 2 重に保存されます。
• メールボックス内メールではさらに増幅します。転送用に Base64 エンコードされた添付ファイルは回線上で 3 分の 1 膨らむため、25 MB の添付上限は実質約 18 MB のファイルを意味します。

Base64 が存在するのは、多くのチャンネルがテキスト専用だからです。メールの規格は 7 ビット ASCII の時代に書かれ、JSON は生のバイトを保持できず、URL はバイナリデータで壊れます——だからバイト安全なテキスト表現が橋渡しになるのです。

画像 → Base64 変換は、最大 4 MiB の PNG・JPEG・WebP・GIF から実際に必要な 2 つの形を生成します。メディアタイプ接頭辞付きの完全な Data URL と、その内側のプレーンな Base64 ペイロードです。変換はタブ内で行われるため、サイズ増加を自分で測っている間も画像はデバイスから出ません。

• Data URLData URL は小さなアセットをインライン化します。data:image/png;base64,… により、アイコンや小さなプレースホルダーが追加リクエストなしで CSS や HTML に同梱されます。
• メールと MIMEメール添付は Base64 に依存しています。SMTP がテキスト用に設計されているためで、MIME はバイナリ部分をエンコードして全リレーで無傷にします。
• トークンと証明書トークンや証明書——JWT の各セグメント、PEM ファイル、HTTP Basic 認証情報——は Base64 またはその URL セーフ変種で、バイナリ構造をテキストプロトコルに収めます。

エンコード後の姿は判読不能に見えるため、保護と誤解されがちです。実際は違います。デコードは容易で即座で、認証情報も不要です。エンコードした秘密を安全と見なすことは、コミットされたコードやログからの認証情報漏洩の最も一般的な原因の一つです。

議論を終わらせる簡単なセルフチェックがあります。その「保護」を外すのに鍵も秘密も権限も要らないなら、それは保護ではなくフォーマットです。Base64 は設計上このチェックを通りません。連携なしにどの受信者もデコードできることが、その存在意義のすべてだからです。

• 誰でも読める設定ファイル内の Base64 エンコード済みパスワードは、余計な手間が増えただけの平文パスワードです。読み取り権限のある人はすでに秘密を持っています。
• 依然として認証情報URL・スクリーンショット・バグレポートに現れるエンコード済みトークンも依然として認証情報です。生の値と同じように必ずマスクしてください。
• 本物の保護を本物の保護とは、鍵による暗号化、検証のためのハッシュ、あるいは値を公開しないことです。エンコードはそのどれの代わりにもなりません。

Base64 のバグのほとんどは方言のバグです。古典的なアルファベットは + と / を使い = でパディングします。URL セーフ変種は - と _ に置き換え、パディングを省略することが多い。MIME は 76 文字で折り返します。一方の方言を期待するデコーダーは他方を拒否し、エラーメッセージがどの方言を期待していたかを教えてくれることはめったにありません。

Base64 エンコード / デコードは方言を直接操作できます。UTF-8 テキスト、URL セーフ出力、改行処理のトグルに加え、入力が無効な場合——不正な文字、あり得ない長さ、有効な UTF-8 でないバイト列——には明示的なエラーが出るため、壊れた文字列がどの前提を直すべきかを教えてくれます。

• アルファベット不一致アルファベットの不一致：- や _ を含む URL セーフ文字列は厳格な古典デコーダーに拒否され、逆に古典的な + と / は URL セーフ処理を壊します。
• パディングパディング欠落：パディングありの方言は長さが 4 の倍数であることを要求するため、削られた = の尻尾はデータが無事でも厳格なパーサーを失敗させます。
• 紛れ込み文字紛れ込んだ文字：MIME の折り返し、先頭の data:…;base64, 接頭辞、メールクライアントから貼られた空白は、すべて不正な入力として扱われます。

Base64 文字列はたいてい何か機密の断片です。設定ファイル、トークン、顧客向けメールに入れる画像。適当なサイトでデコードすることは、その材料を他人のログに貼り付けることを意味します。

Toolars の 2 つのワークスペースはどちらもブラウザタブ内だけで動作します。テキストや画像はデバイス上のコードで処理され、操作の一部として送信されることはありません。変換中にネットワークモニターを開いてください——コンテンツを運ぶリクエストはありません。

この境界があるからこそ、同僚のトークン断片のデコード、証明書ブロックの確認、インラインスタイルシート用の製品画像の変換といった実務に使えます。ちょっとした照会を情報開示に変えずに済みます。