今日の午後、またデータ問題にさんざん悩まされた。顧客がファイルを送ってきて、暗号化されているから開けないと言う。その形式を見て、すぐにピンときた——これはBase64だ、暗号化なんかじゃない、ただの殻で、見た目だけ脅かしているだけだ。
正直言って、Base64はこの業界では愛憎半ばする存在だ。好きなのは、単純明快で、バイナリデータを一見整ったテキストに変換でき、どこに送っても文字化けしないから。嫌いなのは、いつも暗号化と勘違いされて、まるで神秘的なもののように扱われるからだ。今日の件も、私がこのことを頭に入れていなければ、また顧客に「これは暗号化ではなくエンコードです」と長々と説明しなければならなかっただろう。
事の次第はこうだ。相手がCSVファイルを送ってきて、その中の1列のデータがすべて「U2FsdGVkX1+...」で始まる文字列だった。顧客はこれが自社システムが自動生成した「暗号化パスワード」だと言い、新しいシステムに移行しようとしたが、新システムが認識しないという。私はその先頭を見て、笑いをこらえるのがやっとだった。これは典型的なBase64の特徴ではないか。私は手軽にオンラインツールに貼り付けてデコードをクリックした。なんと、中身は普通のUTF-8テキストで、暗号化なんてどこにもなかった。
実は、こういう場面には何度も遭遇してきた。多くの人が「エンコード」と「暗号化」の違いを理解していない。Base64は本質的に、8ビットのバイトを6ビットの印刷可能な文字に変換するエンコード方式であり、鍵は一切なく、誰でも解読できる。しかし、その見た目が難解なため、「疑似暗号化」として使われることがよくある。今日の件も、私がこのパターンに精通していなければ、推測だけで定時までに終わらせるのは難しかっただろう。
また、別の時には画像アップロードの問題を処理した。フロントエンドが画像をBase64文字列に変換してそのままバックエンドに送信したが、バックエンドがデータベースに保存する際、その文字列が非常に長くなり、テーブル構造が壊れそうになった。その後、ネイティブのバイナリストリームで転送するように教えたら、問題はすぐに解決した。Base64は便利だが、致命的な欠点がある——サイズが約33%膨張する。画像が大きいと、文字列の長さは驚くほどになる。
とはいえ、今日の仕事は本当にBase64に感謝すべきだ。これほど「おバカな」エンコード方式でなければ、データの内容を迅速に確認できなかっただろう。スクリプトを書く必要すらなく、ウェブページでデコードツールを見つけて、数秒で内容を把握できた。これが本当の暗号化だったら、今日は残業になっていただろう。
だから、ツール自体に良し悪しはなく、それを理解しているかどうかが重要だ。Base64はまるでマスターキーのようで、鍵はかかっていないが、一見鍵がかかっているように見える多くのドアを開けられる。同業者の皆さんにお勧めしたいのは、「一見乱码のようだが規則性のある」文字列に遭遇したら、慌てずに、一部をコピーしてBase64デコーダーに入れて試してみてください。十中八九、30分の調査時間を節約できます。今日、また私の命を救ってくれた。次はあなたの番です。この技を忘れないでください。