home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc2237.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  11.4 KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          K. Tamaru
  8. Request for Comments: 2237                         Microsoft Corporation
  9. Category: Informational                                    November 1997
  10.  
  11.  
  12.  
  13.            Japanese Character Encoding for Internet Messages
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  It does
  19.    not specify an Internet standard of any kind.  Distribution of this
  20.    memo is unlimited.
  21.  
  22. Copyright Notice
  23.  
  24.    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  25.  
  26. 1. Abstract
  27.  
  28.    This memo defines an encoding scheme for the Japanese Characters,
  29.    describes "ISO-2022-JP-1", which is used in electronic mail [RFC-
  30.    822], and network news [RFC 1036]. Also this memo provides a listing
  31.    of the Japanese Character Set that can be used in this encoding
  32.    scheme.
  33.  
  34. 2. Requirements Notation
  35.  
  36.    This document uses terms that appear in capital letters to indicate
  37.    particular requirements of this specification. Those terms are
  38.    "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY". The meaning of
  39.    each term are found in [RFC-2119]
  40.  
  41. 3. Introduction
  42.  
  43.    RFC 1468 defines the way Japanese Characters are encoded, likewise
  44.    what this memo defines. It defines the use of JIS X 0208 as the
  45.    double-byte character set in ISO-2022-JP text.
  46.  
  47.    Today, many operating systems support proprietary extended Japanese
  48.    characters or JIS X 0212, This includes the Unicode character set,
  49.    which does not conform to JIS X 0201 nor JIS X 0208. Therefore, this
  50.    limits the ability to communicate and correspond precise information
  51.    because of the limited availability of Kanji characters. Fortunately
  52.    JIS (Japanese Industry Standard) defines JIS X 0212 as "code of the
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Tamaru                       Informational                      [Page 1]
  59.  
  60. RFC 2237              Japanese Character Encoding          November 1997
  61.  
  62.  
  63.    supplementary Japanese graphic character set for information
  64.    interchange". Most Japanese characters which are used in regular
  65.    electronic mail in most cases can be accommodated in JIS X 0201, JIS
  66.    X 0208 and JIS X 0212.
  67.  
  68.    Also it is recognized that there is a tendency to use Unicode,
  69.    however, Unicode is not yet widely used and there is a certain
  70.    limitation with old electronic mail system. Furthermore, the purpose
  71.    of this comment is to add the capability of writing out JIS X 0212.
  72.  
  73.    This comment does not describe any representation of iso-2022-jp-1
  74.    version information in addition to JIS X 0212 support.
  75.  
  76. 4. Description
  77.  
  78.    In "ISO-2022-JP-1" text, the initial character code of the message is
  79.    in ASCII. The "double-byte-seq"(see "Format Syntax" section) (ESC "$"
  80.    "B" / ESC "$" "@" / ESC "$" "(" "D") is the only designator that
  81.    indicates that the following character is double-byte, and it is
  82.    valid until another escape sequence appears.  It is very discouraged
  83.    to use (ESC "$" "@") for double byte character encoding, new
  84.    implementation SHOULD use only (ESC "$" "B") for double byte encoding
  85.    instead.
  86.  
  87.    The end of "ISO-2022-JP-1" text MUST be in ASCII. Also it is strongly
  88.    recommended to back up to the ASCII at the end of each line rather
  89.    than JIS X 0201-Roman if there is any none ASCII character in middle
  90.    of a line.
  91.  
  92.    Since "ISO-2022-JP-1" is designed to add the capability of writing
  93.    out JIS X 0212, if the message does not contain none of JIS X 0212
  94.    characters. "ISO-2022-JP" text MUST BE used.
  95.  
  96.    JIS X 0201-Roman is not identical to the ASCII with two different
  97.    characters.
  98.  
  99.    The following list are the escape sequences and character sets that
  100.    can be used in "ISO-2022-JP-1" text. The registered number in the ISO
  101.    2375 Register which allow double-byte ideographic scripts to be
  102.    encoded within ISO/IEC 2022 code structure is indicated as reg#
  103.    below.
  104.  
  105.    reg# character set     ESC sequence                  designated to
  106.    6    ASCII             ESC 2/8 4/2                   ESC ( B    G0
  107.    42   JIS X 0208-1978   ESC 2/4 4/0                   ESC $ @    G0
  108.    87   JIS X 0208-1983   ESC 2/4 4/2                   ESC $ B    G0
  109.    14   JIS X 0201-Roman  ESC 2/8 4/10                  ESC ( J    G0
  110.    159  JIS X 0212-1990   ESC 2/4 2/8 4/4               ESC $ ( D  G0
  111.  
  112.  
  113.  
  114. Tamaru                       Informational                      [Page 2]
  115.  
  116. RFC 2237              Japanese Character Encoding          November 1997
  117.  
  118.  
  119.    Other restrictions are given in the Formal Syntax below.
  120.  
  121. 5. Formal Syntax
  122.  
  123.    The notational conventions used here are identical to those used in
  124.    STD 11, RFC 822 [RFC822].
  125.  
  126.    The * (asterisk) convention is as follows:
  127.           l*m something
  128.    meaning at least l and at most m something, with l and m taking
  129.    default values of 0 and infinity, respectively.
  130.  
  131.    iso-2022-jp-1-text  = *( line CRLF ) [line]
  132.  
  133.    line                = (*single-byte-char *segment
  134.                         single-byte-seq *single-byte-char) /
  135.                         *single-byte-char
  136.  
  137.    segment             = single-byte-segment / double-byte-segment
  138.  
  139.    single-byte-segment = single-byte-seq *single-byte-char
  140.    double-byte-segment = double-byte-seq *(one-of-94 one-of-94)
  141.  
  142.    reset-seq           = ESC "(" ( "B" / "J" )
  143.    single-byte-seq     = ESC "(" ( "B" / "J" )
  144.    double-byte-seq     = (ESC "$" ( "@" / "B" )) /
  145.                               (ESC "$" "(" "D" )
  146.  
  147.    CRLF             = CR LF;( Octal, Decimal.)
  148.    ESC              = <ISO 2022 ESC, escape>;( 33,27.)
  149.    SI               = <ISO 2022 SI, shift-in>;( 17,15.)
  150.    SO               = <ISO 2022 SO, shift-out>;( 16,14.)
  151.    CR               = <ASCII CR, carriage return>;( 15,13.)
  152.    LF               = <ASCII LF, linefeed>;( 12,10.)
  153.    one-of-94        = <any one of 94 values>;(41-176,33.-126.)
  154.    one-of-96        = <any one of 96 values>;(40-177,32.-127.)
  155.    7BIT             = <any 7-bit value>;(0-177,0.-127.)
  156.    single-byte-char = <any 7BIT, including bare CR & bare LF,
  157.                         but NOT including CRLF, and not including
  158.                         ESC, SI, SO>
  159.  
  160. 6. Security Considerations
  161.  
  162.    This memo raises no known security issues.
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Tamaru                       Informational                      [Page 3]
  171.  
  172. RFC 2237              Japanese Character Encoding          November 1997
  173.  
  174.  
  175. 7. MIME Considerations
  176.  
  177.    The name to be used for the Japanese encoding scheme in content is
  178.    "ISO-2022-JP-1". When this name is used in the MIME message form, it
  179.    would be:
  180.  
  181.               Content-Type: text/plain; charset=iso-2022-jp-1
  182.  
  183.    Since the "ISO-2022-JP-1" is 7bit encoding, it will be unnecessary to
  184.    encode in another format by specifying the "Content-Transfer-
  185.    Encoding" header. Also applying Based64 or Quoted-Printable encoding
  186.    MAY cause today's software to fail to decode the message.
  187.  
  188.    "ISO-2022-JP-1" can be used in MIME headers. Also "ISO-2022-JP-1"
  189.    text can be used with Base64 or Quoted-Printable encoding.
  190.  
  191. 8. Additional Information
  192.  
  193.    As long as mail systems are capable of writing out Unicode, it is
  194.    recommended to also write out Unicode text in addition to "ISO-
  195.    2022-JP-1" text. Also writing out "ISO-2022-JP" text in addition to
  196.    "ISO-2022-JP-1" is strongly encouraged for backward compatibility
  197.    reasons.
  198.  
  199.    Some mail systems write out 8bits characters in 'parameter' and
  200.    'value' defined in [RFC 822] and [RFC 1521]. All 8bit characters MUST
  201.    NOT be used in those fields. The implementation of future mail
  202.    systems SHOULD support those only for interoperability reasons.
  203.  
  204. 9. References
  205.  
  206.    [ISO2022]
  207.              International Organization for Standardization (ISO),
  208.              "Information processing -- ISO 7-bit and 8-bit coded
  209.              character sets -- Code extension techniques",
  210.              International Standard, Ref. No. ISO 2022-1986 (E).
  211.  
  212.    [ISOREG]
  213.              International Organization for Standardization (ISO),
  214.              "International Register of Coded Character Sets To Be Used
  215.              With Escape Sequences".
  216.  
  217.    [RFC-822]
  218.              Crocker, D., "Standard for the Format of ARPA Internet
  219.              Text Messages", STD 11, RFC 822, August 1982.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Tamaru                       Informational                      [Page 4]
  227.  
  228. RFC 2237              Japanese Character Encoding          November 1997
  229.  
  230.  
  231.    [RFC-1468]
  232.              Murai, J., Crispin, M., and E. van der Poel, "Japanese
  233.              Character Encoding for Internet Messages", RFC 1468, June
  234.              1993.
  235.  
  236.    [RFC-1766]
  237.              Alvestrand, H., "Tags for the Identification of
  238.              Languages", RFC 1766, March 1995.
  239.  
  240.    [RFC-2045]
  241.              Freed, N., and N. Borenstein, "Multipurpose Internet Mail
  242.              Extensions (MIME) Part One: Format of Internet Message
  243.              Bodies", RFC 2045, December 1996.
  244.  
  245.    [RFC-2046]
  246.              Freed, N., and N. Borenstein, "Multipurpose Internet Mail
  247.              Extensions (MIME) Part Two: Media Types", RFC 2046,
  248.              December 1996.
  249.  
  250.    [RFC-2047]
  251.              Moore, K., "Multipurpose Internet Mail Extensions (MIME)
  252.              Part Three: Representation of Non-ASCII Text in Internet
  253.              Message Headers", RFC 2047, December 1996.
  254.  
  255.    [RFC-2048]
  256.              Freed, N., Klensin, J. and J. Postel, "Multipurpose
  257.              Internet Mail Extensions (MIME) Part Four: MIME
  258.              Registration Procedures", RFC 2048, December 1996.
  259.  
  260.    [RFC-2049]
  261.              Freed, N., and N. Borenstein, "Multipurpose Internet Mail
  262.              Extensions (MIME) Part Five: Conformance Criteria and
  263.              Examples", RFC 2049, December 1996.
  264.  
  265.    [RFC-2119]
  266.              Bradner, S., "Key words for use in RFCs to Indicate
  267.              Requirement Levels", RFC 2119, March 1997.
  268.  
  269. Author's Address
  270.  
  271.    Kenzaburo Tamaru
  272.    Microsoft Corporation
  273.    One Microsoft Way
  274.    Redmond, WA 98052-6399
  275.  
  276.    EMail: kenzat@microsoft.com
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Tamaru                       Informational                      [Page 5]
  283.  
  284. RFC 2237              Japanese Character Encoding          November 1997
  285.  
  286.  
  287. Full Copyright Statement
  288.  
  289.    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  290.  
  291.    This document and translations of it may be copied and furnished to
  292.    others, and derivative works that comment on or otherwise explain it
  293.    or assist in its implementation may be prepared, copied, published
  294.    and distributed, in whole or in part, without restriction of any
  295.    kind, provided that the above copyright notice and this paragraph are
  296.    included on all such copies and derivative works.  However, this
  297.    document itself may not be modified in any way, such as by removing
  298.    the copyright notice or references to the Internet Society or other
  299.    Internet organizations, except as needed for the purpose of
  300.    developing Internet standards in which case the procedures for
  301.    copyrights defined in the Internet Standards process must be
  302.    followed, or as required to translate it into languages other than
  303.    English.
  304.  
  305.    The limited permissions granted above are perpetual and will not be
  306.    revoked by the Internet Society or its successors or assigns.
  307.  
  308.    This document and the information contained herein is provided on an
  309.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  310.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  311.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  312.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  313.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Tamaru                       Informational                      [Page 6]
  339.  
  340.