Email Address Obfuscator（電子郵件地址混淆器）會產生單一 HTML 錨點元素，其可見文字與 mailto 目標全部以十進位數值 HTML 字元參考寫成，在渲染後的原始碼中不會留下任何字面意義的地址字元。本地端部分、@ 符號以及正規化後網域的每個碼位都會成為像 a 這樣的參考（用於小寫 a），瀏覽器在顯示頁面時會解碼，而基本的純文字爬蟲可能會忽略，因為原始碼中已不再包含可辨識的地址樣式。輸出是一個錨點元素，原樣複製到受控的 HTML 原始碼環境中，而非可能會在儲存時重寫實體的所見即所得欄位。整個處理流程都在瀏覽器內完成，不會上傳任何內容，沒有伺服器會檢查郵件信箱，而產生的原始碼僅包含實體參考與 mailto: 前綴。本速查表詳細說明輸出的確切格式、決定工具接受哪些地址的驗證規則、判斷混淆是否適合您網頁的限制，以及在您貼上與訪客載入頁面之間，可能悄悄撤銷混淆效果的 CMS 與編輯器重寫行為。
產生之錨點的輸出結構
單次執行的結果是一個單獨的錨點元素。在 href 內部，常值字串 mailto: 後面接著地址，地址的每個碼位都以十進位數值字元參考寫成。在可見文字內部也適用相同規則，因此訪客看到的是真實地址，而非實體本身。若地址為 [email protected]，連結目標看起來會像 mailto:info@example.com，瀏覽器解碼後，可見文字會解析為同一字串。不需要 JavaScript 在執行階段組合地址，沒有 document.write 呼叫會在點擊時重建 mailto，也沒有 CSS 偽元素將地址從原始碼中取出。單一錨點就是完整的輸出，這種簡單性正是它能在停用指令碼的瀏覽器中運作，並在禁止內嵌指令碼的內容安全政策下生效的原因。十進位數值字元參考格式本身，與 HTML 現行標準為一般標記中的字元參考所記載的格式相同，這就是為何每個符合標準的瀏覽器解碼結果完全一致，無需任何自訂解析。
對於像 [email protected] 這樣含有加號的地址，加號會編碼為 +，其餘遵循相同規則，因此一旦瀏覽器解碼頁面，產生的錨點行為與使用常值字元所撰寫的錨點完全相同。該錨點仍可點擊，會以正確收件者開啟設定的郵件用戶端，並能從渲染後的頁面複製貼上，因為可見文字就是實際的地址。
驗證規則：接受與拒絕的格式
此工具刻意只驗證單一格式，並拒絕該格式以外的所有輸入。一個接受所有 RFC 5322 格式的寬鬆驗證器會誤導使用者對支援範圍的認知，因此契約範圍狹窄且明確。本地端部分不得為空，不得以點開頭或結尾，不得包含連續點，且不得包含空白字元或控制字元。網域必須包含多個標籤，不得包含空白字元，並會經過小寫處理後傳遞給瀏覽器的 URL 主機解析器。國際化網域會序列化為 ASCII 相容形式，使輸出在不同瀏覽器間保持一致。IPv4 常值與單一標籤主機會遭到拒絕，因為本頁面是針對一般公開網站地址所設計，而非專門系統所允許的每一種信箱語法。
| 地址格式 | 狀態 | 原因 |
|---|---|---|
| [email protected] | 接受 | 標準未加引號本地端，多標籤網域 |
| [email protected] | 接受 | 本地端支援加號標記 |
| [email protected] | 接受 | 保留本地端大小寫，網域轉為小寫 |
| [email protected] | 接受 | 含子網域的多標籤網域 |
| info@bücher.example | 接受 | 國際化網域序列化為 ASCII 相容形式 |
| [email protected] | 拒絕 | 本地端開頭有點 |
| [email protected] | 拒絕 | 本地端包含連續點 |
| info@@example.com | 拒絕 | 超過一個 @ 字元 |
| info@example | 拒絕 | 單一標籤網域 |
| info@[192.0.2.1] | 拒絕 | 不支援 IPv4 常值 |
| "quoted"@example.com | 拒絕 | 不支援加引號的本地端部分 |
| info@ example.com | 拒絕 | 地址中任何位置出現空白字元 |
這種狹窄範圍就是契約。若您的地址未通過驗證器，通常的修正方式是改用未加引號的格式、正規化網域大小寫，或移除一個本就不適合用於公開聯絡連結的加引號本地端語法。此工具不會測試信箱是否存在或能否接收郵件；它僅檢查該格式是否符合一般公開聯絡地址。被拒絕並不代表地址在某種絕對意義上無效；它代表語法落在本頁面實際服務的子集之外。
逐步使用工具的方法
- 開啟 Email Address Obfuscator，輸入您想要發布的公開聯絡地址。請使用您會原樣發布在聯絡頁面上的形式，而非內部別名、不希望曝光的角色地址，或任何類似憑證的內容。
- 點擊產生動作。工具會去除空白字元、驗證狹窄的未加引號格式、將網域轉為小寫、透過瀏覽器的 URL 主機解析器處理網域，並在您的瀏覽器中本機產生錨點元素。不會有任何請求離開此頁面。
- 複製完整的錨點元素。從開頭的 <a 一直選到結尾的 </a>，讓 href 與可見文字一起移動。請勿將其貼到可能自動格式化或清理 HTML 的所見即所得編輯器，也不要貼到會在您輸入時轉換字元的 WYSIWYG 欄位。
- 將錨點貼到接受原始 HTML 的 HTML 原始碼範本、靜態檔案編輯器或 CMS 欄位中。頁面應僅在此步驟之後才會發布到實際的 URL。
- 在瀏覽器中開啟已發布的頁面，確認可見文字與您輸入的地址相符，並點擊連結一次以確認郵件用戶端收到預期的收件者。
- 檢視已發布頁面的原始碼，確認實體仍然保持為實體。若 CMS 已將 a 重寫回 a，則混淆效果已消失。若 CMS 已將實體內部的 & 重寫為其他參考，訪客可能會看到像 i 這樣的實體文字，而非其所代表的字母。
真正重要的硬性限制
此工具會在結果旁標示單一限制，而該限制是每個誠實的電子郵件混淆器所共有：混淆並非安全機制。速查表版本的事實是一個小型參考表，列出輸出的能與不能，因為電子郵件混淆器不應製造虛假的安全感。
| 能力 | 是或否 |
|---|---|
| 阻擋基本純文字樣式爬蟲 | 視情況而定，取決於爬蟲 |
| 阻擋會解析 HTML 並解碼實體的爬蟲 | 否 |
| 阻擋會循著 mailto 連結的爬蟲 | 否 |
| 阻擋會渲染頁面並讀取 DOM 的爬蟲 | 否 |
| 減少信箱的垃圾郵件 | 無法保證 |
| 作為存取控制或隱私保護 | 否 |
| 需要伺服器處理 | 否，僅在瀏覽器內運作 |
| 在所有 HTML 原始碼環境中皆能存活 | 否，部分 CMS 欄位會重寫實體 |
| 驗證信箱是否存在 | 否 |
搜尋結果或社群預覽所關注的每個現代爬蟲，都會解析 HTML、解碼數值字元參考，並檢查渲染後的 DOM。點擊連結、複製連結或將游標懸停以讀取目標的訪客也會看到地址。任何您不希望謹慎的訪客或有能力 bot 知道的內容，都不應是通過此工具的字串，而啟動連結的訪客會看到設定的郵件應用程式開啟並填入地址。若要更深入了解僅含實體的錨點格式本身，Email Address Encoder 指南會從編碼角度探討相同的錨點結構。
剝除實體的 CMS 與編輯器陷阱
最常見的失敗模式並非出現在工具中，而是出現在發布步驟。編輯器與內容管理系統例行會將收到的 HTML 正規化，而這種正規化正是撤銷混淆效果的操作。會透過 DOM 解析器往返處理內容的所見即所得編輯器，會在儲存時將 a 替換為常值字元 a，因為對解析器而言，實體與字元是等價的。頁面可能正確渲染，但原始碼已不再符合您複製的混淆片段，地址會以純文字形式重新出現在發布後的 HTML 中。
會清理輸入的欄位可能會拒絕實體、將 & 符號逸出為像 & 這樣的不同參考，或移除 mailto: 前綴。在此情況下，混淆在標記中存活，但連結本身已無法開啟郵件用戶端，訪客會看到損壞的連結，或在應為字母的位置看到像 i 這樣的可見實體文字。防禦之道在於驗證。發布後，請在瀏覽器中檢視實際頁面的原始碼，搜尋您預期編碼的常值地址字元，並點擊該連結。若常值字元存在，表示 CMS 已解碼實體。若連結損壞或可見文字顯示實體代碼，表示清理器重寫過於積極。無論哪種結果，都代表混淆未能在發布後存活，修正方式在於發布步驟而非工具本身。
混淆處理 vs 真正的防護
當頁面本來就需要一個可點擊的聯絡地址、這個地址本來就會以明文形式公開，而且目標只是為簡單的爬蟲增加一層薄薄的摩擦、又不想增加伺服器依賴時，混淆器就是正確的選擇。但當地址屬於私人性質、需要有意義地減少垃圾郵件、或涉及存取控制時，混淆器就不是合適的選擇。當訪客點擊、複製連結或檢查渲染後的 DOM 時，Mailto 連結可能會暴露地址，而且它們可能會啟動已設定的郵件應用程式，因此輸入內容絕對不應該是秘密地址、憑證或私人別名。
若要建立有意義的防護，實際的做法組合是：含有輸入驗證、速率限制以及您平台所提供的垃圾郵件控制機制的伺服器端聯絡表單；一個可以在開始收到濫用郵件時進行輪換的角色地址；以及能攔截漏網之魚的郵件信箱服務商過濾器。混淆器應擺在這些措施的前面，而不是取代它們，任何聲稱可以取代這些措施的電子郵件混淆器都不應該被信任。正是這種區隔，使得這個工具會把限制說明直接顯示在結果旁邊，而不是埋在說明文件中。速查表的版本也是一樣的：對公開的聯絡地址使用混淆器以在原始碼層級增加摩擦，而一旦目標從單純造成不便轉變為真正的保護，就應該改用聯絡表單。
發佈前的驗證清單
要快速判斷混淆處理是否真的已經生效，最快的方法就是對實際上線的網址執行一段簡短且可重複的檢查。請在瀏覽器中開啟已發佈的頁面，然後檢視其原始碼並搜尋您地址的逐字字元；如果搜尋得到，代表實體參考在存檔時已經被解碼，混淆處理也就失效了。點擊連結一次，確認郵件用戶端能正確開啟並帶有正確的收件者；如果地址缺失或錯誤，那就是消毒器對 & 符號過度跳脫、或移除了 mailto 前綴最明顯的症狀。將滑鼠移到連結上，查看瀏覽器所顯示的目標；可見的錨點文字與 mailto 目標都應該解碼為您當初輸入的同一個地址。最後，從渲染後的頁面（而非原始碼）重新複製地址並使用一次；如果這個來回過程的結果與您原本輸入的一致，那麼無論底層原始碼看起來如何，訪客體驗都是正確的。這些檢查都不需要特殊工具，但結合起來就能夠抓出所有會默默把工具剛才為您完成的工作復原的 CMS 行為。