Base64 デコード

Base64 の文字列を貼り付けると、何と書いてあるかが読めます。両方のアルファベットを受け付け、パディングは任意なので、ヘッダーからコピーしたトークンがそのまま通ります。背後のバイト列がテキストでない場合は、結果のように見える置換文字を返す代わりにそう伝えます。このサイトで最も資格情報が集まるページなので、処理はすべてあなたのタブの中で完結します。

結果

入力すると、ここに答えが出ます。

  • 処理される場所

    ファイルがないので、何もアップロードされません。計算はこのページの中で行われます。

  • 順番待ちもアカウントもなし

    お使いの機械の速さで答え、あなたが誰かを尋ねることはありません。

  • 何度でも

    回数は数えず、上限もありません。もう一度答えることに費用はかからないからです。

仕組み

  1. Base64 の文字列を貼り付けてください。末尾の等号はあってもなくてもかまいません。
  2. テキストを読みます。中身が文字列ではなくファイルなら、その旨が示されます。
  3. 何も送信されていません。

たいてい中に入っているもの

多い順に、JWT、Basic 認証のヘッダー、Kubernetes の Secret の値、webhook のペイロード。4 つのうち 3 つは資格情報で、残りの 1 つもたいてい人のデータを含みます。

このページの背後にサーバーがないのはそのためです。姿勢の問題ではなく、何に使われるかから直接出てくる帰結です。これを遠隔で復号するツールは資格情報を見ており、リクエストのログに持っています。どんな注意書きもその事実を変えません。

JWT は 3 つの部分で、読めるのは 2 つ

JWT はヘッダー、ペイロード、署名がドットで区切られ、それぞれが URL セーフの Base64 です。前の 2 つは JSON なのでそのまま読めます。3 つめは署名でテキストではないので、復号しても使えるものは出てきません。

居心地の悪い帰結として、トークンの中身は秘密ではありません。持っている人は誰でも、それが誰のものか、いつ失効するか、どんな権限を名乗っているかを読めます。署名が防ぐのは改変であって閲覧ではありません。JWT のペイロードに個人データを入れることは、そのトークンを見る全員に対してそれを公開することです。

中身がテキストでないとき

Base64 の文字列は、文章と同じくらい容易に PNG や PDF や ZIP を含みえます。そのバイト列をテキストとして読むと置換文字が並び、多くのツールはそれをそのまま返すので、Base64 が壊れているように見えます。実際には完全に無事なのに。

ここでは区別します。文字列は妥当な Base64 だがバイト列がテキストを構成しない場合、その旨と何バイトあるかを伝えます。それが役に立つ答えです。存在しない符号化の誤りを探すのをやめさせ、問いを「これは実際どんな種類のデータなのか」へ移します。

ときどき欠けているパディング

JWT は末尾の等号を意図的に取り除きます。URL セーフの Base64 の仕様がそれを許しているからです。一方で多くのライブラリはパディングなしのデコードを拒み、何も説明しないエラーを返します。

このデコーダーは必要なときだけ補うので、ヘッダーからコピーしたトークンがそのまま読めます。ここで通る値でご自身のコードが落ちるなら、原因はまさにそれで、対処はライブラリに渡す前に 4 の倍数まで詰めることです。

2 つのアルファベットを混ぜて受け付けます

標準のアルファベットは `+` と `/`、URL セーフは `-` と `_` を使います。ここでは尋ねずに両方を受け付けます。誰かが渡してきた文字列を読むために、どちらが当たったかを先に知っていなければならない、というのはおかしいからです。

逆方向では知っておくべきです。アドレスを旅する値を作るのに標準のアルファベットを使うと、スラッシュがパスを壊し、プラスが空白と読まれます。値は届くが変わって届き、失敗は発生地点からはるか遠くで現れます。

改行は無視されます

メールは Base64 を 76 文字で、PEM 形式の証明書は 64 文字で折り返します。それぞれの標準がそう要求しているからです。`.pem` ファイルやメール本文からコピーした値には、したがって改行が入っています。

