Why do spaces turn into %20 sometimes and + other times?

Two different specs. RFC 3986, which governs URLs themselves, encodes a space as %20. The application/x-www-form-urlencoded format used by HTML form submissions, defined in the WHATWG URL Standard, encodes a space as +. Both are valid in their own context, which is why + in a query string is ambiguous. The safe practice: always produce %20 for spaces and %2B for literal plus signs — every parser handles those correctly.

What is the difference between encodeURI and encodeURIComponent?

encodeURIComponent encodes nearly everything, including /, ?, &, and =, making it safe for individual values placed inside a URL. encodeURI preserves those reserved characters so a complete URL keeps its structure. Use encodeURIComponent for parameter values and path segments — which is almost every real-world case — and encodeURI only when sanitizing a full URL without restructuring it. Using encodeURI on a value containing & will silently break your query string.

How do I fix a double-encoded URL?

Double encoding happens when an already-encoded string gets encoded again — %20 becomes %2520 because the % itself turns into %25. To fix it, decode the string repeatedly until no %XX sequences remain and the output stops changing. Then find which layer of your system encoded twice — commonly your code plus a proxy, redirect service, or email link-wrapper — and remove one of the encoding steps. The rule: encode exactly once, at the last moment before the value enters the URL.

Is it safe to decode URLs in an online tool?

Only if the tool runs client-side. URLs frequently contain OAuth codes, password-reset tokens, session IDs, and email addresses. A server-side tool receives all of that and may keep it in access logs indefinitely. The toolz.dev URL Encoder/Decoder performs all conversion in your browser with JavaScript — no data is transmitted anywhere, which you can verify in your browser's network tab. For anything containing credentials or tokens, client-side processing should be non-negotiable.

Do I need to encode the whole URL or just the parameters?

