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