開發者工具 · URL 編碼器和解碼器
RFC 3986 保留與非保留字元：URI 標準的規定
· 背景
url 編碼 rfc3986 百分比編碼
RFC 3986 將字符分為保留字符、非保留字符和其他所有字符，這種劃分解釋了您遇到的每個百分比編碼規則。這篇文章清楚地閱讀了相關部分。
RFC 3986 保留和非保留字元 - 建置 URL 時最重要的是什麼
RFC 3986 將字元分為三類：未保留的、保留的以及所有其他必須編碼的內容。非保留字元永遠不需要編碼——它們是字母、數字、連字符、句點、底線和波形符。 RFC 在 2.3 節中明確列出了這些內容，宣告它們在任何 URI 上下文中都可以安全地保持未編碼狀態。使用這些字元在 URL 編碼器和解碼器中進行測試表明它們沒有變化。保留字元細分為 gen-delims (: / ? # [ ] @) 和 sub-delims (! $ & ' ( ) * + , ; =)，每個在不同的 URL 元件中具有結構意義。
字元什麼時候需要編碼？只有當保留字元產生歧義時，才必須對它們進行百分比編碼。斜線標記路徑段；在查詢值中，它必須是 %2F。 & 分隔參數； & 值中需要 %26。未保留的字元永遠不需要編碼－連字符仍然是連字符。 URL 標準確保正確解析。使用 URL 編碼器和解碼器進行測試：使用encodeURIComponent 輸入「hello/world"」會產生「hello%2Fworld」；使用encodeURI 會保留斜線。
Unreserved：字母、數字、連字符、句點、底線和波形符 - 不需要編碼且永遠不應該編碼的字符
百分比編碼使用 %HH，其中 HH 是十六進位表示法。 ASCII 字母 A（代碼 65）變成 %41。非 ASCII é 需要 UTF-8 編碼：é (U+00E9) 變成 %C3%A9。現代標準跨瀏覽器統一指定 UTF-8。
完整的 URL 需要完整的結構語法；查詢值需要內部保留字符，無害。如果手動，查詢參數 ?q=R&D 應將 & 編碼為 %26，否則 & 符號將成為分隔符號。帶有正斜線的值在組件模式下變為 %2F。元件編碼 (encodeURIComponent) 透過對未保留的字母、數字和 - _ 之外的所有內容進行編碼來處理此問題。 ！ 〜*'（）。測試清楚地顯示了方法之間的差異。
保留：gen-delims 和 sub-delims — 兩個群組、其成員及其結構角色
查詢字串示範了保留字元為何重要。 & 分隔鍵=值對：?utm_source=email&utm_campaign=sale 表示兩個參數。在值內，未轉義的 & 符號結束該對。等於將鍵與值分開。解析發生在多個層；每個都適用相同的規則。
查詢值中需要編碼的字元包括與號、等於、雜湊、問號、空格和非 ASCII 字母。哈希是最狡猾的：#anything 成為片段標識符，永遠不會發送到伺服器。在請求離開瀏覽器之前，以哈希結尾的活動名稱會失去其後的所有內容。空格必須變成 %20。使用 URL 編碼器和解碼器進行測試顯示元件和表單模式。了解位置決定編碼需求。
當必須對保留字元進行編碼時 - 僅在它們會被誤認為分隔符號的地方逐個組件
百分比編碼在 RFC 3986 中保留。未保留的套件保持較小，確保便攜性。百分比編碼的非保留字元可以在不改變含義的情況下進行解碼。將 %41 解碼為 A 是正確的，因為 A 是未保留的。當斜線是資料而不是分隔符號時，將 %2F 解碼為 / 會改變含義。 RFC 3986 規範化部分 6 涵蓋語法方法。
不同位置的保留字元有不同的作用。方案中的冒號標記方案：權限邊界； userinfo 中的冒號是資料。問號打開查詢部分；查詢值中的斜線是文字。哈希標記片段開始。位置決定編碼需要。查詢字串攜帶的值本身就是 URI。將 https://example.com/page?param=value 這樣的重定向 URL 編碼為參數需要將斜線和冒號編碼為 %2F 和 %3A。上下文始終定義安全字元。
工作範例：對真實 URL 的每個字元進行分類 — 未保留、保留為分隔符號、保留為資料
RFC 1738 (1994) 認為許多字元不安全。隨著部署在 UTF-8 上標準化，後來的標準放寬了限制。波形符號 (~) 舉例說明了演變：RFC 1738 需要 %7E，RFC 2396 (1998) 將波形符號移至未保留狀態，RFC 3986 確認未保留狀態。演變反映了部署經驗教訓。標準保留向後相容性。
RFC 規範化允許對不必要的百分比編碼的非保留字元進行解碼。 %41 安全地標準化為 A。像 %2F 這樣的編碼保留字元永遠不會解碼；改變意義會破壞結構。現代共識使用 RFC 3986 作為參考基準。 URL 編碼器和解碼器始終遵循 RFC 3986，提供獨立於瀏覽器行為的固定參考。 WHATWG URL 標準在 RFC 之外添加了特定於元件的編碼集。標準共存：用於一般 URL 解析的 RFC 3986，用於 Web 瀏覽器的 WHATWG。圖書館有所不同；檢查檔案。
6 部分中的規範化指南 — 十六進位大小寫、未保留的解碼和路徑段規則
根據 RFC 3986 進行測試可確保 URL 在跨越數十年的軟體中運作。 URL 編碼器和解碼器提供 RFC 3986 編碼基準以應用於建置的元件。閱讀解釋 URL 庫中每個編碼決策的標準檔案。 WHATWG URL 是基於 RFC 3986 構建，而不是完全取代它。為通用瀏覽器建立 URL？遵循 RFC 3986；瀏覽器在頂部套用 WHATWG 規則。較舊的系統？測試實際實作。標準化存儲？一致地套用 RFC 3986。了解保留/unreserved差異可以告訴您安全字元。
URL 編碼不是安全清理。每個上下文（SQL、HTML、JavaScript、URI）都需要自己的輸出編碼。百分比編碼僅保護 URL 結構。在正確的層次上應用正確的防禦。
這不包括什麼 - WHATWG URL 標準的不同編碼集和 IRI 處理
RFC 2396 (1998) 比 RFC 1738 更嚴格地闡明了字元集。它形式化了服務於 URI 結構的保留字符，而未保留的字符則作為文字資料。無保留擴展，包括連字符、句點、底線、波浪號超過原始定義。 RFC 2396 引入了 gen-delims (:, /, ?, #, [, ], @) 和子 delims (!, $, &, ', (, ), *, +, ,, ;, =) 之間的區別。每個群組在 URL 中具有不同的結構角色。命名明確了保留字元分為兩組。知道名字有助於技術討論。
RFC 3986 (2005) 是現代參考。它保留了保留/unreserved的區別，但簡化了符號。標準機構不會追溯性地破壞網路。故意編碼以了解您的標準。 URL 編碼器和解碼器提供 RFC 3986 參考。
重點：標準簡短而精確 — URL 編碼器和解碼器的兩種模式如何對應於編碼資料與保留分隔符
選擇標準取決於上下文。為通用瀏覽器建立 URL？遵循 RFC 3986；瀏覽器套用 WHATWG 規則。較舊的系統？測試實際實作。標準化存儲？一致地套用 RFC 3986。百分比編碼規則從保守的 RFC 1738 發展到澄清的 RFC 2396 和 RFC 3986 到分層的 WHATWG URL 標準。每一代人都反映了經驗。現代建構者根據上下文遵循 RFC 3986 或 WHATWG。新舊 URL 共存需要相容性思維。了解類別可以防止編碼錯誤。
在部署之前驗證 URL 編碼是否正確。 URL 編碼器和解碼器示範 RFC 3986 端對端規則。查看確切的十六進位值並了解哪些字元進行編碼。透過連接片段建立 URL 時，請使用此工具。 RFC 3986 保留和非保留類別分區字元集以實現一致的 URI 解析。