開發者工具 · URL 編碼器和解碼器
URL 建構函式為您編碼的內容：瀏覽器的百分比編碼集
· 工作原理
url 編碼 JavaScript 什麼工作小組 網路 API
URL API 會默默地對某些字符進行百分比編碼，而不會影響其他字符，這取決於它們位於 URL 的哪個部分。這篇文章解釋了 WHATWG 編碼集以及如何預測輸出。
成為 %20 的空間和 |留下來了 - new URL() 部分編碼路徑的具體情況
當 new URL("https://example.com/hello world") 執行時，空間默默地變成 %20 。但是 new URL("https://example.com/hello|world") 保持管道不變。這種差異不是隨機的。WHATWG URL 標準定義了單獨的字元集來為每個 URL 元件進行編碼：路徑、查詢、片段和使用者資訊都有自己的規則。了解這些集意味著預測建構函式將做什麼。
該空間需要百分比編碼，因為它在 HTTP 上不安全並會破壞可讀性。管道是不同的：不是分割結構的保留字符，因此瀏覽器不會管它。安全性和可讀性之間的界線是由 WHATWG 劃定的，而不是猜測。測試「hello world」顯示編碼；測試「hello|world」揭示了每個 URL 部分的邊界。
一個 URL，多個編碼集 — 路徑、查詢、片段和使用者資訊都有自己的要轉義的字元列表
一個 URL 包含多個區域，每個區域都有自己的編碼規則。路徑遵循一組，查詢另一組，分段第三組，使用者資訊第四組。路徑和查詢中的空格變成 %20。等號保留在查詢中，用於分隔鍵和值，但encodeURIComponent 將其轉換為 %3D。 URL 建構函數了解其上下文並為每個部分應用正確的規則。
編碼集精確且小。 Path有自己的字元清單；查詢有一個相似但不同的清單。這反映了哪些字符具有結構意義。正斜線分割路徑段，因此encodeURIComponent 將其編碼為 %2F。在片段中，可以存在正斜線而不破壞任何內容。了解 WHATWG 規則意味著無需執行程式碼即可預測輸出。
為什麼百分比編碼是單向的：保持編碼的內容保持這種方式
URL 建構子執行單向規範化。將「%20」傳遞給新 URL，它會產生未更改的 %20。建構函數將其識別為已編碼並保留它。這就是雙重編碼很重要的原因：編碼一次，透過建構函數，編碼保持不變。構造函數不會解碼、重新解釋和重新編碼；它向前讀。
此單向屬性會影響將 URL.href 視為規範的應用程式。如果將使用者輸入與路徑連接起來，輸入將被標準化但不會被解碼。像“my+file”這樣的值保持原樣，或者在某些情況下變成“my%2Bfile”。如果從表單資料中讀取加號，則使用decodeURIComponent 的後續程式碼可能會將加號讀取為空格。構造函數標準化一次；之後，你的價值就固定好了。
工作範例：透過 new URL() 傳遞相同的混亂字串並讀取 href、pathname 和 searchParams — 三個不同的視圖
將「hello world&foo=bar|test#anchor」放入具有不同元件的新 URL 中。該空間到處都變成%20。路徑中的＆符號保留（那裡沒有結構意義），但在查詢中它也保留（分隔參數，因此規範化會失去“q =”和“foo = bar”之間的邊界）。管道和哈希的行為因位置而異。
讀取 href、pathname 和 searchParams 顯示三個不同的視圖。 pathname 顯示沒有方案、主機或查詢的編碼路徑。 searchParams 給出解碼後的參數，因此表單資料中的「hello+world」變成了空格。搜尋屬性保留文字字串。 href 顯示完整的標準化 URL。這些共存於一個物件上；使用哪一個取決於您的下一步。
URLSearchParams 和表單編碼規則 — 為什麼它會為空格產生 +，而路徑名產生 %20
URLSearchParams 應用程式表單編碼：空格變成加號，而不是 %20。 new URLSearchParams({q: "hello world"}) 產生“q=hello+world”，而不是“q=hello%20world”。這是歷史應用/x-www-form-urlencoded規則。但是，如果您將此字串作為原始查詢傳遞給新 URL，則加號將保持加號；只有 URLSearchParams 將其解碼為空格。構造函數忠於它所看到的。
這個加號差異會導致常見錯誤。網址列中的 URL 使用 %20 作為空格。表單資料使用加號。如果使用decodeURIComponent（字面意思是加號）而不是URLSearchParams.get 進行解碼，空格將變成加號字元。 URL 編碼器和解碼器同時顯示：貼上「hello+world」並比較元件和表單模式以查看空格出現的位置。
與encodeURI 比較－兩者一致的地方和分歧的地方
URL 建構子和encodeURIComponent 是不同的工具。 encodeURIComponent 對除了未保留的字母、數字和 - _ 之外的幾乎所有內容進行編碼。 ！ 〜*'（）。它假設沒有上下文。 URL 建構函式解析實際的 URL 並為每個元件套用 WHATWG 規則。 encodeURIComponent 將「hello/world"」轉換為「hello%2Fworld」；新 URL 將斜線視為路徑分隔符號。相同的輸入，不同的輸出。
在透過連接片段建構 URL 時使用encodeURIComponent。使用 URLSearchParams 或 URL 建構子來取得完整或部分 URL。不要對整個 URL 使用encodeURIComponent；你會破壞這個計劃。將結果與意圖進行比較。瀏覽器強制執行 URL 結構意見，而新的 URL 則實作它們。 URL 編碼器和解碼器並排顯示兩個視圖。
這不包括什麼 - 主機解析、IDNA 以及特殊與非特殊方案
WHATWG URL 標準是事實來源，但閱讀它需要耐心。編碼集在演演算法片段中定義，而不是普通列表。在實踐中，理解原理比記住集合更重要。路徑允許更多字元（斜線是結構性的）；查詢有自己的規則；片段的限制最少（在客戶端處理，從不發送到伺服器）。每個組件都有自己的規則；知道這一點可以告訴您去哪裡尋找。
規範化和驗證是不同的邊界。建構函數規範化：清理百分比編碼、應用元件規則、給出規範形式。它不驗證：拋出無效字符，但接受空主機。建構函數對格式嚴格，但對解釋寬鬆。若要了解確切的規範合規性，請閱讀 WHATWG 的百分比編碼位元組部分。對於日常構建，請使用 URLSearchParams、URL API 和真實範例。
重點：解析器有意見－URL 編碼器和解碼器如何向您顯示值或位址的簡單百分比編碼，以便您可以將其與瀏覽器產生的內容進行比較
此處不支援的 WHATWG 功能包括使用 IDNA 轉換（國際網域至 ASCII）的主機解析以及特殊與非特殊方案處理。檔案：URL 使用雙斜線權限；資料：URL 沒有。構造函數強制執行這些規則。轉換主機名稱和確定特殊狀態屬於規範讀取，而不是百分比編碼。當跨不同方案建立 URL 時，這一點很重要。
透過將瀏覽器解釋與預期進行比較來測試您的 URL 建構。使用新的 URL 構建，讀取重要的屬性：完整表單的 href、路徑的路徑名稱、原始查詢的搜尋、解碼的 searchParams。如果輸出讓您感到驚訝，請貼上到 URL 編碼器和解碼器中並逐步進行轉換。該工具顯示標準化輸出和原始編碼，揭示差異。了解 WHATWG 集意味著了解瀏覽器選擇以及如何使用它們。