公開網站上的「特殊」電子郵件地址，是指在錨點元素內部，所有可見字元都被十進位數字 HTML 實體取代的地址，因此渲染後的頁面仍然顯示一個可點擊的聯絡連結，而底層原始碼中則不包含任何可供簡易擷取器複製的明顯地址字元。這項技術仰賴一個事實：瀏覽器在渲染時會將像 a 這類字元參考解碼為字母 "a"，而掃描原始碼中 [email protected] 模式的基本擷取器，只會看到一串編號實體。其結果是任何現代瀏覽器都能正確顯示的普通、可點擊 HTML，同時刻意讓訪客看到的內容與純文字收集器能擷取的內容之間產生落差。無論是可見文字還是 mailto 目標中，每個 Unicode 碼位都會被取代為參考字串，例如 @ 代表 @ 符號、. 代表句點，因此對任何搜尋明顯地址格式的工具來說，產生的原始碼讀起來就像一連串不中斷的 &、# 與數字。
公開網址中「特殊」的含義
在公開網站上，「特殊」電子郵件地址是指對真人訪客顯示正確，但在 HTML 原始碼中不儲存任何明顯地址字元的電子郵件地址。可見連結能正常運作，是因為瀏覽器即時解碼數字參考，而底層標記只包含參考、數字與 & 符號。這是一種刻意的取捨：普通的聯絡連結會嵌入任何訪客都能複製的明顯 mailto 地址，任何爬蟲當然也能複製。實體編碼版本則以少量的原始碼複雜度，換取最簡易的收集器可能完全忽略該模式的機會。
聯絡連結仍可點擊，底層語法仍是符合標準的 HTML，點擊後仍會啟動設定好的電子郵件應用程式。對看到連結並點擊的訪客來說，使用體驗完全沒有改變。改變的是瀏覽器收到的原始碼：標記中不再出現 "[email protected]"，而是一串數字參考。HTML 規格將這些數字字元參考定義為使用者代理必須在顯示前解碼的普通文字，這正是這項技術能在維持相同視覺效果的同時，改變原始碼實際內容的原因。
為何數字實體能阻擋純文字擷取器
特殊電子郵件地址的防禦價值，建立在廉價擷取器的工作方式上。最常見的電子郵件收集器會對原始碼執行簡單的正規表示式模式，比對像 [email protected] 這類形狀。如果原始碼中不存在這些字元，正規表示式就找不到任何東西。將每個碼位取代為十進位參考，能從標記中移除明顯的模式，同時讓渲染結果維持不變。
這是模糊化，而不是加密。有能力的爬蟲可以解碼實體、檢查 DOM、追蹤 mailto 連結，或執行 JavaScript 來讀取解析後的地址。因此，這項技術能提高最簡易機器人的收集成本，卻無法阻止任何下定決心的人。這項限制應與結果並列顯示在任何產生此類輸出的工具上，發布這類連結的人也必須予以正視。
實務上也偏好使用十進位實體而非其他替代方案有其理由。以 JavaScript 組合地址的方式，在關閉指令稿時會失敗，可能與嚴格的內容安全政策衝突，並增加需要維護的環節。純粹的數字參考能讓結果維持為普通 HTML，即使在無指令稿的瀏覽器上也能正常渲染。根據 WHATWG HTML 規格中關於字元參考的章節，十進位數字字元參考是核心解析模型的一部分，會在標記化過程中解碼，這正是讓產生的頁面能與一般 mailto 連結渲染結果完全相同的原因。
如何逐步建立特殊的電子郵件地址
整個任務可以用三個明確的步驟完成。每一個步驟都很重要，因為任何階段出錯都會在無聲無息中破壞混淆效果。
- 將公開聯絡地址輸入電子郵件地址混淆工具。在輸入欄位中輸入地址，並在瀏覽器本地產生錨點。該工具會先正規化網域、將其轉為小寫，透過瀏覽器 URL 主機解析器處理地址，並將國際化網域序列化為其 ASCII 相容形式，然後才輸出結果。不會上傳任何資料，您取得的原始碼中完全不含明顯的地址字元。
- 將完整的錨點複製到 HTML 原始碼範本中。在原始 HTML 檢視模式（而非所見即所得編輯器）中開啟檔案或範本。許多所見即所得編輯器在存檔時會解碼實體，這會重新引入明顯字元，在頁面送達瀏覽器之前就破壞混淆效果。
- 開啟發布後的頁面並驗證結果。檢視渲染後的頁面，確認可見文字是您預期的地址，點擊連結一次以驗證郵件用戶端收到正確的目標，並檢查頁面原始碼以確認您的內容管理系統沒有解碼或重複跳脫實體。如果內容管理系統在發布時將實體參考還原成明顯字母，混淆效果就會消失。
電子郵件地址混淆工具會產生一個錨點元素，可見文字與 mailto 目標都經過完整的實體編碼，因此通常只需一次貼上即可在公開頁面上部署這種特殊形式的連結。
驗證器會接受與不會接受的內容
驗證器的接受範圍刻意比完整的電子郵件標準更窄。它接受一個實用的未引號地址格式：包含一個 @ 符號、本地部分不為空、網域包含多個標籤，且不含空白字元或控制字元。本地部分中位於開頭、結尾或連續的句點會被拒絕。本地部分保留原始大小寫與支援的標點符號，網域則轉為小寫並通過瀏覽器 URL 主機解析器處理，國際化網域會序列化為 ASCII 相容形式，讓輸出在各種瀏覽器之間都能重現。
| 輸入格式 | 驗證器決定 | 原因 |
|---|---|---|
| [email protected] | 接受 | 實用的未引號聯絡地址 |
| [email protected] | 接受 | 本地部分支援加號標籤地址 |
| [email protected] | 接受 | 支援多層網域標籤 |
| name@localhost | 拒絕 | 單標籤主機不是公開地址 |
| [email protected] | 拒絕 | 不在處理範圍內的 IPv4 字面值 |
| "quoted local"@domain.com | 拒絕 | 刻意不支援引號內的本地部分 |
| na [email protected] | 拒絕 | 任何位置都不允許空白字元 |
這種嚴格的規範是為了避免讓使用者誤以為驗證器很寬鬆，產生錯誤的信任感。本頁面適用於一般公開網站的地址，而非特殊系統所允許的所有信箱語法。如果您的輸入被拒絕，最常見的原因包括：單標籤主機（請使用真實網域）、引號內的本地部分（請使用未引號的形式），或是 IPv4 字面值（請使用主機名稱）。此工具不會測試該信箱是否存在或能否接收郵件，因此即使編碼成功，仍可能在實際寄送時退信。
發布前必須正視的限制
混淆不是安全防護。工具本身在結果旁標示了這項限制，因為電子郵件混淆工具不應製造虛假的安全感。公開渲染的地址對訪客與有能力的機器人來說仍然可被發現，以下幾項具體限制正是源自這個事實。
| 問題 | 誠實的回答 |
|---|---|
| 這能阻止垃圾郵件機器人嗎？ | 無法保證。基本的純文字比對可能會忽略它；現代爬蟲能解碼實體並檢查渲染後的連結。 |
| 此工具會驗證該信箱是否存在嗎？ | 不會。它只驗證狹義的地址格式並產生 HTML，不會寄送郵件或查詢伺服器。 |
| 連結仍可點擊嗎？ | 可以。瀏覽器在渲染時會解碼實體，mailto 目標會啟動設定好的電子郵件應用程式。 |
| 內容管理系統會保留編碼嗎？ | 只有在貼入原始 HTML 時才會。在存檔時解碼實體的所見即所得編輯器會破壞混淆效果。 |
| 嵌入秘密地址是否安全？ | 不安全。請勿嵌入秘密地址、憑證或私人別名；mailto 連結會將地址暴露給任何點擊、複製或檢查 DOM 的人。 |
若要真正抵擋濫用，請使用伺服器端聯絡表單，搭配驗證、速率限制與適當的垃圾訊息防護。可拋棄式角色地址、信箱服務商提供的過濾規則，以及以表單為基礎的接收層，都比單獨使用實體編碼提供更實用的防禦。僅在您能接受輕量級原始碼模糊化、且該地址本就預計公開時，才使用特殊的電子郵件地址。
何時選擇混淆而非聯絡表單
是否在頁面上發布可點擊的 mailto 地址，與是否對其進行混淆，是兩個獨立的決定。聯絡表單能完全將地址從頁面中移除，並將防禦集中在伺服器端。當目標是讓人類仍可看到並複製直接連結，同時讓最廉價的工具更難收集明顯模式時，特殊的電子郵件地址就很合適。這種取捨適用於聯絡頁、作品集頁、活動講者介紹、會議網站等地址本來就屬於公開資訊的場景。
如果您尚未串接基本的 mailto 錨點，並想取得該步驟更完整的操作說明，可以參考 如何逐步建立電子郵件地址連結 指南，內容涵蓋基礎連結語法。本篇文章則聚焦於更狹隘的任務：產生該連結的實體編碼版本，也就是「特殊」一詞所指的格式。
當您希望地址保持可見且可點擊，同時偏好讓明顯字元不出現在頁面原始碼中時，請選擇本工具。當首要考量是防止自動化濫用，且能將提交導向受控端點時，請選擇聯絡表單。許多網站同時採用兩者：對偏好直接回覆的訪客提供混淆後的 mailto 連結，對其他訪客則提供聯絡表單。
延伸閱讀：如何寄信給州務卿：找到該單位的地址。
<