Base64って何?なぜこんなに頻繁に出てくるの?
コードの中の謎の文字列、それは意味不明じゃありません。実際は何を意味しているのか解説します。
APIをデバッグしていると、レスポンスのどこかでこんなものを見かけます:
SGVsbG8gV29ybGQh
あるいはメールの生ソースを見ると、キーボードを適当に叩いたような文字の塊が見つかります。CSSの背景画像が data:image/png;base64, で始まり、その後に文字の壁が続いていたり。
それがBase64です。意識して見始めると、どこにでもあります。
Base64とは実際何なのか
バイナリデータ——画像、ファイル、プレーンテキストでないあらゆるもの——は、テキスト用に設計されたシステムとは相性が悪いです。メールはASCII文字向けに作られました。URLには文字制限があります。JSONは生のバイナリを扱えません。
Base64はバイナリデータを64個の「安全な」文字列に変換します:A-Z、a-z、0-9、+、/。あらゆるバイナリファイルが、テキスト専用システムを通しても壊れないテキスト文字列になります。
これは暗号化ではありません。圧縮でもありません。ただのエンコーディング——同じデータを別の方法で表現しているだけです。
どこで見かけるか
メールの添付ファイル。 PDFをメールで送ると、Base64エンコードされ、テキストとして送信され、受信側でデコードされます。
データURI。 data:image/png;base64,... という構文は、画像をHTMLやCSSに直接埋め込みます。別ファイルのリクエストが不要になります。
API認証。 Basic認証は username:password をBase64文字列として送信します。(これがHTTP上のBasic認証が安全でない理由です——Base64は暗号化ではありません。)
JWT。 JSON Web Tokenは、ドットで結合された3つのBase64エンコードされたJSONオブジェクトです。
JSON内のバイナリデータ。 JSONは生のバイトを含められないため、バイナリを先にBase64エンコードします。
エンコーディング vs 暗号化
これらを混同する人が絶えません。
Base64エンコーディング: 誰でも可逆できます。鍵不要。安全ではありません。ただの再フォーマット。
暗号化: 正しい鍵があって初めて可逆できます。実際に安全。
パスワードなしでデコードできるなら、それは暗号化されていません。Base64がデータを「隠す」のは、Base64が何か知らない人からだけ——でも実際に読みたい人でBase64を知らない人はいません。
パスワードをBase64で保存してはいけません。API内のBase64データがプライベートだと思ってはいけません。それはただ見た目が変なテキストです。
サイズの問題
Base64はデータサイズを約33%増加させます。100KBの画像はBase64エンコードすると約133KBになります。
これはデータURIで重要になります。大きな画像をBase64としてCSSに埋め込むと、ファイルが大きくなり、個別にキャッシュもできません。小さなアイコンには良い。ヒーロー画像には悪い。
実用的な使い道
デバッグ。 APIレスポンスでBase64を見かけたら?デコードして中身を確認しましょう。
小さな画像の埋め込み。 1-2KB以下のアイコンは、HTTPリクエストを節約するためにデータURIとして埋め込む価値があることが多いです。
テキストチャネルを通じたバイナリの受け渡し。 JSONにファイルの内容を含める必要がある?Base64エンコードしましょう。
JWTの読み取り。 各セクションをデコードしてヘッダー、ペイロードを確認し、トークンに含まれるクレームを理解しましょう。
Base64は複雑ではありません。あらゆるデータをテキスト文字列に変換する方法にすぎません。認識して、必要に応じてデコードし、セキュリティは提供していないことを理解しておきましょう——提供しているのは互換性だけです。