Unicode and e-mail
From Wikipedia, the free encyclopedia
| Unicode |
|---|
| Character encodings |
| UCS |
| Mapping |
| Bi-directional text |
| BOM |
| Han unification |
| Unicode and HTML |
| Unicode and E-mail |
| Unicode typefaces |
Many E-mail clients now offer some support for Unicode in E-mail bodies. Most do not send in Unicode by default, but as time passes, more and more systems are likely to be set up with fonts capable of displaying the full range of Unicode characters (or at least the set likely to be of interest to the user).[citation needed]
Unicode support for E-mail subject lines and E-mail addresses is more problematic, because several different standards need to be used to retrofit the handling of non-ASCII data to the originally ASCII-only E-mail protocol:
- RFC 2047 provides support for encoding non-ASCII values such as real names and subject lines in E-mail headers
- RFC 3490 provides support for encoding non-ASCII domain names
However, mailbox names (the part of the E-mail address before the '@' sign) are still limited to a subset of ASCII printable characters by RFC 2822.
Contents |
[edit] Unicode support in message bodies
HTML e-mail can use HTML entities to use characters from anywhere in Unicode even if the HTML source text for the e-mail is in a legacy encoding. For details of this see Unicode and HTML. The rest of this article will deal with e-mail messages where the actual raw text (whether HTML markup or plain text) is in an encoding that covers the whole of Unicode.
As with all encodings apart from US-ASCII, when using Unicode text in e-mail, MIME must be used to specify that a Unicode transformation format is being used for the text. To use Unicode in email headers, the Unicode text has to be encoded using a MIME "Encoded-Word" with a unicode encoding as the charset.
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. UTF-8 and UTF-16 on the other hand must be transfer encoded in base64 or quoted-printable to allow safe transmission across seven-bit mail servers (i.e., those that do not advertise 8BITMIME).
[edit] Unicode in various mail clients
[edit] Evolution
View > Character Encoding > Unicode
Tools > Settings > Mail Preferences and Composer Preferences > Check default Character Encoding to Unicode
[edit] Mozilla Thunderbird
View > Character Encoding > Unicode
Tools > Options… > Fonts > Outgoing Mail / Incoming Mail (change to Unicode)
For Mac: Preferences > Display > Formatting > Fonts… > Character Encoding (bottom of the window).
[edit] MS Outlook
Outlook supports sending mail in UTF-7 and UTF-8 but does not do so by default. When replying, Outlook uses the same encoding as the message it is replying to. All Unicode characters can be entered in the edit box, but ones not available in the selected encoding will be silently replaced (usually with a question mark: ?) when sending the message.
[edit] Lotus Notes
Notes can send Unicode also:
- From the menu, select File -> Preferences -> User Preferences.
- under Basics -> Additional Options -> Tick Enable UNICODE Display
- Click Mail, then Internet.
- Under "Multilingual Internet mail," choose an option.
[edit] Scribe/InScribe
Scribe will display Unicode with default settings. But you can override the charset specified in the headers by right clicking on the body and using the "Change Charset" menu to select a new charset. You can also configure preferred charsets for 8-bit text and us-ascii in the receive options. When sending a suitable legacy charset (8-bit, e.g. ISO-8859-?? or Windows-???) is chosen automatically - however, if the message has a complicated script or a mixture of scripts, UTF-8 will be used by default. You can set a preferred legacy charset in the sending options panel to override the default charset choice. Characters not available in the current font will be substituted from another font installed on the system (if available).
