一個乾淨的電子郵件地址範例是一行字串，結合非空白的本機部分、單一 @ 符號，以及多層級的公開網域，且不含空白字元、IP 字面量，或引號語法。本機部分（@ 符號之前的文字）通常用來識別個人、角色或團隊；網域（@ 符號之後的文字）則告訴郵件路由系統訊息應該送往何處；頂級標籤（最後一個以點分隔的段落）會將地址錨定到已註冊的命名空間，例如 .com、.org 或 .gov。常見的範例包括用於一般聯絡的 [email protected]、用於客服的 [email protected]、用於具名聯絡人的 [email protected]，以及在需要使用國際化網域時的 hello@münchen.de。挑選一個清楚的範例是公開聯絡頁面衛生的前半段；後半段則是要確保這個地址在被放到網頁上後，不會在上線的那一瞬間就被自動化郵件爬蟲收刮走。
格式正確的電子郵件地址結構解析
一個乾淨的電子郵件地址範例永遠具有相同的四段式結構：左側非空白的本機部分、單一 @ 符號、多層級網域，以及頂級標籤。本機部分用來識別組織內部的信箱或角色，網域告訴郵件路由系統應該將訊息送往何處，而 TLD 則將地址錨定到一個已註冊的命名空間。本機部分可以包含字母、數字，以及一組少量的標點符號（點、底線、連字號、加號），但不可有前導、結尾或連續的點。網域不區分大小寫，且幾乎一律包含至少兩個以點分隔的標籤。
像 [email protected] 這樣一個實用的範例一次展示了所有限制：本機部分僅含小寫字母，@ 符號只出現一次，網域有三個標籤，且不含任何空白字元。一個只接受這種實用子集的工具，可以避免呈現一個看似正確、卻在頁面渲染那一刻悄悄在邊界案例上失效的寬鬆驗證器。
| 部分 | 所在位置 | 乾淨範例的規則 |
|---|---|---|
| 本機部分 | @ 符號之前 | 字母、數字、點、底線、連字號、加號；不可有前導、結尾或連續的點 |
| @ 符號 | 分隔符 | 僅出現一次 |
| 網域 | @ 符號之後 | 兩個以上以點分隔的標籤；全部小寫 |
| TLD | 最後一個標籤 | 已註冊的公開後綴；不可為 IP 字面量，也不可為單一標籤的主機 |
值得直接複製的常見電子郵件地址範例
以下的範例涵蓋幾乎適用於所有公開聯絡頁面、且能通過嚴格驗證器的格式。請挑選一個符合你想在頁面上公開角色的範例。
| 範例 | 模式 | 使用時機 |
|---|---|---|
| [email protected] | 角色地址 | 一般公開聯絡；經得起人事異動 |
| [email protected] | 角色地址 | 行銷網站上客戶導向的詢問 |
| [email protected] | 角色地址 | 客服與工單分流 |
| [email protected] | 友善角色 | 創作者、自由工作者與獨立專案 |
| [email protected] | 角色地址 | 媒體與新聞記者聯繫 |
| [email protected] | 角色地址 | 招募流程 |
| [email protected] | 必備角色 | 接收垃圾郵件檢舉的標準信箱 |
| [email protected] | 個人地址 | 具品牌的領導層聯絡人 |
| [email protected] | 加號標記 | 將收到的郵件篩選至子資料夾 |
| hello@münchen.de | IDN | 國際化網域範例 |
前七個是角色地址，比個人地址更容易輪替，也能讓整個團隊一起分流處理信箱。第八個是適合 CEO 或創辦人使用的個人地址。第九個使用加號標記來為收到的郵件加上專案標籤，以便規則自動歸檔。第十個展示國際化網域；工具會將其序列化為 ASCII 相容的形式，使輸出在任何瀏覽器、不分頁面託管位置都能重現相同結果。
如果你需要為公開網站做出更審慎的選擇，這份關於為公開網站建立特殊電子郵件地址的指南會更詳細地說明同樣的權衡取捨。
應避免的錯誤電子郵件地址範例
看似有效、但會在嚴謹驗證器上失敗的範例包括：本機部分含有連續點的地址 ([email protected])、完全沒有 @ 符號的地址 (janedoe.example.com)、含有多個 @ 符號的地址 (jane@[email protected])、網域只有單一標籤的地址 (jane@example)，以及夾帶空白字元的地址 (jane @example.com)。以上這些都會被電子郵件地址混淆器的嚴格驗證器拒絕，而這是刻意的設計：一個「接受」它們的寬鬆驗證器，會在頁面發布前給人錯誤的成功感。
網域中的 IP 字面量 (jane@[192.0.2.1]) 也會被拒絕，因為這個頁面是為一般公開聯絡地址所設計，而不是為了處理長尾的舊式信箱語法。不支援引號形式的本機部分 ("jane doe"@example.com)、不解析本機部分中的註解，也會拒絕單一標籤的主機。請將這個嚴格的契約視為一項特性：它能讓輸出可預期，也讓驗證器對其測試範圍保持誠實。
如何使用電子郵件地址混淆器在網頁上顯示公開電子郵件地址
當你手上有一個乾淨的地址之後，下一步就是以純文字爬蟲無法單純在原始碼中搜尋「@」或大致位置正確的「點」就能讀取的方式，將它呈現在頁面上。電子郵件地址混淆器會將可見文字與 mailto 目標都轉為十進制數字 HTML 實體，使最終送出的原始碼完全不含任何字面上的地址字元。
- 開啟電子郵件地址混淆器，並將公開電子郵件地址輸入到輸入欄位中。請使用實用且不加引號的形式，避免本機部分含空白字元或不常見的標點符號。
- 產生錨點連結。工具會將網域標準化為小寫、把國際化網域解碼為其 ASCII 相容形式，並輸出一個錨點元素，其中可見文字與 mailto 目標的每一個字碼點都會變成十進制數字字元參考。
- 將完整的錨點連結複製到剪貼簿。請勿貼到會在儲存時解碼實體的所見即所得編輯器；應直接貼到 HTML 原始檔、模板欄位，或會原樣輸出 HTML 的程式碼區塊中。
- 透過你的 CMS 或模板引擎發布頁面。在瀏覽器中開啟線上頁面，點擊一次可見連結，確認你設定的郵件用戶端收到的是正確無誤的地址，沒有夾帶多餘字元。
- 檢查已發布 URL 的頁面原始碼。確認實體仍然是十進制數字參考，並確認你的 CMS 並未將它們解碼回純文字、再另行重新編碼為另一種跳脫形式。如果託管的 CMS 重寫了實體，那麼混淆效果在上線那一刻就會消失。
- 驗證渲染後的頁面，而非僅驗證片段。同時交叉檢查可見文字、mailto 目標與原始碼，確認這個地址能端到端地被使用。
若需要更深入了解連結程式碼本身，這份逐步說明如何建立電子郵件地址連結的指南會展示周圍的 HTML 內容。
基本混淆失效的時機
這項混淆技術只是一層薄薄的原始碼模糊處理，並非安全邊界。一個能解析 HTML、解碼數字字元參考，或等待 JavaScript 重寫 DOM 的現代爬蟲，會和訪客一樣看到這個地址。當訪客點擊 mailto 連結、複製連結，或檢查渲染後的 DOM 時，mailto 連結同樣會暴露地址，而且點擊的動作本身可能會啟動已設定的郵件應用程式。這個工具並不保證能減少垃圾郵件，也絕不應被視為存取控制或隱私防護。
這個工具所使用的數字字元參考，與 WHATWG HTML 字元參考規範 中所記載的實體相同，瀏覽器便是從中學會如何將這種形式解碼回原本的字碼點。正是這種簡單性，讓任何一個稱職的爬蟲都能輕易進行解碼。
當真正有意義的濫用防護很重要時，務實的防禦手段是伺服器端聯絡表單，搭配驗證、速率限制、蜜罐或 CAPTCHA，以及由郵件服務商在信箱層級執行的篩選。將聯絡表單與像 abuse@ 或 support@ 這類角色信箱搭配使用，就能讓你在不必重寫頁面的情況下輪替目的地。這款混淆器的價值可以總結為：它能阻擋最簡單的純文字爬蟲、讓可見地址保持可點擊，而且除了複製貼上之外不產生任何成本。
檢查已發布的頁面
請將已發布的頁面視為唯一事實來源，而非你複製的片段。檢視線上 URL，確認可見文字如預期顯示，在連結上按右鍵讀取 mailto 目標，並點擊一次以確認郵件用戶端收到的地址正確無誤。如果你看到像 "info@..." 這種實體文字直接以字面形式呈現在頁面上，代表託管的 CMS 重寫了 & 符號，地址已經損壞；請修正模板或改用會輸出原始 HTML 的程式碼區塊。如果原始碼顯示的是純文字 "[email protected]" 而非實體，代表 CMS 已解碼參考，混淆效果已經消失。
請在行動裝置視窗與列印樣式表中執行同樣的檢查，因為有些模板會依據不同的媒體查詢輸出不同的標記。同時，確認你所引用的任何角色式地址都符合適用的相關 RFC 信箱慣例，例如保留給垃圾郵件檢舉的 abuse@ 信箱。當線上頁面通過這些檢查時，代表這個被混淆的錨點已經發揮了它所能發揮的全部作用，下一步就是在它之上再加上一個真正的聯絡表單，以提供超越模糊處理的實質保護。