電子郵件地址混淆器會產生單一 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 | 拒絕 | 地址中任何位置出現空白字元 |
這份狹隘性就是合約內容。若您的地址無法通過驗證，通常的修正方式是改用未加引號的格式、正規化網域大小寫，或捨棄本來就不適合用於公開聯絡連結的引號本地端語法。此工具不會測試信箱是否存在或能否接收郵件;它只檢查格式是否符合一般公開聯絡地址。被拒絕並不代表該地址在絕對意義上無效;它代表該語法落在本頁面所服務的實用子集範圍之外。
如何逐步使用此工具
- 開啟電子郵件地址混淆器，輸入您想發布的公開聯絡地址。請使用您會原樣發布在聯絡頁面上的格式，而不是內部別名、不想公開的角色地址，或任何類似憑證的內容。
- 點擊產生動作。工具會去除空白字元、驗證狹隘的未加引號格式、將網域轉為小寫、透過瀏覽器的 URL 主機解析器處理網域，並在您的瀏器中本地端產生錨點元素。不會有任何請求離開此頁面。
- 複製完整的點元素。從開頭的 <a 一直選到結尾的 </a>，讓 href 與可見文字一起被複製。請勿將其貼到可能會自動格式化或清理 HTML 的所見即所得編輯器，也勿貼到會在您輸入時轉換字元的 WYSIWYG 欄位。
- 將錨點貼到 HTML 原始碼範本、靜態檔案編輯器，或接受原始 HTML 的 CMS 欄位中。頁面應僅在此步驟之後才會到達實際可訪問的 URL。
- 在瀏覽器中開啟已發布的頁面，確認可見文字與您輸入的地址一致，並點擊連結一次以確認郵件用戶端收到預期的收件者。
- 檢視已發布頁面的原始碼，確認實體仍為實體。若 CMS 已將 a 改寫回 a，則混淆效果已消失。若實體內部的 & 被改寫為另一個參考，訪客可能會看到實體文字，例如 i，而不是它所代表的字母。
真正重要的硬性限制
此工具在結果旁邊標示單一限制，而此限制與每個誠實的電子郵件混淆器所共同面對的限制相同:混淆並非安全性。速查表版本將這個事實整理成一張小型參考表，列出輸出能做到與無法做到的事，因為電子郵件混淆器不應製造虛假的安全感。
| 能力 | 是或否 |
|---|---|
| 阻擋基本的純文字樣式爬蟲 | 可能，視爬蟲而定 |
| 阻擋會解析 HTML 並解碼實體的爬蟲 | 否 |
| 阻擋會追蹤 mailto 連結的爬蟲 | 否 |
| 阻擋會渲染頁面並讀取 DOM 的爬蟲 | 否 |
| 減少信箱收到的垃圾郵件 | 不保證 |
| 作為存取控管或隱私保護 | 否 |
| 需要伺服器處理 | 否，僅限瀏覽器 |
| 在每個 HTML 原始碼環境中皆能存活 | 否，部分 CMS 欄位會改寫實體 |
| 驗證信箱是否存在 | 否 |
搜尋結果或社群預覽所關心的每個現代爬，都會解析 HTML、解碼數值字元參考，並檢查渲染後的 DOM。點擊連結、複製連結，或將游標懸停以讀取目標的訪客，也都會看到地址。任何您不希望細心的訪客或有能力的使用者代理程式知道的內容，都不應該是通過此工具的字串，而啟動連結的訪客將會看到設定好的郵件應用程式開啟，並已填入該地址。若想更深入了解僅含實體的錨點格式本身，電子郵件地址編碼器指南會從編碼角度介紹相同的錨點格式。
會剝除實體的 CMS 與編輯器陷阱
最常見的失敗模式並不在工具本身;而是出在發布步驟。編輯器與內容管理系統經常會將收到的 HTML 進行正規化，而這種正規化正好會還原混淆效果。一個會透過 DOM 解析器往返處理內容的所見即所得編輯器，在儲存時會將 a 取代為字面字元 a，因為在解析器看來，實體與字元是等價的。頁面可能正確渲染，但原始碼已不再符合您複製的混淆片段，地址也以純文字形式回到發布後的 HTML 中。
對輸入進行清理的欄位可能會拒絕實體、將 & 符號跳脫為不同的參考(例如 &)，或剝除 mailto: 前綴。在此情況下，混淆雖然存活於標記中，但連結本身已無法開啟郵件用戶端，訪客會看到損壞的連結或顯示為實體文字(例如 i)，而非應該出現的字母。防禦之道在於驗證。發布後，在瀏覽器中檢視實際頁面的原始碼，搜尋您預期已被編碼的字面地址字元，並點擊該連結。若出現字面字元，表示 CMS 已解碼實體。若連結損壞或可見文字顯示為實體代碼，則表示清理器改寫過於激烈。無論是哪種結果，都代表混淆未能在發布後存活，而修正方式應從發布步驟下手，而非工具本身。
混淆處理 vs 真正的防護
當頁面已經需要一個可點擊的聯絡地址、該地址本來就會以明文形式發布，而目標是在不增加伺服器相依性的前提下，為簡易爬蟲加上薄薄一層摩擦阻力時，混淆器是正確的選擇。但當地址屬於私密的、需要有意義的垃圾訊息減少效果，或涉及存取控制時，它就是錯誤的選擇。Mailto 連結可能在訪客點擊、複製連結或檢查渲染後的 DOM 時暴露地址，也可能會啟動已設定的電子郵件應用程式，因此輸入內容絕對不該是機密地址、憑證或私人別名。
若要建立有意義的防護，實務上的堆疊應包含：具備輸入驗證、速率限制及平台所提供垃圾訊息控制功能的伺服器端聯絡表單；一個可在遭受濫用時輪換的角色地址；以及能攔截漏網之魚的信箱服務商篩選器。混淆器應置於這些機制「之前」而非「取代」它們，任何聲稱能取代它們的電子郵件混淆器都不應被信任。正是這樣的分層考量，使得工具將限制說明顯示在結果旁，而非埋入文件中。速查表的版本也是同樣的道理：在公開的聯絡地址上使用混淆器以達成原始碼層級的摩擦阻力，而當目標從「造成不便」轉變為「提供保護」時，就應改用聯絡表單。
發布前的驗證清單
要知道混淆處理是否確實生效，最快的方式是針對線上 URL 進行一段簡短且可重複的檢查。在瀏器中開啟已發布的頁面，然後檢視其原始碼並搜尋您地址的逐字元字串；若搜尋找到了，代表實體參考在存檔時已被解碼，混淆處理便已失效。點擊連結一次，確認郵件用戶端能正確帶出收件者；若地址缺失或錯誤，這是最明顯的症狀，代表清除器對 & 符號過度跳脫，或移除了 mailto 前綴。將游標懸停於連結上並讀取瀏器所顯示的目標；可見的錨點文字與 mailto 目標兩者解碼後，都應等同於您當初輸入的地址。最後，從渲染後的頁面（而非原始碼）重新複製地址並使用一次；若往返結果與您原本輸入的內容相符，那麼無論底層原始碼為何，訪客體驗都是正確的。這些檢查無需任何特殊工具，但合併起來能夠捕捉到所有會悄悄撤銷工具所做工作的 CMS 行為。
想深入了解，請參閱 條碼產生器速查表：格式、位數、輸出。