Just the data parts — individual parameter values and, occasionally, path segments. The structural characters of the URL itself (the :// after the scheme, the ? starting the query, the & between parameters) must stay unencoded or the URL stops working. Encode each value separately with component-style encoding, then assemble the URL around them. Encoding a complete URL end-to-end is only correct when that URL is itself becoming a value inside another URL, like an OAuth redirect_uri.

Can URL encoding handle emoji and non-English characters?

Yes — modern percent-encoding operates on UTF-8 bytes, so any Unicode character works. A two-byte character like é becomes %C3%A9, and a four-byte emoji becomes four percent-sequences, such as %F0%9F%9A%80. Problems only arise with legacy tools or JavaScript's deprecated escape() function, which assume single-byte encodings and produce invalid output. The toolz.dev encoder handles full UTF-8 correctly in both directions.

Why does my URL break when a parameter contains an ampersand?

Because & is the delimiter between parameters. If a value contains a raw ampersand — say utm_campaign=black&friday — the server parses it as a parameter named utm_campaign with value black, plus a second parameter named friday. No error is raised; your data is just silently wrong. Encode the ampersand as %26 inside the value and the parameter arrives intact. This is one of the most common and least visible URL bugs.

What does %2F mean in a URL?

%2F is the percent-encoded forward slash. You'll see it when a value that happens to contain a slash — a file path, a date like 07/07, or a nested URL — is correctly encoded before being placed in a query parameter or path segment. Be aware that some servers and proxies (Apache, older Tomcat versions, various API gateways) reject or silently decode %2F in the path for security reasons, so if a request with an encoded slash returns a 404, the server-side configuration is usually the culprit, not your encoding.

How do I URL encode in Python, PHP, or on the command line?

Python: urllib.parse.quote() for path segments and quote_plus() for form-style query values. PHP: rawurlencode() produces RFC 3986 output with %20 for spaces, while urlencode() produces form-style output with +. Command line: jq -rR @uri or curl's --data-urlencode flag. Every one of these matches the component-style behavior of this tool, so you can prototype the encoding here and verify your code produces byte-identical output.

URL 線上編碼和解碼:在不破壞連結的情況下進行百分比編碼的完整指南

教我尊重百分比編碼的錯誤是 OAuth 重定向,但對於一個客戶來說卻失敗了。 WP Adminify 擁有透過 OAuth 進行驗證的 Google Fonts 集成,並且有一個用戶 - 一個運行某些反向代理設定的託管經銷商,我仍然不知道 #39;我完全理解 - 不斷獲得 redirect_uri_mismatch 錯誤。其他人都很好。我花了兩天的大部分時間都指責他的伺服器配置。然後我終於查看了他的瀏覽器發送的實際 URL,逐個字符,結果如下: %2520 空間應該在哪裡。他的代理程式正在對 redirect_uri 進行編碼。我的插件是也編碼它。 Google 收到一個 URL,其中該空間已被編碼兩次 - %20 成為 %2520- 並拒絕了整個握手。兩行代碼修復了它。兩天才能找到它。

那是'甚至我的第一次編碼災難。幾年前,I'd 為外掛程式啟動建立了一個活動鏈接,其中包含一個包含原始&符號的 UTM 參數 - 類似 utm_campaign=black&friday。分析儀表板顯示了一個名為「 black 還有一個幻象參數叫做 friday 那與任何事情都不匹配。&符號默默地將我的參數一分為二。沒有錯誤。沒有警告。只是悄悄地錯誤了十一天的數據,然後我注意到數字沒有't加起來。

這裡'是關於 URL 編碼的事情:它'是那些看起來微不足道的問題之一,直到它才是't。規則存在於 2005 年規範中 (RFC 3986),瀏覽器現實存在於不同的規格中(the) WHATWG URL 標準)、JavaScript 為您提供了三種不同的功能,這些功能都會執行略有不同的操作,而 PHP 則為您提供了另外兩種功能。弄錯了,你就會發現 ' 發生崩潰 - 你會得到截斷的參數、損壞的 OAuth 流程以及在 Chrome 中工作但在電子郵件用戶端中失效的連結。

所以我建立了我一直想要的編碼器/解碼器工具。dev。本指南涵蓋如何使用它,更重要的是,涵蓋百分比編碼的實際工作原理,因此是下一個 %2520 在日誌中,您需要兩分鐘而不是兩天。

TL;DR: 若要在線上進行 URL 編碼或解碼,請將字串貼到 Toolz.dev URL 編碼器/解碼器,選擇模式,然後按 Encode 或 Decode。它正確處理 UTF-8 和表情符號,並且「交換」按鈕將輸出反饋回輸入,以便您可以剝離雙編碼值 (%2520) 一次隔一層。一切都運行客戶端,因此 URL 中的令牌和會話 ID 永遠不會接觸伺服器。編碼參數值具有組件模式;僅在您知道原因時才對完整 URL 進行編碼。

主要特點

在一種工具中進行編碼和解碼

我需要對一個值進行編碼的一半時間。另一半 I'我盯著日誌檔案中的一個粗糙的 URL,需要將其解碼為可讀的東西。該工具從一個輸入框執行這兩個操作 - 編碼和解碼作為兩個按鈕並排放置,因此 #39;不尋找單獨的頁面。貼上編碼字串並點擊解碼;鍵入原始查詢值並點擊編碼。它還乾淨地往返:編碼、解碼,然後您將原始字串逐字返回。這聽起來很明顯,但 I'已經使用了在往返時損壞的線上工具以及標誌,因為它們無法'決定他們遵循哪個規格。這個明確說明它'每一步都在做什麼,這正是您'重新調試時想要的。

組件與全 URL 編碼模式

這種區別是大多數編碼錯誤誕生的地方。組件模式對 't 未保留的所有內容進行編碼 - 包括 /, ?, &, 和 =- 這就是您想要的單一參數值。全 URL 模式不考慮結構字符,因此 URL 仍然作為 URL 工作,這就是您想要的內容'正在清理完整的位址。使用錯誤的模式要么破壞您的 URL 結構,要么不編碼危險字符。該工具將兩種模式分開一次下拉,並用 JavaScript 函數標記,每種模式都對應於 - encodeURIComponent, encodeURI, application/x-www-form-urlencoded. 我反覆討論這個命名。意圖標籤("編碼一個值","編碼一個完整的URL")冷讀會更好,但函數名稱表示下面的參考面板將一對一映射到代碼you&#39上;即將寫作,然後'這是大多數人實際參與的時刻。如果您'曾經輸入過 encodeURI 當你想的時候 encodeURIComponent- 我不只一次 - 面板可以在您發貨之前接住它。

處理 UTF-8、表情符號和國際字元

類型 café 你得到了 caf%C3%A9- 的 é 正確擴展為兩個 UTF-8 位元組。輸入表情符號,您將獲得百分之四的編碼位元組。這就是舊工具和已棄用的 JavaScript 的地方 escape() 函數分崩離析:它們假設 Latin-1 或產生非標準 %uXXXX 沒有伺服器可以解析的序列。如果您'使用使用者產生的內容建立 URL - 名稱、搜尋查詢、任何語言的城市名稱 't 英語 - 正確的 UTF-8 處理 is't 很高興擁有。孟加拉語文字、阿拉伯語段塞、中文搜尋字詞:所有這些都編碼到有效的 RFC 3986% 序列,這些序列在另一端解碼相同。

雙編碼值的交換按鈕

的 %2520 trap - 已編碼 %20 再次編碼 - 一次需要我兩天的時間,所以這是個人的。解碼是單層操作: %2520 解碼至 %20,不是到一個空間,因為 %25 是的編碼 %. 一次即可獲得一層。交換按鈕 (⇄) 將輸出移回輸入框,以便點擊即可完成下一遍。我'在 URL 通過代理、重定向服務和電子郵件連結包裝器後,將其展開三層深 - 交換、解碼、交換、解碼,直到字串停止更改。那個&引用;停止更改&引用;時刻是實際訊號你'正在尋找。誠實地說這是什麼:它'是一個手動循環,而不是檢測器。該工具沒有't 標誌 %25XX 對於你,我來回討論是否應該 - 自動解碼直到穩定會很方便,直到它默默地破壞合法包含百分號的值。

三種模式,一個明確的參考面板

模式選擇器攜帶三個選項 - 組件、完整 URL 和表單網址編碼 - 下面的面板準確地闡明了該模式轉義的字元、保留了這些字符,並顯示了一個有效的範例。我添加它是因為我永遠不記得是否 encodeURIComponent 葉子 ~ 單獨(確實如此)或是否 ! 和 * 生存(他們確實如此,這讓人們感到驚訝,因為 RFC 3986 將他們歸類為子定義而不是無保留)。而不是記住三個 JavaScript 函數'怪癖,你憑意圖選擇模式並讀回它'即將做的事情。該參考文本是我最常用的部分,它'這是 I'如果我凌晨 1 點冷落頁面,我會想要。

100% 客戶端 - 沒有什麼可以離開您的瀏覽器

想想什麼'實際上在您解碼的 URL 內:OAuth 授權碼、密碼重設令牌、會話 ID、取消訂閱連結中的電子郵件地址、API 金鑰、一些有助於填充到查詢字串中的框架。將它們貼到伺服器端工具中,它們就會登陸某人'存取日誌,與您的 IP 綁定,保留多長時間。 toolz。dev 編碼器完全在您的瀏覽器中運行 - 轉換是在本地執行的幾行 JavaScript,並且不會使用您的資料提出任何請求。打開 DevTools,如果選擇 #39,請觀看網路標籤;對於任何與安全相關的內容,客戶端都是 '它'最小條。

免費,無註冊,無限制

沒有帳戶牆,沒有進行字串轉換的工具的每日配額,沒有"升級到 Pro 解碼超過 1,000 個字元。"我建立了 toolz。dev,因為我厭倦了廣告堵塞的實用網站,這些網站會透過電子報彈出視窗中斷十秒的任務。給它加書籤,每天使用五十次,完成。

如何使用 URL 編碼器和解碼器

第 1 步:打開工具並選擇方向

去 Toolz.dev/tools/url 編碼器並將字串放入左側框中。有兩個操作按鈕,編碼和解碼,您在貼上後選擇一個,而不是先設定方向。如果您'從可讀的東西開始(搜尋查詢、重定向 URL you'即將嵌入),按 Encode。如果您'從充滿百分比符號的東西(日誌條目、引用標頭)開始,按 Decode。輸出落在右側窗格中,標頭中有一個複製按鈕,交換和清除位於兩個操作按鈕旁邊。

