URL 編碼解碼工具
快速進行 URL 編碼和解碼，支援多種編碼模式
選擇轉換方式
什麼是 URL 編碼？
URL 編碼（也稱為百分號編碼）是一種將字元轉換為可在 URL 中安全傳輸的格式的機制。因為 URL 只能包含 ASCII 字元集中的特定字元，所以其他字元（如中文、空格、特殊符號等）需要被編碼為 %XX 格式，其中 XX 是字元的十六進位值。 例如：空格會被編碼為 %20，中文字元「你」會被編碼為 %E4%BD%A0。 實際開發中還需要區分整段 URL、查詢參數和路徑片段的編碼方式；例如空格、斜線、問號、等號在不同位置含義不同，錯誤編碼可能導致參數遺失或路由解析異常。
使用方式
使用方式
- 在輸入框中輸入或貼上要編碼/解碼的文字
- 選擇編碼方式：encodeURIComponent 或 encodeURI
- 結果會自動顯示，可一鍵複製或交換輸入/輸出
- 解碼時，請選擇對應的解碼方式
URL 語境
- 對查詢值和路徑區段使用 component 編碼；使用錯誤的函式編碼整個 URL 可能會破壞 /、? 和 & 等分隔符。
- 解碼時，請檢查是否存在雙重編碼，例如 %2520，這代表百分比符號被再次編碼。
使用場景
技術原理
URL 編碼（百分號編碼）由 RFC 3986 §2.1 定義，將字元轉換為 %XX 格式，其中 XX 是 UTF-8 位元組值的兩位大寫十六進位表示。RFC 定義了兩個字元類別：非保留字元（A-Z a-z 0-9 - _ . ~）永遠不會被編碼，以及保留字元（gen-delims : / ? # [ ] @ 和 sub-delims ! $ & ' ( ) * + , ; =）其編碼取決於上下文——它們在某些 URL 組件中具有結構意義，但在其他地方是字面資料。 JavaScript 提供兩個作用範圍不同的內建函式。encodeURIComponent() 編碼除 A-Z a-z 0-9 - _ . ! ~ * ' ( ) 以外的所有字元——這是編碼個別查詢參數值、路徑區段和片段識別碼的正確選擇。encodeURI() 額外保留結構字元 : / ? # [ ] @ ! $ & ' ( ) * + , ; =，設計用於編碼完整 URI 同時保持其語法結構完整。關鍵區別在於 encodeURIComponent() 會編碼 / 和 &，如果套用到整個字串會破壞 URL，而 encodeURI() 則保留它們。 空格處理是最常見的互通性陷阱。RFC 3986 指定 %20 作為空格字元（U+0020）的標準百分號編碼。然而 application/x-www-form-urlencoded MIME 類型（自 HTML 4.01 起用於 HTML 表單提交）將空格編碼為 +。兩者不可互換：預期 %20 的伺服器會將 + 解讀為字面量，預期 + 的伺服器會將 %20 視為百分號後跟 20。本工具使用 encodeURIComponent() 產生 %20，符合 RFC 3986。解碼 x-www-form-urlencoded 載荷（來自 POST 主體或舊版中介軟體解析的查詢字串）的使用者應注意此差異。 多位元組字元處理是自動的但值得理解：輸入字串先編碼為 UTF-8 位元組，然後每個位元組分別進行百分號編碼。一個 CJK 字元如「你」（U+4F60）佔用 3 個 UTF-8 位元組（E4 BD A0），產生 %E4%BD%A0。如果伺服器使用不同字元集如 GBK 解析，同一字元編碼為 %C4%E3（2 位元組），除非雙方約定 UTF-8 否則解碼結果會出現亂碼。雙重編碼是另一個常見錯誤：%2520 表示字面百分號（%25）後跟 20，表示輸入已經被百分號編碼又被編碼了一次。解碼模式會擷取格式錯誤的序列（不完整的 %XX）並呈現錯誤，而非靜默產生垃圾資料。
- encodeURIComponent 與 encodeURI：encodeURIComponent 編碼 / ? & #，適用於查詢值、路徑區段和片段；encodeURI 保留這些結構字元，適用於完整 URL——使用錯誤的函式是最常見的 URL 編碼錯誤
- RFC 3986 保留字元集合：gen-delims（: / ? # [ ] @）承載 URL 語法；sub-delims（! $ & ' ( ) * + , ; =）可能是分隔符或資料，取決於 URL 組件——上下文決定保留字元是否需要百分號編碼
- 空格編碼：RFC 3986 標準格式為 %20（由 encodeURIComponent 產生）；application/x-www-form-urlencoded 使用 +（HTML 表單預設值）——兩者在語義上不相容，混用會破壞伺服器端解析器
- UTF-8 多位元組編碼：「你」（U+4F60）→ UTF-8 位元組 E4 BD A0 → %E4%BD%A0（3 個百分號編碼的八位元組）；同一字元在 GBK 下 → %C4%E3（2 個八位元組）——客戶端和伺服器之間的字元集約定對非 ASCII 文字是強制性的
- 雙重編碼偵測：%2520 先解碼為 %20 再解碼為空格——解碼模式的輸出會呈現此模式；格式錯誤的序列如 %ZZ 或 %2（不完整）會被捕獲並報告為錯誤
- IRI（RFC 3987）：國際化資源識別碼允許 URL 中直接使用 Unicode 字元；瀏覽器在網址列顯示解碼形式，但在傳輸時發送百分號編碼的 UTF-8 形式——本工具的編碼模式顯示實際在網路上傳輸的內容
- decodeURIComponent 錯誤處理：傳入包含不完整百分號序列（% 後跟少於 2 位十六進位數字）的字串會拋出 URIError——本工具將呼叫包在 try/catch 中並呈現錯誤訊息，而非靜默傳回空字串
範例
編碼中文字元（UTF-8 百分號編碼）
輸入： 你好世界 (4 個 CJK 字元，12 個 UTF-8 位元組)
輸出： %E4%BD%A0%E5%A5%BD%E4%B8%96%E7%95%8C
每個 UTF-8 位元組（E4、BD、A0、...）轉為 %XX
RFC: RFC 3986 第 2.1 節定義 URI 的百分號編碼
用途： 查詢參數、路徑片段、表單資料提交編碼查詢字串分隔符
輸入： name=张三&age=20
輸出： name%3D%E5%BC%A0%E4%B8%89%26age%3D20
%3D 編碼 '='（鍵與值之間的分隔符）
%26 編碼 '&'（參數之間的分隔符）
RFC: RFC 3986 第 3.4 節定義查詢元件的保留字元編碼完整 URL（部分編碼）
輸入： https://example.com/search?q=你好&type=web
輸出： https://example.com/search?q=%E4%BD%A0%E5%A5%BD&type=web
備註： scheme、host 與既有分隔符「不」進行編碼
僅對非 ASCII 的查詢值進行百分號編碼
RFC: RFC 3986 第 3 節定義階層式 URI 元件編碼空白字元（兩種慣例）
路徑片段： %20（符合 RFC 3986）
查詢字串： +（HTML 表單的歷史慣例）
範例：/search for me -> /search%20for%20me
範例：q=hello world -> q=hello+world
兩者解碼結果相同；encodeURI 使用 %20，部分實作中 encodeURIComponent 在路徑使用 %20、查詢使用 +常見問題
URL 編碼的作用是什麼？
把 URL 中不安全的字元換成 % 編碼：空白 → %20、& → %26、# → %23 等。RFC 3986 列出了哪些字元是安全的（英數字加上 -、_、.、~）以及哪些需要編碼。瀏覽器、伺服器與 HTTP 函式庫都會在適當的邊界套用或預期 URL 編碼。
encodeURI 和 encodeURIComponent 有什麼差別？
encodeURI 會保留 URL 語法字元（: / ? # & =），它預期收到的是整個 URL；encodeURIComponent 連這些字元也會編碼，因為它預期收到的是單一參數值。頁面同時提供兩種模式：查詢參數用 component 編碼，整段 URL 用 URI 編碼。
為什麼空白有時是 %20、有時是 +？
%20 是 URI 標準；+ 是 HTML 表單送出時 application/x-www-form-urlencoded MIME 類型使用的舊慣例。多數伺服器會把它們視為相同，但嚴格來說並不等價——現代 URL 中請使用 %20。
需要編碼 Unicode 字元嗎？
RFC 3986 只允許 ASCII；非 ASCII 必須先用 UTF-8 編碼再做百分號轉義（中 → %E4%B8%AD）。現代瀏覽器網址列會顯示 Unicode 形式，但傳輸時送出的是編碼後的形式。頁面會自動完成 UTF-8 編碼步驟。
哪些字元絕對不該編碼？
RFC 3986 中的「非保留字元」：A-Z、a-z、0-9、-、_、.、~。雖然技術上允許編碼，但會產生不同的 URL 字串；伺服器在規範化規則下，可能把「a」與「%61」當成相等，也可能視為不同。
為什麼解碼後的 URL 看起來怪怪的？
很可能是被「雙重編碼」了：%2520 解碼一次得到 %20，再解一次才是空白——表示有人對 URL 做了兩次編碼。遇到這種情況就解碼兩次。某些伺服器會自動雙重編碼，請檢查你客戶端的編碼行為。
編碼是在本機完成的嗎？
是的。encodeURIComponent 與 decodeURIComponent 都在你的瀏覽器中執行，URL 不會被上傳。