一個完全在貼上的 HTML 原始碼上運作的連結萃取工具替代方案,可從貼上的原始碼中萃取出 href 目標,完全不會對列出的 URL 發出任何網路請求。該工具會掃描 a、area 和 link 元素的起始標籤中的 href 屬性,正規化網頁、郵件和電話連結,並對結果進行去重複處理,使每個目的地以首次出現的順序僅顯示一次。由於所有資料都不會離開瀏覽器,因此不需要註冊、不需要安裝擴充功能、不需要代理伺服器,也沒有在稽核中觸發這些目的地的風險。可選的 HTTP 或 HTTPS 基礎 URL 會將根相對、路徑相對、父項目相對和協定相對的值解析為絕對位址,因此 https://example.com/products/page 下的 /pricing 會變成 https://example.com/pricing,而不是您必須手動修正的路徑。javascript、data 和 vbscript 等可執行的協定,以及空白的 href 和同文件的片段會一併被過濾掉,介面會回報這些項目被略過的數量,因此唯一結果的數量並非一個黑盒子。

基於原始碼的連結萃取工具實際上做了什麼
市面上大多數「連結萃取工具」可分為兩類:為您擷取 URL 的全頁爬蟲,以及讀取您已開啟頁面之即時 DOM 的瀏覽器擴充功能。可解析貼上原始碼的連結萃取工具是第三種選擇,其行為更像是靜態解析器而非蜘蛛。您提供 HTML,並可選擇性地提供頁面 URL 以便解析相對路徑,工具則會回傳一個去重複的 href 目標清單。該頁面本身永遠不會被聯繫,這消除了安全性和遷移稽核中一整類的風險,在這些稽核中,點擊或探測錯誤的目標可能會造成嚴重後果。
這類工具的合約刻意設計得很狹窄。解析器僅掃描起始標籤,尋找 a、area 和 link 元素上的 href,並忽略錨點文字、周圍的標記,以及任何關於連結是否為導航、規範或預載的指示。納入三種元素類型是因為原始碼清單應反映文件實際引用的所有內容:普通錨點、影像地圖區域,以及文件層級的 link 元素,例如樣式表、圖示、規範頁面或替代資源。註解和 script、style、textarea、title、iframe、noembed 和 noframes 等原始文字容器會在掃描前先被移除,因此 JavaScript 樣板字面值中看似錨點標記的字串不會變成誤判的連結。
如何從貼上的 HTML 原始碼中萃取連結
- 在您的瀏覽器中開啟您有權檢查的頁面,查看其原始碼,並將 HTML 複製到連結萃取工具的輸入欄位。如果您沒有即時頁面,請貼上由您自己的爬蟲所產生的 HTML。
- 當原始碼使用諸如 /pricing、../guide 或 //cdn.example.com/file.css 等相對路徑時,請在基礎 URL 欄位中輸入絕對頁面 URL。如果每個 href 都已是絕對路徑,則將該欄位留空。
- 執行萃取並一同讀取三個計數器:唯一、重複和略過。唯一計數是您的清單,重複計數會告訴您原始碼中有多少重複,而略過計數則會告訴您有多少空白、僅含片段、可執行或無效的目標被過濾掉。
- 將一行一筆的結果複製到您工作流程的下一個步驟,然後使用另一個經授權的爬蟲或瀏覽器 DOM 匯出來驗證狀態、重新導向、rel 屬性的意義,以及任何由 JavaScript 新增的連結。
基礎 URL 欄位是最常見的混淆來源。當提供有效的 HTTP 或 HTTPS 基礎 URL 時,解析器會使用瀏覽器 URL 模型將根相對、路徑相對、父項目相對和協定相對的 href 解析為絕對位址。若未提供基礎,相對值會刻意保持為相對,因此輸出內容永遠不會憑空捏造主機。基礎 URL 不能包含使用者認證資訊,而 file: 或 ftp: 等非 HTTP 協定會被拒絕,否則這兩種情況可能會將使用者資訊洩漏到每個解析結果中,或產生誤導性的解析環境。
相對路徑、基礎 URL 與解析規則
解析規則之所以重要,是因為相同的貼上 HTML 會根據您提供的基礎 URL 而產生不同的輸出。在 https://example.com/products/page 上提供的頁面中,包含 href="/pricing" 的文件會解析為 https://example.com/pricing。相同的 href 若在未提供基礎的情況下貼上,則會保持為 /pricing,這對於離線封存而言是正確的,但對於期望絕對 URL 的爬蟲來說卻毫無用處。諸如 //cdn.example.com/assets/style.css 等協定相對的 href 會採用基礎 URL 的協定,因此 HTTP 和 HTTPS 來源會解析為相符的協定。諸如 ../../guide 等父項目相對路徑則依循一般的目錄規則。
郵件和電話連結會被刻意保留。mailto:[email protected] 和 tel:+15551234567 即使網頁爬蟲無法造訪,也是有效的連結目的地,若將其捨棄將會使合法的聯絡資料從清單中隱藏。解析器會在 href 值內解碼一組有限的 HTML 字元參考:十進位和十六進位數值參考,加上具名集合 amp、quot、apos、lt 和 gt。這涵蓋了查詢字串中出現 & 符號的常見情況。罕見的具名參考則保持編碼狀態,而非從猜測的全域表格中靜默替換,這在結果將於下游被重新解析時更為安全。
| 輸入 href | 基礎 URL | 解析後的目標 |
|---|---|---|
| /pricing | https://example.com/products/page | https://example.com/pricing |
| ../guide | https://example.com/products/page | https://example.com/guide |
| //cdn.example.com/file.css | https://example.com/ | https://cdn.example.com/file.css |
| https://other.com/a | https://example.com/ | https://other.com/a |
| mailto:[email protected] | 任意 | mailto:[email protected] |
| #section | https://example.com/page | 略過 (僅含片段) |
原始碼解析與爬蟲及瀏覽器擴充功能的差異
選擇連結萃取工具替代方案實際上是一個關於您想要哪種信任邊界的問題。基於爬蟲的工具會自行擷取 URL,因此它們總是會看到最終渲染後的 DOM,但它們需要網路存取、可能會被封鎖、會將您的 IP 記錄到目標伺服器上,並會悄悄跟隨改變清單意義的重新導向。瀏覽器擴充功能會讀取您已開啟頁面的即時 DOM,這可以捕捉到由 JavaScript 注入的連結,但會將工具繫結到特定的瀏覽器,通常需要廣泛的權限,並且仍然取決於您是否獲得授權來載入該頁面。基於原始碼的萃取工具則居中:它所看到的是與提供時完全相同的靜態標記,沒有渲染、沒有網路副作用,且無論由誰執行,輸出結果都完全相同。
| 方法 | 其可見內容 | 是否需要網路 | 由 JavaScript 注入的連結 | 最適用於 |
|---|---|---|---|---|
| 基於原始碼的萃取工具 | 您貼上的靜態 HTML | 否 | 否 | 稽核、遷移、離線審查 |
| 瀏覽器擴充功能 | 已開啟分頁的渲染後 DOM | 僅限頁面本身 | 是 | 對即時頁面進行手動檢查 |
| 雲端爬蟲 | 重新導向和 JS 執行後的最終 HTML | 是,由工具的伺服器發出 | 是 | 跨多個頁面的大規模探索 |
| 自訂腳本 | 腳本所指定的任何目標 | 取決於腳本 | 僅當您解析渲染後的 DOM 時 | 已使用 Python 或 Node 的管線 |
基於原始碼的方法在可重複性方面勝出。兩位審查者貼上相同的 HTML 並得到相同的清單,且略過計數也相同,該結果可以簽入版本控制或附加到工單中。爬蟲和擴充功能的結果會因重新導向、逾時和用戶端狀態而產生差異,這使得它們在稽核追蹤中更難以辯護。
解讀輸出:計數、順序與略過的內容
結果面板會顯示三個計數器,因為每一個都回答一個不同的問題。唯一計數是清單的大小。重複計數會告訴您原始碼中有多少重複,這通常是模板或側邊欄雜訊的訊號。略過計數則是安全網:它會告訴您某些 href 已被看見並捨棄,因此較短的唯一清單並不意味著原始碼很少。略過的目標包含空白的 href、同文件片段、無效的絕對 URL,以及任何協定為 javascript:、data: 或 vbscript: 的 href。
首次出現的順序會被刻意保留。如果原始碼先列出導覽連結再列出頁尾連結,輸出會保留該順序,這使得與頁面版面進行比較,或將該清單饋入使用原始碼順序作為提示的審查表單變得容易。去重複會在正規化之後精確進行,這表示兩個僅在追蹤參數、片段、大小寫或重新導向行為上有所不同的 href 仍會計為不同的目標。該工具不會假設 https://Example.com/A 和 https://example.com/a 指向相同的資源,也不會為您移除 utm_source 權杖。請將輸出視為原始清單,並在其上套用您自己的正規化規則。
| 原始碼中可見的 href 值 | 動作 | 原因 |
|---|---|---|
| https://example.com/a | 納入 | 標準絕對 URL |
| /a (具備有效的基礎) | 解析後納入 | 已解析為絕對路徑 |
| https://example.com/a (第二次出現) | 去重複 | 正規化後為相同目標 |
| #intro | 略過 | 同文件片段 |
| 略過 | 空白的 href | |
| javascript:void(0) | 略過 | 可執行的協定 |
| data:text/html,... | 略過 | 內嵌資料協定 |
| mailto:[email protected] | 納入 | 合法的非網頁目的地 |
| tel:+15551234567 | 納入 | 合法的非網頁目的地 |
| https://exa mple.com | 略過 | 無效的 URL |
When a Source-Based Extractor Is the Wrong Tool
The tool is honest about what it does not do. It does not fetch the page, so it cannot tell you whether a target returns 200, 301, or 404; that has to come from a separate authorized crawler. It does not evaluate rel attributes, so canonical, nofollow, sponsored, and ugc signals are not surfaced in the output. It does not label internal versus external links, because the parser only sees the source you paste, not the network topology. It also does not render JavaScript, which means any link injected after scripts run is absent from the result.
Severely malformed markup can also produce a different DOM from the bounded scan, because the implementation is a source parser rather than a full browser HTML tree builder. For a legal, security, or migration audit, compare the original source against a browser DOM export and a real crawler rather than trusting one extraction channel. Input is capped at 200,000 characters to keep the interactive scan bounded, so very large documents should be split or handled with a controlled crawler. None of these are bugs so much as the shape of the contract, and recognizing them up front is what makes a source-based link extractor a useful piece of the workflow rather than a black box.
Related reading: Link Extractor API Alternative: A Local Source Parser.
Related reading: Bulk Link Extractor: Parse and Deduplicate Pasted HTML.