URL 編碼/解碼
對 URL 進行編碼和解碼。
URL 無效
Tips
- 日語字元「あ」經 UTF-8 編碼後變為
%E3%81%82。 - 空格在 URL 路徑中編碼為
%20，在查詢引數中有時編碼為+（RFC 3986 與 HTML 表單規範的差異）。 - 將
?、&、=等保留字元用於引數值時，必須進行編碼。 - 在 REST API 查詢引數中包含非 ASCII 字元，或安全傳遞重定向 URL 時非常實用。
常見問題
編碼是將漢字、空格等非 ASCII 字元轉換為
%XX 十六進位制格式的過程，解碼則是將其還原為原始文本。瀏覽器位址列會自動對 URL 進行解碼顯示。在 URL 路徑部分使用
%20（RFC 3986 標準）；在 HTML 表單的 application/x-www-form-urlencoded 查詢字串中使用 +。如無特殊要求，推薦統一使用 %20。字母（A–Z、a–z）、數字（0–9）以及
- _ . ~ 等非保留字元無需編碼。&、=、?、# 等保留字元在作為引數值使用時必須進行編碼。
閒話 ― URL 的誕生：Tim Berners-Lee 與全球資訊網的黎明
URL 由 Tim Berners-Lee（全球資訊網的發明者）於 1991 年設計。由於最初僅針對 ASCII 字元，多位元組字元（如日語）及特殊字元需通過百分號編碼來表示。
網際網路第一個網頁的 URL「http://info.cern.ch/hypertext/WWW/TheProject.html」至今仍可訪問。表情符號域名（如 🍕.ws）在技術上可行，內部會被轉換為 Punycode（以 xn-- 開頭的格式）。URL 在理論上可超過 2,000 個字元，但實際上受瀏覽器和伺服器的限制（約 2,048 個字元）。
RFC 3986 定義了 URL 規範，但 "%20（空格）"與"+（空格）"的區別至今仍是常見混淆點。%20 是 URI 標準，+ 用於 HTML 表單的 application/x-www-form-urlencoded 格式，應根據使用場景加以區分。