URL デコード

URL か値を貼り付けて、パーセント列の下に何と書いてあるかを読んでください。本当に曖昧な点はひとつだけで、それは選択として提示します。プラス記号が、フォームのクエリ文字列のように空白なのか、パスのように本物のプラスなのか。何も送信されません。ここに貼り付けられる URL はログから来ていて、隣にセッション識別子が並んでいるからです。

HTML フォームのクエリ文字列は空白を + と書きます。パスの中では、プラスはプラスです。

結果

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

  • 処理される場所

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

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

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

  • 何度でも

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

仕組み

  1. URL かエンコードされた値を貼り付けてください。
  2. 文字列の出どころに応じて、プラス記号の扱いを選びます。
  3. 結果を読みます。何も送信されていません。

プラス記号だけが本当の判断です

クエリ文字列の中の `+` は、ほぼ常に空白を意味します。HTML のフォームがそう書くからです。パスの中では違います。そこでは文字としてのプラスです。同じ文字列が、URL のどの部分から来たかによって 2 通りに読まれます。

噛みついてくる帰結は、本物のプラスを含む値です。国際形式の電話番号と、サブアドレス付きのメールアドレス。`+81 90 …` はフォームの規則で読むと先頭が空白になり、`[email protected]` は `a [email protected]` になります。失敗は配送の段階で現れ、そこではもう誰も原因と結びつけません。

バイトであって、文字ではありません

`%` に 16 進 2 桁が続いたものはそれぞれ 1 バイトで、ASCII の外の文字は複数を占めます。`%E3%81%82` が「あ」で、漢字も 3 列、絵文字は 4 列続きます。デコードとは、バイトを集めてから UTF-8 として読むことです。

だから、桁が正しくても単独の列が無効になりえます。`%82%A0` は Shift_JIS の「あ」で、UTF-8 としては妥当ではありません。ここでは、結果のように見える置換文字を返す代わりにその旨を伝えます。その列が見えたことは、値を作ったのが UTF-8 以前の道具だという手がかりです。

二重エンコードはデコードして初めて見えます

デコードしたあとにまだパーセント列が残っているなら、その文字列は 2 回エンコードされていました。それが正しい結果です。1 回の処理は `%2520` を `%20` にします。何も残らなくなるまでデコードし続ける道具は、本物の `%` を含む値を壊します。

対処は、習慣的にここへ 2 回通すことではなく、処理の鎖の中でエンコード済みの値をもう一度エンコードしている段を見つけることです。たいていはフレームワークが自動でやり、テンプレートがもう一度やっています。

URL 全体をデコードすると壊れることがあります

アドレス全体をデコードすると `%2F` はスラッシュに、`%3F` は疑問符になり、結果は同じ構造を持たなくなります。値だったものが、パスや新しいクエリ文字列に見えるようになります。

読むためには有用で、再利用するには危険です。オープンリダイレクトはまさにこの形で作られます。攻撃者がエンコードされた URL を値として入れ、何かが検査の前にそれをデコードする。規則は、見るためにデコードし、検証は必ず元の形に対して行うことです。

フラグメントはログに来ません

サーバーのログから URL を読んでいるなら、`#` より後ろにあったものはそこにありません。ブラウザーは決して送らないからです。見えているアドレスは設計上不完全で、利用者が持っていたものと記録に残ったものとのあいだでパラメーターが「消える」事例の少なからずを説明します。

分析のエクスポートには現れることがあります。そちらはそれを見ているスクリプトが書いているからです。いま見ている文字列がどの出どころから来たかを知ることは、そこから何を結論できるかを変えます。1 時間の混乱を節約する種類の細部です。

パラメーターにたいてい入っているもの

検索語、リダイレクト先、メールアドレス、確認用のトークン、そして UTM のパラメーター。最初の 3 つはかなりの頻度で個人データで、4 つめは 1 回きりの資格情報です。

エンコードされていることは何の保護にもなりません。パーセントエンコードは誰にでも読め、その文字列はサーバーのログ、ブラウザーの履歴、次のクリックのリファラーヘッダーにあります。ここで秘密らしきものが出てきたなら、それが発見です。デコードできたこと自体ではありません。

UTM パラメーターが無害である理由

`utm_source`、`utm_medium`、`utm_campaign`、`utm_term`、`utm_content` は、Google Analytics の元になった Urchin という道具から来ています。サーバーでは何もしません。ブラウザーの計測スクリプトが読むテキストです。

何もしないので、リンクを転送するときに削っても影響はありません。送ってくれた人の統計と自分の転送を混ぜたくなければ、そうする理由があります。そしてアドレスに入っているので、履歴と共有リンクとブックマークに残ります。メールマガジンのリンクがばかばかしく長い理由です。

プレビューも、開くこともしません

ここではデコードするだけで、訪問しません。ホストへのリクエストもリダイレクトの追跡もプレビューもありません。判断です。怪しい URL を調べている人は、道具にそれを開いてほしくない筆頭だからです。

開けば何かを漏らしもします。リクエストはサーバーから出て、その IP と時刻は相手側のログに残り、1 回きりのアドレス——確認リンク、パスワード再設定——なら道中で使い切ってしまいます。

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

ログや分析のエクスポートに含まれる URL は、頻繁に個人データを運びます。検索語、パラメーターに入ったメールアドレス、アカウントに結びつく識別子。ここではページの中でデコードされるので、そのいずれも当方へ提供されません。

この種のエクスポートをオンラインの道具で見られるのはそのためです。遠隔でデコードするサービスはその 1 行を受け取っており、ログに持っています。多くの社内規程が存在するのは、まさにその事態を防ぐためです。

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

+ は空白として扱うべきですか。

クエリ文字列から来た文字列ならほぼ確実にそうです。HTML のフォームは空白を + と書きます。パスから来たなら違います。そこではプラスはプラスです。だから推測ではなく選択にしています。

デコードしても %20 が残ります。なぜですか。

文字列が 2 回エンコードされていて、%2520 を含んでいたからです。1 回の処理としては正しい結果です。直すべきは、エンコード済みの値をもう一度エンコードしている処理の段です。

正しく見える列が失敗するのはなぜですか。

そのバイト列が妥当な UTF-8 を構成しないからです。%82%A0 は Shift_JIS の「あ」で、ここでは妥当ではありません。結果のように見える置換文字を返す代わりに、その旨を伝えます。

そのアドレスは開かれますか。

いいえ。デコードするだけで訪問しません。ホストへのリクエストも、プレビューも、リダイレクトの追跡もありません。怪しい URL や 1 回きりの URL では、それこそが肝心です。

文字列は端末から出ますか。

いいえ。このページの中でデコードされます。重要です。ログから来た URL は、隣にセッション識別子やトークン、ときにはメールアドレスを連れているからです。

他のツール