URL エンコードとデコード オンライン: リンクを壊さずにパーセント エンコードの完全ガイド

パーセントエンコーディングを尊重することを教えてくれたバグは、ちょうど1 人の顧客のために失敗したOAuthリダイレクトでした。 WP Adminifyは、OAuthを介して認証されたGoogle Fontsの統合を持っていました、そして、1 人のユーザー - いくつかのリバースプロキシセットアップを実行しているホスティングリセラー私はまだdon& #39; 完全に理解していません - を取得し続けました redirect_uri_mismatch エラー。 他のみんなは元気でした。 2 日間の大半を彼のサーバー構成のせいにして過ごしました。 最終的に、彼のブラウザが送信していた URL を文字ごとに確認したところ、次のようになりました。 %2520 スペースがあってはならない場所。 彼のプロキシは、Redirect_URI をエンコードしていました。 私のプラグインは 同じく エンコードします Googleはスペースが2 回エンコードされていたURLを受け取りました - %20 になった %2520ー そしてハンドシェイク全体を拒否しました 2 行のコードで修正しました 2 日で探せました。

それは& #39; 私の最初のエンコーディング災害でさえありました。何年も前、I& #39; d は、生のアンパサンドを含む UTM パラメーターを使用してプラグイン起動用のキャンペーン リンクを構築しました。のようなもの utm_campaign=black&friday。 分析ダッシュボードには、次のような不思議なキャンペーンが表示されました black というファントムパラメータ friday それは何にも合いませんでした。 アンパサンドは私のパラメーターを静かに 2 つに分割しました。 エラーなし。 警告なし。 数が足りないことに気付く前の 11 日間、データが間違っていただけでした。

Here's the thing about URL encoding: it's 1 つのそれらの問題のそれはisn& #39;tまで些細なように見えます。ルールは2005 年の仕様で生きています ()RFC 3986)、ブラウザの現実は別の仕様 (the) で動作します WHATWG URL Standard)、JavaScript では 3 つの異なる関数が提供され、すべてわずかに異なる動作が行われます。そして、PHP ではさらに 2 つの関数が提供されます。間違って、あなたは ' クラッシュを取得しません。 - パラメータが切り詰められ、OAuth フローが壊れ、Chrome で動作するが電子メール クライアントで消えるリンクが表示されます。

そこで、ずっと欲しかったエンコーダ/デコーダーを作りました Toolz.dev. このガイドでは、その使用方法、そして - さらに重要なことに - パーセントエンコーディングが実際にどのように機能するかについて説明しています。したがって、次は %2520 ログに入れると、2 日ではなく 2 分かかります。

tl;dr: オンラインで URL エンコードまたはデコードをするには、文字列を Toolz.dev URL エンコーダ/デコーダ、モードを選択して、エンコードまたはデコードを押します。 UTF-8 と絵文字を正しく処理し、スワップ ボタンで出力を入力に送り返すので、ダブルエンコードされた値 (%2520) 一度に 1 つのレイヤーを分けて。 すべてがクライアント側で実行されるため、URL 内のトークンとセッション ID がサーバーに触れることはありません。 エンコード パラメータ 値 コンポーネント モードで、完全な URL をエンコードするだけです。理由がわかっている場合のみです。

主な機能

1 つのツールでエンコードとデコード

値をエンコードする必要がある時間の半分. 他の半分I& #39; mはログファイルからgnarly URLを見つめ、読みやすいものにデコードする必要があります.ツールは両方の1 つの入力ボックスから行う - エンコードとデコードは2 つのボタンとして互いに隣り合って座っているので、there& #39; sは別のページを探す必要はありません.エンコードされた文字列を貼り付けてDecode; にヒットします生のクエリ値を入力してEncodeにヒットします.また、ラウンドトリップもきれいに:エンコード、デコード、そしてあなたは元の文字列を戻します, バイトごとにバイト.それは明白に聞こえますが、I& #39; 彼らはできたので往復でプラス記号をmangledオンラインツールを使用しました& #39; 彼らは従っていたどのスペックを決定しました.これは、すべてのステップで何をしているかについて明示的です& #39; sは、まさにあなたがしたいものです.you& #39; reデバッグ。