それらは、ターミナルからのコピーで混ざる空白ともども無視されます。事前の掃除は不要です。貼り付けたものにアルファベット外の文字が含まれていれば、中途半端に復号してそれらしい結果を返す代わりに、何が問題かを伝えます。

デコードは検証ではありません

文字列が復号できることは、その中身が正しいことを意味しません。失効した JWT は有効なものと同じように読め、偽の署名も本物とまったく同じように復号されます。署名の検証には鍵が要り、このページはそれを持っていませんし、欲しくもありません。

読むためのものであって、信じるためのものではありません。トークンが有効かどうかを知りたいのなら、それを発行したシステムが答えるべきです。このページが答えるのは何と書いてあるかで、それは別の問いであり、たいていは最初の問いです。

文字化けと、その出どころ

結果に「�」や見覚えのない漢字の羅列が出たら、バイト列が妥当な UTF-8 ではありません。バイナリデータ——文字列ではなくファイル——であるか、元は Shift_JIS や EUC-JP で符号化されたテキストがいま UTF-8 として読まれているかのどちらかです。

2 つは模様で見分けられます。ファイルなら最初のバイトからごみですが、Shift_JIS のテキストなら英数字の部分だけは読めて、日本語のところだけが崩れます。後者は移行を誤った日本語データの古典で、Base64 に現れるよりずっと前に、照合順序を間違えたデータベースで現れます。

Kubernetes の Secret は Base64 なだけです

Kubernetes の `Secret` は値を Base64 で保持します。これが多くの人を混乱させます。別途設定しないかぎり保存時に暗号化されておらず、そのリソースを読める権限がある人は 1 手で資格情報を読めます。

だから何が何を守っているのかを整理しておく価値があります。Base64 はバイナリの値を YAML に収めるためにあるのであって、隠すためではありません。実際の保護はクラスターの権限であり、必要なら保存時の暗号化です。そして `Secret` の値をオンラインのツールに貼り付けた時点で、その資格情報はクラスターの外へ出ています。

個人情報保護法から見たときの位置

このサイトのどのページよりも、ここには資格情報と個人データが集まります。氏名や住所の入った webhook のペイロード、個人を特定するトークン、設定のダンプ。復号はページの中で行われるので、そのいずれも当方へ提供されません。

社内規程が厳しい環境でもこのツールが使える理由がそこにあります。遠隔で復号するサービスはその個人データを受け取っており、ログに持っています。そうした規程が存在する理由はまさにその事態を避けるためです。ネットワークパネルなら 1 分で証明できます。

このページがエンコードもしない理由

符号化に専用のページがあるのは、別の場面だからです。符号化する人は何かを組み立てていてアルファベットを決めなければならず、復号する人は届いたものを読んでいて、結果がテキストでないときの対処を知る必要があります。

エンジンは同じで、説明は同じではありません。切り替え付きの合体ページは、どの訪問者にも自分に関係のない半分を通らせ、その人の問題を実際に解決する 2 つの節を、関係のない節のあいだに薄めてしまいます。

Base64 デコード:よくある質問

ここで JWT を読めますか。

はい。必要な部分を貼り付けてください。JWT はドットで区切られた 3 つの塊で、前の 2 つは JSON です。3 つめは署名でテキストではないため、復号しても読めるものは出ません。

末尾に等号がありませんが、問題ですか。

いいえ。パディングは必要なときにこちらで補います。JWT は意図的に省いており、それこそが、一見して申し分のないトークンを多くのライブラリが拒む理由です。

テキストではないと言われるのはなぜですか。

文字列は妥当な Base64 でも、中のバイト列がテキストを構成しないからです。文章ではなくファイル——PNG、PDF、ZIP——です。結果のように見える置換文字を返す代わりに、その旨を示します。

トークンが有効かどうかも確認できますか。

いいえ。署名の検証には鍵が必要で、このページはそれを持っていませんし、持ちたくもありません。ここで読めるのはトークンの主張です。有効かつ本物かは、発行したシステムが答えるべきことです。

貼り付けたものは端末から出ますか。

いいえ。このページの中で復号されます。ほかのどのページよりここで重要です。Base64 のデコーダーに貼り付けられるものは、大半が資格情報だからです。

他のツール