網址編碼

這件事有兩個答案，這一頁兩個都給你

這是最值得避開的錯誤，也是為什麼這裡不替你做決定。

encodeURIComponent 會把分隔符號 : / ? & = # 一起轉掉，因為它假設這段文字是要放 進網址裡的——當成查詢參數，或路徑的一段。如果那些字元原樣保留，它們就會改變外層網址的 結構。

encodeURI 則保留它們不動，因為它假設你給的是一整個網址，只是需要整理一下——裡面有 空白，或有中文字。

搞反了就是那個經典的錯誤：用 encodeURI 把一個網址塞進查詢參數，它的 ? 和 & 會併進 外層網址裡，於是 ?next=https://x.com/a?b=1 悄悄地變成兩個參數而不是一個。

狀態列會在兩者結果不同時告訴你，而那正是這個選擇有意義的時候。

表單編碼是第三種東西

HTML 表單送出空白時用的不是 %20，而是 +，而且從以前就是這樣—— application/x-www-form-urlencoded 比現代的網址規則更早出現，之後也沒有跟上。

這就是為什麼解碼那邊有一個把 + 視為空白的選項。少了它，表單值解碼出來會留下一堆真的 加號；而把它套用在一般網址上，又會把合法的 + 變成空白。光看字串本身無法判斷是哪一種， 所以它是一個開關，而不是一個猜測。

對已經編碼過的東西再編碼

%20 會變成 %2520，這是正確的而不是 bug：% 本身就是保留字元，把它編碼是表示「一個真 正的百分號」的唯一辦法。一個會自動跳過既有編碼序列的工具，根本沒辦法編碼 100%。

如果你在網址裡看到 %2520，就表示有東西被編碼了兩次。那就解碼兩次。

Emoji 與中文

兩者都會編成 UTF-8 位元組，所以一個中文字會變成三個百分號序列，大多數 emoji 會變成四個。 這是正常的。

不正常的、而且有些工具真的會做錯的，是把一個字元從中間切開。任何 U+FFFF 以上的字元——大多數 emoji，以及像 𝕏 這樣的字元——在內部是以代理對儲存的，如果依索引而不是依字元來編碼，就會產生 兩個壞掉的半邊，解碼出來什麼都不是。這裡是依字元編碼的。

沒有任何上傳

編碼在這個頁面裡完成。這一點在這裡特別重要：正在被除錯的網址，常常帶著權杖、工作階段識別碼 和 API 金鑰。