コンポーネントとフル URL エンコーディング モード

この区別はほとんどのエンコードバグが生まれる場所です。 component モードは isn't unreserved - を含む全てのものをエンコードします /、 ?、 &、そして =ーこれは、単一のパラメータ値に求めるものです。 full-URL モードでは構造文字が放置されるため、URL は URL として動作します。これは、you're が完全なアドレスをクリーンアップするときに求めるものです。間違ったものを使用すると、URL 構造が壊れるか、危険な文字がエンコードされないままになります。ツールは、両方のモードを 1 回のドロップダウンでワンクリックで区切り、それぞれに対応する JavaScript 関数でラベル付けします。 - encodeURIComponent、 encodeURI、 application/x-www-form-urlencoded。 私はその命名について行ったり来たりしました。 インテント ラベル (「値をエンコード」、「URL 全体をエンコード」) はより冷たく読み取れますが、関数名は、あなたが書き込もうとしているコードに 1 対 1 マップの下の参照パネルを意味し、実際にほとんどの人が参加する瞬間です。 タイプしたことがあるなら encodeURI あなたが意味したとき encodeURIComponent- 私は複数回持っています - パネルはあなたが出荷する前にそれを捕まえるためにあります。

UTF-8、絵文字、国際文字を処理します

タイプ café そしてあなたは得る caf%C3%A9ー the é 2 つの UTF-8 バイトに正しく拡張されました。 絵文字を入力すると、4% エンコードされたバイトが得られます。 これは、古いツールと廃止された JavaScript です。 escape() 機能がバラバラになる: ラテン語-1 を想定するか、非標準を生成します %uXXXX サーバーが解析できないシーケンス。 if you'ユーザー生成コンテンツを含む URL を構築し直します - isn't 英語 - isn't を処理する正しい UTF-8 ベンガル語テキスト、アラビア語のスラグ、中国語の検索語: これらはすべて、もう一方の端で同じようにデコードする有効な RFC 3986 パーセント シーケンスにエンコードされます。

ダブルエンコード値のスワップ ボタン

ザ・ %2520 トラップ - すでにエンコードされています %20 もう一度エンコードを取得する - 1 回で2 日間かかるので、これは個人的なものです デコードは単層操作です: %2520 にデコードします %20、スペースではなく、なぜなら %25 です のエンコード %。 1 つのパスで 1 つのレイヤーが得られます。 スワップボタン（⇄) は、出力を入力ボックスに戻し、次のパスがワンクリックで行えるようにします。 I'veは、プロキシ、リダイレクトサービス、および電子メールリンクラッパーを通過した後、3 層の深さのURLを開きます - 文字列が変更を停止するまで、スワップ、デコード、スワップ、デコードします。 that " stops changing" moment is the actual signal you're looking for. Be honest about what this is: it's a manual loop, not a detector. The tool does't flag %25XX あなたのために、そして私はそうすべきかどうかについて行ったり来たりします。パーセント記号を正当に含む値を静かに破壊するまで、安定するまで自動デコードが便利でしょう。

3 つのモード、1 つの明示的なリファレンス パネル

モードセレクターには、コンポーネント、フルURL、フォームURLエンコード済みの3 つのオプションが搭載されており、その下のパネルには、そのモードがエスケープする文字が正確に綴られ、それが保存され、実際に動作する例が記憶に残らなかったため、追加しました encodeURIComponent 葉 ~ 一人で（そうです）、それとも ! あんど * RFC 3986 は予約されていないものではなく、サブデリムとして分類されているため、生き残る (彼らは人々を驚かせます)。 JavaScript の 3 つの関数を覚える代わりに、意図的にモードを選択し、これから実行しようとしていることを読み返します。 その参照テキストは、私が最もよく使う部分であり、午前 1 時に寒いページに着地していたら、私が望んでいるものです。

