線上使用電子郵件地址混淆器安全嗎？

電子郵件地址混淆器在線上使用時，只有在目的是進行輕度的來源碼模糊處理時才算安全，並不適合用來保證防止垃圾郵件或保護私人地址。在公開聯絡頁面上，這兩者的差別很重要。電子郵件地址混淆器會在瀏覽器中進行處理，並將可見地址及 mailto 目標中的每個字元代碼點轉換為十進位數值的 HTML 字元參考。產生的來源碼不包含任何明文地址字元，因此，只搜尋一般地址格式的簡易擷取程式可能會漏掉它。這是它有效的地方，但也是它的極限。瀏覽器會解碼這些參考以供顯示，因此地址仍可見且可點擊。現代爬蟲可以解析 HTML、解碼數值實體、檢查 DOM，或追隨 mailto 連結。訪客可以複製連結或檢查算繪頁面來還原地址。此工具不保證能減少垃圾郵件。如果只需要適度的來源碼模糊處理，它適合用於公開聯絡地址；但不適合秘密信箱、認證資訊、私人別名，也不適用於任何存取控制的主張。當防止濫用很重要時，請使用具備驗證、速率限制及適當垃圾郵件控制的受保護伺服器端聯絡表單，然後在實際發布的頁面上驗證該表單。

安全性取決於發布情境

安全與否取決於你發布的內容，以及你希望編碼能防止什麼。公開的商務聯絡資訊與私人登入身分不應被視為相同。

使用情境	實務結論	原因
需要輕度來源碼模糊處理的公開聯絡地址	合理，但預期應限於有限範圍	它可能避開基本的明文比對，但算繪後的地址仍可被找到。
秘密信箱、私人別名或認證資訊	不要發布	混淆既不是隱私保護，也不是存取控制。
防止大量垃圾郵件	單獨使用並不足夠	現代爬蟲可以解碼實體、檢查 DOM，並追隨 mailto 連結。
供一般瀏覽器使用的可點擊聯絡連結	適合	數值參考會算繪成一般文字，同時保留標準 mailto 錨點。

對於公開地址而言，如果目標是避開簡單的明文格式，同時保留一般的點擊寫郵件體驗，這種方法是合理的。它不會建立安全邊界。如果目標是阻止蓄意收集地址或讓信箱無法被使用，受保護的伺服器端表單會是更好的主要控制方式。

僅使用實體的 mailto 錨點如何運作

此工具會在單一錨點元素內，將可見地址以及完整 mailto 前綴與地址中的每個 Unicode 字元代碼點輸出為十進位數值的 HTML 字元參考。例如，小寫字母 a 在來源碼中寫成 a，算繪後顯示為 a。可見標籤與 href 都會經過編碼，因此一般瀏覽器仍會呈現可讀且可點擊的連結。

十進位字元參考屬於標準 HTML 解析行為，如 WHATWG HTML 字元參考規則所述。與以 JavaScript 為基礎的注入方式不同，產生的錨點不依賴指令碼執行，也避免增加指令碼及內容安全政策可能造成的失敗點或額外變動環節。但這仍然不是加密：編碼很容易還原，技術純熟的爬蟲也能解碼。

處理會留在瀏覽器中，因此轉換本身是在本機進行。這並不會讓發布的地址變成私人地址。瀏覽器解碼後，可見的聯絡地址仍可供訪客及具備相應能力的機器人存取。

產生並發布錨點

請將此工作流程用於公開聯絡地址，並在實際發布的頁面上完成每個驗證步驟。

