rfc1642.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 788 行 · 第 1/2 页


RFC 1642                         UTF-7                         July 1994


   8859-x in Base64

      Text type          Average octets/character
      All                      1.33

   8859-x in Quoted Printable

      Text type          Average octets/character
      US-ASCII                 1
      Western European         1.25
      Other                    2.67

   Note also that Unicode encoded in Base64 takes a constant 2.67 octets
   per character. For purposes of comparison, we will look at UTF-8 in
   Base64 and Quoted Printable, and UTF-7. UTF-1 gives results
   substantially similar to UTF-8.  Also note that fixed overhead for
   long strings is relative to 1/n, where n is the encoded string length
   in octets.

   UTF-8 in Base64

      Text type          Average octets/character
      US-ASCII                 1.33
      Western European         1.5
      Some Alphabetics         2.44
      All others               4

   UTF-8 in Quoted Printable

      Text type          Average octets/character
      US-ASCII                 1
      Western European         1.63
      Some Alphabetics         5.17
      All others               7-9

   UTF-7

      Text type          Average octets/character
      Most US-ASCII            1
      Western European         1.5
      All others               2.67+2/n

   We feel that the UTF-8 in Quoted Printable option is not viable due
   to the very large expansion of all text except Western European. This
   would only be viable in texts consisting of large expanses of US-
   ASCII or Latin characters with occasional other characters
   interspersed. We would prefer to introduce one encoding that works
   reasonably well for all users.



Goldsmith & Davis                                               [Page 8]

RFC 1642                         UTF-7                         July 1994


   We also feel that UTF-8 in Base64 has high expansion for non-
   Western-European users, and is less desirable because it cannot be
   read directly, even when the content is largely US-ASCII. The base
   encoding of UTF-7 gives competitive results and is readable for ASCII
   text.

   UTF-7 gives results competitive with ISO-8859-x, with access to all
   of the Unicode character set. We believe this justifies the
   introduction of a new transformation format of Unicode.

   As an alternative to use of UTF-7, it is possible to intermix Unicode
   characters with other character sets using an existing MIME
   mechanism, the multipart/mixed content type (thanks to Nathaniel
   Borenstein for pointing this out). For instance (repeating an earlier
   example):

      Content-type: multipart/mixed; boundary=foo

      --foo
      Content-type: text/plain; charset=us-ascii

      Hi Mom
      --foo
      Content-type: text/plain; charset=UNICODE-1-1
      Content-transfer-encoding: base64

      Jjo=
      --foo
      Content-type: text/plain; charset=us-ascii

      !
      --foo--

   Theoretically, this removes the need for UTF-7 in message bodies
   (multipart may not be used in header fields). However, we feel that
   as use of the Unicode character set becomes more widespread,
   intermittent use of specialized Unicode characters (such as dingbats
   and mathematical symbols) will occur, and that text will also
   typically include small snippets from other scripts, such as
   Cyrillic, Greek, or East Asian languages (anything in the Roman
   script is already handled adequately by existing MIME character
   sets). Although the multipart technique works well for large chunks
   of text in alternating character sets, we feel it does not adequately
   support the kinds of uses just discussed, and so we still believe the
   introduction of UTF-7 is justified.






Goldsmith & Davis                                               [Page 9]

RFC 1642                         UTF-7                         July 1994


Summary

   The UTF-7 encoding allows Unicode characters to be encoded within the
   US-ASCII 7 bit character set. It is most effective for Unicode
   sequences which contain relatively long strings of US-ASCII
   characters interspersed with either single Unicode characters or
   strings of Unicode characters, as it allows the US-ASCII portions to
   be read on systems without direct Unicode support.

   UTF-7 should only be used with 7 bit transports such as mail and
   news. In other contexts, use of straight Unicode or UTF-8 is
   preferred.

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
         Kari E. Hurtta
         John H. Jenkins
         John C. Klensin
         Valdis Kletnieks
         Keith Moore
         Masataka Ohta
         Einar Stefferud
         Erik M. van der Poel















Goldsmith & Davis                                              [Page 10]

RFC 1642                         UTF-7                         July 1994


