Unicode and email
The topic of Unicode and email is of great relevance today and has been the subject of numerous studies and debates over time. The importance of Unicode and email lies in its impact on various aspects of daily life, from health to the economy. Throughout history, Unicode and email has played a fundamental role in society, influencing the way people relate to each other and the environment around them. In this article, different perspectives on Unicode and email will be explored, analyzing its impact on society and its relevance in today's world.
Many email clients now offer some support for Unicode. Some clients will automatically choose between a legacy encoding and Unicode depending on the mail's content, either automatically[1] or when the user requests it.[2]
Technical requirements for sending 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
If the sender's or recipient's email address contains non-ASCII characters, sending a message also requires encoding these characters in a format that can be understood by mail servers.
Support in protocols
RFC 6531 provides a mechanism for allowing non-ASCII email addresses encoded as UTF-8 in the SMTP[3] and LMTP protocols.
Message headers
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 the domain part of email addresses, IDNA encoding must traditionally be used. Alternatively, SMTPUTF8[3] 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 headers.[4]
- RFC 5890 provides support for encoding non-ASCII domain names in the Domain Name System.[5]
- RFC 6532 allows the use of UTF-8 in a mail header section.[6]
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, an obsolete encoding, had an advantage on obsolete non–8-bit clean networks over Unicode encodings in that it does not require a transfer encoding to fit within the 7-bit limits of legacy Internet mail servers. On the other hand, UTF-16 must be transfer encoded to fit the data format of SMTP. Although not strictly required, UTF-8 is usually also transfer encoded to avoid problems across 7-bit mail servers. MIME transfer encoding of UTF-8 makes it either unreadable as 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. 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).
See also
References
- ^ "wanderlust/apel". GitHub. Retrieved 2018-09-05.
- ^ "Setting Outlook to Use UTF-8". Retrieved 2018-09-05.
- ^ a b Jiankang, Yao; Wei, Mao (February 2012). "SMTP Extension for Internationalized Email". tools.ietf.org. Retrieved 2018-09-05.
- ^ Moore, Keith (November 1996). "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text". tools.ietf.org. Retrieved 2018-09-05.
- ^ Klensin, John C (August 2010). "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework". tools.ietf.org. Retrieved 2018-09-05.
- ^ Abel, Yang; Shawn, Steele (February 2012). "Internationalized Email Headers". tools.ietf.org. Retrieved 2018-09-05.
