rfc2152.txt

<VC++网络游戏建摸与实现>源代码

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









Goldsmith & Davis            Informational                      [Page 8]

RFC 2152                         UTF-7                          May 1997


   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.

   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.




















Goldsmith & Davis            Informational                      [Page 9]

RFC 2152                         UTF-7                          May 1997


   As an alternative to use of UTF-7, it might be possible to intermix
   Unicode characters with other character sets using an existing MIME
   mechanism, the multipart/mixed content type, ignoring for the moment
   the issues with line breaks (thanks to Nathaniel Borenstein for
   suggesting this). For instance (repeating an earlier example):

      Content-type: multipart/mixed; boundary=foo
      Content-Disposition: inline

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

      Hi Mom
      --foo
      Content-type: text/plain; charset=UNICODE-2-0
      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.

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. In
   other contexts, use of straight Unicode or UTF-8 is preferred.



Goldsmith & Davis            Informational                     [Page 10]

RFC 2152                         UTF-7                          May 1997


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            Informational                     [Page 11]

RFC 2152                         UTF-7                          May 1997


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 so may not pass
   through some mail gateways), and the second does not.

   Content-type: text/plain; charset=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
   (omitted...)

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

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



Goldsmith & Davis            Informational                     [Page 12]

RFC 2152                         UTF-7                          May 1997


   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- jenkins+AEA-apple.com 5 January 1993
   (omitted...)



















Goldsmith & Davis            Informational                     [Page 13]

RFC 2152                         UTF-7                          May 1997


Security Considerations

   Security issues are not discussed in this memo.

References

[UNICODE 2.0]  "The Unicode Standard, Version 2.0", The Unicode
               Consortium, Addison-Wesley, 1996. ISBN 0-201-48345-9.

[ISO 10646]    ISO/IEC 10646-1:1993(E) Information Technology--Universal
               Multiple-octet Coded Character Set (UCS). See also
               amendments 1 through 7, plus editorial corrections.

[RFC-1641]     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.

[MIME]         Borenstein N., N. Freed, K. Moore, J. Klensin, and J.
               Postel, "MIME (Multipurpose Internet Mail Extensions)
               Parts One through Five", RFC 2045, 2046, 2047, 2048, and
               2049, November 1996.

Authors' Addresses

   David Goldsmith
   Apple Computer, Inc.
   2 Infinite Loop, MS: 302-2IS
   Cupertino, CA 95014

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



Goldsmith & Davis            Informational                     [Page 14]

RFC 2152                         UTF-7                          May 1997


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

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











































Goldsmith & Davis            Informational                     [Page 15]