100% クライアント側 - ブラウザから何も残らない

考えてみてください& #39; sは、実際には、あなたがデコードするURLの内側: OAuth認可コード、パスワードリセットトークン、セッションID、配信停止リンクの電子メールアドレス、APIキーいくつかのフレームワークは、クエリ文字列に詰め込まれて便利にそれらを貼り付け、サーバー側のツールに着地& #39; sアクセスログ、あなたのIPに縛ら、保持誰がどのくらいの時間を知っています. Toolz.devエンコーダは完全にブラウザで実行されます - 変換は、ローカルで実行JavaScriptの数行であり、あなたのデータを使用して要求は行われません.devToolsを開き、ネットワークタブを見て、あなたがdon& #39; tが私を信じるなら、セキュリティに隣接するものは何でも、クライアント側のisn& #39; t機能、it& #39; s最小バー。

無料、サインアップなし、制限なし

アカウント ウォールも、文字列変換を行うツールのクォータのしなやかで、1,000 文字を超えるデコードをプロにするための「プログラミング」はありません。 ブックマークして、1 日 50 回使用して、完了です。

URL エンコーダとデコーダの使い方

ステップ 1: ツールを開いて、方向を選択してください

に行く Toolz.dev/tools/url-encoder そして、あなたの弦を左の箱に入れます。 エンコードとデコードの 2 つのアクション ボタンがあり、最初に方向を設定するのではなく、貼り付け後に 1 つを選択します。 読みやすいもの (検索クエリ、埋め込みしようとしているリダイレクト URL) から始めている場合は、エンコードを押します。 パーセント記号 (ログ エントリ、リファラー ヘッダー) でいっぱいの何かから始めている場合は、デコードを押します。 出力は右側のペインに着陸し、ヘッダーにコピー ボタンを配置し、2 つのアクション ボタンの隣にスワップしてクリアします。

ステップ 2: コンポーネント、フル URL、またはフォーム モードを選択します

エンコード 値 それはパラメーター、つまり redirect_uri、検索語、その後のあらゆるものの内側に位置します = サイン? コンポーネント モードを使用します。 それはエンコードします /、 ?、 &、そして = したがって、あなたの価値は周囲の URL を壊すことはできません。 エンコード 完全な URL スペースと非 ASCII 文字をクリーンアップする必要があるだけですか? 構造文字を保持する完全な URL モードを使用します。 3 番目のモード、form-urlencoded は、スペースを次のように書き込んだコンポーネントのエンコーディングです。 + 代わりに %20ー pick it when you're hand-building an application/x-www-form-urlencoded 体。 このモードはデコードにも影響することに注意してください。フォーム モードでは、 + デコードする前にスペースに戻されます。残りの 2 つは文字通りプラスのままです。 疑わしい場合: ピースのコンポーネント モード、全体のフル URL モード。

ステップ 3: 出力を読み、パーセント記号が残っているかを確認する

出力が右側のペインに表示されます。 デコードする場合は、結果にまだ含まれているかどうかを確認してください %XX シーケンス - もしそうなら、値は複数回エンコードされました。 「スワップ」を押して、その出力を入力に戻し、再度デコードして、文字列の変化が止まるまで繰り返します。 「入力」が不正な形式 (迷走) になっている場合 % 文字通りのように、2 桁の 16 進数が続くわけではありません 100%)、サイレント ハーフ デコードではなく、明示的なエラーが発生します。これは、デバッグ時に必要な動作です。

ステップ 4: コピーして確認する

コピーボタンを押して、結果が属する場所に貼り付けます 重要なことなら何でも - OAuthは特にリダイレクトします - 最後の正気度チェックを1 つ行います: エンコードされた値をデコードモードで貼り戻し、ラウンドトリップで始めたものを正確に確認します 30 秒の検証は2 日分を上回ります redirect_uri_mismatch。

