Base64 エンコード

Base64 は暗号化でも圧縮でもありません。ほぼどんな経路も通り抜ける 64 種類の文字だけを使って、バイト列を書き直します。3 バイトを 24 ビットとして見て、6 ビットずつ 4 つに切り分け、それぞれを表の 1 文字に置き換えます。

そこから費用が出ます。結果は必ず元より約 3 分の 1 大きくなります。テキストしか理解しない経路を越えられることの代価であり、メールの添付が中のファイルより重い理由です。メールは中身がいまだにテキストのプロトコルだからです。

標準のアルファベットは最後の 2 文字に `+` と `/` を使います。どちらも URL の中では意味を持ちます。スラッシュはパスの区切りで、プラスはクエリ文字列では空白と読まれます。標準の Base64 をそのままアドレスに入れると、届きはしますが変わって届きます。

URL セーフの変種はこの 2 つを `-` と `_` に替えます。どちらもアドレスのどの部分でも意味を持ちません。JWT が使っているのがこれで、ヘッダーからコピーしたトークンにスラッシュもプラスも入っていない理由でもあります。値が URL を旅するならこちら、そうでなければ標準がほかのすべての期待する形です。

Base64 は 3 バイト単位で処理します。入力が 3 の倍数でないときは 1 バイトか 2 バイト余り、その埋め合わせが末尾の等号 1 つか 2 つとして印されます。結果が `=`、`==`、あるいは何もなしで終わるのはそのためで、長さが常に 4 の倍数になるのもそのためです。

このパディングは、仕様によっては任意で、別の仕様では必須です。そこから繰り返し行き違いが起きます。JWT は意図的に省き、多くのライブラリはそれがないとデコードを拒みます。正しく見える値がどこかで弾かれたら、まず文字数を見てください。

Base64 が符号化するのは文字ではなくバイトなので、まずテキストをどうバイトにするかを決めなければなりません。ここでは常に UTF-8 で、「あ」は `e3 81 82` の 3 バイト、漢字も 3 バイト、絵文字は 4 バイトです。3 バイトが 4 文字になるので、日本語のテキストは 1 文字あたりおよそ 4 文字の Base64 になります。

他のツールと突き合わせるときの最も多い食い違いがここです。相手が Shift_JIS で処理していたなら「あ」は `82 a0` の 2 バイトで、結果は一致しません。どちらのエンコーダーの誤りでもありません。別のテキストを符号化していたのであって、食い違いは 1 段下の層にあります。

`Authorization: Basic` ヘッダーは、`ユーザー名:パスワード` を Base64 にしただけのものです。鍵は存在しないので、ヘッダーを見た人は誰でも 1 秒で元に戻せます。符号化であって暗号化ではありません。

その資格情報を守っているのは HTTPS だけです。だから平文の HTTP 上の Basic 認証はパスワードを裸で送るのと等価で、だからスクリーンショットやチケットやログの中のそのヘッダーは露出した資格情報です。読めない見た目であることは何も変えません。

`src` の中に Base64 の画像を入れればリクエストが 1 本減ります。小さなアイコンや数キロバイトの SVG なら妥当です。そこから先は割に合わなくなります。ファイルは 3 分の 1 膨らみ、HTML に埋め込まれるので別々にキャッシュされず、ブラウザーは何かを描く前にそれを解析しなければなりません。

符号が入れ替わる地点はページによりますが、目安は保ちます。数キロバイト以下ならたいてい data URI の勝ち、数十キロバイトを超えるとたいてい負けです。大きな画像を埋め込むと、訪問のたびに膨らんだ HTML を丸ごとダウンロードすることになります。

アプリのコード、設定ファイル、スクリプトの中で鍵を「隠す」方法として、ときどき使われます。何も隠れていません。戻すのはボタン 1 つで、漏洩した秘密情報を探す道具は Base64 の文字列をまさに認識します。非常に見分けやすい模様だからです。

実際に起きるのは、ざっと目を通す人への警告が消えることで、そこが問題です。平文の秘密情報は目に入って直されますが、Base64 の秘密情報はレビューを通過します。本当に隠す必要があるなら、鍵が別の場所にある暗号化が要ります。あるいは、そもそもそこに入れないことです。

メールは 1996 年の標準の要求で Base64 を 76 文字ごとに折り返し、PEM 形式の証明書は 64 文字で折り返します。その形式は完全に妥当ですが、現代のデコーダーの多くは、先に取り除かないと改行でつまずきます。

このページは連続した 1 行を出します。いまどきの API がほぼ例外なく期待する形です。行分割を要求する何かに貼り付けるなら、折り返しはご自身で入れることになります。逆に改行入りのものをデコードする場合、このサイトのデコーダーはそれを無視します。

どんなテキストも Base64 になります。無効な入力が存在せず、したがってこの方向にはエラーもありません。楽ではありますが罠が隠れています。Base64 の文字列は、中身がごみであっても申し分ない見た目のままでいられるからです。

検査が要るなら、それは前段です。JSON を符号化するなら先に検証を、識別子を符号化するなら正しいものかを確かめてください。壊れた値を符号化したものは、良い値のものと寸分たがわず同じに見えます。そしてエラーは向こう側で、はるかに見つけにくい場所で現れます。

この欄に貼り付けられるものは、たいてい動かさないほうがよいものです。資格情報、顧客データの入ったペイロード、設定ファイルの中身。符号化はページの中で行われるので、当方への提供が起きず、その内容についての第三者提供も委託も生じません。

ネットワークパネルで確認できます。使っているあいだ、入力を運ぶリクエストは出ません。実際に残るものはプライバシーポリシーにあります——訪問と、広告および分析のリクエスト。欄の中身はそこに含まれず、この種の値については、それが唯一重要な点です。

デコードには専用のページがあり、分けているのは手間の問題ではありません。符号化する人は何かを組み立てている最中で、決めることが 1 つあります。どちらのアルファベットか。復号する人は届いたものを読んでいて、別の問題を抱えています。出てきたものがテキストでないときにどうするか。

2 つのページは同じエンジンを共有し、違うことを説明します。失敗の仕方が違うからです。1 つにまとめれば、どの訪問者も自分に関係のない半分を読まされ、その人が来た理由である細部がちょうど削られます。