跳转到内容

HTML郵件

维基百科，自由的百科全书

这是本页的一个历史版本，由Tcsh002​（留言 | 贡献）在2017年12月17日 (日) 11:22编辑。这可能和当前版本存在着巨大的差异。

HTML郵件 用於一個子集在HTML提供格式化和語義標記功能在email裡是個不合宜的計畫文本:[1] 文本可以連接而不用顯示統一資源定位服, 或是闖入統一資源定位服,多件的事件被包裹在適當寬度的視窗裡, 而不是均勻的打破每一行在78個文字裡

（定義在 RFC 5322, 是必要在舊的文本末). 它允許在自行間包容影像,表格,以及圖或是數學公式影像 , 那些除此以外的傳達困難 (一般使用ASCII art).

採用

大多數圖形的電郵客戶支持HTML郵件, 還有很多默認它. 很多的客戶包含一個GUI編輯者來構成構成 HTML 電子郵件以及用於顯示接收到的HTML電子郵件的呈現引擎。

從它的概念以來, 一些人有聲音反對整個HTML email (和甚至 MIME本身), 由於各種不同的理由.[2] 舉例來說,ASCII Ribbon 運動主張全部的電子郵件應該被放進去 ASCII 文字格式. 而這個運動 是不成功的而在2013被放棄了.[3][4] 當持續思考不當 i在很多的新聞群組的發表和郵件清單, 它採用個人和商務郵件隨著時間的推移而增加. 一些強烈反對它的人當它首度出現至今我們視它為無害.[5]

根據線上市場公司調查, 採用HTML能夠讓電郵用戶現今能幾乎普遍, 憑著小於 3% 報告他們的純文本客戶端。他們大多數用戶喜歡通過純文本接收HTML電子郵件.[6][7]

兼容性

郵件軟體符合規定是靠著 RFC 2822 只需要支持純文本,不是將HTML格式化. 發送HTML格式的電子郵件可以因此導致問題 如果收件人的電郵客戶沒有支持它.在最糟的案子裡 收件人將會看到HTML碼而不是預期的消息.

那些支持HTML的電子郵件客戶端, 有些沒有給予它的W3C 始終如一 規格, 許多HTML電子郵件也不兼容， 那些可能造成翻譯或呈現問題, 特別是Gmail的用戶.[來源請求]

尤其是<head>的標記, 它用於容納CSS樣式規則在整個HTML裡文件，沒有很好的支持，有時完全剝離, 導致在線樣式聲明成為事實上的標準, 即使在線樣式聲明效率低下，也無法充分利用HTML的能力從內容分離風格。[來源請求] 儘管已經制定了解決方法,[8] 這已經在通訊開發人員中引起了不少挫折, 催生基層電子郵件標準項目, 對電子郵件客戶端進行酸性測試的評分，受到Web標準項目的啟發， 並遊說開發商改進他們的產品.[9] 說服Google改善Gmail中的呈現, 例如，他們發表了一個鬼臉網絡開發者的視頻剪輯，引起員工的注意。

"電子郵件標準項目“酸性測試比較（截至2013年1月)[1]
客戶端 結果（截至）
美國在線Webmail Solid support (13 July 2011)
蘋果iPhone Solid support (13 July 2011)
蘋果iPad
蘋果iPod Touch
蘋果郵件 Solid support (28 November 2007)
蘋果MobileMe Solid support (15 August 2008)
Eudora

Eudora OSE代號為“Penelope”

Solid support (28 November 2007)
Microsoft Entourage Solid support (28 November 2007)
Mozilla Thunderbird Solid support (28 November 2007)
Windows Live Mail Solid support (28 November 2007)
Windows Mail Solid support (28 November 2007)
雅虎 郵件測試版 Solid support (8 July 2011)
Windows Live Hotmail Some improvement recommended (8 July 2011)
Google Gmail Improvement recommended (13 July 2011)
Lotus Notes 8 Improvement recommended (28 November 2007)
Microsoft Outlook 2007 Improvement recommended (28 November 2007)

風格

一些發件人可能過分依賴大型，豐富多彩，或分散字體，使訊息更難以閱讀.[10] 對於那些特別被格式化困擾的用戶來說，一些用戶代理可以讓讀者部分地重寫格式 （例如，Mozilla Thunderbird允許指定最小的字體大小）; 但是，這些功能並不是全球可用的. 此外，發件人和讀者之間的光學外觀差異可以幫助區分每個部分的作者，提高可讀性。

多部分格式

許多電子郵件服務器被配置為自動生成純文本版本的消息，並將其與HTML版本一起發送， 以確保它甚至可以通過純文本的電子郵件客戶端使用Content-Type來閱讀: 多部分/備選，如RFC 1521中所規定的.[11][12][13] T他的信息本身是多部分/替代的類型,它包含兩個部分，第一個是純文本客戶端讀取的文本/純文本，第二個是帶有HTML / HTML的客戶端讀取的文本。 但純文本版本可能會丟失重要的格式信息。 （例如，一個數學方程可能會失去一個上標，並具有一個全新的含義。）