第 2 步:選擇元件、完整 URL 或表單模式

編碼a 價值這將位於參數 - redirect_uri、搜尋字詞、an 之後的任何內容內 = 符號?使用組件模式。它編碼 /, ?, &, 和 = 所以你的值可以't 破壞周圍的 URL。編碼a 完整的網址 這只需要清理空格和非 ASCII 字元?使用全URL模式,保留結構字元。第三種模式是形式url編碼,是元件編碼,空格寫為 + 代替 %20- 當你選擇它時'是手工建造的 application/x-www-form-urlencoded 身體。請注意,該模式也會影響解碼:在表單模式下, + 在解碼之前轉換回空格;在另外兩個中,它保持字面加號。如有疑問:分塊的組件模式,整塊的全 URL 模式。

步驟 3:讀取輸出並注意剩餘百分比符號

輸出出現在正確的窗格中。若要解碼,請查看結果是否仍包含 %XX 序列 - 如果確實如此,則該值被編碼多次。點擊交換將該輸出移回輸入,再次解碼,然後重複,直到字串停止變更。如果輸入格式錯誤(雜散) % 後面沒有兩個十六進制數字,就像文字一樣 100%),你'將會得到一個明確的錯誤,而不是一個無聲的半解碼,這就是你're調試時想要的行為。

