info@ 電子郵件地址是公開網站上最常見的一般聯絡別名,通常寫成 [email protected],用於業務、支援和一般詢問。為了減少明文收集器擷取的風險,同時在頁面上發布該地址,您可以使用十進位數值 HTML 字元參考來編碼整個錨點(可見文字與 mailto: 目標),例如 i 代表「i」、n 代表「n」。瀏覽器仍會解碼這些參考並完整顯示該地址,但在 HTML 原始碼中搜尋明文地址模式的基本爬蟲程式,將找不到任何可複製的可辨識內容。混淆機制存在於頁面原始碼中——渲染後的頁面、點擊目標和收件人地址都與一般 mailto 連結完全相同。使用此方法代表您須接受以下事實:任何訪客或任何現代爬蟲在頁面渲染後,仍然可以解析出該地址,因此此技術適合用於輕量級的公開聯絡資訊顯示,而非存取控制。本文其餘部分將逐步說明確切步驟、原始碼層級的驗證方式,以及在依賴此技術前需要了解的限制。
info@ 電子郵件地址的用途
info@ 屬於一組小型、標準化的角色型信箱——info@、contact@、sales@、support@——組織會將其路由到負責處理一般詢問的人員或共用收件匣。選擇 info@ 代表訪客不需要指定特定部門,且任何回覆稍後都可以再分流處理。這個慣例比消費級網路郵件更早出現,並沿用至今,因為它易於記憶,且郵件伺服器會將 @ 符號前的本機部分視為一般識別碼,可以轉發、設定別名或整合到共用信箱,而不需寄件者端進行設定變更。
由此衍生出兩個實際狀況。第一,這個前綴廣為人知,代表爬蟲程式不必猜測——它可以在網域附近搜尋「info@」,輕鬆收集候選地址。第二,該地址的設計本意就是公開的,因此不預期具有機密性;真正的問題在於該地址如何在頁面上曝光,以及這種曝光為收集過程帶來多少阻力。對網站經營者而言,取捨在於讓真實訪客能點擊並清楚閱讀該地址,同時避免在 HTML 原始碼中遭到簡易的明文搜尋,而這正是數值實體編碼設計要解決的問題。如果您正在為小型網站選擇角色型地址,關於哪個前綴適合哪種用途的更廣泛討論,涵蓋在為公開網站建立特殊電子郵件地址的指南中。
原始碼層級的混淆機制如何運作
網頁上一般的可點擊電子郵件連結由兩個部分組成——<a> 與 </a> 之間的可見文字,以及 href 屬性的值(以 mailto: 開頭,後接地址)。兩部分中的每個字元都是儲存在 HTML 檔案中的字面字元。下載該檔案並執行如 [\w.+-]+@[\w-]+\.[\w.-]+ 正規表示式的爬蟲程式,會在數毫秒內擷取該地址。
數值實體編碼會重新編寫每個字元,讓檔案不再以明文形式包含該地址。小寫 a 變成 a,@ 變成 @,依此類推,每個碼點使用一個十進位參考。當瀏覽器渲染該檔案時,會依循這些參考、組合出地址並正常顯示。當爬蟲程式以文字方式讀取該檔案並執行相同的正規表示式時,該模式找不到任何東西——標籤之間的位元都是 &、#、數字和 ;,而不是電子郵件地址的字母。這個機制在 WHATWG HTML 標準中,以位於 html.spec.whatwg.org/multipage/named-characters.html#character-references 的十進位數值字元參考記載,所有現代瀏覽器都以相同方式解碼這些參考。
逐步產生 info@ 錨點
使用電子郵件地址混淆工具,輸入像 [email protected] 這樣的聯絡地址。
- 輸入完整的公開地址並在本機產生錨點。此工具會驗證本機部分、將網域轉為小寫、將國際化網域序列化為其 ASCII 相容形式,並輸出一個單一錨點元素,其中每個碼點——可見文字、mailto: 前綴和地址——都是十進位數值參考。
- 將完整的錨點複製到 HTML 原始碼檢視中。將其貼到模板中或直接貼到您頁面的 HTML。切勿將其貼到所見即所得編輯器或內容管理系統的視覺模式中,因為這些介面經常在儲存時解碼實體,導致混淆機制失效。
- 開啟已發布的頁面、檢查其原始碼並測試 mailto 連結。確認檔案中仍存在這些實體,然後點擊渲染後的連結一次,驗證您的郵件用戶端接收到的正是您輸入的地址。如果原始碼顯示字面字母,或顯示雙重跳脫的參考(例如 &#97;),則表示混淆機制已失效,該連結已退回到一般的 mailto。
第三步是唯一能證明操作成功的步驟。略過原始碼檢查是團隊發布了他們以為已混淆的地址,後來卻發現頁面仍包含字面字串的最常見原因。
驗證已發布的 info@ 錨點
驗證包含三項檢查,每一項都能捕捉到不同的失敗模式。
首先,檢視頁面原始碼。錨點中應該全程都是 &# 序列。如果您看到明文字母,或看到 &# (& 符號本身被跳脫為 &),則表示 CMS 已重寫標記,訪客將會看到原始 HTML 實體形式的地址,或混淆機制完全失效。
其次,從全新的瀏覽器工作階段點擊渲染後的連結。您的郵件用戶端應會開啟,顯示的地址與您輸入的完全相同,本機部分的大小寫一致,網域也同樣為小寫。如果用戶端顯示不同的地址,則代表實體序列存在碼點錯誤,需要重新產生輸出。
第三,從渲染後的頁面複製連結(右鍵點擊、複製連結位址),並貼到文字編輯器中。大多數瀏覽器會顯示解析後的 mailto: 值,而在那裡顯示的任何地址,對於能對同一頁面執行 JavaScript 的能力足夠的爬蟲來說同樣可見。這是一個有用的健全性檢查,而非漏洞——任何訪客都能做同樣的事。
混淆與聯絡表單:何者足夠
原始碼層級編碼與伺服器端聯絡表單解決的問題有重疊但不相同。下表定性比較其功能;每項所提供的確切保證取決於您的伺服器設定、訪客特徵和發布流程,因此應將表格內容視為能力,而不是量測到的垃圾訊息比率。
| 需求 | 使用數值實體編碼的 info@ | 伺服器端聯絡表單 |
|---|---|---|
| 為任何訪客提供可見、可點擊的聯絡方式 | 是 — 正常渲染 | 由表單欄位取代 |
| 阻擋明文正規表示式收集器 | 是 — 原始碼不含字母模式 | 不適用 — 未發布任何地址 |
| 阻擋會解碼實體或追蹤 mailto 連結的現代爬蟲 | 否 | 大致可以 — 地址完全未曝光 |
| 在停用指令碼、CSP 規則或 JavaScript 錯誤時仍可運作 | 是 — 純 HTML | 是 — 純 HTML 表單 |
| 提供速率限制、驗證碼和輸入驗證 | 否 | 是 — 在伺服器端強制執行 |
| 將訊息路由至角色收件匣或共用信箱 | 是 — 視您的郵件設定而定 | 是 — 後端可自由路由或設定別名 |
| 適用於機密地址、憑證或私人別名 | 否 | 較接近,但目的地伺服器仍需強化防護 |
請以定性方式解讀此比較:原始碼混淆為最簡易的掃描器增加了一道薄弱的屏障,而聯絡表單則提供了可隨流量擴充的營運防禦。對於有意義的抗濫用能力,應將表單與速率限制、一次性角色地址及信箱提供者控制結合使用,而不是單獨依賴其中一種。
常見限制與陷阱
數值實體編碼有三項值得明確說明的特性。
這是一種原始碼層級的技術。任何會剖析 HTML 的對象——螢幕閱讀器、瀏覽器擴充功能、設計良好的爬蟲、對渲染後文字的剪貼簿複製——都會看到已解析的地址並可對其採取行動。沒有任何純 HTML 編碼能對看得見頁面的訪客隱藏該地址。
此方法只有在您的發布流程能保留實體時才能維持。所見即所得編輯器、會跳脫 & 符號的 Markdown 處理器、自動跳脫的伺服器端模板,以及某些輔助工具,都可能在背景中將 a 改回 a。每次 CMS、外掛程式或框架更新之後,請重新檢查原始碼。
這不是存取控制。請勿依賴它來保護機密地址、憑證、內部別名,或任何遭到入侵將造成嚴重後果的信箱。針對這些情況,請使用具有伺服器端驗證和速率限制的聯絡表單,且絕不以任何形式發布該地址。
當 info@ 不符合驗證程式時
電子郵件地址混淆工具接受範圍較窄、實用的地址格式:非空白的未加引號本機部分、剛好一個 @、含多個標籤的網域,且不含空白字元或控制字元。本機部分的開頭、結尾或連續的點會被拒絕,且不支援加引號的本機部分、註解、網域字面常數和 IPv4 信箱形式。
如果您的角色地址使用加號分址進行路由——例如 [email protected]——由於本機部分包含支援的標點符號且周圍無空白字元,工具會接受它。如果您的託管服務提供者給您的地址是單一標籤網域或基於 IP 的主機,驗證程式會將其拒絕,因為此工具設計用於一般公開網站地址,而非特殊系統允許的所有信箱語法。這些規則以語法的廣度換取輸出內容的明確性;對您組織重要的特殊形式應該在工具外部設定,而不是強行通過會錯誤呈現其內容的驗證程式。
如果您正在權衡選項,公開網站的最佳電子郵件地址範例對此有詳細說明。