電子郵件混淆器的 API 替代方案是一種在本機瀏覽器中運作的工具,它會將公開聯絡地址以十進位數值 HTML 字元參考的形式編碼後,放入 mailto 錨點內,因此原始碼中不會包含任何字面上的地址字元,也無需任何伺服器呼叫來產生或提供該連結。您想要發佈的地址永遠不會離開這個頁面,不會傳送到任何第三方端點,也不需要依賴 JavaScript SDK 在執行階段動態擷取。輸出內容是靜態 HTML,瀏覽器會正常渲染,而非常基本的純文字爬蟲只會看到實體參考,看不到地址形狀的字串。這項技術記載於 WHATWG HTML 規範中,規範定義任何字元碼位都可以寫成數值字元參考,由瀏覽器在渲染時解碼。在 mailto 錨點內使用時,會產生一個可點擊的連結,其可見文字與 href 完全由參考組成,原始碼中不會留下任何字面上的 @ 或網域字元。
「API 替代方案」對電子郵件混淆的意義
許多已發佈的電子郵件混淆服務要求開發者帳號、API 金鑰、在執行階段擷取地址的 JavaScript SDK,或是會重寫頁面的伺服器端點。當您想要相同的保護範圍——也就是渲染後的地址在原始碼中不會以純文字形式顯示——卻不想將地址送往第三方系統、不想設定憑證,也不想引入可能失敗、記錄資料或被內容安全政策封鎖的網路請求時,「API 替代方案」這個框架就顯得重要。
在本機瀏覽器中運作的電子郵件混淆器 API 替代方案是一種工具,接受單一地址,將每個字元編碼為十進位數值 HTML 實體,並回傳一個錨點,其可見文字與 mailto 目標完全由這些參考組成。地址永遠不會離開頁面,永遠不會送達伺服器,結果就是可以檢閱、複製並提交到範本的靜態 HTML。
當您維護靜態網站、在嚴格的 CSP 環境下託管(禁止第三方腳本)、執行無網路存取的 CI 管道來建構 HTML,或單純偏好讓公開聯絡地址保留在您掌控的基礎架構上時,這個模式非常實用。該錨點因為是純 HTML 而可跨主機攜帶,沒有 SDK 版本需要追蹤,也沒有客戶端程式庫需要載入。
純實體編碼在瀏覽器中的運作方式
這項編碼技術奠基於WHATWG HTML 字元參考規範,該規範定義了數值字元參考,例如 a 代表字母 a。瀏覽器在渲染時解碼這些參考並顯示原始字元。當原始碼僅包含實體時,在原始來源文字中搜尋字面模式 [email protected] 的天真爬蟲將不會找到符合的結果。
工具會一致地套用編碼。可見的錨點文字與 mailto href 都由每個 Unicode 碼位的十進位參考構成,產生的原始碼不含任何字面上的地址字元。地址會被修剪、驗證,網域部分會轉為小寫,同時保留本機部分的原始大小寫,而國際化網域會序列化為 ASCII 相容形式,使輸出在不同瀏覽器之間完全一致地重現。
處理程序完全在瀏覽器中執行。沒有 POST 請求、沒有 API 呼叫、沒有限流端點,也沒有需要管理的密鑰。您複製的錨點就是最終的 HTML,可以直接貼到範本中。數值參考也能讓結果保持為普通 HTML,任何瀏覽器都能在不執行程式碼的情況下渲染,這避免了基於 JavaScript 的地址重組所帶來的腳本停用和 CSP 衝突問題。
在瀏覽器中產生純實體的 Mailto 錨點
- 在瀏覽器中開啟電子郵件地址混淆器,並將公開聯絡地址輸入輸入欄位。驗證器要求實用的未加引號格式:非空白的本機部分、一個 @、含多個標籤的網域、無空白字元,且本機部分中沒有前置、結尾或連續的點。
- 執行產生動作。工具會修剪輸入、驗證格式、將網域轉為小寫、透過瀏覽器的 URL 主機解析器處理主機,然後輸出一個錨點,其可見文字與 mailto 目標完全以十進位數值字元參考撰寫。
- 完整複製錨點,與顯示內容完全一致。請勿將其貼到所見即所得的編輯器中,例如 CMS WYSIWYG 欄位、文書處理器或電子郵件撰寫器。這些環境會在貼上時解碼實體、將 & 重寫為 &,或將 a 替換為字母 a,在頁面發佈前就會破壞混淆效果。
- 將錨點貼到您範本的 HTML 原始碼中——直接貼到靜態檔案、CMS 的 HTML 檢視,或是伺服器端渲染的元件中。
- 發佈頁面,用一般瀏覽器開啟,確認可見文字與預定地址相符。點擊連結一次,確認您的郵件用戶端收到預定目標。接著檢視原始碼,確認實體仍然存在,且 @ 符號與點字元並非字面字元。
如果您的 CMS 在儲存時解碼實體,您在儲存的 HTML 中會看到普通的地址字元。如果是雙重跳脫,則會看到 a,頁面會渲染成實體文字而非地址。無論哪種情況,都代表混淆效果已消失,必須在範本層級編輯原始碼,而不是透過所見即所得欄位處理。
混淆器套用的驗證規則
驗證器刻意比 RFC 5321 與 5322 引用的完整電子郵件標準更為嚴格。它只接受一種實用的未加引號格式,因為這幾乎涵蓋所有真實的聯絡地址,同時讓規則集保持可稽核。帶引號的本機部分、註解、IP 位址字面值、單一標籤的主機,以及不常見的舊式格式都會刻意被拒絕;一個接受奇怪形狀但仍為無人能識別的地址產生可點擊錨點的寬鬆驗證器,所造成的誤導會多於幫助。
接受的格式需要一個 @ 字元、非空白的本機部分、以點分隔多個標籤的網域、無空白字元或控制字元,且本機部分中沒有前置、結尾或連續的點。本機部分保留其原始大小寫,並支援常見的標點符號,例如加號、連字號、底線,以及用於加號地址的點。網域在編碼前會轉為小寫。
工具不會驗證信箱是否存在、是否接受郵件,或是否屬於輸入該地址的人。語法上有效的地址仍可能退信或無人監看。此處的驗證應視為對您即將貼入 HTML 的內容進行的格式檢查,而非地址可用的證明。
| 接受 | 拒絕 | 原因 |
|---|---|---|
| [email protected] | name@localhost | 不接受單一標籤主機 |
| [email protected] | [email protected] | 本機部分前置點 |
| [email protected] | [email protected] | 不接受 IP 字面值 |
| name@bücher.example (IDN) | name@@domain.tld | 重複的 @ 字元 |
| [email protected] | "quoted"@domain.tld | 不支援帶引號的本機部分 |
此方法的侷限
實體編碼是混淆,不是安全性。開啟渲染後頁面的人類訪客會清楚看到地址。有能力的爬蟲可以解碼數值字元參考、解析 DOM、走訪錨點的 href,並在單次處理中擷取 mailto 目標。任何點擊連結或從瀏覽器狀態列複製連結的人都會看到解析後的地址,接著就會成為其所用用戶端的囊中之物。
此工具並不保證能減少垃圾郵件,也絕不應視為存取控制。如需有意義的防濫用效果,既有的防禦措施仍然適用:帶有驗證、限流與垃圾郵件過濾的伺服器端聯絡表單;可輪換的可丟棄角色地址(例如 info@ 或 contact@);信箱提供者控制項(例如自訂規則、別名和挑戰回應);以及絕不在公開渲染的頁面中嵌入秘密地址、憑證或私人別名。
依賴 JavaScript 的地址注入是另一種模式,而本工具刻意避開。在執行階段透過 String.fromCharCode 解碼地址,可能會在腳本停用時失敗、與嚴格的內容安全政策衝突,並增加靜態 HTML 不需要的不穩定因素。數值參考讓結果保持為普通 HTML,任何瀏覽器都能在不執行程式碼的情況下渲染,這也是為什麼輸出在各種檢視器之間可重現且易於在原始碼控制中稽核。
發佈後驗證實際運作的錨點
在實務上,複製貼上步驟是純實體錨點最常失敗的地方。範本可能在儲存時將 & 重寫為 &;CMS 可能因為所見即所得編輯器將 HTML 視為內容而解碼實體;電子郵件式編輯器可能會將標點符號正規化。請以發佈後的頁面(而非編輯器預覽)作為事實來源。
在私密視窗中開啟實際 URL,檢視原始碼,確認 @ 符號與點字元仍然以數值參考編碼。點擊連結一次,確認郵件用戶端收到預定地址。如果原始碼顯示普通字元,則混淆效果已消失,該頁面現在只是一個普通的 mailto 連結,原始碼並無遮蔽。請在範本中替換該欄位,以確保未來的編輯能保留實體。
若要深入了解編碼本身以及純實體錨點的結構,電子郵件地址編碼器指南從頭到尾涵蓋了相同的技術。若要回到上述產生錨點的工具,請開啟電子郵件地址混淆器,輸入公開地址,然後將產生的錨點直接複製到您的 HTML 原始碼中。
如需更深入的說明,請參閱Apache 2.4 的窄化 htaccess 產生器替代方案。