米葫芦网

RFC1641 - Using Unicode with MIME

热度:9℃ 发布时间:2024-11-18 01:00:41

Network Working Group D. Goldsmith
Request for Comments: 1641 M. Davis
Category: EXPerimental Taligent, Inc.
July 1994
Using Unicode with MIME
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Distribution of this memo is unlimited.
Abstract
The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993(E)
jointly define a 16 bit character set (hereafter referred to as
Unicode) which encompasses most of the world"s writing systems.
However, Internet mail (STD 11, RFC822) currently supports only 7-
bit US ASCII as a character set. MIME (RFC1521 and RFC1522) extends
Internet mail to support different media types and character sets,
and thus could support Unicode in mail messages. MIME neither defines
Unicode as a permitted character set nor specifies how it would be
encoded, although it does provide for the registration of additional
character sets over time.
This document specifies the usage of Unicode within MIME.
Motivation
Since Unicode is starting to see widespread commercial adoption,
users will want a way to transmit information in this character set
in mail messages and other Internet media. Since MIME was expressly
designed to allow sUCh extensions and is on the standards track for
the Internet, it is the most appropriate means for encoding Unicode.
RFC1521 and RFC1522 do not define Unicode as an allowed character
set, but allow registration of additional character sets.
In addition to allowing use of Unicode within MIME bodies, another
goal is to specify a way of using Unicode that allows text which
consists largely, but not entirely, of US-ASCII characters to be
represented in a way that can be read by mail clients who do not
understand Unicode. This is in keeping with the philosophy of MIME.
Such an encoding is described in another document, "UTF-7: A Mail
Safe Transformation Format of Unicode" [UTF-7].
Overview
Several ways of using Unicode are possible. This document specifies
both guidelines for use of Unicode within MIME, and a specific usage.
The usage specified in this document is a straightforward use of
Unicode as specified in "The Unicode Standard, Version 1.1".
This encoding is intended for situations where sender and recipient
do not want to do a lot of processing, when the text does not consist
primarily of characters from the US-ASCII character set, or when
sender and receiver are known in advance to support Unicode.
Another encoding is intended for situations where the text consists
primarily of US-ASCII, with occasional characters from other parts of
Unicode. This encoding allows the US-ASCII portion to be read by all
recipients without having to support Unicode. This encoding is
specified in another document, "UTF-7: A Mail Safe Transformation
Format of Unicode" [UTF-7].
Finally, in keeping with the principles set forth in RFC1521, text
which can be represented using the US-ASCII or ISO-8859-x character
sets should be so represented where possible, for maximum
interoperability.
Definitions
The definition of character set Unicode:
The 16 bit character set Unicode is defined by "The Unicode
Standard, Version 1.1". This character set is identical with the
character repertoire and coding of the international standard
ISO/IEC 10646-1:1993(E); Coded Representation Form=UCS-2;
Subset=300; Implementation Level=3.
Note. Unicode 1.1 further specifies the use and interaction of
these character codes beyond the ISO standard. However, any valid
10646 BMP (Basic Multilingual Plane) sequence is a valid Unicode
sequence, and vice versa; Unicode supplies interpretations of
sequences on which the ISO standard is silent as to
interpretation.
This character set is encoded as sequences of octets, two per 16-
bit character, with the most significant octet first. Text with an
odd number of octets is ill-formed.
Rationale. ISO/IEC 10646-1:1993(E) specifies that when characters
in the UCS-2 form are serialized as octets, that the most
significant octet appear first. This is also in keeping with
common network practice of choosing a canonical format for
transmission.
General Specification of Unicode Character Sets Within MIME
The Unicode Standard is currently at version 1.1. Although new
versions should be compatible with old implementations if an
implementation is compliant with the standard, some implementations
may choose to check the version of the character set that is being
used. In order to allow some implementations to check the version
number and allow others to ignore it, all registrations of Unicode
variants and versions for MIME usage should have MIME charset names
which conform to one of the two following patterns:
UNICODE-major-minor
UNICODE-major-minor-variant
Where major and minor are strings of decimal digits (0 through 9)
specifying the major and minor version number of the Unicode standard
to which the text in question conforms. In the interests of
interoperability, the lowest version number compatible with the text
should be used. The lowest acceptable version number is UNICODE-1-1,
corresponding to "The Unicode Standard, Version 1.1". The optional
trailing string "variant" describes the particular transformation
format of Unicode that the registration describes; its content is up
to the particular registration. If there is no trailing variant
string, the charset name refers to the basic two octet form of
Unicode as described in "The Unicode Standard".
Example. A hypothetical charset which referred to the UTF-8
transformation format of Unicode/10646 (also known as UTF-2 or UTF-
FSS) might be named UNICODE-1-1-UTF-8.
Encoding Character Set Unicode Within MIME
Character set Unicode uses 16 bit characters, and therefore would
normally be used with the Binary or Base64 content transfer encodings
of MIME. In header fields, it would normally be used with the B
content transfer encoding. The MIME character set identifier is
UNICODE-1-1.
Example. Here is a text portion of a MIME message containing the
Japanese Word "nihongo" (hexadecimal 65E5,672C,8A9E) written in Han
characters.
Content-Type: text/plain; charset=UNICODE-1-1
Content-Transfer-Encoding: base64
ZeVnLIqe
Example. Here is a text portion of a MIME message containing the
Unicode sequence "A<NOT IDENTICAL TO><ALPHA>." (hexadecimal
0041,2262,0391,002E)
Content-Type: text/plain; charset=UNICODE-1-1
Content-Transfer-Encoding: base64
AEEiYgORAC4=
Acknowledgements
Many thanks to the following people for their contributions,
comments, and suggestions. If we have omitted anyone it was through
oversight and not intentionally.
Glenn Adams
Harald T. Alvestrand
Nathaniel Borenstein
Lee Collins
Jim Conklin
Dave Crocker
Steve Dorner
Dana S. Emery
Ned Freed
John H. Jenkins
John C. Klensin
Valdis Kletnieks
Keith Moore
Masataka Ohta
Einar Stefferud
Security Considerations
Security issues are not discussed in this memo.
References
[UNICODE 1.1] "The Unicode Standard, Version 1.1": Version 1.0, Volume 1
(ISBN 0-201-56788-1), Version 1.0, Volume 2 (ISBN 0-201-
60845-6), and "Unicode Technical Report #4, The Unicode
Standard, Version 1.1" (available from The Unicode
Consortium, and soon to be published by Addison-Wesley).
[ISO 10646] ISO/IEC 10646-1:1993(E) Information Technology--Universal
Multiple-octet Coded Character Set (UCS).
[UTF-7] Goldsmith, D., and M. Davis, "UTF-7: A Mail Safe
Transformation Format of Unicode", RFC1642, Taligent,
Inc., July 1994.
[US-ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[ISO-8859] Information Processing -- 8-bit Single-Byte Coded Graphic
Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-
1:1987. Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.
Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. Part 4:
Latin alphabet No. 4, ISO 8859-4, 1988. Part 5:
Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6:
Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7:
Latin/Greek alphabet, ISO 8859-7, 1987. Part 8:
Latin/Hebrew alphabet, ISO 8859-8, 1988. Part 9: Latin
alphabet No. 5, ISO 8859-9, 1990.
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC822, UDEL, August 1982.
[RFC-1521] Borenstein N., and N. Freed, "MIME (Multipurpose Internet
Mail Extensions) Part One: Mechanisms for Specifying and
Describing the Format of Internet Message Bodies", RFC
1521, Bellcore, Innosoft, September 1993.
[RFC-1522] Moore, K., "Representation of Non-Ascii Text in Internet
Message Headers" RFC1522, University of Tennessee,
September 1993.
[UTF-8] X/Open Company Ltd., "File System Safe UCS Transformation
Format (FSS_UTF)", X/Open Preliminary Specification,
Document Number: P316. This information also appears in
Unicode Technical Report #4, and in a forthcoming annex to
ISO/IEC 10646.
Authors" Addresses
David Goldsmith
Taligent, Inc.
10201 N. DeAnza Blvd.
Cupertino, CA 95014-2233
Phone: 408-777-5225
Fax: 408-777-5081
EMail: david_goldsmith@taligent.com
Mark Davis
Taligent, Inc.
10201 N. DeAnza Blvd.
Cupertino, CA 95014-2233
Phone: 408-777-5116
Fax: 408-777-5081