第四步:複製並驗證

點擊複製按鈕並將結果貼到它所屬的位置。對於任何重要的內容 - OAuth 尤其重定向 - 進行最後一次健全性檢查:將編碼值貼回解碼模式並確認其往返於您開始的位置。三十秒的驗證比兩天的驗證還要好 redirect_uri_mismatch.

百分比編碼、RFC 3986 以及為什麼空間變成 %20 或 +

URL 只能安全地包含一組有限的字元。其他所有內容都必須以百分比編碼位元組的形式走私進來。規則手冊是 RFC 3986 (2005),它將角色分成兩個陣營。

未保留的字元 永遠不需要編碼:字母 A–Z 和 a–z,數字 0–9,還有四個符號-連字符 -, 時期 .,強調 _,還有波浪號 ~. 對這些進行編碼是合法的,但毫無意義。

保留字元 在 URL 內進行結構作業: : / ? # [ ] @ (一般分隔符號)和 ! $ & ' ( ) * + , ; = (子分隔符號)。冒號將方案與主機分開。問號啟動查詢字串。& 分隔參數。保留字元是否需要編碼完全取決於 它出現的地方. A / 路徑上有結構; A / redirect_uri 參數值內是數據,它必須成為 %2F 或者伺服器會錯誤地解析您的 URL。

機制:取得字元、取得其 UTF-8 位元組,並將每個位元組寫為 % 後面跟著兩個十六進位數字。 ASCII 字元是一個位元組 - 空格是 %20& 符號是 %26. 但 UTF-8 是多位元組編碼,所以 é 是兩個位元組: %C3%A9。典型的表情符號是四個位元組 - & 編碼為 %F0%9F%9A%80. 這就是為什麼假設一個字元等於一個位元組的工具會破壞簡單英語以外的任何內容。

現在,空間問題 - URL 編碼中最令人困惑的事情。根據 RFC 3986,空間變成 %20. 但 HTML 表單提交使用不同的序列化, application/x-www-form-urlencoded,今天定義於 WHATWG URL 標準, 和那個格式將空格編碼為 +。兩者都是正確的--在它們自己的背景下。這意味著 + 在查詢字串中是不明確的:它可能是文字加號(RFC 3986 讀取)或編碼空間(表單編碼讀取)。如果您'曾經看過電話號碼到達 1234 5678 當有人發送時 +1234...'遇到了這個錯誤。我的建議:永遠發出 %20 對於空間和 %2B 對於文字加號。沒有人誤用這些。

