home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc1843.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  8.6 KB  |  284 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                             F. Lee
  8. Request for Comments: 1843                           Stanford University
  9. Category: Informational                                      August 1995
  10.  
  11.  
  12.                HZ - A Data Format for Exchanging Files of
  13.              Arbitrarily Mixed Chinese and ASCII characters
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  This memo
  18.    does not specify an Internet standard of any kind.  Distribution of
  19.    this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    The content of this memo is identical to an article of the same title
  24.    written by the author on September 4, 1989.  In this memo, GB stands
  25.    for GB2312-80.  Note that the title is kept only for historical
  26.    reasons.  HZ has been widely used for purposes other than "file
  27.    exchange".
  28.  
  29. 1. Introduction
  30.  
  31.    Most existing computer systems which can handle a text file of
  32.    arbitrarily mixed Chinese and ASCII characters use 8-bit codes.  To
  33.    exchange such text files through electronic mail on ASCII computer
  34.    systems, it is necessary to encode them in a 7-bit format.  A generic
  35.    binary to ASCII encoder is not sufficient, because there is currently
  36.    no universal standard for such 8-bit codes. For example, CCDOS and
  37.    Macintosh's Chinese OS use different internal codes.  Fortunately,
  38.    there is a PRC national standard, GuoBiao (GB), for the encoding of
  39.    Chinese characters, and Chinese characters encoded in the above
  40.    systems can be easily converted to GB by a simple formula. (* The ROC
  41.    standard BIG-5 is outside the scope of this article.)
  42.  
  43.    HZ is a 7-bit data format proposed for arbitrarily mixed GB and ASCII
  44.    text file exchange.  HZ is also intended for the design of terminal
  45.    emulators that display and edit mixed Chinese and ASCII text files in
  46.    real time.
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Lee                          Informational                      [Page 1]
  59.  
  60. RFC 1843        HZ - A Data Format for Exchanging Files      August 1995
  61.  
  62.  
  63. 2. Specification
  64.  
  65.    The format of HZ is described in the following.
  66.  
  67.    Without loss of generality, we assume that all Chinese characters
  68.    (HanZi) have already been encoded in GB.  A GB (GB1 and GB2) code is
  69.    a two byte code, where the first byte is in the range $21-$77
  70.    (hexadecimal), and the second byte is in the range $21-$7E.
  71.  
  72.    A graphical ASCII character is a byte in the range $21-$7E. A non-
  73.    graphical ASCII character is a byte in the range $0-$20 or of the
  74.    value $7F.
  75.  
  76.    Since the range of a graphical ASCII character overlaps that of a GB
  77.    byte, a byte in the range $21-$7E is interpreted according to the
  78.    mode it is in.  There are two modes, namely ASCII mode and GB mode.
  79.  
  80.    By convention, a non-graphical ASCII character should only appear in
  81.    ASCII mode.
  82.  
  83.    The default mode is ASCII mode.
  84.  
  85.    In ASCII mode, a byte is interpreted as an ASCII character, unless a
  86.    '~' is encountered. The character '~' is an escape character. By
  87.    convention, it must be immediately followed ONLY by '~', '{' or '\n'
  88.    (<LF>), with the following special meaning.
  89.  
  90.    o The escape sequence '~~' is interpreted as a '~'.
  91.    o The escape-to-GB sequence '~{' switches the mode from ASCII to
  92.      GB.
  93.    o The escape sequence '~\n' is a line-continuation marker to be
  94.      consumed with no output produced.
  95.  
  96.    In GB mode, characters are interpreted two bytes at a time as (pure)
  97.    GB codes until the escape-from-GB code '~}' is read. This code
  98.    switches the mode from GB back to ASCII.  (Note that the escape-
  99.    from-GB code '~}' ($7E7D) is outside the defined GB range.)
  100.  
  101.    The decoding process is clear from the above description.
  102.  
  103.    The encoding process is straightforward. Note that an (ASCII) '~' is
  104.    always encoded as '~~'. A sequence of GB codes is enclosed in '~{'
  105.    and '~}'.
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Lee                          Informational                      [Page 2]
  115.  
  116. RFC 1843        HZ - A Data Format for Exchanging Files      August 1995
  117.  
  118.  
  119. 3. Remarks & Recommendations
  120.  
  121.    We choose to encode any ASCII character except '~' as it is, rather
  122.    than as a two byte code, and we choose ASCII as the default mode for
  123.    the following reasons. The computer systems we use is ASCII based.  A
  124.    HZ file containing pure ASCII characters (i.e. no Chinese characters)
  125.    except '~' is precisely a pure ASCII file. In general, the English
  126.    (ASCII) portion of a HZ file is directly readable.
  127.  
  128.    The escape character '~' is chosen not only because it is commonly
  129.    used in the ASCII world, but also because '~' ($7E) is outside the
  130.    defined range ($21-$77) of the first byte of a GB code.
  131.  
  132.    In ASCII mode, other potential escape sequences, i.e., two byte
  133.    sequences beginning with '~' (other than '~~', '~{', '~\n') are
  134.    currently invalid HZ sequences. Hence, they can be used for future
  135.    extension of HZ with total upward compatibility.
  136.  
  137.    The line-continuation marker '~\n' is useful if one wants to encode
  138.    long lines in the original text into short lines in this data format
  139.    without introducing extra newline characters in the decoding process.
  140.  
  141.    There is no limit on the length of a line. In fact, the whole file
  142.    could be one long line or even contain no newline characters. Any
  143.    DECODER of this HZ data format should not and has no need to operate
  144.    on the concept of a line.
  145.  
  146.    It is easy to write encoders and decoders for HZ. An encoder or
  147.    decoder needs to lookahead at most one character in the input data
  148.    stream.
  149.  
  150.    Given the current mode, it is also possible and easy to decode a HZ
  151.    data stream by scanning backward. One of the implication is that
  152.    "backspaces" can be handled correctly by a terminal emulator.
  153.  
  154.    To facilitate the effective use of programs supporting line/page
  155.    skips such as "more" on UNIX with a terminal emulator understanding
  156.    the HZ format, it is RECOMMENDED that the ENCODER (which outputs in
  157.    HZ) sets a maximum line size of less than 80 characters.  Since '\n'
  158.    is an ASCII character, the syntax of HZ then automatically implies
  159.    that GB codes appearing at the end of a line must be terminated with
  160.    the escape-from-GB code '~}', and the line-continuation marker '~\n'
  161.    should be inserted appropriately. The price to paid is that the
  162.    encoded file size is slightly larger.
  163.  
  164.    It is important to understand the following distinction.  Note that
  165.    the above recommendation does NOT change the HZ format.  It is simply
  166.    an encoding "style" which follows the syntax of HZ. Note that this
  167.  
  168.  
  169.  
  170. Lee                          Informational                      [Page 3]
  171.  
  172. RFC 1843        HZ - A Data Format for Exchanging Files      August 1995
  173.  
  174.  
  175.    "style" is not built into HZ. It is an additional convention built
  176.    "on top of" HZ.  Other applications may require different "styles",
  177.    but the same basic HZ DECODER will always work. The essence of HZ is
  178.    to provide such a flexible basic data format for files of arbitrarily
  179.    mixed Chinese and ASCII characters.
  180.  
  181. 4. Examples
  182.  
  183.    To illustrate the "stylistic" issue of HZ encoding, we give the
  184.    following four examples of encoded text, which should produce the
  185.    same decoded output. (The recommendation in the last section refers
  186.    to Example 2.)
  187.  
  188.    Example 1:  (Suppose there is no line size limit.)
  189.    This sentence is in ASCII.
  190.    The next sentence is in GB.~{<:Ky2;S{#,NpJ)l6HK!#~}Bye.
  191.  
  192.    Example 2:  (Suppose the maximum line size is 42.)
  193.    This sentence is in ASCII.
  194.    The next sentence is in GB.~{<:Ky2;S{#,~}~
  195.    ~{NpJ)l6HK!#~}Bye.
  196.  
  197.    Example 3: (Suppose a new line is started whenever there is a mode
  198.               switch.)
  199.    This sentence is in ASCII.
  200.    The next sentence is in GB.~
  201.    ~{<:Ky2;S{#,NpJ)l6HK!#~}~
  202.    Bye.
  203.  
  204. Acknowledgement
  205.  
  206.    Edmund Lai was the first one who brought my attention to this topic.
  207.    Discussions with Ed, Tin-Fook Ngai, Yagui Wei and Ricky Yeung were
  208.    very helpful in shaping the ideas in this article. Thanks to Tin-Fook
  209.    for his careful review of the draft and numerous interesting
  210.    suggestions.
  211.  
  212. References
  213.  
  214.    [1] Fung Fung Lee, "HZ - A Data Format for Exchanging Files of
  215.        Arbitrarily Mixed Chinese and ASCII Characters," September 4,
  216.        1989.
  217.        As part of //ftp.ifcss.org/software/unix/convert/HZ-2.0.tar.gz
  218.  
  219. Security Considerations
  220.  
  221.    Security issues are not addressed in this memo.
  222.  
  223.  
  224.  
  225.  
  226. Lee                          Informational                      [Page 4]
  227.  
  228. RFC 1843        HZ - A Data Format for Exchanging Files      August 1995
  229.  
  230.  
  231. Author's Address
  232.  
  233.    Fung Fung Lee
  234.    Computer Systems Laboratory
  235.    Stanford University
  236.    Stanford, CA 94309
  237.  
  238.    Phone: +1 415 723 1450
  239.    EMail: lee@csl.stanford.edu
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Lee                          Informational                      [Page 5]
  283.  
  284.