网友评论
评论
发 布

更多软件教程
  • 软件教程推荐
更多+
Greenfoot设置中文的方法

Greenfoot设置中文的方法

Greenfoot是一款简单易用的Java开发环境,该软件界面清爽简约,既可以作为一个开发框使用,也能够作为集成开发环境使用,操作起来十分简单。这款软件支持多种语言,但是默认的语言是英文,因此将该软件下载到电脑上的时候,会发现软件的界面语言是英文版本的,这对于英语基础较差的朋友来说,使用这款软件就会...

07-05

Egret UI Editor修改快捷键的方法

Egret UI Editor修改快捷键的方法

Egret UI Editor是一款开源的2D游戏开发代码编辑软件,其主要功能是针对Egret项目中的Exml皮肤文件进行可视化编辑,功能十分强大。我们在使用这款软件的过程中,可以将一些常用操作设置快捷键,这样就可以简化编程,从而提高代码编辑的工作效率。但是这款软件在日常生活中使用得不多,并且专业性...

07-05

KittenCode新建项目的方法

KittenCode新建项目的方法

KittenCode是一款十分专业的编程软件,该软件给用户提供了可视化的操作界面,支持Python语言的编程开发以及第三方库管理,并且提供了很多实用的工具,功能十分强大。我们在使用这款软件进行编程开发的过程中,最基本、最常做的操作就是新建项目,因此我们很有必要掌握新建项目的方法。但是这款软件的专业性...

07-05

Thonny设置中文的方法

Thonny设置中文的方法

Thonny是一款十分专业的Python编辑软件,该软件界面清爽简单,给用户提供了丰富的编程工具,具备代码补全、语法错误显示等功能,非常的适合新手使用。该软件还支持多种语言,所以在下载这款软件的时候,有时候下载到电脑中的软件是英文版本的,这对于英语基础较差的小伙伴来说,使用这款软件就会变得十分困难,...

07-05

最新软件下载