URL 編碼是什麼？

為什麼 URL 需要編碼

RFC 3986 把 URL 限制在一小組 ASCII 字元內，其中有些字元還有特定任務：? 開始查詢字串，& 分隔參數，= 分開名稱與值，# 開始片段，/ 分隔路徑段落。如果某個值含有這些字元，URL 就會產生歧義。

以搜尋「salt & pepper」為例。直接寫成 ?q=salt & pepper，伺服器會看到參數 q 的值是 salt ，外加另一個名為 pepper 的空參數。編碼成 ?q=salt%20%26%20pepper 後，才會以單一值送達。

哪些字元需要編碼

編碼是以位元組為單位，而不是字元。非 ASCII 文字會先轉成 UTF-8，每個位元組各自變成一組 %XX：

十六進位數字不分大小寫，%c3%a9 和 %C3%A9 意思相同，但 RFC 3986 建議統一用大寫。

%20 還是 +：空格的兩套規則

依 RFC 3986 定義的百分比編碼，空格一律寫成 %20。HTML 表單送出時使用另一種相關格式 application/x-www-form-urlencoded，其中空格變成 +，真正的加號則變成 %2B。

• 在 /files/my report.pdf 這類路徑中請用 %20。路徑中的 + 就是字面上的加號。
• 在查詢字串中，解析表單編碼的伺服器會把 + 當成空格。%20 兩種慣例都看得懂，不確定時用它比較保險。
• 如果值裡可能有真正的 +，例如 +84 這種電話號碼，就必須以 %2B 送出，否則會變成空格。

JavaScript 的 encodeURIComponent 與 encodeURI

encodeURIComponent("a b&c") 會回傳 a%20b%26c，而 encodeURI("a b&c") 回傳 a%20b&c，因為它假設 & 是分隔符號。常見的錯誤是對參數值呼叫 encodeURI，讓 &、= 和 # 原樣通過，把值切斷了。

new URLSearchParams({ q: "a b&c" }).toString() 會得到 q=a+b%26c。在標準伺服器上，兩種形式解碼後都是同一個值。

常見錯誤

1. 重複編碼：對已編碼的文字再編碼一次，%20 會變成 %2520，因為 % 本身被編碼成 %25。每個值只在放進 URL 的那一刻編碼一次。
2. 用元件函式編碼整個 URL：https:// 會變成 https%3A%2F%2F，連結就失效了。
3. 路由前先解碼：伺服器若在比對路由前就把 %2F 解成 /，可能被誘導去讀取另一個路徑。
4. 預設使用舊字元集：有些舊系統把「é」編碼成 %E9（Latin-1）。現代瀏覽器和 WHATWG URL Standard 都使用 UTF-8。