World Library  
Flag as Inappropriate
Email this Article

Unicode and email

Article Id: WHEBN0002008884
Reproduction Date:

Title: Unicode and email  
Author: World Heritage Encyclopedia
Language: English
Subject: Email, Kerio Connect, IBM Notes, IMail, Eudora Internet Mail Server
Collection:
Publisher: World Heritage Encyclopedia
Publication
Date:
 

Unicode and email

Many email clients now offer some support for Unicode. While some use Unicode by default,[1] many others will automatically choose between a legacy encoding and Unicode depending on the mail's content, either automatically[2] or when the user requests it.[3]

Technical requirements for sending of messages containing non-ASCII characters by email include

  • encoding of certain header fields (subject, sender’s and recipient’s names, sender’s organization and reply-to name) and, optionally, body in a content-transfer encoding
  • encoding of non-ASCII characters in one of the Unicode transforms
  • negotiating the use of UTF-8 encoding in email addresses and reply codes (SMTPUTF8)
  • sending the information about the content-transfer encoding and the Unicode transform used so that the message can be correctly displayed by the recipient (see Mojibake).

If the sender’s or recipient’s email address contains non-ASCII characters, sending of a message requires also encoding of these to a format that can be understood by mail servers.

Unicode support in protocols

  • RFC 6531 provides a mechanism for allowing non-ASCII email addresses encoded as UTF-8 in an SMTP[4] or LMTP protocol

Unicode support in message header

To use Unicode in certain email header fields, e.g. subject lines, sender and recipient names, the Unicode text has to be encoded using a MIME "Encoded-Word" with a Unicode encoding as the charset. To use Unicode in domain part of email addresses, IDNA encoding must traditionally be used. Alternatively, SMTPUTF8[5] allows the use of UTF-8 encoding in email addresses (both in a local part and in domain name) as well as in a mail header section. Various standards had been created to retrofit the handling of non-ASCII data to the originally ASCII-only email protocol:

  • RFC 2047 provides support for encoding non-ASCII values such as real names and subject lines in email header[6]
  • RFC 5890 provides support for encoding non-ASCII domain names in the Domain Name System[7]
  • RFC 6532 allows the use of UTF-8 in a mail header section [8]

Unicode support in message bodies

As with all encodings apart from US-ASCII, when using Unicode text in email, MIME must be used to specify that a Unicode transformation format is being used for the text.

UTF-7, although sometimes considered deprecated, has an advantage over other Unicode encodings in that it does not require a transfer encoding to fit within the seven-bit limits of many legacy Internet mail servers. On the other hand, UTF-16 must be transfer encoded to fit SMTP data format. Although not strictly required, UTF-8 is usually also transfer encoded to avoid problems across seven-bit mail servers. MIME transfer encoding of UTF-8 makes it either unreadable as a plain text (in the case of base64) or, for some languages and types of text, heavily size inefficient (in the case of quoted-printable).

Some document formats, such as HTML, PostScript and Rich Text Format have their own 7-bit encoding schemes for non-ASCII characters and can thus be sent without using any special email encodings. E.g. HTML email can use HTML entities to use characters from anywhere in Unicode even if the HTML source text for the email is in a legacy encoding (e.g. 7-bit ASCII). For details of this see Unicode and HTML. The rest of this article deals with email messages where the actual raw text (whether markup or plain text) is in an encoding that covers the whole of Unicode.

See also

References

  1. ^ https://support.google.com/mail/answer/22841?hl=en
  2. ^ https://github.com/wanderlust/apel/blob/apel-wl/mcs-20.el#L189
  3. ^ http://smallbusiness.chron.com/setting-outlook-use-utf8-32242.html
  4. ^ SMTP Extension for Internationalized Email
  5. ^ SMTP Extension for Internationalized Email
  6. ^ MIME (Multipurpose Internet Mail Extensions) Part Three
  7. ^ Internationalized Domain Names for Applications (IDNA)
  8. ^ Internationalized Email Headers

External links

  • SIL's freeware fonts, editors and documentation
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and USA.gov, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for USA.gov and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
 
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
 
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.
 


Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.