パーセントエンコーディング、RFC 3986、なぜスペースが %20 または + になるのか

URL には、限られた文字セットしか安全に含めることができません。 他のすべてはパーセント エンコード バイトとして密輸する必要があります。 ルールブックは RFC 3986 (2005) で、キャラクターを 2 つの陣営に分けます。

予約されていない文字 エンコーディングは必要ありません: 文字 A–Z あんど a–z、数字 0–9、および4 つの記号 - ハイフン -、期間 .、アンダースコア _、そしてチルダ ~。 これらをエンコードすることは合法ですが、意味がありません。

予約文字 URL 内に構造的なジョブを設定します。 : / ? # [ ] @ (一般的な区切り記号) そして ! $ & ' ( ) * + , ; = (サブデリミタ)。 コロンは、スキームをホストから分離します。 疑問符は、クエリ文字列を開始します。 アンパサンドはパラメーターを分離します。 予約文字にエンコーディングが必要かどうかは、完全に依存しています。 登場するところ。 あ / パスには構造があります。 / REDIRECT_URI パラメータの値の中にある値はデータであり、次のようになる必要があります。 %2F さもないと、サーバーがあなたの URL を間違って解析します。

メカニズム: 文字を取り、その UTF-8 バイトを取得し、各バイトを次のように書きます。 % 16 進数2 桁が続きます. ASCII文字は1 バイトです - 空間は %20、アンパサンドは %26。 ただし、UTF-8 はマルチバイト エンコーディングであるため、 é 2 バイトです。 %C3%A9。典型的な絵文字は 4 バイト - 涔は としてエンコードされます %F0%9F%9A%80。 これが、1 文字を想定するツールが 1 バイトに等しいと仮定するツールが、平易な英語以外のすべてを破損する理由です。

さて、スペースの問題 - URLエンコーディングで最も混乱する唯一のもの RFC 3986 によれば、スペースは になります %20。 しかし、HTML フォームの送信では、別のシリアル化を使用します。 application/x-www-form-urlencoded、今日定義されている 何という URL 標準、そして あれか フォーマットはスペースを次のようにエンコードします +.どちらも正しい - それぞれの文脈で.つまり + クエリ文字列では、あいまいです。それは、リテラルプラス記号 (RFC 3986 読み取り) またはエンコードされたスペース (フォームエンコードの読み取り) である可能性があります。 電話番号が次のように届くのを見たことがあるなら 1234 5678 誰かが送ったとき +1234...、あなたはこのバグに遭遇しました。 私のアドバイス: 常に発信する %20 スペースや %2B 文字通りのプラス記号の場合。 誰もそれらを誤って言いません。

JavaScript は 3 つの関数を提供しますが、それらは交換可能ではありません。 文字列を指定すると a=b&c d:

const s = "a=b&c d";

encodeURIComponent(s); // "a%3Db%26c%20d"  — encodes =, &, and space
encodeURI(s);          // "a=b&c%20d"      — leaves = and & alone
escape(s);             // "a%3Db%26c%20d"  — deprecated; breaks on Unicode

