開發者工具 · URL 編碼器和解碼器
URL 剖析：方案、權限、路徑、查詢和片段解釋
· 背景
url 結構 網路標準 開發者工具
每個百分比編碼決策都取決於字元位於 URL 的哪一部分。這篇文章命名了 RFC 3986 中的五個元件，展示了每個分隔符號的含義以及片段永遠不會到達伺服器的原因。
為什麼相同的 # 在一個地方沒問題，但在另一個地方卻破壞了連結－一個元件問題，而不是字元問題
URL 中的雜湊字元 (#) 意義完全不同，取決於它出現的位置。在像 ?search=C%23sharp 這樣的查詢字串值中，必須將其編碼為 %23 才能安全。在像 https://example.com/page#section, 這樣的 URL 末尾，它標記了片段分隔符，並它後面的所有內容都是片段。一個字符，兩種上下文，兩種不同的意義。這就是為什麼編碼決策取決於您正在使用的 URL 的哪一部分。
問號（？）也具有雙重性。在路徑或查詢值內，必須將其編碼為 %3F 才能顯示為資料。作為路徑和查詢字串之間的文字字符，它是結構語法。了解這五個元件（方案、權限、路徑、查詢和片段）是正確 URL 處理的基礎。
五個組成部分：方案、權限、路徑、查詢、片段 - 以及分隔它們的分隔符
RFC 3986 正式將 URL 定義為具有五個組成部分：方案、權限、路徑、查詢和片段，並由特定分隔符號分隔。首先是方案，然後是 ://, 然後是權限，然後是 /, 然後是路徑，然後是 ?，然後是查詢，然後是 #，然後是片段。並非所有元件都出現在每個 URL 中。最小 URL 可能只有方案和路徑，例如「mailto:user@example.com」。完整的 URL 包括所有五個。
每個元件都有自己的語法規則。冒號在方案中保留，斜線在路徑中保留，& 符號在查詢中保留。保留字元作為資料出現時需要編碼：路徑值中的斜線變為 %2F。
權限內部 — 使用者資訊、主機和端口，以及為什麼保留 @ 和 :
權限元件包含資源的網路位址：使用者名稱、密碼、主機名稱和連接埠。格式為[使用者資訊@]主機[:連接埠]。 userinfo和host以@分隔；主機和連接埠以 : 分隔。這些@ 和: 字元在權限範圍內保留以分隔這些子組件。如果您的用戶名包含@符號，則在連接它之前必須對其進行百分比編碼。例如，「user@email.com:password」作為使用者名稱將在最後的@之前變為「user%40email.com:password」。
主機名稱可以是註冊網域（如 example.com）、點分十進位的 IP 位址（如 192.0.2.1）或用方括號括起來的 IPv6 位址（如 [::1]）。連接埠可選；如果省略，則該方案確定預設值（http 為 80，https 為 443 等）。 userinfo 部分很少在現代 URL 中使用，但仍然是語法的一部分。
路徑段和/的意義－層次結構和點段解析
該路徑是由正斜線分隔的一系列段。路徑 /a/b/c 有三段：a、b 和 c。每個段可以包含非保留字元、百分比編碼字元或在此上下文中安全的某些保留字元。段內的斜線必須編碼為 %2F 以避免與段分隔符號混淆。路徑是分層的；它意味著 a 是一個位置，那麼 a/b 更具體。
路徑也支援特殊的點段：單點 (.) 表示“目前目錄”，兩個點 (..) 表示“父目錄”。像 ../../etc/passwd 這樣的路徑向上解析。現代 URL 和 HTTP 避免使用這些，但它們存在於語法中。如果不希望字面點的含義，則包含字面點或雙點的路徑段必須進行百分比編碼。
查詢和片段 - 鍵值約定，以及片段保留在瀏覽器中的原因
查詢字串遵循路徑並以 ? 開頭。傳統上，它是一系列由 & 分隔的鍵=值對，儘管語法實際上是非結構化的——查詢中可以包含任何內容。如果您的值包含 & 或 =，則這些字元必須進行百分比編碼，這樣它們就不會被誤認為分隔符號。查詢被傳送到伺服器；伺服器決定如何處理它。
該片段跟隨查詢並以 # 開頭。 # 之後的所有內容都是片段，它永遠不會到達伺服器。瀏覽器在本機處理片段，通常是為了跳到命名錨點或指示單頁應用程式中的狀態。由於片段永遠不會到達伺服器，因此具有不同片段的 URL 將被視為指向相同的資源。
工作範例：剖析一個很長的現實世界 URL — 標記每個元件和每個分隔符
取 URL「https://user:pass@example.com:8080/path/to/page?search=hello&sort=date#results". 方案為 https。權限為 user:pass@example.com:8080，分為 userinfo (user:pass)、主機 (example.com) 和連接埠 (8080)。路徑為 /path/to/page,，其中包含路徑段、topage 和 page。 search=hello&sort=date，包含兩個參數。
如果搜尋包含 &，例如 ?search=R&D，則在正確編碼後將變為 ?search=R%26D。百分比編碼的字元不會在文字中創建視覺邊界，因此仔細的編碼和解碼對於正確的解析至關重要。
這不包括相對參考解析和特殊方案，例如 mailto: 和 data:
像是「../page"」或「?query=value」這樣的相對引用在 HTML 中是有效的，並相對於當前檔案進行解釋，但它們有自己單獨的解析規則。像 mailto:、data: 和 file: 這樣的特殊方案遵循完全不同的規則，並不是標準的絕對 URL。
這篇文章僅關注檢查器演示的標準絕對 URL 結構。相對引用需要一個基本 URL，然後才能解釋其元件，而諸如 mailto 和 data 之類的方案不共享相同的權限和路徑形狀。將這些情況分開可以防止從 HTTPS 位址學習的規則被盲目地應用於具有不同分隔符號、解析步驟或傳輸行為的語法。
重點：在編碼之前了解元件 — URL 編碼器和解碼器的單值和全位址模式如何對應到此結構
您正在編碼的元件決定哪些字元需要轉義以及哪些字元是安全的。斜杠是路徑中的文字語法，因此數值中的斜杠必須是 %2F。在查詢中，如果 & 和 = 出現在值中，則必須對它們進行編碼。 URL 編碼器和解碼器有兩種模式：用於編碼單一值的「元件」模式和用於編碼完整 URL 的「完整位址」模式。透過連接各個部分來建立 URL 時使用元件模式；使用完整位址模式來驗證現有 URL。
了解這五個元件及其分隔符號可以讓您在每次遇到編碼任務時正確選擇。