エンコード・文字コード
Base64には何が入っている？元の内容を確認したい
使うツール
APIのレスポンスや設定ファイルに、意味の分からない長い英数字が入っていたことはありませんか。「暗号化されているのかな」と思って調査を止めたくなる場面ですが、文字の表し方を変えただけのBase64である場合もあります。
このガイドでは、短い公開サンプルを実際に戻し、条件を一つずつ変えてみます。いきなり実運用の認証情報を貼る必要はありません。何が入力で、何が出力なのかを分けて確かめると、長い文字列にも落ち着いて向き合えます。
YWJjを戻すと、何が出てくる？
Base64変換ツールを開き、デコード、標準Base64、UTF-8の出力を選びます。入力欄には次の4文字だけを入れて実行してください。引用符やこの記事の説明文は含めません。
YWJj出てくるのはabcです。今度はエンコードへ切り替え、abcを入力してみましょう。YWJjに戻れば、元データと変換後の文字列を往復できたことになります。ここでは暗号を解く鍵も、解除用のパスワードも登場しません。
エンコードは一定の規則で表現を変えること、デコードはその表現からデータを取り出すことです。『読みづらくなった』だけで『第三者には戻せない』とは限らない。この違いが、この後の調査で大切になります。
なぜ、わざわざ読みにくくするの？
abcなら、そのまま送ればよさそうです。しかし、送るものが画像や任意のファイルになると事情が変わります。受け渡しに使う形式が文字を前提としていると、どんなバイトでもそのまま入れられるとは限りません。
Base64は、元のバイト列を限られた文字で表すための方法です。目的は秘密にすることではなく、文字として扱える姿にすること。API仕様にBase64形式の項目があるときも、『その項目の中身を文字の形で運んでいる』と考えると理解しやすくなります。
同じabcなのに、結果が違う？
エンコードのままabcを入力し、次に末尾へ改行を一つ加えてみます。LFという改行が付いたabcなら、結果はYWJjCg==です。改行なしのYWJjより長くなりました。文字の後ろの見えない1バイトまで、変換対象になったためです。
YWJj
YWJjCg==結果の表示で違いが分かりにくいときは、デコード出力をHexへ切り替えます。改行なしは616263、LF付きは6162630aです。別の環境から持ち込んだデータでは改行がCRLFになっている場合もあるため、画面で同じ行に見えることと、バイト列が一致することを分けて確認しましょう。
日本語も戻せる。でも文字コードには注意
次は『日本語』という3文字をUTF-8としてエンコードします。SheepDevのテキスト入力はUTF-8のバイト列へ変換してからBase64にするため、結果は5pel5pys6Kqeです。これをUTF-8出力でデコードすると元の3文字へ戻ります。
Base64そのものが日本語を理解しているわけではありません。『文字をバイトにする』処理と『バイトをBase64にする』処理が続けて行われています。元データがShift_JISなど別の文字コードなら、Base64を戻せてもUTF-8の文章としては読めないことがあります。
その場合はHexで取り出し、入力元で確認した文字コードを使って調べます。『エラーを出さない文字コード』を片っ端から選ぶのではなく、作成元の設定を確かめるのが先です。読める文字が出たとしても、それだけで元の文章を正しく復元できたとは断定できません。
長くなったのは失敗ではない。Base64は圧縮ではない
abcはUTF-8で3バイト、YWJjはASCIIで4文字です。Base64は基本的に元の3バイトを4文字へ表すので、長いデータではおよそ1.33倍になります。容量を減らす仕組みではありません。画像をBase64へ変えただけで通信が軽くなる、とは考えないようにしましょう。
| 元の文字 | 標準Base64 |
|---|---|
| a | YQ== |
| ab | YWI= |
| abc | YWJj |
短い文字列では、末尾の調整を含むため倍率が大きく見えることもあります。a、ab、abcを順番に試すと、末尾の=の数が変わります。=はデータの長さに応じたパディングであり、壊れた文字やコピー時のごみではありません。外すかどうかは利用する形式の仕様で決めます。
Base64urlは、どこが違う？
標準Base64は+と/を使います。Base64urlでは、その位置の文字を-と_に変えます。SheepDevのBase64urlエンコードでは末尾の=も省略します。ただし標準Base64を選ぶべきかどうかは、単にWeb上で使うからではなく、受け渡し先の仕様で判断してください。
違いを見るには、abcだけでは不十分です。両方式で同じ結果になる入力もあるからです。試しに????をエンコードすると、標準はPz8/Pw==、Base64urlはPz8_Pwです。元へ戻すときにも対応する方式を選び、文字を手作業で置換する前に設定を見直しましょう。
戻したのに文章にならないとき
Base64が運べるのは文章だけではありません。デコード後が画像・圧縮データ・暗号文なら、そのままUTF-8として読むことはできない場合があります。Base64の形式エラーと、復元したバイト列を文章として読めないエラーは別の問題です。
練習には/w==を使います。標準Base64としてHexへ戻すとffになりますが、1バイトのFFは有効なUTF-8文章ではありません。UTF-8出力でエラーになっても、Base64自体が間違いとは限らないことを確認できます。Hex出力はバイトの観察用であり、元の画像をそのまま表示する機能ではありません。
戻せないときの確認順序
- 入力元の仕様でBase64であることを確かめます。英数字が長く続くという見た目だけでは、IDやハッシュとの区別はできません。
- 値だけをコピーできているか確認します。引用符、説明、data:URLのヘッダーなどまで含めていないか、途中で切れていないかを見ます。
- 標準Base64とBase64urlの選択を確認します。SheepDevは入力途中の改行や空白を自動的にすべて取り除くわけではありません。変換元が折り返しを入れる仕様かどうかも調べます。
- 形式として戻せるなら、次は中身の種類を確認します。文章なら文字コード、文章でなければ元のファイル形式を確認し、意味不明な結果を正しい文章だと扱わないようにします。
読めなく見えても、秘密にはならない
最初のYWJjを、鍵なしでabcへ戻せたことを思い出してください。パスワードや個人情報をBase64へ変えても、同じことができます。障害報告に通信内容を貼るとき、『英数字になっているから伏せ字の代わりになる』と判断するのは危険です。
ハッシュは別の目的の計算であり、ハッシュ値をBase64のようにデコードして元の文章へ戻すものではありません。またJWTの内容を読めても、その署名や信頼性まで確認できたわけではありません。必要なら、それぞれの専用ガイドで『何を確認できるのか』から使い分けましょう。
実際の調査へ持ち帰るなら
報告に残すと役立つのは、『デコードできた』という一言より、入力元で確認した形式、使った出力方式、期待した内容と実際の差です。例えば『標準Base64としては戻せるがUTF-8では読めず、HexではFFだった』なら、次に調べるべき文字コードやデータ形式へ話を進められます。
長い文字列を見たら、まず形式を確認し、値だけを取り出し、元のデータが何だったかを考える。この順序が身に付けば、変換ツールは単に文字列を戻す道具ではなく、問題の場所を絞り込む道具になります。なお、このページで文字列を読めたことは、その内容を安全に実行・公開してよいという判定ではありません。