URL 解析工具

輸入 URL 即可將其拆解為協議、主機、路徑、查詢引數和片段。還能自動識別 utm_source 等跟蹤引數。

URL 結構一覽

組成部分	示例	說明
協議（Scheme）	https:	表示通訊方式。網頁使用 http:/https:，郵件連結使用 mailto: 等，始終位於 URL 最前端。
使用者資訊	user:pass@	Basic 認證中使用的使用者名稱和密碼，以明文形式保留，共享含此資訊的 URL 時需格外小心。
主機名	example.com	目標伺服器的域名或 IP 地址。
埠號	:8080	目標埠號。http 預設為 80，https 預設為 443，因此通常省略。
路徑	/users/123	表示伺服器上資源位置的層級結構字串。
查詢字串	?id=123&sort=asc	緊跟在“?”之後的 key=value 引數組，多個引數用“&”連線。
片段	#section2	指向頁面內特定位置的識別符號。“#”之後的內容不會發送到伺服器，僅在瀏覽器內處理。

常見跟蹤查詢引數

引數名	說明
utm_source	用於 Google Analytics 等工具識別流量來源（如 newsletter、google、twitter）。UTM 是 Urchin Tracking Module 的縮寫。
utm_medium	用於識別流量的媒介（如 email、cpc、social），通常與 utm_source 搭配使用。
utm_campaign	用於識別營銷活動的名稱，便於衡量特定推廣活動的效果。
utm_term	用於識別付費搜尋廣告（PPC）中使用的關鍵詞。
utm_content	用於區分同一廣告內的多個連結或素材。
gclid	Google 廣告（Google Ads）發放的點選 ID，用於轉化跟蹤。
fbclid	Facebook 廣告發放的點選 ID，用於 Meta 的廣告效果測量。

什麼是 URL 解析器

URL 解析器是把輸入的 URL 拆解為方案（協定）、主機名稱、連接埠、路徑、查詢參數、片段等構成要素並列表顯示的工具。它不必讓您用眼睛追著長 URL 手動解讀，而是使用瀏覽器標準的 URL API 精確拆分，並自動偵測 utm_source、gclid、fbclid 等追蹤用參數。

輸入的 URL 全部在瀏覽器內的 JavaScript 中處理，不會傳送至伺服器。即便是含有認證資訊的 URL 或帶密碼的 URL（user:pass@host 形式），也能在不向外洩漏內容的前提下安全地確認其結構。

URL 解析器的使用方式

把 URL 貼到輸入欄請輸入含有方案（https:// 等）的完整 URL。相對路徑或省略方案的 URL 無法解析。
確認構成要素的清單協定、主機名稱、連接埠、路徑、片段等會被自動拆解，並分別顯示在各自的列中。
確認查詢參數鍵與值的組合會以清單顯示，utm_source 等追蹤用參數會帶有專用標記。
判斷哪些參數不需要查看帶有追蹤標記的參數，判斷在分享之前是否應當刪除。

用好本工具的小技巧

在社交媒體分享 URL 之前，先用此工具檢查是否含有 utm_source 等跟蹤引數。刪除不需要的引數後分享的連結會更簡潔。
輸入的 URL 全部在瀏覽器內通過 JavaScript 處理，不會發送到 toolbase.cc 的伺服器，因此即使包含賬號密碼資訊也可以安全檢查。
當查詢字串中同一個鍵出現多次時（例如 ?tag=a&tag=b），每一次出現都會作為獨立的一行顯示。
片段（“#”之後的部分）不會發送到伺服器，只在瀏覽器內用於頁內錨點跳轉或單頁應用的路由，僅檢視伺服器日誌無法獲取這部分資訊。
當埠欄顯示為空時，表示使用了預設埠（http 為 80，https 為 443），因此在 URL 中被省略了。

URL 解析器的應用情境

社群分享前的追蹤確認

在分享連結之前確認其中是否含有 utm_source 等，必要時可去除後分享乾淨的 URL。

理解長 URL 的結構

即便是串接了大量查詢參數的長 URL，由於會按鍵與值逐一拆解，也能一眼看出各自指定了什麼。

伺服器端實作的偵錯

在實作路由或重新導向處理時，可以瀏覽器 URL API 相同的行為，確認實際 URL 會被如何拆解。

廣告點擊 ID 的調查

收到帶有 gclid、fbclid 等參數的連結時，可作為判別其來自哪個廣告平台的線索。

URL 構成要素的用語

來源（origin）: 指方案、主機名稱與連接埠的組合。是否為同源，是瀏覽器安全控制（CORS 等）的判定基準。
查詢字串: 指 URL 中「?」之後所接的 key=value 形式的參數群。可用「&」串接多個參數。
片段（fragment）: 指 URL 中「#」之後的部分。它不會傳送至伺服器，而用於瀏覽器內的頁內連結與 SPA 的路由。
百分比編碼: 為在 URL 中處理非 ASCII 字元，把 UTF-8 的位元組序列轉換為 %XX 形式的機制，也稱為 URL 編碼。
UTM 參數: 指 utm_source 等，供流量分析工具識別來源的一系列查詢參數的統稱。
點擊 ID: 指如 gclid、fbclid 那樣由廣告平台按點擊發放的識別碼，用於轉換衡量。

常見問題

大多數情況下刪除後不會影響頁面的顯示和功能，因為它們主要用於訪問統計分析，很少參與伺服器端的路由邏輯。但極少數網站會用查詢引數做條件判斷，因此建議刪除後先確認連結仍可正常開啟再分享。

這是百分號編碼（URL 編碼）的結果。由於 URL 無法直接包含非 ASCII 字元，因此會將 UTF-8 位元組序列轉換為 %XX 形式表示。本工具會通過 URLSearchParams 自動解碼後顯示。

本工具使用瀏覽器原生的 URL API，只能解析包含協議（如 http://）的完整 URL。若要檢查類似 localhost:3000/path 的地址，請在前面加上 http://，寫成 http://localhost:3000/path。

不會。片段是瀏覽器在頁面載入之後才處理的部分，並不包含在 HTTP 請求本身中，因此不會到達伺服器。它主要用於頁內錨點跳轉和單頁應用的路由。

這些是廣告平臺發放的點選 ID，目標網站會用該 ID 向 Google 或 Meta 報告“此次訪問來自哪個廣告”，用於轉化效果跟蹤。這本身不屬於個人資訊，但確實能讓廣告平臺追蹤到訪問來源的廣告渠道。

閒話 ― 為什麼 URL 裡的跟蹤引數越來越多

像 ?utm_source=... 這樣的查詢引數，最早源自 2005 年 Urchin 公司提供的一項統計分析服務所用的識別符號“Urchin Tracking Module”。Google 收購 Urchin 後將其發展為 Google Analytics，“UTM 引數”這一叫法由此成為行業標準。

2010 年代以後，Google、Facebook 等廣告平臺開始各自新增專屬的跟蹤引數（如 gclid、fbclid），導致一個 URL 上同時疊加多個跟蹤引數的情況越來越常見。社交媒體上分享的連結看起來異常冗長，往往正是這種疊加造成的。

一些瀏覽器和注重隱私的工具已具備自動清除這些引數的功能。不過統計分析本身對許多正規網站而言是重要功能，並非單純的“壞東西”，如何在營銷效果測量與個人隱私之間取得平衡，至今仍是持續討論的話題。

檢視全部趣味知識