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）.