分析と広告のためのCookie
分析と広告のためにCookieを使っており、どちらもGoogleに送られます。拒否しても、目に見える動作は何も変わりません。プライバシーポリシーを読む
URL か値を貼り付けて、パーセント列の下に何と書いてあるかを読んでください。本当に曖昧な点はひとつだけで、それは選択として提示します。プラス記号が、フォームのクエリ文字列のように空白なのか、パスのように本物のプラスなのか。何も送信されません。ここに貼り付けられる URL はログから来ていて、隣にセッション識別子が並んでいるからです。
処理される場所
ファイルがないので、何もアップロードされません。計算はこのページの中で行われます。
順番待ちもアカウントもなし
お使いの機械の速さで答え、あなたが誰かを尋ねることはありません。
何度でも
回数は数えず、上限もありません。もう一度答えることに費用はかからないからです。
クエリ文字列の中の `+` は、ほぼ常に空白を意味します。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 回通すことではなく、処理の鎖の中でエンコード済みの値をもう一度エンコードしている段を見つけることです。たいていはフレームワークが自動でやり、テンプレートがもう一度やっています。
アドレス全体をデコードすると `%2F` はスラッシュに、`%3F` は疑問符になり、結果は同じ構造を持たなくなります。値だったものが、パスや新しいクエリ文字列に見えるようになります。
読むためには有用で、再利用するには危険です。オープンリダイレクトはまさにこの形で作られます。攻撃者がエンコードされた URL を値として入れ、何かが検査の前にそれをデコードする。規則は、見るためにデコードし、検証は必ず元の形に対して行うことです。
サーバーのログから URL を読んでいるなら、`#` より後ろにあったものはそこにありません。ブラウザーは決して送らないからです。見えているアドレスは設計上不完全で、利用者が持っていたものと記録に残ったものとのあいだでパラメーターが「消える」事例の少なからずを説明します。
分析のエクスポートには現れることがあります。そちらはそれを見ているスクリプトが書いているからです。いま見ている文字列がどの出どころから来たかを知ることは、そこから何を結論できるかを変えます。1 時間の混乱を節約する種類の細部です。
検索語、リダイレクト先、メールアドレス、確認用のトークン、そして UTM のパラメーター。最初の 3 つはかなりの頻度で個人データで、4 つめは 1 回きりの資格情報です。
エンコードされていることは何の保護にもなりません。パーセントエンコードは誰にでも読め、その文字列はサーバーのログ、ブラウザーの履歴、次のクリックのリファラーヘッダーにあります。ここで秘密らしきものが出てきたなら、それが発見です。デコードできたこと自体ではありません。
`utm_source`、`utm_medium`、`utm_campaign`、`utm_term`、`utm_content` は、Google Analytics の元になった Urchin という道具から来ています。サーバーでは何もしません。ブラウザーの計測スクリプトが読むテキストです。
何もしないので、リンクを転送するときに削っても影響はありません。送ってくれた人の統計と自分の転送を混ぜたくなければ、そうする理由があります。そしてアドレスに入っているので、履歴と共有リンクとブックマークに残ります。メールマガジンのリンクがばかばかしく長い理由です。
ここではデコードするだけで、訪問しません。ホストへのリクエストもリダイレクトの追跡もプレビューもありません。判断です。怪しい URL を調べている人は、道具にそれを開いてほしくない筆頭だからです。
開けば何かを漏らしもします。リクエストはサーバーから出て、その IP と時刻は相手側のログに残り、1 回きりのアドレス——確認リンク、パスワード再設定——なら道中で使い切ってしまいます。
ログや分析のエクスポートに含まれる URL は、頻繁に個人データを運びます。検索語、パラメーターに入ったメールアドレス、アカウントに結びつく識別子。ここではページの中でデコードされるので、そのいずれも当方へ提供されません。
この種のエクスポートをオンラインの道具で見られるのはそのためです。遠隔でデコードするサービスはその 1 行を受け取っており、ログに持っています。多くの社内規程が存在するのは、まさにその事態を防ぐためです。
クエリ文字列から来た文字列ならほぼ確実にそうです。HTML のフォームは空白を + と書きます。パスから来たなら違います。そこではプラスはプラスです。だから推測ではなく選択にしています。
文字列が 2 回エンコードされていて、%2520 を含んでいたからです。1 回の処理としては正しい結果です。直すべきは、エンコード済みの値をもう一度エンコードしている処理の段です。
そのバイト列が妥当な UTF-8 を構成しないからです。%82%A0 は Shift_JIS の「あ」で、ここでは妥当ではありません。結果のように見える置換文字を返す代わりに、その旨を伝えます。
いいえ。デコードするだけで訪問しません。ホストへのリクエストも、プレビューも、リダイレクトの追跡もありません。怪しい URL や 1 回きりの URL では、それこそが肝心です。
いいえ。このページの中でデコードされます。重要です。ログから来た URL は、隣にセッション識別子やトークン、ときにはメールアドレスを連れているからです。