Appendix A -- Examples

   Here is a longer example, taken from a document originally in Big5
   code. It has been condensed for brevity. There are two versions: the
   first uses optional characters from set O (and thus may not pass
   through some mail gateways), and the second uses no optional
   characters.

   Content-type: text/plain; charset=unicode-1-1-utf-7

   Below is the full Chinese text of the Analects (+itaKng-).

   The sources for the text are:

   "The sayings of Confucius," James R. Ware, trans.  +U/BTFw-:
   +ZYeB9FH6ckh5Pg-, 1980.  (Chinese text with English translation)

   +Vttm+E6UfZM-, +W4tRQ066bOg-, +UxdOrA-:  +Ti1XC2b4Xpc-, 1990.

   "The Chinese Classics with a Translation, Critical and
   Exegetical Notes, Prolegomena, and Copius Indexes," James
   Legge, trans., Taipei:  Southern Materials Center Publishing,
   Inc., 1991.  (Chinese text with English translation)

   Big Five and GB versions of the text are being made available
   separately.

   Neither the Big Five nor GB contain all the characters used in
   this text.  Missing characters have been indicated using their
   Unicode/ISO 10646 code points.  "U+-" followed by four
   hexadecimal digits indicates a Unicode/10646 code (e.g.,
   U+-9F08).  There is no good solution to the problem of the small
   size of the Big Five/GB character sets; this represents the
   solution I find personally most satisfactory.

   (omitted...)

   I have tried to minimize this problem by using variant
   characters where they were available and the character
   actually in the text was not.  Only variants listed as such in
   the +XrdxmVtXUXg- were used.

   (omitted...)

   John H. Jenkins
   +TpVPXGBG-
   [e-mail]
   5 January 1993



Goldsmith & Davis                                              [Page 11]

RFC 1642                         UTF-7                         July 1994


   (omitted...)


   Content-type: text/plain; charset=unicode-1-1-utf-7

   Below is the full Chinese text of the Analects (+itaKng-).

   The sources for the text are:

   +ACI-The sayings of Confucius,+ACI- James R. Ware, trans.  +U/BTFw-:
   +ZYeB9FH6ckh5Pg-, 1980.  (Chinese text with English translation)

   +Vttm+E6UfZM-, +W4tRQ066bOg-, +UxdOrA-:  +Ti1XC2b4Xpc-, 1990.

   +ACI-The Chinese Classics with a Translation, Critical and
   Exegetical Notes, Prolegomena, and Copius Indexes,+ACI- James
   Legge, trans., Taipei:  Southern Materials Center Publishing,
   Inc., 1991.  (Chinese text with English translation)

   Big Five and GB versions of the text are being made available
   separately.

   Neither the Big Five nor GB contain all the characters used in
   this text.  Missing characters have been indicated using their
   Unicode/ISO 10646 code points.  +ACI-U+-+ACI- followed by four
   hexadecimal digits indicates a Unicode/10646 code (e.g.,
   U+-9F08).  There is no good solution to the problem of the small
   size of the Big Five/GB character sets+ADs- this represents the
   solution I find personally most satisfactory.

   (omitted...)

   I have tried to minimize this problem by using variant
   characters where they were available and the character
   actually in the text was not.  Only variants listed as such in
   the +XrdxmVtXUXg- were used.

   (omitted...)

   John H. Jenkins
   +TpVPXGBG-
   John+AF8-Jenkins+AEA-taligent.com
   5 January 1993
   (omitted...)







Goldsmith & Davis                                              [Page 12]

RFC 1642                         UTF-7                         July 1994


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).

[MIME/UNICODE] Goldsmith, D., and M. Davis, "Using Unicode with MIME",
               RFC 1641, 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, RFC 822, 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" RFC 1522, University of Tennessee,
               September 1993.







Goldsmith & Davis                                              [Page 13]

RFC 1642                         UTF-7                         July 1994


[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: [phone]
   Fax: [phone]
   EMail: [e-mail]


   Mark Davis
   Taligent, Inc.
   10201 N. DeAnza Blvd.
   Cupertino, CA 95014-2233

   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]

























Goldsmith & Davis                                              [Page 14]