encodeURIComponent 未予約文字以外のすべてをエンコードします (さらに !'()*- 従来の癖なので、パラメータ値に対して安全です。 encodeURI 完全な URL が機能し続けるように予約文字が保存されますが、それはまたそれを意味します しない 保護する & あなたのデータの中に。 あんど escape() 正当な理由で非推奨となります: 非標準を生成します %uXXXX ラテン語以外の文字のシーケンス。 新しいコードでは絶対に使用しないでください。

PHP は、ひねりを加えた同じ分割をミラーリングします。 urlencode() フォーム スタイルのエンコードを生成します (スペースは、 +)、その間 rawurlencode() RFC 3986 に従います (スペースは %20. フォーム ポストの本文以外の URL を作成している場合は、 rawurlencode() あなたが望むものです。 早い段階で WP を間違ったコードで出荷しましたが、WordPress のコードを自分のものとしました。 add_query_arg() 認めたくなかったよりも多くの時間を救ってくれました。

最後に、ダブルエンコード トラップです。 %20 エンコードされたスペースです。 エンコードする あのストリング 再び、そして % それ自体になる %25、あなたに与える %2520。 一度デコードして、あなたは得る %20 back - still encoded.これは、システムの2 つのレイヤーが、それぞれ" helpfully" encode:あなたのコードプラスプロキシ、リダイレクトサービスプラス電子メールのリンクラッパーのたびに発生します。それを防ぐルール:正確に1 回エンコードし、値がURLに入る前の最後の可能な瞬間に、そしてあなたがやったことを決してエンコードしない& #39; 単にデコードするか、生の生成をするだけ。

よくある使用例

ユーザー入力によるクエリ文字列の構築

ユーザー入力されたテキストが URL に入るたびに - 検索ボックス、フィルター、GET 経由で渡されるフォーム値 - コンポーネントエンコードされている必要があります。 を検索するユーザー Q&A tips なる ?q=Q%26A%20tips; エンコードされていない場合、サーバーは次の検索を行います。 Q そして謎のパラメータ A tips。 開発中には、 URLエンコーダ コードを記述する前に期待値を生成するため、正しい既知の正しい参照をテストしてテストします。 これは、「この文字をエンコードする必要があるか」を解決する最も簡単な方法でもありますか?」 引数 コード レビュー: コンポーネント モードで貼り付けて見てみてください。 JavaScript のような最新の API URLSearchParams これを自動的に処理し、使用する必要がありますが、それでも使用する必要があります 確認する 何かが壊れたときの出力、そしてそれはデコード作業です。

UTM とキャンペーン リンクのデバッグ

マーケティングリンクは、地雷原をエンコードしています. UTM値 スペース、パイプ、またはアンパサンド; URL短縮ツールを通過するリンク、次に電子メールサービス& #39; sクリックトラッカー、次にリダイレクト - 各レイヤーは、エンコードを追加またはマングルする機会が分析で間違って表示されたキャンペーン、私の最初の動きは常に同じです: デコードモードに完全なリンクを貼り付け、分析サーバーが実際に受け取ったものを読み取る 10 回中9 回 犯人は数秒で見えます - 生の & パラメータを分割する場合、 + それは文字通りのプラス、または %2520 二重符号化を裏切る。 わたしの black&friday インシデントは、1 日目にこれを行った場合、11 日間のデータ ホールではなく、11 秒の修正でした。

OAuth Redirect_URI とコールバック URL

エンコードミスが高額になるのは、プロバイダーがそうするため、OAuth は、 完全な文字列マッチング リダイレクトURI上。 redirect_uriは別のURLの中にパラメータ値として埋め込まれた完全なURLです - だからそれはコンポーネントエンコードされている必要があります、ちょうど1 回. under-encode it and the ? や & その中にあると、外部の承認 URL が壊れます。 ダブルエンコードすると、プロバイダーは比較します https%3A%2F%2F... あなたの登録に対して https://... そして返品 redirect_uri_mismatch さらに詳細はありません。 そのエラーが発生した場合は、ブラウザのアドレス バーから実際の承認 URL をデコードし、Redirect_Uri 文字ごとの文字とアプリの登録値を比較します。 それとペアリング JWT デコーダ 戻ってきたトークンを検査するため、ブラウザーを離れることなく、OAuth フロー全体をデバッグできます。

ログとリファラー ヘッダーからの危険な URL のデコード

サーバー ログとリファラー ヘッダーは、パーセント エンコードされたスープでいっぱいです。 %D0%9F%D1%80%D0%B8%D0%B2%D0%B5%D1%82 検索リファラーでは、ボット トラフィックからの三重エンコードされたパス、疑わしいリクエストでエンコードされたペイロード。これらをデコードすることで、実際に何が起こったのかを知ることができます。その奇妙な 404 がキリル文字のクエリを持つユーザーだったのか、スクリプトを調べていたのか ../../etc/passwd エンコーディングの 3 つのレイヤーの背後にあります。 これはまさにプライバシーの観点からも重要な状況です。ログ URL には、定期的にセッション トークンと電子メール アドレスが含まれます。 独自のログを保持するランダムなサーバーではなく、クライアント側のツールでそれらをデコードします。 このワークフローについて詳しくは、 API デバッグ ツール ガイド。

Curl を使用した API テスト

シェルとカールは、URL エンコーディングの上に 2 番目の地雷原を形成します。 & Bash でのバックグラウンドのプロセス、 ? zsh で glob 拡張をトリガーする - そのため、引用符で囲まれていないエンコードされていない URL は、ネットワークに到達する前に混乱を招く方法で失敗します。 私のワークフロー: ツール内の各パラメータ値をエンコードし、URL を組み立て、シングル クォートでラップしてから curl を実行します。 " が正しく見えるリクエストに対して API が 400 を返したとき、" は冗長な出力から正確な URL をデコードします (" は、その URL を正確にデコードします)curl -v)本当に送信されたものを確認するには - バグは私のAPIではなく、私の端末だったことが一度ならず。 curl' s --data-urlencode フラグはポスト ボディのエンコードを処理しますが、クエリ文字列を取得する場合は、ほとんど自分で使用でき、信頼できるエンコーダは推測に勝ります。

非 ASCII テキストとリンクを共有する

他の言語のウィキペディアの記事、地元の地名を含む Google マップのリンク、ベンガル語またはアラビア語のナメクジを含むドキュメント URL - アドレス バーから 1 つをコピーすると、どちらかがきれいになる場合があります ユニコード の形または壁 %E0%A6%ACースタイルバイト, ブラウザに応じて& #39; sムード.いくつかのチャットアプリや電子メールクライアントは、切り捨てたり、生のUnicodeフォームをマングル.共有する前にURLをエンコードすると、すべてのメッセンジャーを生き残る純粋なASCII文字列を生成します, メーリングリスト, そしてMarkdownレンダラーI& #39; 試してみました.逆に行く, デコードは、人間がクリックする前に検証できる何かに戻って読めない共有リンクを回します - あなたが行ノイズのように見えた到着何かを転送する前に行う価値があります.

encodeUriComponent vs encodeUri と secse(): どちらを使用する必要がありますか?

3 つの関数、1 つの正しいデフォルト。 正直な比較は次のとおりです。

私のスタンス、そうすれば私はこの丘で死ぬだろう: 使い encodeURIComponent 値の場合、ほとんどの場合。 メンタルモデルは簡単です - 文字列が行く場合 中に URL (クエリ値、パス セグメント、リダイレクト_uri)、コンポーネントであり、 encodeURIComponent。 ある場合 encodeURI 真に正しいことはめったにありません。完全に構造化されたスペースまたは非 ASCII 文字を含む完全な URL を持っているので、その構造に触れずにサニタイズしたいということです。 これは、実際のエンコーディング コールの 5% かもしれません。 あんど escape() 2010 年頃以降に書かれたコードには決して表示されるべきではありません。その Unicode 出力は isn't 有効なパーセント エンコーディングであり、最新のリンターはすべてとにかくフラグを立てます。

もう 1 つのニュアンス: encodeURIComponent 葉 ! ' ( ) * 歴史的な理由でエンコードされていないが、RFC 3986 では予約済みのサブデリミターとしてリストされているにもかかわらず、 OAuth および strict-parsing API の場合、一部のライブラリはこれら 5 つもエンコードするために 2 番目のパスを追加します。 picky API があなたの値を拒否した場合、that' s は、探す場所 - と URL エンコーダ コンポーネント モードでは、どの文字が変換されたかを正確に表示して、比較できるようにします。

よくある質問

URLエンコーディングとは何ですか?

URLエンコーディング (percent-encoding) は、URL内の文字を表現するためのメカニズムで、そうでなければ安全でないか、構造的に意味のあるものになります。問題のある各文字はそのUTF-8 バイトに変換され、各バイトはパーセント記号の後に2 つの16 進数が続くものとして記述されます - スペースは% 20 になり、アンパサンドは% 26 になります。このルールはRFC 3986 で定義されています。 URLは限られた文字セットしか許可せず、?や& のような文字はURL構造内で行うべきジョブがあるからです。

スペースが %20 になることがあるのはなぜですか?

2 つの異なるスペック URL 自体を管理する RFC 3986 は、スペースを % 20 としてエンコードします。 WHATWG URL 標準で定義されている HTML フォーム送信で使用される application/x-www-form-urlencoded 形式は、スペースを + としてエンコードします。どちらも独自のコンテキストで有効であるため、クエリ文字列内の + は曖昧です。安全な慣行: スペースには常に % 20 を生成し、リテラル プラス記号には % 2B を生成します。すべてのパーサーはそれらを正しく処理します。

encodeuri と encodeuricomponent はどう違いますか?

encodeuricomponent は /, ?, &, = を含むほぼすべてをエンコードし、URL 内に配置された個々の値に対して安全になります。 encodeURI はそれらの予約文字を保存するため、完全な URL はその構造を維持します。 encodeuricomponent はパラメータ値とパスセグメントに使用します - これはほとんどすべての現実世界のケースです - そして、完全な URL を再構築せずにサニタイズする場合にのみ encodeURI を使用します。 & を含む値に encodeURI を使用すると、クエリ文字列が静かに破られます。

ダブルエンコードされた URL を修正するにはどうすればよいですか?

二重符号化は、既に符号化された文字列が再び符号化されると起こる - %20 は %25 に変わるのは % 自体が %25 になるからである 修正するには、% XX シーケンスが残らなくなり出力の変化が止まるまで繰り返し文字列を復号し、次にシステムのどのレイヤーが 2 回エンコードされるかを見つける - 一般的にはコードにプロキシ、リダイレクト サービス、または電子メール リンク ラッパーを加えたもの - そして、符号化ステップの 1 つを削除する。 ルール: 値が URL に入る前の最後の瞬間に、正確に 1 回エンコードする。

オンライン ツールで URL をデコードしても安全ですか?

ツールがクライアント側で実行されている場合に限ります。 URL には OAuth コード、パスワードリセットトークン、セッション ID、および電子メールアドレスが頻繁に含まれます。サーバー側のツールはそれらすべてを受信し、無期限にアクセスログに保存する場合があります。 Toolz.dev URL Encoder/Decoder は、JavaScript を使用してブラウザですべての変換を実行します。データはどこにも送信されません。これは、ブラウザ's ネットワーク タブで確認できます。資格情報やトークンを含むものについては、クライアント側の処理は交渉不可能である必要があります。

URL 全体をエンコードする必要がありますか、それともパラメーターだけをエンコードする必要がありますか?

データ部分 - 個々のパラメータ値と、時折、パスセグメントだけです。 URL自体の構造文字 (スキームの後の://、クエリの開始、パラメータ間の&) はエンコードされないままにする必要がありますか、URLが機能しなくなります。各値をコンポーネント形式のエンコーディングで個別にエンコードし、その周りにURLを組み立てます。完全なURLをエンドツーエンドでエンコードすることは、そのURL自体がOAuth redirect_uriのように、別のURL内の値になっている場合にのみ正しいです。

URL エンコーディングでは、絵文字と非英語の文字を処理できますか?

はい - 最新のパーセントエンコーディングはUTF-8 バイトで動作するため、Unicodeの文字はどれでも動作します。 eのような2 バイトの文字は% C3% A9 になり、4 バイトの絵文字は% F0% 9F% 9A % 80 のような4 パーセントシーケンスになります。 1 バイトエンコーディングを想定して無効な出力を生成するレガシーツールまたはJavaScript& #39; s非推奨のescape()関数でのみ問題が発生します。 Toolz.devエンコーダは、完全なUTF-8 を両方向に正しく処理します。

パラメータにアンパサンドが含まれていると、URL が壊れるのはなぜですか?

なぜなら & はパラメータ間の区切り文字です。 値に生の ampersand が含まれている場合 - utm_campaign=black&friday と言います - サーバーは値を black で utm_campaign という名前のパラメーターと friday という名前の 2 番目のパラメーターとして解析します。エラーは発生しません。データは単にサイレントに間違っています。 ampersand を値内で % 26 としてエンコードすると、パラメーターはそのまま到着します。これは、最も一般的で、最も目に見えない URL バグの 1 つです。

URL で %2F は何を意味しますか?

% 2F はパーセントエンコードされた前方スラッシュです。 you' lll see it when a value that that happens to contain a slash - a file path, a date like 07/07, or a nested URL - is correctly encoded before being placed in a query parameter or path segment.一部のサーバーやプロキシ (Apache、古い Tomcat バージョン、さまざまな API ゲートウェイ) は、セキュリティ上の理由からパス内の % 2F を拒否したり、サイレントにデコードしたりするため、エンコードされたスラッシュを持つリクエストが 404 を返す場合、通常はサーバー側の構成が原因であり、エンコードではありません。

Python、PHP、またはコマンド ラインで URL エンコードを行うにはどうすればよいですか?

Python: パス セグメントの場合は urllib.parse.quote() で、フォーム スタイルのクエリ値の場合は quote_plus()。 php: rawurlencode() はスペースに対して %20 で RFC 3986 出力を生成し、urlencode() は + のフォーム スタイルの出力を生成します。 コマンド ライン: jq -rr @uri または curl&-data-urlencode フラグ。 これらはすべて、このツールのコンポーネント スタイルの動作と一致するため、ここでエンコーディングのプロトタイプを作成し、コードがバイト同一の出力を生成することを確認できます。

まとめ

URL エンコーディングは、特大の見返りがある小さなスキルです。 一度読めるようになったら %C3%A9 エとスポットとして %2520 二重符号化の臭いとして、 " it works on my machine" bugs - broken OAuth flows, phantom UTM campaigns, APIs rejecting perfectly reasonable-looking requests - turns from mysterious to mechanical. (訳注: 仮訳) のカテゴリー全体が、私のマシンに作用する" bugs - は、インデックスカードに収まるルールである: 予約されていない文字が通過し、他の全てが % HH として UTF-8 バイトになり、値が構造化されずエンコードされ、そして正確に一度エンコードされる。

を保持します URL エンコーダ/デコーダ 兄弟の隣にブックマークが付いています Base64 コンバーター 他のエンコーディング スキームでは、すべての認証ヘッダーで出会うでしょう (私は完全な文字を書きました Base64 エンコーディングガイド いつ使用するか） HTML エンティティ エンコーダ/デコーダ Web コンテンツが一番上に積み重ねるのが大好きな 3 番目のエンコード レイヤー ( HTML エンティティ ガイド 私がヒットした同じトラップのダブル エスケープ バージョンをカバーしています %2520)、そして JSON フォーマッタ 復号化された URL が指すものは何でも。

より広範なブラウザーベースのデバッグ キットを組み立てる場合、 コーディング ツール ガイド これらのツールが実際のワークフローにどのように適合するかを説明します。 Toolz.dev 上のすべてのものはクライアント側で実行され、コストは何もかからず、1 つのジョブをうまく実行します。 That's のピッチ全体 - 1 つの置き忘れに 2 日間費やす前に、誰かが私に教えてくれたらよかったのにと思うピッチ %25。