一個電子郵件提供商拒絕了一封包含特殊字符（例如元音變音）的電子郵件。他們說他們符合 RFC-5321 和 RFC-5322。現在我瀏覽了這些標準，但它們不支持國際電子郵件（因此沒有變音）。僅支持 ASCII-127。現在有一個名為 RFC-6532 的擴展，它標準化了國際電子郵件。我們的電子郵件采用 UTF-8（參考可列印）編碼并按如下方式發送：
"=?UTF-8?Q?B=C3=B6rge_M=C3=B6ller?="<[email protected]>
這是符合 RFC-6532 的地址嗎？還是其他/較舊的 RFC（如 RFC-2054）？畢竟有太多與郵件相關的 RFC，我可能錯過了 10 或 20 個 ;-)
uj5u.com熱心網友回復：
它在正確的軌道上，但它是錯誤的。
"=?UTF-8?Q?B=C3=B6rge_M=C3=B6ller?="<[email protected]>
上述表格有兩個問題：
- 編碼字（=?UTF-8?Q?...?= 位）被參考，不應該被參考。如果它們符合標準，決議此地址的郵件軟體將不會解碼該令牌。
- “名稱”靠在尖括號上，不應該如此。為了符合標準，必須有一個空間。
換句話說，它應該是這樣的：
=?UTF-8?Q?B=C3=B6rge_M=C3=B6ller?= <[email protected]>
您需要查看的 RFC 是：
- RFC5322 - 這定義了由您嘗試與之互操作的服務器實作的現代訊息語法。
- RFC2047 - 這定義了在標頭
Subject和地址標頭（例如，收件人/發件人/抄送/回復收件人/等）中表示非 ASCII 字符所需的編碼字的方法和語法。（這是=?UTF-8?Q?B=C3=B6rge_M=C3=B6ller?=部分） - RFC822 - 這定義了 RFC2047 使用的語法，是 RFC5322 的舊版本。
這可能也有助于閱讀RFC2822比RFC822比RFC5322新的，但舊的。然而，我的猜測是你可以跳過它，因為它不會有很多價值。唯一的原因RFC822仍然具有價值，因為這是由RFC2047參考其更老的語法定義（如atom，dot-atom，phrase，angle-addr，addr-spec，tspecials，等）。
RFC6532 甚至比 RFC5322 更新。其目的是通過允許使用 UTF-8 作為替代方案來完全消除對標頭進行編碼的需要。
在 RFC6532 之前，除了 ASCII（這是 RFC822 使用的）之外，沒有用于標頭的字符編碼標準，因此一切都應該符合 ASCII。
然而，很多軟體不遵循標準，所以現實世界中有很多郵件使用 ISO-8859-1 和其他所有字符編碼，都取決于用戶所在的地區) 以及在這些地區廣泛使用哪些字符編碼（例如 Big5 和 GB2312 在中國各地流行，Shift-JIS 在日本流行，EUC-KR/KS-C-5601-1987 是在韓國流行等）。
然而，這導致了重大的互操作性問題，其中最重要的原因是并非每個郵件客戶端都能在陽光下處理每種字符編碼，還因為客戶端無法確定甚至使用了哪種字符編碼！這只是二進制gobbeldy-gook。
然而，UTF-8 已經存在了很長時間，它可以表示所有語言中的所有字符，因此它最終成為用于國際電子郵件的標準字符編碼是合乎邏輯的。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/352916.html