JavaScript 為您提供了三個函數,它們不可互換。給定字串 a=b&c d:

const s = "a=b&c d";

encodeURIComponent(s); // "a%3Db%26c%20d"  — encodes =, &, and space
encodeURI(s);          // "a=b&c%20d"      — leaves = and & alone
escape(s);             // "a%3Db%26c%20d"  — deprecated; breaks on Unicode

encodeURIComponent 對除未保留字元(plus)之外的所有字元進行編碼 !'()*- 一個遺留的怪癖),使其參數值安全。 encodeURI 保留保留的字符,以便完整的 URL 保持功能 - 但這也意味著它 贏了#39;t 保護一個 & 在你的數據內部。和 escape() 被棄用是有充分理由的:它產生非標準 %uXXXX 非拉丁 1 字元的序列。切勿在新程式碼中使用它。

PHP 反映了相同的分裂,但有一個轉折: urlencode() 產生形式樣式編碼(空格變成) +),同時 rawurlencode() 遵循 RFC 3986(空格變為) %20).如果您'正在為表格 POST 正文以外的任何內容建立 URL, rawurlencode() 是你想要的。我一開始就發貨了 WP Adminify 程式碼,但程式碼錯誤; WordPress'自己的 add_query_arg() 比 I&#39 拯救我的次數還多;想承認。

最後是雙編碼陷阱。 %20 是一個空間,經過編碼。編碼 那根弦 再次和 % 本身就變成了 %25,給你 %2520. 解碼一次,你就會得到 %20 返回 - 仍然編碼。每當系統的兩層都引用時,就會發生這種情況;有幫助地引用;編碼:您的程式碼加上代理、重定向服務以及電子郵件連結包裝器。阻止它的規則:在值進入 URL 之前的最後一個可能的時刻精確編碼一次,並且從不對您沒有的東西進行編碼'不僅僅是解碼或產生原始內容。

常見用例

使用使用者輸入建立查詢字串

每當使用者鍵入的文字進入 URL(搜尋框、篩選器、透過 GET 傳遞的表單值)時,它都必須進行元件編碼。用戶搜尋 Q&A tips 成為 ?q=Q%26A%20tips;未編碼,伺服器看到搜尋 Q 還有一個神秘的參數 A tips. 在開發過程中,我使用了網址編碼器為了在編寫程式碼之前產生期望值,所以我有一個已知的正確參考來測試。 It'也是最快結算和報價的方法;該字元應該被編碼嗎?&引用;程式碼審查中的參數:將其貼上到元件模式並查看。現代 API,例如 JavaScript's URLSearchParams 自動處理此問題,您應該使用它們 - 但您仍然需要這樣做驗證當有東西壞了時他們的輸出,並且#39;是一項解碼工作。

調試 UTM 和活動連結

行銷連結正在編碼雷區。帶有空格、管道或&符號的 UTM 值;透過 URL 縮短器、電子郵件服務和#39 的連結;點擊追蹤器,然後重定向 - 每層都有機會添加或損壞編碼。當活動在分析中出現錯誤時,我的第一步始終是相同的:將完整連結貼上到解碼模式並讀取分析伺服器實際收到的內容。十分之九的罪魁禍首在幾秒鐘內可見 - 原始的 & 分割參數,a + 這應該是字面上的加號,或a %2520 背叛雙重編碼。我的 black&friday 如果 I' 在第一天就這樣做了,事件將是 11 秒的修復,而不是 11 天的資料漏洞。

OAuth 重定向_uri 和回調 URL

OAuth 是編碼錯誤變得昂貴的地方,因為提供者確實如此 精確的字串匹配 在重定向 URI 上。 redirect_uri 是一個完整的 URL,作為參數值嵌入到另一個 URL 中 - 因此它必須進行元件編碼一次。對它和進行下編碼 ? 或者 & 內部破壞了外部授權 URL。對其進行雙重編碼並進行提供者比較 https%3A%2F%2F... 反對您的註冊 https://... 並返回 redirect_uri_mismatch 更多細節為零。當出現該錯誤時,從瀏覽器解碼實際授權 URL's 位址列,並將 redirect_uri 字元逐個字元與您的應用程式和#39;s 註冊值進行比較。將其與配對中國航空解碼器用於檢查傳回的令牌,您可以在不離開瀏覽器的情況下調試整個 OAuth 流程。

