開發者工具 · URL 編碼器和解碼器
如何對 mailto 進行編碼：與主題、正文換行符和符號的連結
· 為什麼它很重要
郵寄至 url 編碼 html
帶有主題和正文的 mailto: 連結是一個 URL，因此空格、換行符和 & 必須進行百分比編碼。這篇文章展示了哪些情況下它們不會損壞，以及如何建立在郵件用戶端中正確打開的連結。
主題停在第一個空格的聯絡連結 — 一個特定的損壞的 mailto：以及郵件用戶端收到的內容
聯絡連結（例如 <a href="mailto:test@example.com?subject=Support Inquiry">發送</a>）會中斷，因為「支援查詢」中的空格會終止郵件用戶端中的連結。許多客戶僅收到“支援”作為主題。發生這種情況是因為 mailto: 連結遵循 RFC 6068，指定查詢參數中的空格和特殊字元需要百分比編碼。 & 符號需要 %26 編碼以避免成為參數分隔符號。
損壞的郵件：連結清楚地說明了問題。像是 <a href="mailto:test@example.com?subject=Support Inquiry&body=Reply">Contact</a> 這樣建構的連結只會產生主題為「Support」的郵件。在不同的郵件用戶端中進行的測試顯示出不同的容忍度：Apple Mail 部分處理連結，Gmail 僅顯示“支援”，Outlook 完全失敗。
mailto：是一個 URL 方案 — RFC 6068 簡而言之，哪些部分是查詢字串
RFC 6068 定義 mailto：具有特定於元件的編碼規則的 URL 方案。與常規 URL 不同，mailto: 每個元件都有特定的規則。位址部分 (test@example.com) 保持未編碼狀態； @ 和域是結構性的。查詢參數（主題、內文、副本、密件副本）需要編碼。 RFC 6068 參考 RFC 3986 的規則，強制對空格和特殊字元進行百分比編碼。當值中的「&」以資料而非分隔符號出現時，將變成 %26。
了解 mailto：方案結構可防止編碼錯誤。格式為：mailto:位址?參數1=值1&參數2=值2。問號引入查詢部分。分隔參數的 & 符號保持未編碼；僅值中的 & 符號編碼為 %26。如果主題包含“Tom & Jerry”，則編碼為 Tom%20%26%20Jerry。主題和正文之間的“&”符號保持未編碼狀態。這種嵌套編碼很容易出錯。
將主題和正文編碼為 %20、換行符為 %0D%0A、& 為 %26 內部值
主題和正文編碼需要仔細處理空格和特殊字元。 mailto: 連結中的空格變成 %20，而不是與 HTML 表單不同的加號。這種關鍵的差異讓熟悉 Web 表單的開發人員感到困惑。換行符編碼為 %0D%0A（電子郵件中的 CRLF 行結尾）。 & 符號變成 %26。百分號變成 %25。主題通常包含空格、重音符號和括號。正文包含空格、重音符號、換行符。
mailto: 連結中的常見編碼包括：空格為 %20、換行符為 %0D%0A、與號為 %26、百分比為 %25、雜湊為 %23、問題為 %3F。非 ASCII 之類的重音符號首先轉換為 UTF-8 位元組，然後進行百分比編碼。 「Über 報告」變為 %C3%9ber%20report。 「你好！ 再見」變成 Hello%21%0D%0AGoodbye。僅編碼值，而不編碼結構？和 & 字元。
工作範例：建立一個包含主題、兩行正文和副本的連結 - 編碼結果及其在郵件用戶端中的顯示方式
工作範例：建立與主題「會議議程（九月）」、正文「讓我們討論： 季度目標”，並抄送“manager@example.com”演示完整的編碼。受試者需要：空格為 %20，括號為 %28 和 %29。機構需要：「讓我們討論：」基本上不變（空間為 %20），換行符為 %0D%0A，「季度目標」基本上不變。 cc 欄位不需要編碼。
產生的 mailto: 是 mailto:contact@example.com?subject=Meeting%20agenda%20%28Sept%29&body=Let%20us%20discuss%3A%0D%0AQuarterly%20goals&cc=manager@example.com。瀏覽器測試會顯示不同郵件用戶端的解讀差異。Gmail 會開啟含正確主旨、兩行內文與副本的撰寫視窗；Outlook 結果類似；Apple Mail 需要權限；較舊的用戶端可能不支援內文。
為什麼 + 在這裡是錯誤的 - mailto: 遵循 RFC 3986，而不是表單編碼，所以 + 仍然是一個加號
為什麼加號是錯誤的 - mailto: 遵循 RFC 3986，而不是形式編碼，因此加號保持字面意思 - 澄清了關鍵區別。 HTML 表單編碼使用加號表示查詢字串中的空格。 RFC 3986 和 RFC 6068 都指定 %20 為空格。 mailto: with subject="Meeting+Agenda" 建立帶有文字加號而不是空格的主題。將表單編碼邏輯複製到 mailto: Generation 時會發生此錯誤。 plus的意思是加號，不是空格。
為什麼這很重要：開發人員將表單 GET 提交邏輯複製到 mailto: Generation Break 連結。主題「會議議程」在形式上變成「會議+議程」。在 mailto: 連結中，它會建立帶有文字加號的「會議+議程」。使用者手動修復主題行。測試 mailto: 連結需要點擊它們或檢查產生的連結，而不是分析表單規則。
常見錯誤 - 忘記對 href 中的 & 分隔符號進行 HTML 轉義，並對位址中的 @ 進行百分比編碼
常見的 mailto: 建置錯誤包括忘記在 href 屬性中轉義 HTML 和符號。在 HTML 中，對於有效的 XHTML，屬性中的 & 符號應為 &。 href="mailto:address?subject=Test&body=Test" 是無效 HTML；它應該是 href="mailto:address?subject=Test&body=Test」。這表示與 URL 編碼不同的編碼。 HTML 解析器在瀏覽器處理 URL 之前將 & 解釋為 &。
測試這些錯誤需要檢查 HTML 原始碼和瀏覽器控制台。右鍵單擊並選擇“檢查元素”以查看實際的 href 值。將 href 值複製並貼上到網址列（帶有 mailto: 前綴）並檢查郵件用戶端。某些電子郵件連結在某些瀏覽器中有效，但在其他瀏覽器中無效。自動化測試很困難，因為 mailto: 涉及外部客戶端，使得手動驗證很常見。
這不包括什麼 - 郵件用戶端支援差異和深入的多個收件人
這不包括郵件用戶端支援差異和多個收件者。並非所有客戶端都同樣支援 RFC 6068 參數。 body 參數得到了廣泛的支持，但一些舊客戶端忽略了它。 cc 和 bcc 參數具有可變支援。多個收件者需要以逗號分隔的電子郵件地址，對於複雜地址，將逗號編碼為 %2C。不同的區域設定需要正確的 UTF-8 編碼才能顯示。
邮件客戶端的發展影響了 mailto: 跨平台的行為。現代網頁郵件用戶端（Gmail、Outlook.com）比舊的桌面用戶端具有更好的 RFC 6068 合規性。行動客戶端有時有更嚴格的解析。有些支援富文字，而有些則僅支援純文字。開發人員應該使用受眾實際使用的郵件用戶端進行測試。儘管有 RFC 6068 規範，但實際實作有所不同。
重點：對每個值進行編碼，保留結構 — URL 編碼器和解碼器的單值模式如何為您提供要貼上的編碼主題和正文
重點：對每個值進行編碼，保持結構 - URL 編碼器和解碼器單值模式產生編碼的主題和正文，準備貼上到連結中。該工具接受未編碼的值，例如“會議議程（九月）”，並產生“Meeting%20agenda%20%28Sept%29”。將輸出直接複製到 mailto: href 屬性中。對於多行正文，貼上帶換行符的純文字版本，獲得 %0D%0A 編碼版本。
最佳實踐是從編碼部分組裝 mailto: 連結，而不是手動建立。在 JavaScript 或範本中動態建立 HTML 時，請在使用 & 分隔符號連線之前分別對每個參數進行編碼。對於靜態 HTML，URL 編碼器和解碼器在手寫之前可靠地測試編碼。程式碼註解中的文件編碼過程。在部署之前，透過使用實際郵件用戶端點擊連結來測試產生的 mailto: 連結。