home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1468.txt < prev    next >
Text File  |  1996-05-07  |  11KB  |  220 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           J. Murai Request for Comments: 1468                               Keio University                                                               M. Crispin                                                        Panda Programming                                                          E. van der Poel                                                                June 1993 
  8.  
  9.             Japanese Character Encoding for Internet Messages 
  10.  
  11. Status of this Memo 
  12.  
  13.    This memo provides information for the Internet community.  It does    not specify an Internet standard.  Distribution of this memo is    unlimited. 
  14.  
  15. Introduction 
  16.  
  17.    This document describes the encoding used in electronic mail [RFC822]    and network news [RFC1036] messages in several Japanese networks. It    was first specified by and used in JUNET [JUNET]. The encoding is now    also widely used in Japanese IP communities. 
  18.  
  19.    The name given to this encoding is "ISO-2022-JP", which is intended    to be used in the "charset" parameter field of MIME headers (see    [MIME1] and [MIME2]). 
  20.  
  21. Description 
  22.  
  23.    The text starts in ASCII [ASCII], and switches to Japanese characters    through an escape sequence. For example, the escape sequence ESC $ B    (three bytes, hexadecimal values: 1B 24 42) indicates that the bytes    following this escape sequence are Japanese characters, which are    encoded in two bytes each.  To switch back to ASCII, the escape    sequence ESC ( B is used. 
  24.  
  25.    The following table gives the escape sequences and the character sets    used in ISO-2022-JP messages. The ISOREG number is the registration    number in ISO's registry [ISOREG]. 
  26.  
  27.        Esc Seq    Character Set                  ISOREG 
  28.  
  29.        ESC ( B    ASCII                             6        ESC ( J    JIS X 0201-1976 ("Roman" set)    14        ESC $ @    JIS X 0208-1978                  42        ESC $ B    JIS X 0208-1983                  87 
  30.  
  31.    Note that JIS X 0208 was called JIS C 6226 until the name was changed 
  32.  
  33.  
  34.  
  35. Murai, Crispin & van der Poel                                   [Page 1] 
  36.  RFC 1468   Japanese Character Encoding for Internet Messages   June 1993 
  37.  
  38.     on March 1st, 1987. Likewise, JIS C 6220 was renamed JIS X 0201. 
  39.  
  40.    The "Roman" character set of JIS X 0201 [JISX0201] is identical to    ASCII except for backslash () and tilde (~). The backslash is    replaced by the Yen sign, and the tilde is replaced by overline. This    set is Japan's national variant of ISO 646 [ISO646]. 
  41.  
  42.    The JIS X 0208 [JISX0208] character sets consist of Kanji, Hiragana,    Katakana and some other symbols and characters. Each character takes    up two bytes. 
  43.  
  44.    For further details about the JIS Japanese national character set    standards, refer to [JISX0201] and [JISX0208].  For further    information about the escape sequences, see [ISO2022] and [ISOREG]. 
  45.  
  46.    If there are JIS X 0208 characters on a line, there must be a switch    to ASCII or to the "Roman" set of JIS X 0201 before the end of the    line (i.e., before the CRLF). This means that the next line starts in    the character set that was switched to before the end of the previous    line. 
  47.  
  48.    Also, the text must end in ASCII. 
  49.  
  50.    Other restrictions are given in the Formal Syntax below. 
  51.  
  52. Formal Syntax 
  53.  
  54.    The notational conventions used here are identical to those used in    RFC 822 [RFC822]. 
  55.  
  56.    The * (asterisk) convention is as follows: 
  57.  
  58.        l*m something 
  59.  
  60.    meaning at least l and at most m somethings, with l and m taking    default values of 0 and infinity, respectively. 
  61.  
  62.     message             = headers 1*( CRLF *single-byte-char *segment                          single-byte-seq *single-byte-char )                                            ; see also [MIME1] "body-part"                                            ; note: must end in ASCII 
  63.  
  64.    headers             = <see [RFC822] "fields" and [MIME1] "body-part"> 
  65.  
  66.    segment             = single-byte-segment / double-byte-segment 
  67.  
  68.    single-byte-segment = single-byte-seq 1*single-byte-char 
  69.  
  70.  
  71.  
  72. Murai, Crispin & van der Poel                                   [Page 2] 
  73.  RFC 1468   Japanese Character Encoding for Internet Messages   June 1993 
  74.  
  75.     double-byte-segment = double-byte-seq 1*( one-of-94 one-of-94 ) 
  76.  
  77.    single-byte-seq     = ESC "(" ( "B" / "J" ) 
  78.  
  79.    double-byte-seq     = ESC "$" ( "@" / "B" ) 
  80.  
  81.    CRLF                = CR LF 
  82.  
  83.                                                     ; ( Octal, Decimal.) 
  84.  
  85.    ESC                 = <ISO 2022 ESC, escape>     ; (    33,      27.) 
  86.  
  87.    SI                  = <ISO 2022 SI, shift-in>    ; (    17,      15.) 
  88.  
  89.    SO                  = <ISO 2022 SO, shift-out>   ; (    16,      14.) 
  90.  
  91.    CR                  = <ASCII CR, carriage return>; (    15,      13.) 
  92.  
  93.    LF                  = <ASCII LF, linefeed>       ; (    12,      10.) 
  94.  
  95.    one-of-94           = <any one of 94 values>     ; (41-176, 33.-126.) 
  96.  
  97.    7BIT                = <any 7-bit value>          ; ( 0-177,  0.-127.) 
  98.  
  99.    single-byte-char    = <any 7BIT, including bare CR & bare LF, but NOT                           including CRLF, and not including ESC, SI, SO> 
  100.  
  101. MIME Considerations 
  102.  
  103.    The name given to the JUNET character encoding is "ISO-2022-JP". This    name is intended to be used in MIME messages as follows: 
  104.  
  105.        Content-Type: text/plain; charset=iso-2022-jp 
  106.  
  107.    The ISO-2022-JP encoding is already in 7-bit form, so it is not    necessary to use a Content-Transfer-Encoding header. It should be    noted that applying the Base64 or Quoted-Printable encoding will    render the message unreadable in current JUNET software. 
  108.  
  109.    ISO-2022-JP may also be used in MIME Part 2 headers.  The "B"    encoding should be used with ISO-2022-JP text. 
  110.  
  111. Background Information 
  112.  
  113.    The JUNET encoding was described in the JUNET User's Guide [JUNET]    (JUNET Riyou No Tebiki Dai Ippan). 
  114.  
  115.    The encoding is based on the particular usage of ISO 2022 announced 
  116.  
  117.  
  118.  
  119. Murai, Crispin & van der Poel                                   [Page 3] 
  120.  RFC 1468   Japanese Character Encoding for Internet Messages   June 1993 
  121.  
  122.     by 4/1 (see [ISO2022] for details). However, the escape sequence    normally used for this announcement is not included in ISO-2022-JP    messages. 
  123.  
  124.    The Kana set of JIS X 0201 is not used in ISO-2022-JP messages. 
  125.  
  126.    In the past, some systems erroneously used the escape sequence ESC (    H in JUNET messages. This escape sequence is officially registered    for a Swedish character set [ISOREG], and should not be used in ISO-    2022-JP messages. 
  127.  
  128.    Some systems do not distinguish between ESC ( B and ESC ( J or    between ESC $ @ and ESC $ B for display. However, when relaying a    message to another system, the escape sequences must not be altered    in any way. 
  129.  
  130.    The human user (not implementor) should try to keep lines within 80    display columns, or, preferably, within 75 (or so) columns, to allow    insertion of ">" at the beginning of each line in excerpts. Each JIS    X 0208 character takes up two columns, and the escape sequences do    not take up any columns. The implementor is reminded that JIS X 0208    characters take up two bytes and should not be split in the middle to    break lines for displaying, etc. 
  131.  
  132.    The JIS X 0208 standard was revised in 1990, to add two characters at    the end of the table. Although ISO 2022 specifies special additional    escape sequences to indicate the use of revised character sets, it is    suggested here not to make use of this special escape sequence in    ISO-2022-JP text, even if the two characters added to JIS X 0208 in    1990 are used. 
  133.  
  134.    For further information about Japanese character encodings such as PC    codes, FTP locations of implementations, etc, see "Electronic    Handling of Japanese Text" [JPN.INF]. 
  135.  
  136. References 
  137.  
  138.    [ASCII] American National Standards Institute, "Coded character set    -- 7-bit American national standard code for information    interchange", ANSI X3.4-1986. 
  139.  
  140.    [ISO646] International Organization for Standardization (ISO),    "Information technology -- ISO 7-bit coded character set for    information interchange", International Standard, Ref. No. ISO/IEC    646:1991. 
  141.  
  142.    [ISO2022] International Organization for Standardization (ISO),    "Information processing -- ISO 7-bit and 8-bit coded character sets 
  143.  
  144.  
  145.  
  146. Murai, Crispin & van der Poel                                   [Page 4] 
  147.  RFC 1468   Japanese Character Encoding for Internet Messages   June 1993 
  148.  
  149.     -- Code extension techniques", International Standard, Ref. No. ISO    2022-1986 (E). 
  150.  
  151.    [ISOREG] International Organization for Standardization (ISO),    "International Register of Coded Character Sets To Be Used With    Escape Sequences". 
  152.  
  153.    [JISX0201] Japanese Standards Association, "Code for Information    Interchange", JIS X 0201-1976. 
  154.  
  155.    [JISX0208] Japanese Standards Association, "Code of the Japanese    graphic character set for information interchange", JIS X 0208-1978,    -1983 and -1990. 
  156.  
  157.    [JPN.INF] Ken R. Lunde <lunde@adobe.com>, "Electronic Handling of    Japanese Text", March 1992,    msi.umn.edu(128.101.24.1):pub/lunde/japan[123].inf 
  158.  
  159.    [JUNET] JUNET Riyou No Tebiki Sakusei Iin Kai (JUNET User's Guide    Drafting Committee), "JUNET Riyou No Tebiki (Dai Ippan)" ("JUNET    User's Guide (First Edition)"), February 1988. 
  160.  
  161.    [MIME1] Borenstein N., and N. Freed, "MIME (Multipurpose    Internet Mail Extensions): Mechanisms for Specifying and    Describing the Format of Internet Message Bodies", RFC 1341,    Bellcore, Innosoft, June 1992. 
  162.  
  163.    [MIME2] Moore, K., "Representation of Non-ASCII Text in Internet    Message Headers", RFC 1342, University of Tennessee, June 1992. 
  164.  
  165.    [RFC822] Crocker, D., "Standard for the Format of ARPA Internet    Text Messages", STD 11, RFC 822, UDEL, August 1982. 
  166.  
  167.    [RFC1036] Horton M., and R. Adams, "Standard for Interchange of USENET    Messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic    Studies, December 1987. 
  168.  
  169. Acknowledgements 
  170.  
  171.    Many people assisted in drafting this document. The authors wish to    thank in particular Akira Kato, Masahiro Sekiguchi and Ken'ichi    Handa. 
  172.  
  173. Security Considerations 
  174.  
  175.    Security issues are not discussed in this memo. 
  176.  
  177.  
  178.  
  179.  
  180.  
  181. Murai, Crispin & van der Poel                                   [Page 5] 
  182.  RFC 1468   Japanese Character Encoding for Internet Messages   June 1993 
  183.  
  184.  Authors' Addresses 
  185.  
  186.    Jun Murai    Keio University    5322 Endo, Fujisawa    Kanagawa 252 Japan 
  187.  
  188.    Fax: +81 466 49 1101    EMail: jun@wide.ad.jp 
  189.  
  190.     Mark Crispin    Panda Programming    6158 Lariat Loop NE    Bainbridge Island, WA 98110-2098    USA 
  191.  
  192.    Phone: +1 206 842 2385    EMail: MRC@PANDA.COM 
  193.  
  194.     Erik M. van der Poel    A-105 Park Avenue    4-4-10 Ohta, Kisarazu    Chiba 292 Japan 
  195.  
  196.    Phone: +81 438 22 5836    Fax:   +81 438 22 5837    EMail: erik@poel.juice.or.jp 
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  Murai, Crispin & van der Poel                                   [Page 6] 
  219.  
  220.