從日誌和引薦來源網址標頭解碼粗糙的 URL

伺服器日誌和引薦來源網址標頭充滿了百分比編碼的湯: %D0%9F%D1%80%D0%B8%D0%B2%D0%B5%D1%82 在搜尋引用器中,來自機器人流量的三重編碼路徑、可疑請求中的編碼有效負載。解碼這些就是您找出實際發生的情況的方法 - 無論那個奇怪的 404 是具有西里爾文查詢的用戶還是正在探測的腳本 ../../etc/passwd 三層編碼背後。這也正是隱私角度最重要的情況:日誌 URL 通常包含會話令牌和電子郵件地址。在客戶端工具中解碼它們,而不是在保留自己日誌的隨機伺服器上。我在中寫了更多關於此工作流程的資訊 API調試工具指南.

使用 curl 進行 API 測試

您的 shell 和 curl 在 URL 編碼之上形成第二個雷區。 & 背景是一個過程,在狂歡中, ? 觸發 zsh 中的全域擴展 - 因此,未引用、未編碼的 URL 在到達網路之前就會以令人困惑的方式失敗。我的工作流程:對工具中的每個參數值進行編碼,組裝 URL,將其包裝在單引號中,然後運行 curl。當 API 傳回 400 的請求時,"看起來對,"我從冗長的輸出中解碼精確的 URL (curl -v)查看真正發送的內容 - 不只一次該錯誤是我的終端,而不是我的 API。捲曲's --data-urlencode flag 處理 POST 主體的編碼,但對於 GET 查詢字串,you'大部分都是你自己的,可靠的編碼器可以擊敗猜測。

與非 ASCII 文字共用連結

其他語言的維基百科文章、帶有當地地名的 Google 地圖連結、帶有孟加拉語或阿拉伯語 slug 的文檔 URL - 從您的網址列複製一個,您可能會得到漂亮的東西統一碼形式或牆 %E0%A6%AC-樣式字節,取決於瀏覽器'情緒。一些聊天應用程式和電子郵件用戶端會截斷或損壞原始 Unicode 表單。在共享之前對 URL 進行編碼會產生一個純 ASCII 字串,該字串在每個信使、郵件列表和 Markdown 渲染器 I&#39 中都保留下來;已經嘗試過。相反,解碼會將不可讀的共享連結變回人類可以在點擊之前驗證的內容 - 在轉發任何看起來像是線路噪音的東西之前值得做。

encodeuricomponent vs encodeURI vs escape():您應該使用哪一種?

三個功能,一個正確預設。這裡'是誠實的比較:

	`encodeURIComponent()`	`encodeURI()`	`escape()`
編碼	一切都除了 `A-Z a-z 0-9 - . _ ~ ! ' ( ) *`	除未保留 + 所有保留字元外的所有內容 (`: / ? # [ ] @ ! $ & ' ( ) * + , ; =`)	一切都除了 `A-Z a-z 0-9 @ * _ + - . /`
空間變成	`%20`	`%20`	`%20`
`&` 和 `=`	編碼(`%26`, `%3D`)	未編碼	編碼
統一碼處理	正確的 UTF-8 位元組	正確的 UTF-8 位元組	損壞 - 非標準 `%uXXXX`
用於	參數值、路徑段、URL 內的任何內容	您擁有的完整 URL'不想重組	沒什麼
狀態	標準,推薦	標準,利基	已棄用

