なぜあなたのURLが壊れたか（そして修正方法）

メールにURLを貼り付けます。誰かがクリック。404が出ます。

URLは問題なく見えました。でもブラウザと彼らのブラウザの間のどこかで、スペースが %20 になり、アンパサンドが消え、プラス記号が別のものに変わりました。

URLエンコーディングが存在するのは、URLが特定の文字しか含められないからです。それ以外は翻訳が必要。

特殊文字の問題

URLは初期インターネット時代に限られた文字セットで設計されました。安全なのは：

A-Z a-z 0-9 - _ . ~

それ以外？潜在的に問題。

スペース は %20 または + になります、文脈によって。リテラルスペース付きURLは壊れます。

アンパサンド (&) はクエリパラメーターを区切ります。データにアンパサンドが含まれていると、URLパーサーは新しいパラメーターが始まると思います。

疑問符 (?) はクエリ文字列の開始を示します。データ内の1つがすべてを混乱させます。

エンコーディングが自動で起こる時

ブラウザは入力時にURLをエンコードします。だからGoogleに「new york restaurants」を貼り付けても機能するのです。

でも自動システムは多くの場合しません。API、スクリプト、メールクライアント——書かれた通りにURLを渡すかもしれません。安全でない文字が含まれていると、壊れます。

二重エンコーディングの罠

ここが厄介になる所。

URLをエンコード。それからパラメーターとして別のURLに入れる。システムが再度エンコード。今 %20 が %2520 になります。

デコード時、スペースではなく %20 が得られます。

これはリダイレクトURL、トラッキングパラメーター、OAuthコールバックで常に起こります。URLが余分なパーセント記号で壊れて見えるなら、二重エンコーディングをチェック。

よくあるエンコーディングミス

URL全体をエンコード。 しないでください。値だけをエンコード、構造ではなく。https:// は https%3A%2F%2F になるべきではありません。

プラス記号を忘れる。 クエリ文字列で、+ はスペースを意味。データにリテラルのプラス記号があると、エンコードが必要、さもないと消えます。

エンコーディングが冪等だと思う。 すでにエンコードされた文字列をエンコードすると異なる出力を生成。エンコード前にエンコードされているかチェック。

実例

スペース付き検索クエリ：

変更前: https://example.com/search?q=new york pizza
変更後:  https://example.com/search?q=new%20york%20pizza

パラメーターとしてのコールバックURL：

callback = https://mysite.com/auth?token=abc
エンコード:   https%3A%2F%2Fmysite.com%2Fauth%3Ftoken%3Dabc

URL内のメールアドレス：

変更前: user+tag@example.com
変更後:  user%2Btag%40example.com

URL問題のデバッグ

実際のリクエストをチェック。 ブラウザ開発ツールが何が送信されているかを表示。期待したものと比較。

デコードして検査。 URLが機能していないなら、デコードしてサーバーが実際に何を受け取っているかを見る。

特殊文字でテスト。 テストデータにスペース、アンパサンド、プラス記号を含める。「test」で動くが「test & verify」で失敗するなら、エンコーディング問題があります。

---

URLエンコーディングは機能しないまで見えずに機能するものの1つ。ルールを理解すれば、URLが謎に壊れた時のデバッグが速くなります。