我們每天都在瀏覽器的位址列裡面很多次輸入URL，應該對它非常熟悉。瀏覽器位址列包容性很強，英文、中文、日文、韓文統統都能輸入，而瀏覽器也能給出比較正確的反饋。
但是，這只是表象，真正的網路世界對輸入語言的要求是非常苛刻的，可以說是專屬於英文字元的。
雖然在 URL 中使用一些中文字元從技術上講不存在識別和傳輸的問題，但是網路標準協定中卻規定了 URL 中只能包含英文字元。
那麼，我們在位址列裡看到和使用的中文又是怎麼回事呢？
事實上，那只是瀏覽器的障眼法。雖然我們在瀏覽器的輸入框裡使用了中文，可一旦瀏覽器發出網路請求，請求中的中文將不復存在，會變成我們經常看到卻不明所以的東西，比如“％e5%82%bb%e5%91%80”，這就是 URL 中的中文被編碼後的結果。
可能大家會覺得這種編碼結果有些奇特，跟平時看到的編碼比，它多了很多的這個“％”，其實只是分隔符，如果把“％”替換成空格，就可以看到我們熟悉的編碼結果了，比如上面的“e5 82 bb e5 91 80”，眼尖的讀者可能會看出這就是中文的 UTF-8 的編碼。
按照標準進行編碼是合理的，但是標準沒有規定用什麼編碼，於是開發人員開始各自為戰，有用 UTF-8 編碼的，也有用 GB2312 編碼的，這兩種編碼是什麼不重要，重要的是兩種編碼的結果不一樣，很多時候後台、前端、終端之間的矛盾就是因它而起的。
更讓開發者覺得麻煩的是標準沒有提供編碼守則，於是程式設計師開始自由發揮。例如，在 URL 的實際使用過程中，經常會對 URL 的引數進行拼裝，拼裝的 URL 引數來源往往是沒法確定的。
不過，不管引數的內容是什麼，為了避免出現中文字元，開發者一般會在 URL 拼裝完畢後統一做一次編碼。
問題是，引數源可能已經將 URL 編碼過一次了，而編碼後的字串是能夠再次被編碼的，就像俄羅斯套娃一樣，所以看到一個編碼結果時，開發者甚至沒法確定它要被解碼多少次才能得到真正的結果。
大家再看到這種包含很多“％”的字串時，別認為是加密資料，隨便找個 URL 解碼工具就能還原它。