我的立場,以及 I'會死在這座山上: 使用 encodeURIComponent 對於價值觀來說,幾乎總是如此。 心理模型很簡單--如果字串是去的裡面一個 URL(查詢值、路徑段、redirect_uri)、it' 是一個元件,它得到了 encodeURIComponent. 案例在哪裡 encodeURI 確實正確的情況很少見:您有一個完整的、已經結構化的 URL,其中包含空格或非 ASCII 字符,並且您希望在不接觸其結構的情況下對其進行清理。 That'可能佔現實世界編碼呼叫的 5%。和 escape() 根本不應該出現在大約 2010 年之後編寫的程式碼中 - 它的 Unicode 輸出是 't 有效的百分比編碼,並且每個現代 linter 都會對其進行標記。

還有一個細微差別: encodeURIComponent 葉子 ! ' ( ) * 由於歷史原因未編碼,儘管 RFC 3986 將它們列為保留子分隔符號。對於 OAuth 和嚴格解析 API,一些函式庫也會添加第二次來編碼這五個。如果挑剔的 API 拒絕您的值,則 ' 是一個值得尋找的地方 - 和 URL 編碼器's 組件模式會準確地向您顯示哪些字元已轉換,以便您可以進行比較。

常見問題

什麼是 URL 編碼?

URL 編碼(百分比編碼)是表示 URL 中字元的機制,否則這些字元將不安全或有結構意義。每個有問題的字元都轉換為UTF-8 字節,每個位元組寫成百分比符號,後面跟著兩個十六進位數字- 空間變為%20,& 符號變為%26。規則在RFC 3986 中定義。它的存在是因為URL 只允許有限的字元集,以及像 1 這樣的字元?和& URL 結構內部有工作要做。

為什麼空格有時會變成 %20,有時會變成 +?

兩個不同的規格。 RFC 3986 自行管理 URL,將空格編碼為 %20。 HTML 表單提交使用的應用程式/x-www-form-urlencoded 格式(在 WHATWG URL 標準中定義)將空格編碼為 +。兩者都在自己的上下文中有效,這就是為什麼查詢字串中的 + 不明確。安全實踐:始終為空格產生 %20,為文字加號產生 %2B - 每個解析器都正確處理這些。

encodeURI 和 encodeURIComponent 有什麼不同?

encodeuricomponent 幾乎對所有內容都進行編碼,包括/、?、&和 =,使其對於 URL 中放置的各個值是安全的。 encodeURI 保留了這些保留的字符,以便完整的 URL 保留其結構。使用 encodeURIComponent 來獲取參數值和路徑段(幾乎每個現實情況都是如此),並且僅在清理完整 URL 而不對其進行重組時才對 URL 進行編碼。在包含 &amp 的值上使用 encodeURI;會默默地破壞您的查詢字串。

如何修復雙編碼 URL?

當已編碼的字串再次編碼時,會發生雙重編碼 - %20 變為 %2520,因為 % 本身變成 %25。要修復它,請重複解碼字串,直到沒有 %XX 序列保留並且輸出停止更改。然後找到系統的哪一層編碼兩次 - 通常您的程式碼加上代理、重定向服務或電子郵件連結包裝器 - 並刪除其中一個編碼步驟。規則:在值進入 URL 之前的最後一刻精確編碼一次。

在線上工具中解碼 URL 安全嗎?

僅當工具運行客戶端時。 URL 經常包含 OAuth 代碼、密碼重設令牌、會話 ID 和電子郵件地址。伺服器端工具接收所有這些內容,並可能無限期地將其保留在存取日誌中。 toolz。dev URL Encoder/Decoder 使用 JavaScript 在瀏覽器中執行所有轉換 - 任何地方都不會傳輸任何數據,您可以在瀏覽器中驗證這些數據'網路標籤。對於任何包含憑證或令牌的內容,客戶端處理應該是不可協商的。

我需要對整個 URL 進行編碼還是僅對參數進行編碼？

