什麼是 URL 編碼與解碼？
URL 編碼並不是簡單地「把特殊字元換一下」，而是把需要進入 URI 的位元組內容轉換成更安全的文字表示。只要一個值要進入路徑、查詢參數、跳轉位址、回呼連結或其他帶語法含義的 URL 位置，就會遇到這個問題。URL 解碼則是把這些 `%HH` 形式的位元組表示還原回可讀內容，方便你確認原始值到底是什麼。
百分號編碼到底怎樣運作
現代 Web 場景裡，字串通常會先按 UTF-8 變成位元組，再由編碼器決定哪些位元組可以直接保留，哪些位元組必須寫成 `%HH` 十六進位序列。真正影響結果正確性的，不只是「要不要編碼」，而是目前這個值要進入整個 URL、路徑片段、查詢參數，還是表單提交語境。
- 字母、數字、連字號、底線、句點和波浪號通常屬於非保留字元，可以直接保留。
- 空格、`&`、`?`、`=`、`/` 以及非 ASCII 文字，往往需要編碼，否則容易和 URL 語法衝突或在不同系統裡被誤解。
- 表單式編碼有時會把空格寫成 `+`，而通用 URI 編碼更常見的是 `%20`，所以不是所有「編碼過的 URL 字串」都能無腦互換。
如何使用這個工具
- 先確認目前處理的是完整 URL、路径片段，还是单個查询参數值。
- 执行编码或解码后，重点檢查空格、保留字元和 UTF-8 内容是否正确。
- 只有確認轉換方向和目標 URL 上下文都正确后，才继续複用结果。
URL 編碼/解碼 範例
這個 URL 編碼/解碼 示例使用有代表性的查询参数、路径片段、回调地址、複製来的連結和百分号编码文字，展示產生后的適合 URL 传输的文字或解码后的可读字元，便于你先確認保留字元、空格、UTF-8 字节、双重编码，以及目前處理的是完整 URL 还是单個组件，再把同样設定用于真实輸入。
範例輸入
https://codertools.site/search?q=json formatter&lang=en
預期輸出
https%3A%2F%2Fcodertools.site%2Fsearch%3Fq%3Djson%20formatter%26lang%3Den經典編碼範例
原始值：
https://example.com/search?q=json formatter&lang=zh-CN
編碼後：
https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Djson%20formatter%26lang%3Dzh-CN常見使用場景
URL 編碼/解碼 最適合用在查询参数、路径片段、回调地址、複製来的連結和百分号编码文字需要快速变成適合 URL 传输的文字或解码后的可读字元的場景，尤其是OAuth 回调核对、搜索参数调试、連結清理、統計 URL 和複製来的 API 示例。
- 用于编码 URL 组件或解码百分号字元串，服务于OAuth 回调核对、搜索参数调试、連結清理、統計 URL 和複製来的 API 示例。
- 處理重要輸入前，可先用示例流程確認保留字元、空格、UTF-8 字节、双重编码，以及目前處理的是完整 URL 还是单個组件。
- 当结果符合目標流程后，再複製或下载適合 URL 传输的文字或解码后的可读字元。
URL 编码在真实流程里最容易错在哪里
URL 编码的真实问题，往往不是“不会 encodeURIComponent”，而是把正确的动作用在了错误的位置：本来只该编码参數值，却把整条 URL 全部编码；值本身已经是正常文字，又被多解一次；前端、后端和表单系統对同一段資料采用了不同约定。只要上下游约定不统一，這种问题就会反复出现。
- 第一步永远是先分清楚：你目前编码的是完整 URL、路径片段，还是单個参數值。
- 排查回调地址、跳转链路或第三方参数时，最好把原始值和编码值并排保留。
- 瀏覽器輸出應被看作“面向某個具体上下文的文字”，而不是所有下游系統都会以同样方式解释的通用表示。
什麼時候編碼整個 URL，什麼時候只編碼參數值
很多線上問題並不是「不會編碼」，而是編碼層級搞錯了。你在手動拼接查詢字串時，通常應該編碼參數值，而不是把一個已經包含 `?`、`&`、`=` 語法的完整 URL 外殼再整體編碼一次。
- 當一個完整 URL 要作為「另一個 URL 的參數值」出現時，才需要對這個完整 URL 進行編碼。
- 當你只是填寫查詢參數、搜尋關鍵字、回呼 token 或使用者輸入值時，更常見的是只編碼參數值。
- 重複解碼也很危險，因為一個已經恢復好的值，再多解一次，可能把本來需要保留的百分號序列繼續破壞掉。
URL 編碼和相鄰格式的差異
| 格式 | 核心作用 | 常見用途 |
|---|---|---|
| URL 編碼 | 在 URI 語境裡轉義位元組 | 查詢參數、跳轉位址、路徑片段 |
| Base64 | 把二進位位元組轉成可列印文字 | 令牌片段、Data URI 載荷、文字化傳輸 |
| HTML 實體 | 轉義 HTML 敏感字元 | 模板輸出、富文字、標記嵌入 |
使用注意
- 複用適合 URL 传输的文字或解码后的可读字元前，先檢查保留字元、空格、UTF-8 字节、双重编码，以及目前處理的是完整 URL 还是单個组件。
- 不要对来源不明的 URL 反复解码，双重解码可能改变保留字元并破坏連結。
- 当结果会影响生产工作或客户可见内容时，應保留原始查询参数、路径片段、回调地址、複製来的連結和百分号编码文字以便回退和核对。
URL 編碼/解碼 參考說明
URL 編碼/解碼 需要說明百分號編碼的底層規則：字串先轉成位元組，再把 URL 保留集之外的內容寫成 `%HH` 形式。
- URL 編碼通常會先把文字轉換成 UTF-8 位元組，再把保留或不安全的位元組寫成 `%HH` 十六進位序列。
- 字母、數字、連字號、底線、點號和波浪號這類非保留字元通常會原樣保留。
- 解碼時會先把 `%HH` 還原成位元組，再按約定字元集解釋，預設通常是 UTF-8。
參考資料
常見問題
以下問題圍繞 URL 編碼/解碼 的實際用途整理，重點說明輸入要求、輸出結果與常見限制。安全編碼 URL 片段，或解碼跳脫後的 URL 字串。
在 URL 編碼/解碼 里，應该编码完整 URL，还是只编码其中一個组件？
大多数情况下更適合只编码需要转义的那個组件，例如查询参数或回调值。盲目对完整 URL 再编码，会让结果更难阅读和複用。
為什么 URL 編碼/解碼 里空格会变成 %20，而不是 +？
百分号编码和表单编码相关但并不完全相同。`%20` 是更通用、更安全的 URL 表示，而 `+` 常见于特定的表单式查询编码場景。
為什么在 URL 編碼/解碼 里反复解码会把連結弄坏？
双重解码会把保留字元重新还原成真正的分隔符，從而改变查询边界或路径片段。只有在明确知道目前字元串仍是编码态时，才應该继续解码。
URL 編碼/解碼 最適合處理什麼樣的查询参数、路径片段、回调地址、复制来的链接和百分号编码文本？
URL 編碼/解碼 的核心用途是编码 URL 组件或解码百分号字元串。当查询参数、路径片段、回调地址、複製来的連結和百分号编码文字需要快速变成適合 URL 传输的文字或解码后的可读字元，并继续用于OAuth 回调核对、搜索参数调试、連結清理、統計 URL 和複製来的 API 示例时，它最有价值。
複用 URL 編碼/解碼 產生的适合 URL 传输的文本或解码后的可读字符前，最該檢查什麼？
應優先檢查保留字元、空格、UTF-8 字节、双重编码，以及目前處理的是完整 URL 还是单個组件。這些细节最能直接判断结果是否已经適合继续交给下游流程。
URL 編碼/解碼 產生的适合 URL 传输的文本或解码后的可读字符通常會被帶到哪裡繼續使用？
最常见的下一步就是用于OAuth 回调核对、搜索参数调试、連結清理、統計 URL 和複製来的 API 示例。這類輸出是按真实交接場景来组织的，不是泛化占位结果。
什麼時候不應該直接相信 URL 編碼/解碼 的結果，而要人工複核？
不要对来源不明的 URL 反复解码，双重解码可能改变保留字元并破坏連結。