工具說明
關於 URL 編碼解碼器
URL Encoder/Decoder 會把 URL 中不安全或有特殊意義的字元轉成百分號編碼，也能把編碼後的字串還原成可讀文字。
它適合處理查詢參數、中文路徑、回呼網址與從 logs 複製出的 URL 片段，所有轉換都在瀏覽器本機完成。
如何使用 URL Encoder/Decoder
- 貼上完整 URL、查詢參數值或需要編碼的文字。
- 點擊 Encode，把空白、中文、符號等轉成安全的百分號編碼。
- 點擊 Decode，把 %E4%B8%AD%E6%96%87 這類片段還原成原文字。
- 只編碼參數值時，優先處理 value，不要把整個 query string 的 & 和 = 一起誤編碼。
常見使用場景
- 把搜尋詞、回呼網址或轉址參數放進 URL 前先編碼，避免 &、?、# 截斷參數。
- 除錯 API 日誌時，把 percent-encoded 路徑或 query 還原成中文與可讀符號。
- 排查 OAuth redirect_uri、Webhook callback 或分享連結中的二次編碼問題。
- 比較前端 encodeURIComponent 輸出與後端解析結果是否一致。
百分號編碼、URL 參數與常見陷阱
URL 中某些字元有結構意義，例如 ?, &, =, #, /。百分號編碼會把位元組寫成 %HH，讓這些字元作為資料傳輸，而不是被解析為 URL 結構。
- 空白： 常見編碼是 %20；表單編碼中也可能出現 +。
- 中文與 emoji: 會先按 UTF-8 轉成多個位元組，再分別寫成百分號編碼。
- encodeURI vs encodeURIComponent: 前者保留 URL 結構字元，後者更適合單個參數值。
- 二次編碼：%25E4 常表示原本的 % 又被編碼一次。
URL 編碼解碼常見問題
- 應該編碼整條 URL 還是單個參數？
- 多數場景應編碼單個參數值。整條 URL 編碼會把 :、/、?、& 等結構字元也轉義，可能讓連結無法正確解析。
- 為什麼空白有時是 %20，有時是 +?
- %20 是通用 percent-encoding；+ 常見於 application/x-www-form-urlencoded 表單規則。
- Decode 後為什麼還有百分號？
- 可能是二次編碼，或原文字本來就包含百分號。可再解碼一次，但要確認不是誤處理合法百分號。
- URL-safe Base64 還需要 URL encode 嗎？
- 通常比較少需要，因為它避開 + 和 /。但放進 query string 前仍要確認是否有 = padding 或其他特殊字元。
- 輸入會上傳嗎？
- 不會。編碼與解碼在瀏覽器本機執行，不會上傳到 wetool.site。
URL encoding 與 Base64 的差異
URL 編碼讓字元能安全出現在 URL 中；Base64 則把位元組表示成文字。除錯 Token、圖片或二進位片段時可能同時遇到兩者，但用途不同。
encodeURI 與 encodeURIComponent 對照
許多 URL 編碼問題不是演算法錯，而是把「整條 URL」與「單個參數值」混在一起處理。
- 整條 URL: 用 encodeURI 語義，保留 : / ? & = # 等結構字元，適合已經組好的連結。
- 參數值： 用 encodeURIComponent 語義，編碼 &、=、?、#，適合 search、redirect_uri、callback 等 value。
- 表單規則： application/x-www-form-urlencoded 常把空白寫成 +，一般 percent encoding 更常見的是 %20。
除錯 URL 編碼先查這些點
當 API 收到的 URL 參數不對時，通常要同時檢查瀏覽器、前端程式碼、gateway 與後端框架各自做了幾次 decode。
- %25 常代表原本的 % 又被編碼一次，可疑點是二次編碼。
- redirect_uri 如果包含自己的 query string，內部的 ?、&、= 必須作為資料編碼。
- 不要把解碼後的使用者輸入直接拼進 HTML 或轉址網址，仍要做協定白名單與輸出跳脫。