有一次我在一個下午輸給了一個看起來不錯的 URL。 OAuth 回調不斷失敗,重定向 URI "匹配並引用;在提供者註冊的那一個,我不明白為什麼握手破裂了。當我最終將東西貼到解析器中時,答案是一個地方路徑上的尾隨斜線,而另一個地方沒有,再加上一個 state 已雙重編碼的參數 %20 已經成為 %2520. 在人眼看來,這兩個 URL 是相同的。對於 OAuth 伺服器來說,它們是不同的字串,拒絕不匹配是正確的。
這就是 URL 的問題:它們很密集,很容易被誤讀,而破壞事物的細節--編碼斜線、雜散端口、重複查詢密鑰、您期望路徑的片段--正是那些隱藏在字元牆中。我建立了 [toolz。dev](/,並且我花了足夠的時間盯著查詢字串,同時調試我建立了一個 網址解析器 為我凝視。貼上鏈接,將每個組件標記並在表中解碼每個查詢參數。本指南解釋了這些組件是什麼、為什麼這些區別很重要以及如何使用它們。
TL;DR: URL 由方案組成 (
https),可選憑證(()user:pass@),一個主機(example.com) 具有可選端口,路徑 (/blog/post),查詢字串(()?id=42),還有一個片段(#section).這 網址解析器 使用瀏覽器將任何連結分割到這些部分'擁有 WHATWG URL 引擎,將查詢解碼為有序鍵值表(重複的鍵保持獨立),顯示方案的有效端口,並假設https://如果您貼上裸域。它完全在您的瀏覽器中運行,因此與令牌的連結保持私密。
網址的部分是什麼？
每個 URL 都遵循 WHATWG URL 標準定義的相同語法 - 瀏覽器實際實現的規範。一旦您可以命名各個部分,大多數 URL 錯誤就會變得明顯。這是完整的解剖結構,使用一個故意忙碌的範例:
https://john:[email protected]:8443/catalog/shoes?color=red&size=42#reviews
└─┬─┘ └──┬──┘└─┬──┘└──────┬────────┘└─┬─┘└──────┬──────┘└──────┬──────┘ └──┬──┘
scheme user pass hostname port path query fragment
打破它:
| 組件 | 範例值 | 它是什麼 |
|---|---|---|
| 方案 | https |
協議。決定預設連接埠以及如何發出請求。 |
| 用戶名 | john |
可選憑證,之前 @. |
| 密碼 | s3cret |
可選憑證之後 : 在用戶資訊中。 |
| 主機名稱 | shop.example.co.uk |
網域或 IP 位址,無連接埠。 |
| 港口 | 8443 |
可選的。省略時回退到方案預設值。 |
| 主持人 | shop.example.co.uk:8443 |
當存在連接埠時,主機名稱加上連接埠。 |
| 起源 | https://shop.example.co.uk:8443 |
方案加主機 - 瀏覽器用於安全的單元。 |
| 路徑 | /catalog/shoes |
主機上的資源位置。 |
| 查詢 | ?color=red&size=42 |
之後的關鍵值參數 ?. |
| 碎片 | #reviews |
客戶端錨點之後 #,從未發送到伺服器。 |
解析器透過複製按鈕將這些中的每一個都作為自己的行放置,因此您再也不必從怪物 URL 中手動提取主機名稱。它還標記原始字串隱藏的一些內容:顯示的連接埠是明確的還是方案'預設值,以及主機是命名網域還是原始 IP。
主機名稱、主機名稱和來源有什麼區別？
這三個人不斷地絆倒人們,混亂會導致真正的錯誤--CORS 故障、cookie 範圍錯誤、重定向不匹配。它們不是同義詞。這 WHATWG URL 標準 瀏覽器是否實際實現了定義,它是解決關於什麼算是起源的爭論的地方。
主機名稱 只是網域或IP: shop.example.co.uk. 沒有端口,沒有方案。這就是您要放入 DNS 查找的內容。
主持人 是主機名稱加上連接埠 但僅當 URL 中存在連接埠時.為了 shop.example.co.uk:8443 主持人是 shop.example.co.uk:8443.對於一個平原 https://shop.example.co.uk/ 主機和主機名稱是相同的,因為預設連接埠 443 是隱含的而不是書面的。那個&引用;僅在存在&引用時;規則很微妙,這就是為什麼同一網站可能看起來有兩個不同的主機。
起源 是方案加主機: https://shop.example.co.uk:8443. 這是瀏覽器最關心的問題,因為同源策略(Web 安全的基礎)比較的是來源,而不是主機名稱。兩個 URL 只有在其方案(主機名稱)共享來源時才會共用來源 和 連接埠全部匹配。 http://example.com 和 https://example.com 由於方案不同,起源也不同。 https://example.com 和 https://example.com:8443 儘管主機名稱相同,但由於連接埠不同,因此來源也不同。如果取得因 CORS 錯誤而失敗,則在解析器中並排比較兩個來源通常是發現不匹配的最快方法。
如何解析查詢字串？
查詢字串是大多數日常疼痛所在的位置,因為它是一個扁平的、看起來無法逃脫的斑點,實際上是結構化的和百分比編碼的。解析器為您分割它:之後的一切 ?,斷了 &,與每一個 key=value 對已解碼並按原始順序列在表中。
有兩種行為在這裡很重要。首先, 解碼. 寫為的參數 q=trail%20runner 在電線上顯示為 trail runner 在值列中,因為 %20 是一個百分比編碼的空間。原始的 search 字串在元件清單中仍然顯示為未觸及的,因此您可以比較編碼和解碼的形式 - 當您懷疑雙重編碼時,例如我的,這是非常寶貴的 %2520 噢,錯誤。
第二, 重複的按鍵。 URL 可以合法地多次攜帶相同的金鑰: ?tag=react&tag=typescript&tag=node. 許多樸素的解析器會崩潰這些,只保留第一個或最後一個值並默默地遺失資料。這是錯誤的 - 重複鍵是 HTML 表單提交多重選擇欄位的方式以及許多 API 如何表達數組。解析器將每個事件按順序保留為自己的行,以便您可以看到所有三個標籤。當您將查詢複製為 JSON 時,重複鍵會變成數組,這是大多數程式碼期望的形狀。
您甚至不需要完整的 URL 即可使用它。只貼上一個查詢字串 - color=red&size=42 - 工具會自行解析它。這是我知道理解網路掛鉤有效負載或某人轉發給您的追蹤連結的最快方式。
如何使用 URL 解析器?
該工具旨在讓您擺脫困境。將 URL 貼到單一輸入中,並在您鍵入時即時解析 - 無需按下按鈕。預先載入範例鏈接,以便您可以立即看到完整故障,並且清除按鈕清空欄位。
您不必輸入方案。貼上像裸主機一樣 example.com/pricing 解析器提前 https:// 然後自動告訴你它是用一個小紙條這樣做的,這樣你就永遠不會混淆這個方案來自哪裡。貼上明確的方案 - http://, ftp://, ssh:// - 相反,它尊重這一點。
輸出有四個區域。在頂部, 標準化網址 - 規範形式的瀏覽器'產生的引擎帶有複製按鈕,可以方便地捕捉微妙的標準化差異。下面, 組件 表,每個部分一行標記,每個部分可獨立複製。然後 路徑段,分成索引晶片,所以路徑很深 /api/v2/users/42/orders 一眼就能看清楚。最後 查詢參數 表格,解碼並排序,帶有 "複製為 JSON"將整個查詢變成乾淨物件的操作。
一切都使用其本機 URL 引擎在瀏覽器中運行。這是一個深思熟慮的選擇:URL 通常包含存取令牌、會話 ID、簽署的參數和內部主機名,並且這些都不應運送到伺服器只是為了讀取。您貼上的任何內容都不會離開您的設備,並且該工具會保持離線工作。這與我在整個工具包背後的隱私優先方法相同 web 開發人員工具包指南.
我什麼時候聯絡 URL 解析器?
在我自己的工作中一次又一次地出現一些情況。 調試重定向和回調 是最大的 - OAuth 流程、付款回報 URL、SSO 握手,所有這些都會因微小的不匹配而失敗,只有當您分解兩個 URL 時才會變得可見。 審計追蹤連結 另一個是:行銷 URL 通常是一個基礎頁面加上十幾個 UTM 和廣告平台參數,將它們讀取為斜視 300 個字元字串的表格節拍。如果您是建立這些連結而不是閱讀它們,那麼 utm 建設者 是同一工作流程的另一半。
然後就有了 API 工作 - 檢查客戶端實際發送的查詢參數,或逆向工程端點期望其過濾器的方式。和 安全審查:電子郵件或日誌中的不熟悉的連結透過解析其各個部分(由哪個主機執行此操作)來更安全地理解 真的 指向?該主機名稱是 IP 嗎?)而不是點擊它。解析器公開真實的主機名稱並標記 IP 文字主機,這正是您在信任連結之前想要的資訊。我寫了更多關於組裝這種檢查套件的文章 API調試工具指南.
解析與編碼和slugs有何關係?
URL 解析器是一小類連結工具中的一個角落,知道您需要哪一個可以節省時間。解析 讀 現有的 URL 並將其拆開。 編碼 在字元層級執行相反的方向 - 將空格和特殊字元轉換為百分比編碼形式,以便它們在 URL 中生存,然後再次返回。當您需要將一個值安全地嵌入到查詢字串中,或解碼一個損壞的字串時,即 URL 編碼器/解碼器,它自然地與解析器配對:解析以查看結構,編碼以修復損壞的值。
Slug一代 是第三份相關的工作 - 採用像 "10 更快建置和報價的技巧這樣的人類頭銜;並將其變成乾淨的 10-tips-for-faster-builds 路徑段。就是這樣 Slug 產生器 手柄,正是它產生了整潔 path 解析器稍後會讀回元件。將其視為管道:進行 slugify 以建立良好的路徑,進行編碼以使值 URL 安全,解析以檢查完成的連結。每個工具都會執行 URL 生命週期的一部分並在瀏覽器中執行此操作。
IP 位址和國際化網域怎麼樣?
並不是每個主持人都整潔 example.com。 有些 URL 指向原始 IP 位址,解析器可以辨識這兩種形式。 IPv4 文字類似 http://192.168.1.10:3000/ 有主機名稱 192.168.1.10,該工具將其標記為 IP 而不是網域 - 當您審核連結並想立即知道它針對的是命名網站還是裸露位址(這是可疑連結中的常見訊號)時,該工具非常有用。 IPv6 文字包裝在 URL 中的方括號中,如下所示 http://[2001:db8::1]:8080/,括號是主機語法的一部分,而不是裝飾;解析器正確處理括號形式,而不是扼殺冒號,否則冒號看起來像連接埠分隔符號。
國際化域名是另一種邊緣情況。以非 ASCII 字元編寫的主機(例如帶有重音或非拉丁字母的網域)由瀏覽器's URL 引擎轉換為 Punycode xn-- 實際請求的表格,因為 DNS 只講 ASCII。看到標準化 href 在解析器中,您會準確地看到瀏覽器將解決什麼問題,這有時會讓那些期望其漂亮的 Unicode 網域保持不變的人感到驚訝。對於頂級域,解析器提取指定主機的最終標籤,因此 shop.example.co.uk 報告 TLD uk. 這是一個故意簡單的規則 - 它不會嘗試取消諸如以下的多部分後綴 .co.uk 進入可註冊域,因為正確執行此操作需要公共後綴列表,這是一個大型移動資料集。為了快速檢查,最後一個標籤是有用的訊號,對於任何更嚴格的內容,您都可以找到一個專用的庫。
一個有效的例子將它聯繫在一起。假設支付提供者不斷拒絕您的退貨 URL。你註冊了 https://app.example.com/checkout/return 但失敗的請求表明 https://app.example.com:443/checkout/return/. 兩者都解析。解析器顯示第一個有主機 app.example.com (預設端口,路徑上沒有尾隨斜線)第二個有主機 app.example.com 太--但它的道路是 /checkout/return/ 帶有尾斜線,其連接埠明確寫為 :443. 眼睛滑過兩個差異,對於精確匹配檢查來說都是致命的。一旦您可以將它們視為單獨的標記組件,修復就很明顯:標準化尾隨斜線並刪除冗餘顯式連接埠。
閱讀 URL 時常見的錯誤
反覆出現的錯誤值得命名。 將片段與路徑或查詢混淆 - 之後的一切 # 是片段,它完全由瀏覽器處理,並且永遠不會發送到伺服器,因此您放置了一個參數 # 不會到達您的後端。 假設缺少連接埠表示沒有連接埠 - 省略連接埠表示該方案 預設 (https 為 443,http 為 80),解析器明確說明這一點,以便您知道請求真正會擊中哪個連接埠。
忽略雙重編碼 - 如果一個值看起來像 %2520 代替 %20,它被編碼了兩次;解析它,如果解碼值仍然包含百分比序列,則再次解碼。 信任連結的可見文字 - 您看到的文字和實際內容 href 可以完全不同,這就是網路釣魚背後的整個機制;解析揭示了真正的目的地主機。和 將重複的查詢金鑰視為要丟棄的重複項 - 它們通常是有意義的數組,丟棄它們會失去資料。
常見問題
網址的部分是什麼？
URL 具有方案 (HTTPS)、可選憑證 (user:pass@)、具有可選連接埠的主機 (example.com)、路徑 (/blog/post)、可選查詢字串 (?id=42) 和可選片段 (#section)。 這個解析器將每個解析器分開並標記。
如何解析查詢字串？
貼上完整的 URL 並讀取查詢表,或僅貼上查詢字串。解析器將其分割為&符號,解碼百分比編碼,並按順序列出每個鍵值對。重複的鍵,例如 tag=a&tag=b 保留為單獨的行。
主機名稱、主機名稱和來源有什麼區別？
Hostname 只是網域或 IP(例如。com)。當存在連接埠時,主機會新增連接埠(例如。com:8443)。起源是方案加主機(https://example.com:8443) 瀏覽器使用 和 進行同源安全檢查。
當 URL 沒有連接埠號碼時，使用什麼連接埠？
該計劃決定。 HTTPS 預設為 443，HTTP 預設為 80，SSH 預設為 22，FTP 預設為 21。 此解析器顯示有效連接埠並將其標記為預設值，因此您知道請求將實際使用哪個連接埠。
解析器是否解碼百分比編碼的字元？
是的,對於查詢值。像 name=John%20Doe 這樣的參數顯示為解碼為 "約翰·多伊&引用;在表中。原始搜尋字串也顯示為未觸及的,因此您可以比較編碼和解碼的形式。
我可以在不鍵入 https 部分的情況下解析 url 嗎？
是的。 如果您貼上裸主機或路徑，例如 example.com/pring，解析器會自動前置 https://，並指出它已採用該方案。 明確貼上一個方案，例如 http:// 或 ftp://，以覆寫這個假設。
為什麼我的網址無法解析？
通常主機遺失或格式錯誤，方案寫錯，或字串包含在 URL 中非法且未編碼百分比的字元。 檢查方案後是否有空格、未轉義的支架或缺少的斜線。
用令牌或會話 ID 貼上 URL 是否安全？
是的。 使用其本機 URL 引擎完全在瀏覽器中運行解析。 該連結永遠不會發送到伺服器，從不記錄，也從不儲存，因此包含存取權杖、API 金鑰或內部主機名稱的 URL 會保留在您的裝置上。
