為什麼你的 URL 壞了(以及如何修復它)

你將 URL 貼到電子郵件中。有人點擊它。他們得到 404。

URL 看起來沒問題。但在你的瀏覽器和他們的瀏覽器之間的某個地方,一個空格變成了 %20,一個 & 符號消失了,或者一個加號變成了完全不同的東西。

URL 編碼存在是因為 URL 只能包含某些字符。其他所有東西都需要翻譯。

特殊字符的問題

URL 在早期網路時代設計時有限的字符集。這些是安全的:

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

其他所有東西?可能有問題。

空格 變成 %20 或 +,取決於上下文。帶有字面空格的 URL 會損壞。

& 符號(&)分隔查詢參數。如果你的資料包含 & 符號,URL 解析器認為它正在開始一個新參數。

問號(?)表示查詢字串的開始。資料中的一個會混淆一切。

何時自動編碼

當你輸入 URL 時,瀏覽器會編碼它們。這就是為什麼你可以將「new york restaurants」貼到 Google 中並且它有效。

但自動化系統通常不會。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 編碼是那些在無形中工作的東西之一,直到它不工作。理解規則有助於你在 URL 神秘地損壞時更快地除錯。