電子郵件混淆器的安全性，就像傳單上印的電話號碼一樣：對一般訪客仍可點擊，可能會減慢只掃描原始 HTML 來尋找明顯地址模式的簡易爬蟲，但對於能解碼 HTML、讀取渲染後的 DOM 或追蹤 mailto 連結的爬蟲，幾乎沒有任何作用。電子郵件地址混淆器會將一個經過驗證的地址轉為單一 HTML 錨點，其可見文字與 mailto 目標皆使用十進位數字字元參考，例如字母 a 會以 a 表示。可見標籤與 href 中的每個字碼點都經過編碼，因此明顯的地址字元絕不會出現在您的頁面原始碼中。所有處理皆在本機瀏覽器中進行，您所輸入的地址不會被上傳。這屬於混淆而非安全性，工具會在結果旁邊標示此限制，以免造成虛假的安全感。請將其視為一層摩擦阻力，絕非存取控制，也絕不要在任何 mailto 連結中嵌入機密別名、憑證或私人信箱。
「安全」對電子郵件混淆器而言究竟意味著什麼
搜尋這組關鍵字的多數讀者，通常想一次釐清兩件事：混淆器本身是否會洩漏其地址，以及混淆後的輸出在公開頁面上是否真的能持續保持隱藏。兩個問題都需要直率的答案，而非空泛的保證。
在「您輸入的內容不會離開您的裝置」這個意義下，此工具是安全的。編碼透過頁面上的 JavaScript 進行，因此處理程序僅限於瀏覽器內部。這個部分的答案簡潔明瞭。
較困難的部分在於其輸出在您已發布頁面上的表現。經實體編碼的 mailto 錨點能擋下最粗心的收集器，也就是那些只從原始 HTML 中尋找「某字串@某字串」模式來進行擷取的程式。但它無法擋下任何稱職的爬蟲，因為數字參考只是一種標準、具決定性的編碼方式，任何 HTML 解析器都會將其還原為文字。此產品的合約對此坦承不諱：它明確指出，現代爬蟲能夠解析 HTML、解碼數字實體、檢查 DOM 並追蹤 mailto 連結，且此技術並未承諾能減少垃圾郵件。
混淆器能與不能隱藏的內容
將常見技巧並列比較，能讓取捨更易於理解。下表依據十進位數字字元參考的行為（依 WHATWG HTML 字元參考規範所定義），針對網站擁有者真正關心的面向來比較各方法。
| 技巧 | 能擋下純文字模式爬蟲 | 能擋下會渲染 DOM 的爬蟲 | 對一般訪客仍可點擊 |
|---|---|---|---|
| HTML 中的明顯地址 | 否 | 否 | 是 |
| 數字實體錨點（本工具） | 通常是，因為沒有明顯的模式可匹配 | 否，實體在渲染時會被解碼 | 是 |
| 於執行階段以 JavaScript 組裝連結 | 是，當指令碼被阻擋時 | 否，當指令碼執行時 | 僅在啟用 JavaScript 時 |
| 伺服器端聯絡表單 | 是，地址從未出現 | 是 | 訪客填寫表單而非點擊 mailto |
中間兩列最值得注意。JavaScript 組裝能擊敗不執行指令碼的爬蟲，但當訪客關閉 JavaScript、當內容安全策略阻擋行內指令碼、以及當搜尋引擎看到的頁面要等到 JS 執行後才有內容時，它就會失效。這正是電子郵件地址混淆器採用靜態數字參考而非動態組裝的原因：產出為純 HTML，可在任何瀏覽器中解碼，同時也容易被任何稱職的爬蟲還原。此工具刻意選擇較簡易的編碼方式，並以淺白易懂的方式提醒您其後果。
如何在使用電子郵件地址混淆器時不喪失混淆效果
最安全的工作流程既簡短又幾乎機械化。請將每個步驟視為合約的一部分：若您略過最後的驗證，您其實並未真正發布一個混淆後的連結，而只是抱持著「應該有」的希望。
- 在電子郵件地址混淆器頁面的表單中輸入公開的聯絡地址，然後點擊產生。輸出結果為一組完整的錨點元素；請將整段內容（含開頭的 <a 與結尾的 </a>）複製下來。
- 以原始 HTML 原始碼形式開啟頁面範本。富文字編輯器可能在您貼上的瞬間，悄悄將實體解碼回明顯字母，因此請直接編輯檔案，或將編輯器切換為程式碼檢視。
- 將錨點貼在地址應出現的精確位置。不要將其切割至不同的區塊，也不要將可見文字放在某個欄位、href 放在另一個欄位；編碼僅保護位於錨點元素內部的內容。
- 透過同一套可讓您編輯 HTML 的內容管理系統來儲存並發布。若您的 CMS 提供程式碼或文字模式，請在此特定步驟使用該模式。
- 使用一般瀏覽器開啟已發布的頁面，在連結上按右鍵，選擇「複製電子郵件地址」（若有此選項），並確認剪貼簿內容與您所輸入的一致。
- 於瀏覽器中檢視上線頁面的原始碼，並搜尋地址的片段。您應會看到諸如 a 的數字實體，而非明顯字母。若原始碼顯示的是真實字母，表示混淆效果已經消失。
- 點擊該連結一次，確認您的郵件用戶端已開啟並預先填入正確的收件者。
上述步驟中有兩個步驟承擔了主要工作：貼入 HTML 原始碼而非富文字欄位，以及驗證已發布的原始碼。其餘皆屬衛生措施，用以捕捉 CMS 代您犯下的小錯。
悄悄破壞混淆效果的 CMS 陷阱
以為自己已設定好混淆地址的發布者，往往在數月後才發現，他們的 CMS 已重寫頁面並以明文形式曝露了地址。最常見的失敗模式既可預期，也值得明確點出。
不認得數字實體的 WYSIWYG 編輯器，會在您首次儲存時把 a 解碼為 a。頁面仍能正確渲染，這讓此種退化若非重新檢查原始碼便難以察覺。某些無障礙或「清理 HTML」外掛也會基於整潔標記的目的做出同樣行為。其他系統則會反向操作，對 & 進行雙重跳脫，將 a 變成 a，使其在畫面上顯示為明顯字串「a」而非字母 a。內建短代碼處理器若重寫不熟悉的標籤，也可能移除 href 看起來不尋常的錨點。
解決之道屬於流程而非技術層面。請以處理自訂短代碼的相同方式來處理經實體編碼的錨點：僅貼入 HTML 原始碼檢視、為該區塊停用任何「格式化 HTML」切換、並在每次 CMS 或外掛更新後重新驗證上線原始碼。對這些輸出規則與 CMS 失敗模式的深入探討，請見 電子郵件混淆器速查表，每當您的發布架構變更時，都值得再讀一次。
當您需要比混淆更強的保護時
當您擁有公開的聯絡地址、不介意任何人最終讀取其內容，且希望減少最低成本的爬蟲時，混淆是合適的工具。當您需要真正的隱私、真正的速率限制，或對誰能寄達您的收件匣有任何保證時，它便是錯誤的工具。
若要具備有意義的抗濫用能力，請將伺服器端聯絡表單置於您保持私密的信箱之前。表單可驗證輸入、節流提交、記錄嘗試並套用垃圾郵件過濾，這些都是 mailto 錨點無法做到的。再搭配一個可丟棄的角色地址，以便在不更動頁面的情況下輪換收件目的地，然後再加上信箱層級的過濾規則與供應商端的濫用回報機制，以涵蓋其餘面向。
電子郵件地址混淆器做出了刻意且範圍明確的承諾：為您願意公開發布的地址提供原始碼層級的隱蔽性。它並未承諾減少垃圾郵件，也未承諾隱私，任何工具頁面若宣稱相反，都是不妥的。請在合適的地方使用它，在威脅模型屬實之處改用聯絡表單，並在每次 CMS 更動時驗證已發布的原始碼。
若想獲得更深入的探討，請參閱 結構化資料標記產生器安全嗎？誠實的限制。