1. 輸入公開地址。開啟電子郵件地址混淆器，輸入你打算發布的地址。此工具會去除周圍空白，並在產生錨點之前，依其實務上未加引號的電子郵件格式驗證地址。
2. 產生並複製完整元素。在本機產生使用數值實體的 HTML 錨點，然後複製整個錨點元素。不要只複製經過編碼的可見文字，也不要手動重建 href，因為完整輸出同時包含可讀連結與經過編碼的 mailto 目標。
3. 使用 HTML 來源碼情境。將完整錨點貼入 HTML 來源碼範本，而不是富文字編輯器。富文字欄位可能會立即算繪這些實體，或在儲存頁面前改寫它們。
4. 開啟實際發布的頁面並進行檢查。檢查頁面來源碼，確認數值參考仍然存在，且未出現明文地址。點擊連結一次，確認設定的電子郵件應用程式會收到預期地址。
5. 必要時使用更強的保護。如果頁面面臨顯著的濫用或資料收集風險，請使用受保護的聯絡表單，不要將混淆後的連結當成安全邊界。

發布後檢查線上頁面

請檢查最終的公開輸出，不要只信任複製的程式碼片段。內容管理系統、範本或發布步驟可能會在錨點離開工具後解碼實體、進行雙重逸出，或以其他方式變更錨點。

• 檢查實際發布的來源碼：確認可見文字與 href 仍使用數值參考，且來源碼未包含任何明文地址字元。檢查 CMS 沒有解碼實體或對實體進行雙重逸出。
• 檢查算繪結果：頁面應顯示預期地址，而不是實體代碼之類的字元序列。連結應保持明顯可點擊。
• 測試 mailto 連結：點擊一次，並在開啟的電子郵件應用程式中驗證目的地。mailto 連結可能會啟動訪客所使用的任何已設定應用程式。

如果 CMS 將經過編碼的 at 符號轉回明文 at 符號，來源碼混淆就會消失。如果它改寫參考中的 ampersand，訪客可能會看到實體文字，而不是地址。每次 CMS 或範本變更後，都應驗證真正的公開頁面，不要只依賴複製的程式碼片段。

影響完成的輸入規則

驗證器的範圍刻意比完整的電子郵件標準更窄。其支援的子集是為一般公開網站聯絡地址而設計，因此部分在技術上有效的信箱格式會遭到拒絕。

輸入或行為	電子郵件地址混淆器規則
地址邊界	驗證前會去除地址周圍的空白。
本機部分	要求本機部分非空且未加引號。開頭、結尾及連續的點號均會被拒絕。原始大小寫及支援的標點符號會保留。
At 符號	要求剛好有一個 at 符號。
網域格式	要求網域包含多個標籤。單一標籤主機及 IPv4 位址常值會被拒絕。
空白與控制字元	包含空白或控制字元的地址會被拒絕。
網域大小寫	網域會轉為小寫，並通過瀏覽器 URL 主機解析器處理。
國際化網域	網域會序列化為其 ASCII 相容形式，以便輸出能跨瀏覽器重現。
複雜信箱語法	不接受加引號的本機部分、註解、網域常值及不尋常的舊式格式。
信箱是否存在	此工具不會測試信箱是否存在或能否接收訊息。

因此，遭到拒絕可能表示不支援複雜語法，而不是信箱不存在。在符合相同實務地址格式規則的前提下，此工具的測試涵蓋加號位址。驗證器既不會傳送郵件，也不會查詢伺服器來確認信箱是否有效。

高風險聯絡資訊應使用更強的控制方式

有效的防濫用能力需要對訊息處理建立控制。請使用具備驗證、速率限制及適當垃圾郵件控制的受保護伺服器端聯絡表單。這能讓目的地信箱不出現在發布頁面的標記中，同時為訊息提供受控的傳送途徑。

如果可點擊的公開地址仍然重要，使用一次性的角色地址可以降低資料收集造成的後果。過濾規則及信箱供應商控制可提供額外的實務防禦。請將任何已發布的角色地址視為可被找到，因為混淆不會改變這個事實。

不要嵌入秘密地址、認證資訊或私人別名。訪客點擊、複製連結或檢查算繪後的 DOM 時，mailto 連結可能會洩漏目的地，也可能會啟動已設定的電子郵件應用程式。只有在輕度來源碼模糊處理是可接受目標時，才使用此混淆器。

如需深入了解，請參閱如何在網站上混淆電子郵件地址。