為網站建立電子郵件地址連結,意即產生一個 mailto 錨點,其中可見地址與 href 目標的每一個字元,皆以十進位數值 HTML 字元參考寫成,使瀏覽器將該參考解碼為可點擊的電子郵件連結,而極為陽春的抓取工具在掃描原始碼中的普通地址樣式時,則看不到任何字面地址字元。電子郵件地址混淆工具可在你的瀏覽器內,將任何通過驗證的公開聯絡地址,完整轉換為此種錨點:它接受未加引號的本地部分與一個正規化後的網域,接著輸出一個完整的錨點元素,而輸出原始碼中完全沒有任何字面地址字元。你所複製貼上的,即是整段已混淆的連結,可直接放入 HTML 模板,在訪客眼中仍呈現為一般的可點擊文字,但對以純文字比對的機器人而言,原始碼則保持隱晦。此技巧屬於原始碼層級的混淆,而非存取控制:任何會解碼數值實體、檢視渲染後 DOM,或在訪客點擊時沿著 mailto 連結追蹤的爬蟲,仍可發現該地址。
為何一般電子郵件地址會從頁面原始碼中被抓取
以純文字形式發布在網站上的聯絡地址,一直以來都是最基本收割工具的目標。這類腳本會擷取頁面、去除 HTML,接著執行正規表示式,尋找如 [email protected] 這類熟悉樣式。由於公開聯絡頁面正是這類樣式出現之處,一個已發布的地址,往往在上線後數小時內,就會被列入行銷名單。
電子郵件混淆將這場戰役,轉移到最簡單抓取工具無法處理的層次。已發布的原始碼不再保留原始字元,而是包含十進位數值字元參考,例如字母 j 會以 j 表示。瀏覽器會在繪製頁面前先將這些參考反轉義,因此可見連結依然顯示為真實地址,mailto 目標也依然能正確解析。僅對原始回應進行純文字樣式比對的抓取工具,將完全錯過該地址;然而,實際解碼實體並走訪 DOM 的抓取工具,則仍會看見它。這是一種從「易於收割」到「稍微難以收割」的轉變,並非從公開轉為私密。
電子郵件地址混淆工具實際輸出的內容
此工具完全在瀏覽器中執行,並產生單一 HTML 元素:一個 <a> 標籤,其可見文字與 href 皆以數值字元參考寫成。輸入會先進行正規化。前後空白會被去除,本地部分保留其原有大小寫與支援的標點符號,網域則轉為小寫,並經由瀏覽器的 URL 主機解析器處理,使諸如 jane@例え.jp 之類的國際化地址,被序列化為其 ASCII 相容形式,以便跨瀏覽器穩定重現。
可見地址與 mailto 目標中的每一個碼位,皆會轉為十進位實體。例如字母 a 的 Unicode 碼位為 U+0061,十進位為 97,因此在原始碼中會以 a 表示(完整參考語法請參閱 WHATWG 字元參考 規格)。產生的程式碼片段包含完整錨點,包括以實體形式呈現的 mailto: 前綴與結束標籤。
一項實際的限制,規範了何者構成可用的輸入。驗證機制刻意支援一組範圍較窄的未加引號地址格式,而非完整的 RFC 5322 文法:
| 地址格式 | 是否接受 | 原因 |
|---|---|---|
| [email protected] | 是 | 標準未加引號的本地部分,搭配多標籤網域 |
| [email protected] | 是 | 加號標記地址,搭配多標籤子網域 |
| jane@例え.jp | 是 | 國際化網域,轉為小寫並以 ASCII 序列化 |
| "jane doe"@example.com | 否 | 加引號的本地部分超出支援子集 |
| jane@[192.0.2.1] | 否 | 含有 IPv4 地址的網域字面值不予接受 |
| jane@example | 否 | 單標籤主機予以拒絕 |
| [email protected] | 否 | 本地部分的開頭句點無法通過驗證 |
| jane@@example.com | 否 | 重複的 @ 字元無法通過驗證 |
如此嚴格的契約,是為了讓結果在不同瀏覽器間皆可重現,並確保工具絕不會在無法忠實重現的輸入上回報成功。它並不會測試該郵箱是否存在、能否收信,或是否可成功投遞。
如何逐步建立電子郵件地址連結
本逐步說明直接使用 電子郵件地址混淆工具,並假設你擁有一個公開 HTML 模板,或一個可讓你編輯原始 HTML 的內容管理系統。
- 在任何現代瀏覽器中開啟電子郵件地址混淆工具頁面。此工具於本機執行,不會將你的地址上傳至伺服器。
- 在輸入欄位中輸入你想發布的公開聯絡地址。請使用未加引號的單純格式,例如 [email protected]。可接受加號標記與國際化網域;加引號的本地部分、IP 字面值與單標籤主機則不接受。
- 產生錨點。輸出為單一完整的 <a> 元素,其可見文字與 mailto: 目標皆以十進位數值字元參考寫成,原始碼中完全沒有任何字面地址字元。
- 將整段產生的程式碼片段複製到剪貼簿。請確認你已將開頭標籤、編碼後的文字、編碼後的 href 與結束標籤一併複製;若僅複製部分內容,將無法正確呈現。
- 將程式碼片段貼至 HTML 原始碼環境中,例如模板中的原始 HTML 區塊、靜態網站檔案,或標示可編輯 HTML 模式的內容管理系統欄位。
- 在新瀏覽器視窗中開啟已發布的頁面,點擊渲染後的連結一次,並確認你的郵件客戶端收到的地址,與你所輸入的完全一致。檢查頁面原始碼,確認實體仍維持數值形式,並未在發布過程中被你的內容管理系統解碼。
應貼入 HTML 原始碼,絕不可貼入所見即所得欄位
混淆後的錨點悄然失效,最常見的原因在於貼入程式碼片段的編輯器。所見即所得或富文字欄位並不會儲存原始 HTML;它會剖析貼上的字串、將實體解碼為一般字元,並以其內部模型重寫標記。當你儲存並重新發布後,頁面原始碼又會顯示為一般的 [email protected],混淆效果已在無聲中消失。
為避免此情況,應將程式碼片段貼入可逐字儲存原始碼的環境。這包含靜態 HTML 檔案、內容管理系統內的原始 HTML 區塊、透過 HTML 直通方式渲染的 MDX 或 Markdown 元件,以及任何「程式碼」或「嵌入 HTML」小工具。若你的內容管理系統僅提供富文字編輯器,請尋找「程式碼檢視」、「自訂 HTML」區塊,或可接受原始標記的短代碼。若無此類選項,此工具便不適合用於該頁面。
測試時,亦應確認編輯器不會對 & 符號進行雙重跳脫。若內容管理系統將 a 替換為 &#97;,訪客在頁面上將看到字面的實體文字,而不是字母 a。這兩種失敗模式在編輯器預覽中皆容易被忽略,因為預覽通常仍會正確渲染連結,即使儲存的原始碼已損壞。
驗證已發布的 Mailto 並檢查 DOM
發布後,請將實際上線的頁面視為唯一真相來源。請在全新的瀏覽器工作階段中開啟,以免因快取或先前造訪而隱藏回歸問題。在腦中將連結文字唸出來,確認與預期地址一致。將游標懸停於連結上,並讀取瀏覽器為 href 所顯示的狀態列或提示文字;兩者應相符。
接著開啟頁面原始碼,搜尋原始地址字串。若找到,即表示實體已在發布流程的某個環節被解碼,混淆效果已不復存在。若僅在錨點內找到數值字元參考,則表示原始碼仍處於混淆狀態,此技巧正依設計運作。
點擊連結一次,確認郵件客戶端完整收到該地址。編碼錯誤的字元會在此處顯現,因為多數郵件客戶端會拒絕格式錯誤的地址,或悄悄投遞至錯誤的郵箱。同時,此刻也是判斷混淆是否為適當防禦層級的時機。可點擊的 mailto 連結,必然會將地址暴露給任何透過瀏覽器「複製連結地址」內容選單複製、檢視渲染後 DOM,或僅僅點擊並讀取新郵件視窗的使用者。對於任何比通用聯絡地址更敏感的內容,以下章節即適用。
當混淆不足以因應,以及替代方案
原始碼混淆是一項刻意的權衡。它不需任何成本,不增加 JavaScript 相依性,且能相容於內容安全政策;但它同樣僅能阻擋最為基本的收割工具。會解碼 HTML 實體、執行無頭瀏覽器,或沿著渲染後連結追蹤的現代爬蟲,仍可還原該地址。此工具本身在輸出旁即標示此一限制,而不會給出虛假的信心。
對於真正需要抵禦濫用的聯絡地址,標準做法是採用伺服器端聯絡表單,並搭配驗證、速率限制、視需要使用的驗證碼,以及完善的垃圾訊息過濾。郵箱根本不會出現於頁面原始碼之中,因此抓取工具無從發現。此外,亦可採用 contact@ 等可丟棄、依角色劃分的地址,並透過服務端規則進行過濾,以提供額外的防護層。
當你明確希望在公開頁面上提供一個可點擊、外觀普通的電子郵件連結,當該地址並非機密,以及當目標是將聯絡資料自最易取得的收割名單中剔除時,電子郵件地址混淆工具即為合適之選。對於其他所有情況,請選擇表單。
若你正在權衡各種選項,如何為公開網站建立專用電子郵件地址 一文對此有詳細說明。
若你正在權衡各種選項,如何寄信給州務卿:查找辦公室地址 一文對此有詳細說明。