許多[來源請求]郵件列表故意阻止HTML電子郵件，或者刪除HTML部分，只留下純文本部分或拒絕整個郵件。[來源請求]

部件的順序是重要的。 RFC1341指出：一般來說，組成多部分/替代實體的用戶代理應該按照優先級遞增的順序放置正文部分，也就是說，首選格式是最後一個。 對於帶有html和純文本版本的多部分電子郵件，這意味著首先列出純文本版本，之後列出html版本，否則即使html版本可用，客戶端也可能默認顯示純文本版本。

郵件大小

HTML電子郵件比純文本大。 即使沒有使用特殊的格式,將會在最小的HTML文檔中使用標籤的開銷, 如果格式化過度使用，可能會高得多。 多部分消息, 以不同格式的相同內容的副本，甚至進一步增加尺寸。純文本部分的一個多部分 消息可以被自己檢索，但是要使用 IMAP的FETCH命令。[14]

雖然明文和混合郵件（可能是十倍或十倍以上）之間的下載時間差異在20世紀90年代（當大多數用戶通過緩慢訪問電子郵件服務器數據機), 在現代連接上，對於大多數人來說差別是微不足道的，尤其是與圖像，音樂文件或其他常見附件相比時。

安全漏洞

HTML允許將鏈接顯示為任意文本，以便不顯示完整的URL， 一個鏈接可能只顯示其中的一部分或只是一個用戶友好的目標名稱。 這可以用於釣魚式攻擊，其中用戶被愚弄，認為鏈接指向權威來源（如銀行）的網站，訪問它，並無意中透露個人信息（如銀行帳號）給騙子

如果電子郵件包含網路漏洞（來自外部服務器的內嵌內容，例如圖片）, the server can alert a third party that the email has been opened. This is a potential privacy（英语：email privacy） risk, revealing that an email address is real (so that it can be targeted in the future) and revealing when the message was read. For this reason, some email clients do not load external images until requested to by the user.

HTML content requires email programs to use engines to parse, render and display the document. This can lead to more security vulnerabilities, denial of service or low performance on older computers.

During periods of increased network threats, the US Department of Defense converts all incoming HTML email to text email.[15]

The multipart type is intended to show the same content in different ways, but this is sometimes abused; some email spam takes advantage of the format to trick spam filter（英语：spam filter）s into believing that the message is legitimate. They do this by including innocuous content in the text part of the message and putting the spam in the HTML part (that which is displayed to the user).

Most email spam is sent in HTML[來源請求] for these reasons, so spam filters sometimes give higher spam scores to HTML messages.[來源請求]

See also

References

  1. ^ Text Email vs HTML Email – The Pros and Cons | Thunder Mailer – Mass Emailing Software. www.thundermailer.com. [2016-01-30]. 
  2. ^ HTML Email: Whenever Possible, Turn It Off!
  3. ^ The Ascii Ribbon Campaign official homepage. 2013-07-25 [2016-01-30]. （原始内容存档于25 July 2013）. 
  4. ^ Shutdown of the ASCII ribbon campaign - Pale Moon forum. forum.palemoon.org. [2016-01-30]. 
  5. ^ HTML Email: The Poll (Scot Hacker, originator of the much-linked-to Why HTML in E-Mail is a Bad Idea discusses how his feelings have changed since the 1990s)
  6. ^ Grossman, Edward. Real-World Email Client Usage: The Hard Data | ClickZ. www.clickz.com. 2002-07-09 [2016-01-30]. Do you prefer receiving HTML or text email? HTML: 41.95%, Text: 31.52%, No preference: 26.53% 
  7. ^ The Science of Email Marketing. www.slideshare.net. [2016-01-30]. In what format do you prefer to receive email messages from companies? HTML: 88%, Plain text: 12% 
  8. ^ Dialect <http://dialect.ca/>. Premailer: make CSS inline for HTML e-mail. Premailer.dialect.ca. [2012-06-24]. 
  9. ^ Why we need standards support in HTML email. Campaign Monitor. [2012-06-24]. 
  10. ^ Shobe, Matt. A pretty fair argument against HTML Email. Burningdoor.com. 2004-10-12 [2012-06-24]. 
  11. ^ RFC 1521 7.2.3. The Multipart/alternative subtype
  12. ^ TN1010-11-2: Multipart/Alternative — Gracefully handling HTML-phobic email clients. (PDF). [2012-06-24]. 
  13. ^ Sending HTML and Plain Text E-Mail Simultaneously. Wilsonweb.com. 2000-04-28 [2012-06-24]. 
  14. ^ Do we really want to send web pages in e-mail?. Dsv.su.se. [2012-06-24]. 
  15. ^ DOD bars use of HTML e-mail, Outlook Web Access. fcw.com. [2015-06-23]. 
检索自“https://zh.wikipedia.org/w/index.php?title=HTML郵件&oldid=47412966”