連結裡的中文為什麼變成了 %E4%B8%AD 這種東西？
那是 URL 編碼後的中文，不是亂碼。URL 規範只允許英文字母、數字和少數符號，中文得先按 UTF-8 轉成位元組、每個位元組寫成一個 %XX。一個漢字通常佔三個 %XX。把整段貼到上面點「解碼」就能還原。反過來，你在瀏覽器網址列看到的中文連結，其實也是瀏覽器幫你把編碼後的形式顯示成了中文，複製出來往往還是 %XX。
%E4%B8%AD%E6%96%87 這類百分號編碼可以在這裡還原成中文；反過來也行，把中文、空格、特殊字元編成能安全放進 URL 的形式。支援 UTF-8 和 GBK 兩種字元集，能辨識加號形式的空格，貼進一整條連結還會自動拆開查詢參數逐個解碼。全部在瀏覽器本機完成，不上傳任何資料。%XX 就自動切到解碼，不帶就切到編碼，手動點過按鈕之後不再自動切。% 片段不會整段失敗，會原樣保留那幾個字元，其餘照常解出來。URL 的規範（RFC 3986）只允許出現英文字母、數字和少數幾個符號，中文、空格、引號這些字元都不在允許之列。要把它們放進連結，就得先按某種字元集轉成位元組，再把每個位元組寫成一個百分號加兩位十六進位數——這就是百分號編碼，也叫 URL 編碼。「中」在 UTF-8 下是三個位元組 E4 B8 AD，寫出來就是 %E4%B8%AD。所以看到一串 %E4%B8... 不是亂碼也不是加密，只是同一段文字的另一種寫法，三個 %XX 一組基本就能判斷是 UTF-8 編的中文。
這是寫程式時最容易搞錯的一處。encodeURIComponent 會把 : / ? # & = 這些結構字元也編掉，適合編單個參數值；encodeURI 會保留它們，適合編整條已經拼好的連結。用錯的後果很具體：把整條 URL 交給 encodeURIComponent，https:// 會變成 https%3A%2F%2F，連結直接失效；反過來用 encodeURI 編一個本身就含 & 的參數值（比如搜尋詞是「A&B」），那個 & 會被原樣保留，伺服器端就會把它當成參數分隔符號，參數被截斷成兩個。上面的編碼模式兩種都提供，預設是編參數值那種。
URL 編碼和 Base64一樣，是編碼不是加密：規則完全公開，沒有金鑰，任何人拿到都能一步還原，本頁就是。它存在的意義是讓特殊字元能安全穿過 URL 這條通道，不提供任何保密性。所以把訂單號、手機號碼、內部 ID 做一次 URL 編碼就放進連結，等於沒做任何處理——瀏覽器網址列、伺服器記錄檔、Referer 標頭裡躺著的都是明文。要不可逆請看 SHA-256，要傳敏感參數請走 POST 並上 HTTPS。順帶一提，「URL 解密」這個說法本身就不成立，準確的詞是解碼。
空格有兩種寫法。表單提交用的 application/x-www-form-urlencoded 把空格編成 +，而路徑和現代 API 普遍用 %20。麻煩的是 JS 的 decodeURIComponent 不認 +，會原樣留下一個加號，所以本頁給了開關，預設按空格解。反過來，如果內容裡本來就有加號（比如1+1），編碼時它會變成 %2B，這是對的。
字元集是另一個坑。現在預設都是 UTF-8，但不少舊網站、舊系統用的是 GBK，「中」在 GBK 下是兩個位元組 %D6%D0。用 UTF-8 去解 GBK 編的內容，得到的就是問號或方塊。本頁解碼側可以切 GBK；編碼側只做 UTF-8，因為瀏覽器原生只能編 UTF-8。
各語言的函式名稱對照。PHP 的 urlencode 會把空格編成 +、rawurlencode 編成 %20，對應的解碼是 urldecode / rawurldecode；Java 的 URLEncoder.encode(s, "UTF-8") 走的是表單那套，也是 +；Python 用 urllib.parse.quote / unquote，其中 quote_plus 才編成 +；JavaScript 只有 encodeURIComponent / decodeURIComponent，永遠是 %20。前後端對不上時，八成就是差在這個加號上。
那是 URL 編碼後的中文，不是亂碼。URL 規範只允許英文字母、數字和少數符號，中文得先按 UTF-8 轉成位元組、每個位元組寫成一個 %XX。一個漢字通常佔三個 %XX。把整段貼到上面點「解碼」就能還原。反過來，你在瀏覽器網址列看到的中文連結，其實也是瀏覽器幫你把編碼後的形式顯示成了中文，複製出來往往還是 %XX。
切到 GBK 再解一次。預設按 UTF-8 解，而不少舊網站和舊系統用的是 GBK，同一個「中」字在 UTF-8 下是 %E4%B8%AD、在 GBK 下是 %D6%D0，用錯字元集必然出問號或方塊。一個簡單的判斷方法：%XX 三個一組多半是 UTF-8，兩個一組且首位元組在 %A1–%FE 之間多半是 GBK。
前者連 : / ? # & = 一起編掉，用來編單個參數值；後者保留這些結構字元，用來編整條連結。拼 URL 時幾乎總該用 encodeURIComponent 去編每個參數值，再自己拼上 ? 和 &。用 encodeURI 編整條 URL 只適合「連結已經拼好、只想讓裡面的中文和空格合法化」這一種場景。
要看上下文，這也是最容易出錯的地方。表單提交（application/x-www-form-urlencoded）把空格編成 +，所以查詢字串裡的 + 通常就是空格；而路徑部分和現代 API 裡的 + 一般就是加號本身。JS 的 decodeURIComponent 不做這個轉換。本頁預設把 + 當空格，如果你的內容裡本來就有加號（比如 C++），把那個勾去掉再解。
說明字串裡有不合法的百分號片段——% 後面不是兩位十六進位數，或者位元組序列拼不成合法的 UTF-8。常見於複製時漏了字元，或者內容被編碼了兩次（%25E4 這種，%25 就是 % 本身，再解一次才是中文）。本頁不會因為這個整段失敗：不合法的片段原樣保留，其餘照常解出來，你能直接看出是哪一段有問題。
不能，它和加密沒有關係。編碼規則是公開的，任何人都能一步還原，你的手機號碼、訂單號編完之後仍然是明文躺在網址列、瀏覽器歷史紀錄、伺服器記錄檔和 Referer 標頭裡。真要保護敏感參數，用 POST 提交、走 HTTPS、在伺服器端做權限驗證，或者改成不可逆的雜湊值。「URL 解密」這個說法本身就不準確，正確的叫法是解碼。
不會。編解碼用的是瀏覽器內建的 encodeURIComponent / TextDecoder，全部在你的裝置上算完直接顯示，沒有一個位元組離開瀏覽器。頁面載入完之後斷開網路，這個工具照常可用——這是最直接的驗證方法。帶 token、帶訂單號的連結可以放心貼。詳見隱私權政策。
有。JSON 格式化把 API 回應展開成能讀的層級，Base64 編解碼處理另一種常見編碼，時間戳轉換把記錄檔裡的 10 位/13 位數字換成人能讀的時間，MD5 和 SHA-256 算驗證用的雜湊值。全部同樣在本機執行，不上傳資料。