HTML郵件
 | 此條目翻譯品質不佳。 (2020年4月27日) |
HTML郵件（HTML email）為使用HTML格式子集的電子郵件，此類郵件較純文本多了HTML格式及語義標記功能 [1]。 HTML郵件已經可以使用文字超連結功能，不必再文本中顯示一長串的URL，也可將一長串的URL按照視窗大小分行，不是像以往一樣只能固定78個字元分行（RFC 5322 格式，較舊文本處理器使用的格式）。 它也允許在文字中插入圖片、表格、圖表、數學算式等，這些功能的表現優於ASCIIart等舊格式。
採用[編輯]
大多數圖形電子郵件用戶端支援HTML郵件，當中有很多將其設為默認設定。
很多用戶端可以使用GUI來編輯HTML郵件，以及使用排版引擎來呈現接收到的郵件。
概念提出以來，一些人基於各種不同的理由反對整個HTML email（乃至MIME本身）[2]。舉例來說，ASCII Ribbon 運動主張全部的電子郵件應該被放進去ASCII文字格式，而這個運動是不成功的而在2013被放棄了[3][4]。當持續思考不當在很多的新聞群組的發表和郵件清單，它採用個人和商務郵件隨着時間的推移而增加。一些強烈反對它的人當它首度出現至今我們視它為無害[5]。
根據線上營銷公司調查， 大部分的電子郵件用戶端都能使用HTML郵件，僅有3%僅能使用純文本客戶端[6]。大多數用戶喜歡通過純文本接收HTML電子郵件[7][8]。
相容性[編輯]
郵件軟件符合規定是靠着 RFC 2822 只需要支持純文本，不是將HTML格式化。發送HTML格式的電子郵件可以因此導致問題如果收件人的電郵客戶沒有支持它。在最糟的案子裏收件人將會看到HTML碼而不是預期的訊息。
那些支持HTML的電子郵件客戶端，有些沒有給予它W3C始終如一規格，許多HTML電子郵件也無法相容，那些可能造成翻譯或呈現問題，特別是Gmail的用戶[來源請求]。
尤其是<head>的標記，它用於容納CSS樣式規則在整個HTML裏文件，沒有很好的支持，有時完全剝離，導致在線樣式聲明成為事實上的標準，即使在線樣式聲明效率低下，也無法充分利用HTML的能力從內容分離風格[來源請求]。儘管已經制定了解決方法，[9]這已經在通訊開發人員中引起了不少挫折，催生基層電子郵件標準項目，對電子郵件客戶端進行酸性測試的評分，受到Web標準項目的啟發，並遊說開發商改進他們的產品。[10]說服Google改善Gmail中的呈現，例如，他們發表了一個鬼臉網絡開發者的視頻剪輯，引起員工的注意。
| 客戶端 | 結果（截至） |
|---|---|
| 美國在線Webmail | 支持（2011年7月13日） |
| 蘋果iPhone | 支持（2011年7月13日） |
| 蘋果iPad | |
| 蘋果iPodTouch | |
| 蘋果郵件 | 支持（2007年11月28日） |
| 蘋果MobileMe | 支持（2008年8月15日） |
| Eudora
EudoraOSE代號為「Penelope」 |
支持（2007年11月28日） |
| MicrosoftEntourage | 支持（2007年11月28日） |
| MozillaThunderbird | 支持（2007年11月28日） |
| WindowsLiveMail | 支持（2007年11月28日） |
| WindowsMail | 支持（2007年11月28日） |
| 雅虎郵件測試版 | 支持（2007年11月28日） |
| WindowsLiveHotmail | 建議進行一些改進（2011年7月8日） |
| GoogleGmail | 建議改進（2011年7月13日） |
| LotusNotes8 | 建議改進（2007年11月28日） |
| MicrosoftOutlook2007 | 建議改進（2007年11月28日） |
風格[編輯]
一些發件人可能過分依賴大型，豐富多彩，或分散字體，使訊息更難以閱讀.[11]對於那些特別被格式化困擾的用戶來說，一些用戶代理可以讓讀者部分地重寫格式（例如，MozillaThunderbird允許指定最小的字體大小）;但是，這些功能並不是全球可用的.此外，發件人和讀者之間的光學外觀差異可以幫助區分每個部分的作者，提高可讀性。
多部分格式[編輯]
許多電子郵件服務器被配置為自動生成純文本版本的消息，並將其與HTML版本一起發送，以確保它甚至可以通過純文本的電子郵件客戶端使用Content-Type來閱讀:多部分/備選，如RFC1521中所規定的.[12][13][14]T他的信息本身是多部分/替代的類型，它包含兩個部分，第一個是純文本客戶端讀取的文本/純文本，第二個是帶有HTML/HTML的客戶端讀取的文本。但純文本版本可能會丟失重要的格式信息。（例如，一個數學方程可能會失去一個上標，並具有一個全新的含義。）
許多郵件列表故意阻止HTML電子郵件，或者刪除HTML部分，只留下純文本部分或拒絕整個郵件。[來源請求]
部件的順序是重要的。RFC1341指出：一般來說，組成多部分/替代實體的用戶代理應該按照優先級遞增的順序放置正文部分，也就是說，首選格式是最後一個。對於帶有html和純文本版本的多部分電子郵件，這意味着首先列出純文本版本，之後列出html版本，否則即使html版本可用，客戶端也可能默認顯示純文本版本。
郵件大小[編輯]
HTML電子郵件比純文本大。即使沒有使用特殊的格式，將會在最小的HTML文檔中使用標籤的開銷，如果格式化過度使用，可能會高得多。多部分消息，以不同格式的相同內容的副本，甚至進一步增加尺寸。純文本部分的一個多部分消息可以被自己檢索，但是要使用IMAP的FETCH命令。[15]
雖然明文和混合郵件（可能是十倍或十倍以上）之間的下載時間差異在20世紀90年代（當大多數用戶通過緩慢訪問電子郵件服務器調制解調器)，在現代連接上，對於大多數人來說差別是微不足道的，尤其是與圖像，音樂文件或其他常見附件相比時。
安全漏洞[編輯]
HTML允許將鏈接顯示為任意文本，以便不顯示完整的URL，一個鏈接可能只顯示其中的一部分或只是一個用戶友好的目標名稱。這可以用於釣魚式攻擊，其中用戶被愚弄，認為鏈接指向權威來源（如銀行）的網站，訪問它，並無意中透露個人信息（如銀行帳號）給騙子
如果電子郵件包含網絡漏洞（來自外部服務器的內嵌內容，例如圖片），服務器可以提醒第三方電子郵件已被打開。這是潛在的私隱風險，揭示了一個電子郵件地址是真實的（以便它可以在將來成為目標）並揭示消息何時被讀取。為此，有些電子郵件客戶端在用戶請求之前不會加載外部映像。
HTML內容要求電子郵件程序使用引擎進行分析，呈現並顯示文檔.這可能會導致更多的安全漏洞，拒絕服務或舊電腦的低性能。
在網絡威脅增加期間，美國國防部將所有傳入的HTML電子郵件轉換為文本電子郵件。[16]
多部分類型旨在以不同的方式顯示相同的內容，但這有時會被濫用;一些垃圾電郵利用這種格式來欺騙垃圾郵件過濾器，使其相信郵件是合法的。他們通過在消息的文本部分包含無害內容並將垃圾郵件放入HTML部分（向用戶顯示的部分）來實現這一點。
大多數電子郵件垃圾郵件都是用HTML發送的，所以垃圾郵件過濾器有時會給HTML郵件提供更高的垃圾郵件分數。
參見[編輯]
參考資料[編輯]
- ^ TextEmailvsHTMLEmail–TheProsandCons|ThunderMailer–MassEmailingSoftware. www.thundermailer.com. [2016-01-30]. （原始內容存檔於2016-02-03）.
- ^ Isaac, Alan G. HTML Email: Whenever Possible, Turn It Off!. subversion.american.edu. [2018-02-03]. （原始內容存檔於2016-06-03） （英語）.
- ^ TheAsciiRibbonCampaignofficialhomepage. 2013-07-25 [2016-01-30]. （原始內容存檔於2013-07-25）.
- ^ ShutdownoftheASCIIribboncampaign-PaleMoonforum. forum.palemoon.org. [2016-01-30]. （原始內容存檔於2016-02-03）.
- ^ [1][永久失效連結](ScotHacker，originatorofthemuch-linked-toWhyHTMLinE-MailisaBadIdeadiscusseshowhisfeelingshavechangedsincethe1990s)
- ^ Email Marketing Statistics and Metrics - EmailLabs. 2007-03-29 [2016-01-30]. （原始內容存檔於2007-03-29）.
HTML has nearly universal adoption among consumers: A Jupiter Research consumer survey found just 3% receive only text email.
- ^ Grossman, Edward. Real-WorldEmailClientUsage:TheHardData|ClickZ. www.clickz.com. 2002-07-09 [2016-01-30]. （原始內容存檔於2016-02-05）.
DoyoupreferreceivingHTMLortextemail?HTML:41.95%，Text:31.52%，Nopreference:26.53%
- ^ TheScienceofEmailMarketing. www.slideshare.net. [2016-01-30]. （原始內容存檔於2016-02-05）.
Inwhatformatdoyouprefertoreceiveemailmessagesfromcompanies?HTML:88%，Plaintext:12%
- ^ Dialect<http://dialect.ca/>. Premailer:makeCSSinlineforHTMLe-mail. Premailer.dialect.ca. [2012-06-24]. （原始內容存檔於2012-06-21）.
- ^ WhyweneedstandardssupportinHTMLemail. CampaignMonitor. [2012-06-24]. （原始內容存檔於2012-07-22）.
- ^ Shobe, Matt. AprettyfairargumentagainstHTMLEmail. Burningdoor.com. 2004-10-12 [2012-06-24]. （原始內容存檔於2012-04-24）.
- ^ 存档副本. [2017-10-01]. （原始內容存檔於2017-10-10）.
- ^ TN1010-11-2:Multipart/Alternative—GracefullyhandlingHTML-phobicemailclients. (PDF). [2012-06-24]. （原始內容存檔 (PDF)於2012-02-13）.
- ^ SendingHTMLandPlainTextE-MailSimultaneously. Wilsonweb.com. 2000-04-28 [2012-06-24]. （原始內容存檔於2012-05-05）.
- ^ Dowereallywanttosendwebpagesine-mail?. Dsv.su.se. [2012-06-24]. （原始內容存檔於2007-02-19）.
- ^ DODbarsuseofHTMLe-mail，OutlookWebAccess. fcw.com. [2015-06-23]. （原始內容存檔於2015-06-23）.