只是資料部分 - 單獨的參數值,偶爾還有路徑段。 URL 本身的結構字元(方案之後的 ://、開始查詢的 ?、參數之間的 &amp)必須保持未編碼或 URL 停止工作。使用元件樣式編碼分別對每個值進行編碼,然後在它們周圍組裝 URL。只有當該 URL 本身成為另一個 URL 內的值(例如 OAuth redirect_uri)時,對完整的 URL 進行端對端編碼才是正確的。

URL 編碼可以處理表情符號和非英語字元嗎?

是的 - 現代百分比編碼對 UTF-8 位元組進行操作,因此任何 Unicode 字元都可以工作。像 é 這樣的兩個位元組字元變成 %C3%A9,四個位元組表情符號變成四個百分比序列,例如 %F0%9F%9A%80。問題僅出現在舊工具或 JavaScript's 已棄用的轉義 () 函數中,該函數假設單字節編碼並產生無效輸出。 toolz。dev 編碼器在兩個方向上正確處理完整的 UTF-8。

當參數包含&號時,為什麼我的 URL 會中斷?

因為&是參數之間的分隔符號。如果一個值包含原始&符號 - 例如 utm_campaign=black&星期五 - 伺服器將其解析為名為 utm_campaign 的參數,其值為 black,加上第二個名為 friday 的參數。沒有出現錯誤;您的資料只是默默地錯誤。將 ampersand 編碼為值內的 %26,且參數完好無損。這是最常見且最不明顯的 URL 錯誤之一。

%2F 在 URL 中是什麼意思?

%2F 是百分比編碼的前向斜線。你'當恰好包含斜線的值(檔案路徑、07/07 等日期或巢狀 URL)在放置在查詢參數或路徑段之前被正確編碼時,將會看到它。請注意,出於安全原因,某些伺服器和代理程式(Apache、舊版Tomcat 版本、各種API 網關)會拒絕或默默地解碼路徑中的%2F,因此,如果帶有編碼斜線的請求返回404,則伺服器端配置通常是罪魁禍首,而不是您的編碼。

如何在 Python、PHP 或命令列上對 URL 進行編碼?

Python:路徑段的 urllib。parse.quote () 和表單樣式查詢值的 quate_plus ()。 PHP:rawurlencode () 產生 RFC 3986 輸出,其中 %20 用於空格,而 urlencode () 產生帶有 + 的表單樣式輸出。命令列:jq -rR @uri 或 curl's --data-urlencode 標誌。這些中的每一個都與此工具的元件樣式行為相匹配,因此您可以在此處建立編碼原型並驗證程式碼產生位元組相同的輸出。

包裹起來

URL 編碼是一項小技能,但回報卻很大。一旦你可以閱讀 %C3%A9 作為一個 é 和斑點 %2520 作為一種雙重編碼的氣味,一整類"它適用於我的機器"錯誤 - 損壞的 OAuth 流程、幻影 UTM 活動、API 拒絕看起來完全合理的請求 - 從神秘變成機械。這些規則適合索引卡:未保留的字元通過,其他所有內容都變成 UTF-8 位元組作為 %HH,編碼值而不是結構,並且編碼一次。

保留 URL 編碼器/解碼器書籤在它的兄弟姊妹旁邊 - Base64 轉換器對於其他編碼方案,you'將在每個 auth 標頭中相遇(I'已寫完整 Base64 編碼指南關於何時使用哪個), HTML 實體編碼器/解碼器對於 Web 內容喜歡堆疊在頂部的第三個編碼層 (the HTML 實體指南涵蓋我擊中的同一陷阱的雙轉義版本 %2520),並且 json 格式化程式無論解碼後的 URL 指向什麼。

如果您'正在組裝一個更廣泛的基於瀏覽器的調試工具包, 編碼工具指南瀏覽這些工具如何在真實的工作流程中組合在一起。 toolz。dev 上的所有內容都運行客戶端,無需花費任何費用,並且做得很好。那'整個推介 - 我希望在我花兩天時間使用一個錯位的 %25 之前有人對我做過同樣的事情。

Frequently Asked Questions

URL encoding (percent-encoding) is the mechanism for representing characters in a URL that would otherwise be unsafe or structurally meaningful. Each problematic character is converted to its UTF-8 bytes, and each byte is written as a percent sign followed by two hexadecimal digits — a space becomes %20, an ampersand becomes %26. The rules are defined in RFC 3986. It exists because URLs only permit a limited character set, and characters like ? and & have jobs to do inside URL structure.

Command Palette