path: root/tools/encoding/cjk.inf

--- BEGIN (CJK.INF VERSION 2.1 07/12/96) 185553 BYTES ---
CJK.INF Version 2.1 (July 12, 1996)

Copyright (C) 1995-1996 Ken Lunde. All Rights Reserved.

CJK is a registered trademark and service mark of The Research
  Libraries Group, Inc.

Online Companion to "Understanding Japanese Information Processing"
- ENGLISH: 1993, O'Reilly & Associates, Inc., ISBN 1-56592-043-0
- JAPANESE: 1995, SOFTBANK Corporation, ISBN 4-89052-708-7


	This online document provides information on CJK (that is,
Chinese, Japanese, and Korean) character set standards and encoding
systems. In short, it provides detailed information on how CJK text is
handled electronically. I am happy to share this information with
others, and I would appreciate any comments/feedback on its content.
The current version (master copy) of this document is maintained at:

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/doc/cjk.inf

This file may also be obtained by contacting me directly using one of
the e-mail addresses listed in the CONTACT INFORMATION section.


TABLE OF CONTENTS

  VERSION HISTORY
  RESTRICTIONS
  CONTACT INFORMATION
  WHAT HAPPENED TO JAPAN.INF?
  DISCLAIMER
  CONVENTIONS
  INTRODUCTION
  PART 1: WHAT'S UP WITH UJIP?
  PART 2: CJK CHARACTER SET STANDARDS
    2.1: JAPANESE
      2.1.1: JIS X 0201-1976
      2.1.2: JIS X 0208-1990
      2.1.3: JIS X 0212-1990
      2.1.4: JIS X 0221-1995
      2.1.5: JIS X 0213-199X
      2.1.6: OBSOLETE STANDARDS
    2.2: CHINESE (PRC)
      2.2.1: GB 1988-89
      2.2.2: GB 2312-80
      2.2.3: GB 6345.1-86
      2.2.4: GB 7589-87
      2.2.5: GB 7590-87
      2.2.6: GB 8565.2-88
      2.2.7: GB/T 12345-90
      2.2.8: GB/T 13131-9X
      2.2.9: GB/T 13132-9X
      2.2.10: GB 13000.1-93
      2.2.11: ISO-IR-165:1992
      2.2.12: OBSOLETE STANDARDS
    2.3: CHINESE (TAIWAN)
      2.3.1: BIG FIVE
      2.3.2: CNS 11643-1992
      2.3.3: CNS 5205
      2.3.4: OBSOLETE STANDARDS
    2.4: KOREAN
      2.4.1: KS C 5636-1993
      2.4.2: KS C 5601-1992
      2.4.3: KS C 5657-1991
      2.4.4: GB 12052-89
      2.4.5: KS C 5700-1995
      2.4.6: OBSOLETE STANDARDS
    2.5: CJK
      2.5.1: ISO 10646-1:1993
      2.5.2: CCCII
      2.5.3: ANSI Z39.64-1989
    2.6: OTHER
      2.6.1: GB 8045-87
      2.6.2: TCVN-5773:1993
  PART 3: CJK ENCODING SYSTEMS
    3.1: 7-BIT ISO 2022 ENCODING
      3.1.1: CODE SPACE
      3.1.2: ISO-REGISTERED ESCAPE SEQUENCES
      3.1.3: ISO-2022-JP AND ISO-2022-JP-2
      3.1.4: ISO-2022-KR
      3.1.5: ISO-2022-CN AND ISO-2022-CN-EXT
    3.2: EUC ENCODING
      3.2.1: JAPANESE REPRESENTATION
      3.2.2: CHINESE (PRC) REPRESENTATION
      3.2.3: CHINESE (TAIWAN) REPRESENTATION
      3.2.4: KOREAN REPRESENTATION
    3.3: LOCALE-SPECIFIC ENCODINGS
      3.3.1: SHIFT-JIS
      3.3.2: HZ (HZ-GB-2312)
      3.3.3: zW
      3.3.4: BIG FIVE
      3.3.5: JOHAB
      3.3.6: N-BYTE HANGUL
      3.3.7: UCS-2
      3.3.8: UCS-4
      3.3.9: UTF-7
      3.3.10: UTF-8
      3.3.11: UTF-16
      3.3.12: ANSI Z39.64-1989
      3.3.13: BASE64
      3.3.14: IBM DBCS-HOST
      3.3.15: IBM DBCS-PC
      3.3.16: IBM DBCS-/TBCS-EUC
      3.3.17: UNIFIED HANGUL CODE
      3.3.18: TRON CODE
      3.3.19: GBK
    3.4: CJK CODE PAGES
  PART 4: CJK CHARACTER SET COMPATIBILITY ISSUES
    4.1: JAPANESE
    4.2: CHINESE (PRC)
    4.3: CHINESE (TAIWAN)
    4.4: KOREAN
    4.5: ISO 10646-1:1993
    4.6: UNICODE
    4.7: CODE CONVERSION TIPS
  PART 5: CJK-CAPABLE OPERATING SYSTEMS
    5.1: MS-DOS
    5.2: WINDOWS
    5.3: MACINTOSH
    5.4: UNIX AND X WINDOWS
    5.5: OTHERS
  PART 6: CJK TEXT AND INTERNET SERVICES
    6.1: ELECTRONIC MAIL
    6.2: USENET NEWS
    6.3: GOPHER
    6.4: WORLD-WIDE WEB
    6.5: FILE TRANSFER TIPS
  PART 7: CJK TEXT HANDLING SOFTWARE
    7.1: MULE
    7.2: CNPRINT
    7.3: MASS
    7.4: ADOBE TYPE MANAGER (ATM)
    7.5: MACINTOSH SOFTWARE
    7.6: MACBLUE TELNET
    7.7: CXTERM
    7.8: UW-DBM
    7.9: POSTSCRIPT
    7.10: NJWIN
  PART 8: CJK PROGRAMMING ISSUES
    8.1: C AND C++
    8.2: PERL
    8.3: JAVA
  A FINAL NOTE
  ACKNOWLEDGMENTS
  APPENDIX A: INFORMATION SOURCES
    A.1: USENET NEWSGROUPS AND MAILING LISTS
      A.1.1: USENET NEWSGROUPS
      A.1.2: MAILING LISTS
    A.2: INTERNET RESOURCES
      A.2.1: USEFUL FTP SITES
      A.2.2: USEFUL TELNET SITES
      A.2.3: USEFUL GOPHER SITES
      A.2.4: USEFUL WWW SITES
      A.2.5: USEFUL MAIL SERVERS
    A.3: OTHER RESOURCES
      A.3.1: BOOKS
      A.3.2: MAGAZINES
      A.3.3: JOURNALS
      A.3.4: RFCs
      A.3.5: FAQs


VERSION HISTORY

	The following is a complete listing of the earlier versions of
this document along with their release dates and sizes (in bytes):

  Document   Version  Release Date  Size
  ^^^^^^^^   ^^^^^^^  ^^^^^^^^^^^^  ^^^^
  JAPAN.INF  1.0      Unknown       Unknown
  JAPAN.INF  1.1      08/19/91      101,784
  JAPAN.INF  1.2      03/20/92      166,929 (JIS) or 165,639 (Shift-JIS/EUC)
  CJK.INF    1.0      06/09/95      103,985
  CJK.INF    1.1      06/12/95      112,771
  CJK.INF    1.2      06/14/95      125,275
  CJK.INF    1.3      06/16/95      130,069
  CJK.INF    1.4      06/19/95      142,543
  CJK.INF    1.5      06/22/95      146,064
  CJK.INF    1.6      06/29/95      150,882
  CJK.INF    1.7      08/15/95      153,772
  CJK.INF    1.8      09/11/95      157,295
  CJK.INF    1.9      12/18/95      170,698
  CJK.INF    2.0      03/12/96      175,973

With the release of this version, all of the above are now considered
obsolete. Also, note the three-year gap between the last installment
of JAPAN.INF and the first installment of CJK.INF -- I was writing
UJIP and my PhD dissertation during those three years. Ah, so much for
excuses...


RESTRICTIONS

	This document is provided free-of-charge to *anyone*, but no
person or company is permitted to modify, sell, or otherwise
distribute it for profit or other purposes. This document may be
bundled with commercial products only with the prior consent from the
author, and provided that it is not modified in any way whatsoever.
The point here is that I worked long and hard on this document so that
lots of fine folks and companies can benefit from its contents -- not
profit from it.


CONTACT INFORMATION

	I would enjoy hearing from readers of this document, even if
it is just to say "hello" or whatever. I can be contacted as follows:

  Ken Lunde
  Adobe Systems Incorporated
  1585 Charleston Road
  P.O. Box 7900
  Mountain View, CA 94039-7900 USA
  415-962-3866 (office phone)
  415-960-0886 (facsimile)
  lunde@adobe.com (preferred)
  lunde@ora.com or ujip@ora.com
  WWW Home Page: http://jasper.ora.com/lunde/

If you wonder what I do for my day job, read on.
	I have been working for Adobe Systems for over four years now
(before that I was a graduate student at UW-Madison), and my current
position is Project Manager, CJK Type Development.


WHAT HAPPENED TO JAPAN.INF?

	Put bluntly, JAPAN.INF died. It first evolved into my first
book entitled "Understanding Japanese Information Processing" (this
book is now into its second printing, and the Japanese translation was
just published). After my book came out, I did attempt to update
JAPAN.INF, but the effort felt a bit futile. I decided that something
fresh was necessary.
	JAPAN.INF also evolved into this document, which breaks the
Japanese barrier by providing similar information on Chinese and
Korean character sets and encodings. It fills the Chinese and Korean
gap, so to speak. My specialty (and hobby, believe it or not) is the
field of CJK character sets and encoding systems, so I felt that
shifting this document more towards those lines was appropriate use of
my (copious) free time (I wish there were more than 24 hours in a
day!). Besides, this document now becomes useful to a much broader
audience.


DISCLAIMER

	Ah yes, the ever popular disclaimer! Here's mine. Although I
list my address here at Adobe Systems Incorporated for contact
purposes, Adobe Systems does not endorse this document which I have
created, and have continued (and will continue) to update on a regular
basis (uh, yeah, I promise this time!). This document is a personal
endeavor to inform people of how CJK text can be handled on a variety
of platforms.


CONVENTIONS

	The notation that is used for detailing Internet resource
information, such as the Internet protocol type, site name, path, and
file follows the URL (Uniform Resource Locator) notation, namely:

  protocol://site-name/path/file

An example URL is as follows:

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/00README

The protocol is FTP, the site-name is ftp.ora.com, the path is pub/
examples/nutshell/ujip/, and the file is 00README. Also note that this
same notation is used for invoking FTP on WWW (World Wide Web)
browsing software, such as Mosaic, Netscape, or Lynx.
	Note that most references to HTTP documents use the four-
letter file extension ".html". However, some HTTP documents are on
file systems that support only three-letter file extensions (can you
say "MS-DOS"?), so you may encounter just ".htm". This is just to let
you know that what you see is not a typo.
	References to my book "Understanding Japanese Information
Processing" are (affectionately) abbreviated as UJIP. These references
also apply to the Japanese translation (UJIP-J).
	Hexadecimal values are prefixed with 0x, and every two
hexadecimal digits represent a one-byte value. Other values can be
assumed to be in decimal notation.
	Chinese characters are referred to as kanji (Japanese), hanzi
(Chinese), or hanja (Korean), depending on context.
	References to ISO 10646-1:1993 also refer to Unicode
(usually). I have done this so that I do not have to repeat "Unicode"
in the same context as ISO 10646-1:1993. There are times, however,
when I need to distinguish ISO 10646-1:1993 from Unicode.


INTRODUCTION

	Electronic mail (e-mail), just one of the many Internet
resources, has become a very efficient means of communicating both
locally and world-wide. While it is very simple to send text which
uses only the 94 printable ASCII characters, character sets that
contain more than these ASCII characters pose special problems.
	This document is primarily concerned with CJK character set
and encoding issues. Much of this sort of information is not easily
obtained. This represents one person's attempt at making such
information more widely available.


PART 1: WHAT'S UP WITH UJIP?

	UJIP (First Edition) was published in September 1993 by
O'Reilly & Associates, Incorporated. The second printing (*not* the
Second Edition) was subsequently published in March 1994. The page
count for both printings is unchanged at 470.
	The following files contain the latest information about
changes (additions and corrections) made to UJIP and UJIP-J for
various printings, both for those that have taken place (such as for
the second printing of the English edition) and for those that are
planned (the first digit is the edition, and the second is the
printing):

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/errata/ujip-errata-1-2.txt
  ftp://ftp.ora.com/pub/examples/nutshell/ujip/errata/ujip-errata-1-3.txt
  ftp://ftp.ora.com/pub/examples/nutshell/ujip/errata/ujip-j-errata-1-2.txt

I *highly* recommend that all readers of UJIP obtain these errata
files. Those without FTP access can request copies directly from me.
	The Japanese translation of UJIP (UJIP-J), co-published by
O'Reilly & Associates, Incorporated and SOFTBANK Corporation, was just
released. The translation was done by my good friend Jack Halpern,
along with one of his colleagues, Takeo Suzuki. The Japanese edition
incorporates corrections and updates not yet found in the English
edition. The page count is 535.
	Late-breaking news! I am currently working on UJIP Second
Edition (to be retitled as "Understanding CJK Information Processing"
and abbreviated UCJKIP). If all goes well, it should be available by
January 1997, and will be well over 700 pages. If there was something
you wanted to see in UJIP, now's your chance to send me a request...


PART 2: CJK CHARACTER SET STANDARDS

	These sections describe the character sets used in Japan,
China (PRC and Taiwan), and Korea. Exact numbers of characters are
provided for each character set standard (when known), as well as
tidbits of information not otherwise available. This provides the
basic foundations for understanding how CJK scripts are handled on
computer systems.
	The two basic types of characters enumerated by CJK character
set standards are Chinese characters (kanji, hanzi, or hanja), which
number in the thousands (and, in some cases, tens of thousands), and
characters other than Chinese characters (symbols, numerals, kana
hangul, alphabets, and so on), which usually number in the hundreds
(there are thousands of pre-combined hangul, though).
	If you happen to be running X Windows, it is very easy to
display these CJK character sets (if a bitmapped font for the
character set exists, that is). Here is what I usually do:

o Obtain a BDF (Bitmap Distribution Format) font for the target
  character set. Try the following URLs for starters:

  ftp://cair-archive.kaist.ac.kr/pub/hangul/fonts/
  ftp://etlport.etl.go.jp/pub/mule/fonts/
  ftp://ftp.ifcss.org/pub/software/fonts/{big5,cns,gb,misc,unicode}/bdf/
  ftp://ftp.kuis.kyoto-u.ac.jp/misc/fonts/jisksp-fonts/
  ftp://ftp.net.tsinghua.edu.cn/pub/Chinese/fonts/
  ftp://ftp.ora.com/pub/examples/nutshell/ujip/unix/
  ftp://ftp.technet.sg:/pub/chinese/fonts/
  http://ccic.ifcss.org/www/pub/software/fonts/

  BDF files usually have the string "bdf" somewhere in their file
  name, usually at the end. If the file is compressed (noticing that
  it ends in .gz or .Z is a good indication), decompress it. BDF files
  are text files.

o Convert the BDF file to SNF (Server Natural Format) or PCF (Portable
  Compiled Format) using the programs "bdftosnf" or "bdftopcf,"
  respectively. Example command lines are as follows:

  % bdftopcf jiskan16-1990.bdf > k16-90.pcf
  % bdftosnf jiskan16-1990.bdf > k16-90.snf

  SNF files (and the "bdftosnf" program) are used on X11R4 and
  earlier, and PCF files (and the "bdftopcf" program) are used on
  X11R5 and later.

o Copy the SNF or PCF file to a directory in the font search path (or
  make a new path). Supposing I made a new directory called "fonts" in
  my home directory, I then run "mkfontdir" on the directory
  containing the SNF or PCF files as follows:

  % mkfontdir ~/fonts

  This creates a fonts.dir file in ~/fonts. I can now add this
  directory to my font search path with the following command:

  % xset +fp ~/fonts

o The command "xfd" (X Font Displayer) with the "-fn" switch followed
  by a font name then invokes a window that displays all the
  characters of the font. In the case of two-byte (CJK) fonts, one row
  is displayed at a time. The following is an example command line:

  % xfd -fn -misc-fixed-medium-r-normal--16-150-75-75-c-160-jisx0208.1990-0

  You can create a "fonts.alias" file in the same directory as the
  "fonts.dir" file in order to shorten the name when accessing the
  font. The alias "k16-90" could be used instead if the content of the
  fonts.alias file is as follows:

  k16-90  -misc-fixed-medium-r-normal--16-150-75-75-c-160-jisx0208.1990-0

  Don't forget to execute the following command in order to make the
  X Font Server aware of the new alias:

  % xset fp rehash

  Now you can use a simpler command line for "xfd" as follows:

  % xfd -fn k16-90

	The "X Window System User's Guide" (Volume 3 of the X Window
System series by O'Reilly & Associates, Inc.) provides detailed
information on managing fonts under X Windows (pp 123-160). The
article entitled "The X Administrator: Font Formats and Utilities" (pp
14-34 in "The X Resource," Issue 2), describes the BDF, SNF, and PCF
formats in great detail.
	There is another bitmap format called HBF (Hanzi Bitmap
Format), which is similar to BDF, but optimized for fixed-width
(monospaced) fonts. It is described in the article entitled "The HBF
Font Format: Optimizing Fixed-pitch Font Support" (pp 113-123 in "The
X Resource," Issue 10), and also at the following URL:

  ftp://ftp.ifcss.org/pub/software/fonts/hbf-discussion/

HBF fonts can be found at the following URL:

  ftp://ftp.ifcss.org/pub/software/fonts/{big5,cns,gb,misc,unicode}/hbf/

	Lastly, you may wish to check out my newly-developed CJK
Character Set Server, which generates various CJK character sets with
proper encoding applied. It is written in Perl, and accessed through
an HTML form. This server can be considered an upgrade to my JChar
tool (written in C). The URL is:

  http://jasper.ora.com/lunde/cjk-char.html


2.1: JAPANESE

	All (national) character set standards that originate in Japan
have names that begin with the three letters JIS. JIS is short for
"Japanese Industrial Standard." But it is JSA (Japanese Standards
Association) who publishes the corresponding manuals. Chapter 3 and
Appendixes H and J of UJIP provide more detailed information on
Japanese character set standards.


2.1.1: JIS X 0201-1976

	JIS X 0201-1976 (formerly JIS C 6220-1969; reaffirmed in 1989;
and its revision [with no character set changes] is currently under
public review) enumerates two sets of characters: JIS-Roman and
half-width katakana.
	JIS-Roman is the Japanese equivalent of the ASCII character
set, namely 128 characters consisting of the following:

o 10 numerals
o 52 uppercase and lowercase characters of the Latin alphabet
o 32 symbols (punctuation and so on)
o 34 non-printing characters (white space and control characters)

The term "white space" refers to characters that occupy space, but
have no appearance, such as tabs, spaces, and termination characters
(line feed, carriage return, and form feed).
	So, how are JIS-Roman and ASCII different? The following
three codes are (usually) different:

  Code   ASCII        JIS-Roman
  ^^^^   ^^^^^        ^^^^^^^^^
  0x5C   backslash    yen symbol
  0x7C   broken bar   bar
  0x7E   tilde        overbar

	Half-width katakana consists of 63 characters that provide a
minimal set of characters necessary for expressing Japanese. The
shapes are compressed, and visually occupy a space half that of
*normal* Japanese characters.


2.1.2: JIS X 0208-1990

	This basic Japanese character set standard enumerates 6,879
characters, 6,355 of which are kanji separated into two levels. Kanji
in the first level are arranged by (most frequent) reading, and those
in the second level are arranged by radical then total number of
(remaining) strokes.

o Row 1: 94 symbols
o Row 2: 53 symbols
o Row 3: 10 numerals and 52 uppercase and lowercase Latin alphabet
o Row 4: 83 hiragana
o Row 5: 86 katakana
o Row 6: 48 uppercase and lowercase Greek alphabet
o Row 7: 66 uppercase and lowercase Cyrillic (Russian) alphabet
o Row 8: 32 line-drawing elements
o Rows 16 through 47: 2,965 kanji (JIS Level 1 Kanji; last is 47-51)
o Rows 48 through 84: 3,390 kanji (JIS Level 2 Kanji; last is 84-06)

Appendix B of UJIP provides a complete illustration of the JIS X
0208-1990 character set standard by KUTEN (row-cell) code. Appendix G
(pp 294-317) of "Developing International Software for Windows 95 and
Windows NT" by Nadine Kano illustrates the JIS X 0208-1990 character
set standard plus the Microsoft extensions by Shift-JIS code
(Microsoft calls this Code Page 932).
	Earlier versions of this standard were dated 1978 (JIS C
6226-1978) and 1983 (JIS X 0208-1983, formerly JIS C 6226-1983).
	JIS X 0208 went through a revision (from November 1995 until
February 1996), and is slated for publication sometime in 1996 (to
become JIS X 0208-1996). More information on this revision is
available at the following URL:

  ftp://ftp.tiu.ac.jp/jis/jisx0208/


2.1.3: JIS X 0212-1990

	This supplemental Japanese character set standard enumerates
6,067 characters, 5,801 of which are kanji ordered by radical then
total number of (remaining) strokes. All 5,801 kanji are unique when
compared to those in JIS X 0208-1990 (see Section 2.1.2). The
remaining 266 characters are categorized as non-kanji.

o Row 2: 21 diacritics and symbols
o Row 6: 21 Greek characters with diacritics
o Row 7: 26 Eastern European characters
o Rows 9 through 11: 198 alphabetic characters
o Rows 16 through 77: 5,801 kanji (last is 77-67)

Appendix C of UJIP provides a complete illustration of the JIS X
0212-1990 character set standard by KUTEN (row-cell) code.
	The only commercial operating system that provides JIS X
0212-1990 support is BTRON by Personal Media Corporation:

  http://www.personal-media.co.jp/

Section 3.3.18 provides information about TRON Code (used by BTRON),
and details how it encodes the JIS X 0212-1990 character set.


2.1.4: JIS X 0221-1995

	This document is, for all practical purposes, the Japanese
translation of ISO 10646-1:1993 (see Section 2.5.1). Like ISO
10646-1:1993, it is based on Unicode Version 1.1.
	It is noteworthy that JIS X 0221-1995 enumerates subsets that
are applicable for Japanese use (a brief description of their contents
in parentheses):

o BASIC JAPANESE (JIS X 0208-1990 and JIS X 0201-1976 -- characters
  that can be created by means of combining are not included -- 6,884
  characters)
o JAPANESE NON IDEOGRAPHICS SUPPLEMENT (1,913 characters: all non-
  kanji of JIS X 0212-1990 plus hundreds of non-JIS characters)
o JAPANESE IDEOGRAPHICS SUPPLEMENT 1 (918 frequently-used kanji from
  JIS X 0212-1990, including 28 that are identical to kanji forms in
  JIS C 6226-1978)
o JAPANESE IDEOGRAPHICS SUPPLEMENT 2 (the remainder of JIS X 0212-
  1990, namely 4,883 kanji)
o JAPANESE IDEOGRAPHICS SUPPLEMENT 3 (the remaining kanji of ISO
  10646-1:1993, namely 8,746 characters)
o FULLWIDTH ALPHANUMERICS (94 characters; for compatibility)
o HALFWIDTH KATAKANA (63 characters; for compatibility)

	Pages 893 through 993 provide Kangxi Zidian (a classic
300-year-old Chinese character dictionary containing approximately
50,000 characters) and Dai Kanwa Jiten (also known as Morohashi)
indexes for the entire Chinese character block, namely from 0x4E00
through 0x9FA5.
	At 25,750 Yen, it is actually cheaper than ISO 10646-1:1993!


2.1.5: JIS X 0213-199X

	I recently became aware that JSA plans to publish an extension
to JIS X 0208, containing approximately 2,000 characters (kanji and
non-kanji). A public review of this new standard is planned for Summer
1996. I would expect that its information will eventually be available
at the following URL:

    ftp://ftp.tiu.ac.jp/jis/


2.1.6: OBSOLETE STANDARDS

	JIS C 6226-1978 and JIS X 0208-1983 (formerly JIS C 6226-1983)
have been superseded by JIS X 0208-1990. Section 4.1 provides details
on the changes made between these earlier versions of JIS X 0208.
	JIS X 0221-1995 does not mean the end of JIS X 0201-1976, JIS
X 0208-1990, and JIS X 0212-1990. Instead, it will co-exist with those
standards.


2.2: CHINESE (PRC)

	All character set standards that originate in PRC have
designations that begin with "GB." "GB" is short for "Guo Biao" (which
is, in turn, short for "Guojia Biaojun") and means "National
Standard." A select few also have "/T" attached. The "T" presumably is
short for "Traditional." Section 2.2.11 describes ISO-IR-165:1992,
which is a variant of GB 2312-80. It is included here because of this
relationship.
	Most people correlate GB character set standards with
simplified Chinese, but as you will see below, that is not always the
case.
	There are three basic character sets, each one having a
simplified and traditional version.

  Character Set  Set Number  Character Forms
  ^^^^^^^^^^^^^  ^^^^^^^^^^  ^^^^^^^^^^^^^^^
  GB 2312-80     0           Simplified
  GB/T 12345-90  1           Traditional of GB 2312-80
  GB 7589-87     2           Simplified
  GB/T 13131-9X  3           Traditional of GB 7589-87
  GB 7590-87     4           Simplified
  GB/T 13132-9X  5           Traditional of GB 7590-87


2.2.1: GB 1988-89

	This character set, formerly GB 1988-80 and sometimes referred
to as GB-Roman, is the Chinese analog to ASCII and ISO 646. The main
difference is that the currency symbol (0x24), which is represented as
a dollar sign ($) in ASCII, is represented as a Chinese Yuan
(currency) symbol instead. GB 1988-89 is sometimes referred to as
GB-Roman.


2.2.2: GB 2312-80

	This basic (simplified) Chinese character set standard
enumerates 7,445 characters, 6,763 of which are hanzi separated into
two levels. Hanzi in the first level are arranged by reading, and
those in the second level are arranges by radical then total number of
(remaining) strokes. GB 2312-80 is also known as the "Primary Set,"
GB0 (zero), or just GB.

o Row 1: 94 symbols
o Row 2: 72 numerals
o Row 3: 94 full-width GB 1988-89 characters (see Section 2.2.1)
o Row 4: 83 hiragana
o Row 5: 86 katakana
o Row 6: 48 uppercase and lowercase Greek alphabet
o Row 7: 66 uppercase and lowercase Cyrillic (Russian) alphabet
o Row 8: 26 Pinyin and 37 Bopomofo characters
o Row 9: 76 line-drawing elements (09-04 through 09-79)
o Rows 16 through 55: 3,755 hanzi (Level 1 Hanzi; last is 55-89)
o Rows 56 through 87: 3,008 hanzi (Level 2 Hanzi; last is 87-94)

Compare some of the structure with JIS X 0208-1990, and you will find
many similarities, such as:

o Hiragana, katakana, Greek, and Cyrillic characters are in Rows 4, 5,
  6, and 7, respectively
o Chinese characters begin at Row 16
o Chinese characters are separated into two levels
o Level 1 arranged by reading
o Level 2 arranged by radical then total number of strokes

The Japanese standard, JIS C 6226-1978, came out in 1978, which means
that it pre-dates GB 2312-80. The above similarities could not be by
coincidence, but rather by design.
	Appendix G (pp 318-344) of "Developing International Software
for Windows 95 and Windows NT" by Nadine Kano illustrates the GB 2312-
80 character set standard by EUC code (Microsoft calls this Code Page
936). Code Page 936 incorporates the correction of the hanzi at 79-81,
and the correction of the order of 07-22 and 07-23 (see Section 2.2.3
for more details).


2.2.3: GB 6345.1-86

	This document specifies corrections and additions to GB
2312-80 (see Section 2.2.2). The following is a detailed enumeration
of the changes:

o The form of "g" in Row 3 (position 71) was altered
o Row 8 has six additional Pinyin characters (08-27 through 08-32)
o Row 10 contains half-width versions of Row 3 (94 characters)
o Row 11 contains half-width versions of the Pinyin characters from
  Row 8 (32 characters; 11-01 through 11-32)
o The hanzi at 79-81 was corrected to have a simplified left-side
  radical (this was an error in GB 2312-80)

Note that these changes affect the total number of characters in GB
2312-80 -- an increase of 132 characters. This now makes 7,577 as
the total number of characters in GB 2312-80 (7,445 plus 132).
	There was, however, an undocumented correction made in GB
6345.1-86. The order of characters 07-22 and 07-23 (uppercase
Cyrillic) were reversed. This error is apparently in the first and
perhaps second printing of the GB 2312-80 manual, because the copy I
have is from the third printing, and this has been corrected. Page 145
(Figure 113) of John Clews' "Language Automation Worldwide: The
Development of Character Set Standards" illustrates this error.
Developers should take special note of this -- I have seen GB 2312-80
based font products that propagate this ordering error.


2.2.4: GB 7589-87

	This character set enumerates 7,237 hanzi in Rows 16 through
92 (last is 92-93), and they are ordered by radical then total number
of (remaining) strokes. GB 7589-87 is also known as the "Second
Supplementary Set" or GB2.


2.2.5: GB 7590-87

	This character set enumerates 7,039 hanzi in Rows 16 through
90 (last is 90-83), and they are ordered by radical then total number
of (remaining) strokes. GB 7590-87 is also known as the "Fourth
Supplementary Set" or GB4.


2.2.6: GB 8565.2-88

	This standard makes additions to GB 2312-80 (these additions
are separate from those made in GB 6345.1-86 described in Section
2.2.3). GB 8565.2-88 is also known as GB8. In this case there are 705
additions, indicated as follows:

o Row 13 contains 50 hanzi from GB 7589-87 (last is 13-50)
o Row 14 contains 92 hanzi from GB 7590-87 (last is 14-92)
o Row 15 contains 69 non-hanzi indicating dates and times, plus 24
  miscellaneous hanzi (for personal/place names and radicals; last is
  15-93).
o Rows 90 through 94 contain 470 hanzi from GB 7589-87 (94 each)

GB 8565.2-88 therefore provides a total of 8,150 characters (7,445
plus 705).


2.2.7: GB/T 12345-90

	This character set is nearly identical to GB 2312-80 (see
Section 2.2.2) in terms of the number and arrangement of characters,
but simplified hanzi are replaced by their traditional versions. GB/T
12345-90 is also known as the "Supplementary Set" or GB1.
	The following are some interesting facts about this character
set (some instances of simplified/traditional pairs that appear below
are actually character form differences):

o 29 vertical-use characters (punctuation and parentheses) included in
  Row 6 (06-57 through 06-85).

o 2,118 traditional hanzi replace simplified hanzi in Rows 16 through
  87. The "G1-Unique" appendix of the unofficial version (supplied to
  the CJK-JRG for Han Unification purposes) is missing the following
  four (specifies only 2,114):

  0x5B3B    0x6D2F
  0x5E7C    0x6F71

  But, ISO 10646-1:1993 ended up getting these hanzi included anyway,
  with correct mappings.

o Four simplified/traditional hanzi pairs (eight affected code points)
  in rows 16 through 87 are swapped:

  0x3A73 <-> 0x6161
  0x5577 <-> 0x6167
  0x5360 <-> 0x6245 (see the next bullet)
  0x4334 <-> 0x7761

o One hanzi (0x6245), after being swapped, had its left-side radical
  unsimplified (this character, now at 0x5360, is considered part of
  the 2,118 traditional hanzi from the second bullet):

  0x6245 -> 0x5360

o 103 hanzi included in Rows 88 (94 characters) and 89 (9 characters;
  89-01 through 89-09). These are all related to characters between
  Rows 16 and 87.

  - 41 simplified hanzi from Rows 16 through 87 moved to Rows 88 and
    89 (traditional hanzi are now at the original code points):

    0x3327 -> 0x7827  0x3E5D -> 0x7846  0x4B49 -> 0x7869
    0x3365 -> 0x7828  0x3F64 -> 0x7849  0x4C28 -> 0x786B
    0x3373 -> 0x7829  0x402F -> 0x784B  0x4D3F -> 0x786F
    0x3533 -> 0x782C  0x4030 -> 0x784C  0x4D72 -> 0x7871
    0x356D -> 0x782D  0x406F -> 0x784E  0x5236 -> 0x7878
    0x3637 -> 0x782F  0x4131 -> 0x7850  0x5374 -> 0x7879
    0x3736 -> 0x7832  0x463B -> 0x785C  0x5438 -> 0x787C
    0x3761 -> 0x7833  0x463E -> 0x785D  0x5446 -> 0x787D
    0x3849 -> 0x7835  0x464B -> 0x785E  0x5622 -> 0x7921
    0x3963 -> 0x7838  0x464D -> 0x785F  0x563B -> 0x7923
    0x3B2E -> 0x783B  0x4653 -> 0x7860  0x5656 -> 0x7926
    0x3C38 -> 0x7840  0x4837 -> 0x7866  0x567E -> 0x7928
    0x3C5B -> 0x7842  0x4961 -> 0x7867  0x573C -> 0x7929
    0x3C76 -> 0x7843  0x4A75 -> 0x7868

  - 62 hanzi added to Rows 88 and 89 (the gaps from the above are
    filled in). These were mostly to account for multiple traditional
    hanzi collapsing into a single simplified form.

  - The following code point mappings illustrate how all of these 103
    hanzi are related to hanzi between Rows 16 and 87 (note how many
    of these 103 hanzi map to a single code point):

    0x7821 -> 0x305A  0x7844 -> 0x3D2A  0x7867 -> 0x4961
    0x7822 -> 0x3065  0x7845 -> 0x3E21  0x7868 -> 0x4A75
    0x7823 -> 0x316D  0x7846 -> 0x3E5D  0x7869 -> 0x4B49
    0x7824 -> 0x3170  0x7847 -> 0x3E6D  0x786A -> 0x4B55
    0x7825 -> 0x3237  0x7848 -> 0x3F4B  0x786B -> 0x4C28
    0x7826 -> 0x3245  0x7849 -> 0x3F64  0x786C -> 0x4C28
    0x7827 -> 0x3327  0x784A -> 0x4027  0x786D -> 0x4C28
    0x7828 -> 0x3365  0x784B -> 0x402F  0x786E -> 0x4C33
    0x7829 -> 0x3373  0x784C -> 0x4030  0x786F -> 0x4D3F
    0x782A -> 0x3376  0x784D -> 0x405B  0x7870 -> 0x4D45
    0x782B -> 0x3531  0x784E -> 0x406F  0x7871 -> 0x4D72
    0x782C -> 0x3533  0x784F -> 0x407A  0x7872 -> 0x4F35
    0x782D -> 0x356D  0x7850 -> 0x4131  0x7873 -> 0x4F35
    0x782E -> 0x362C  0x7851 -> 0x414B  0x7874 -> 0x4F4C
    0x782F -> 0x3637  0x7852 -> 0x4231  0x7875 -> 0x4F72
    0x7830 -> 0x3671  0x7853 -> 0x425E  0x7876 -> 0x506B
    0x7831 -> 0x3722  0x7854 -> 0x4339  0x7877 -> 0x5229
    0x7832 -> 0x3736  0x7855 -> 0x4349  0x7878 -> 0x5236
    0x7833 -> 0x3761  0x7856 -> 0x4349  0x7879 -> 0x5374
    0x7834 -> 0x3834  0x7857 -> 0x4349  0x787A -> 0x5379
    0x7835 -> 0x3849  0x7858 -> 0x4356  0x787B -> 0x5375
    0x7836 -> 0x3948  0x7859 -> 0x4366  0x787C -> 0x5438
    0x7837 -> 0x394E  0x785A -> 0x436F  0x787D -> 0x5446
    0x7838 -> 0x3963  0x785B -> 0x3159  0x787E -> 0x5460
    0x7839 -> 0x6358  0x785C -> 0x463B  0x7921 -> 0x5622
    0x783A -> 0x3A7A  0x785D -> 0x463E  0x7922 -> 0x563B
    0x783B -> 0x3B2E  0x785E -> 0x464B  0x7923 -> 0x563B
    0x783C -> 0x3B58  0x785F -> 0x464D  0x7924 -> 0x5642
    0x783D -> 0x3B63  0x7860 -> 0x4653  0x7925 -> 0x5646
    0x783E -> 0x3B71  0x7861 -> 0x4727  0x7926 -> 0x5656
    0x783F -> 0x3C22  0x7862 -> 0x4729  0x7927 -> 0x566C
    0x7840 -> 0x3C38  0x7863 -> 0x4F4B  0x7928 -> 0x567E
    0x7841 -> 0x3C52  0x7864 -> 0x476F  0x7929 -> 0x573C
    0x7842 -> 0x3C5B  0x7865 -> 0x477A
    0x7843 -> 0x3C76  0x7866 -> 0x4837

So, if we total everything up, we see that GB/T 12345-90 has 2,180
hanzi (2,118 are replacements for GB 2312-80 code points, and 62 are
additional) and 29 non-hanzi not found in GB 2312-80.
	Note that the printing of the GB/T 12345-90 has some
character-form errors. The errors I am aware of are as follows:

  Code Point  Description of Error
  ^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^
  0x4125      The upper-left element should be "tree" instead of
              "warrior"
  0x596C      The "bird" radical should not include the "fire" element


2.2.8: GB/T 13131-9X

	This character set is identical to GB 7589-87 (see Section
2.2.4) in terms of number of characters, but simplified hanzi are
replaced by their traditional versions. The exact number of such
substitutions is currently unknown to this author. GB/T 13131-9X is
also known as the "Third Supplementary Set" or GB3.


2.2.9: GB/T 13132-9X

	This character set is identical to GB 7590-87 (see Section
2.2.5) in terms of number of characters, but simplified hanzi are
replaced by their traditional versions. The exact number of such
substitutions is currently unknown to this author. GB/T 13132-9X is
also known as the "Fifth Supplementary Set" or GB5.


2.2.10: GB 13000.1-93

	This document is, for all practical purposes, the Chinese
translation of ISO 10646-1:1993 (see Section 2.5.1).


2.2.11: ISO-IR-165:1992

	This standard, also known as the CCITT Chinese Set, is a
variant of GB 2312-80 with the following characteristics:

o GB 6345.1-86 modifications (including the undocumented one) and
  additions, namely 132 characters (see Section 2.2.3)
o GB 8565.2-88 additions, namely 705 characters (see Section 2.2.6)
o Row 6 contains 22 background (shading) characters (06-60 through
  06-81)
o Row 12 contains 94 hanzi
o Row 13 contains 44 additional hanzi (13-51 through 13-94; fills the
  row)
o Row 15 contains 1 additional hanzi (15-94)

ISO-IR-165:1992 can therefore be considered a superset of GB 2312-80,
GB 6345.1-86, and GB 8565.2-88. This means 8,443 total characters
compared to the 7,445 in GB 2312-80, 7,577 in GB 6345.1-86, and the
8,150 in GB 8565.2-88.


2.2.12: OBSOLETE STANDARDS

	Most GB standards seem to be revised through other documents,
so it is hard to point to a standard and claim that it is obsolete.
The only revision I am aware of is the GB 1988-89 (the original was
named GB 1988-80).


2.3: CHINESE (TAIWAN)

	The sections below describe two major Taiwanese character
sets, namely Big Five and CNS 11643-1992. As you will learn they are
somewhat compatible. CCCII, also developed in Taiwan, is described in
Section 2.5.2.


2.3.1: BIG FIVE

	The Big Five character set is composed of 94 rows of 157
characters each (the 157 characters of each row are encoded in an
initial group of 63 codes followed by the remaining 94 codes). The
following is a break-down of its contents:

o Row 1: 157 symbols
o Row 2: 157 symbols
o Row 3: 94 symbols
o Rows 4 through 38: 5,401 hanzi (Level 1 Hanzi; last is 38-63)
o Rows 41 through 89: 7,652 hanzi (Level 2 Hanzi; last is 89-116)

This forms what I consider to be the basic Big Five set. Actually, two
of the hanzi in Level 2 are duplicates, so there are actually only
7,650 unique hanzi in Level 2.
	There are two major extensions to Big Five. The first really
has no name, and can be considered part of the basic Big Five set as
specified above. It adds the following characters:

o Rows 38-39: 4 Japanese iteration marks, 83 hiragana, 86 katakana, 66
  uppercase and lowercase Cyrillic (Russian) alphabet, 10 circled
  digits, and 10 parenthesized digits

	The other extension was developed by a company called ETen
Information System in Taiwan, and is actually considered to be the
most widely used version of Big Five. It provides the following
extensions to Big Five (different from the above extension):

o Rows 38-40: 10 circled digits, 10 parenthesized digits, 10 lowercase
  Roman numerals, 25 classical radicals, 15 Japanese-specific symbols,
  83 hiragana, 86 katakana, 66 uppercase and lowercase Cyrillic
  (Russian) alphabet, 3 arrows, 10 radical-like hanzi elements, 40
  fraction-like digits, and 7 symbols
o Row 89: 7 hanzi, 33 double-lined line-drawing elements, and a black
  box

	It is *very* important to note that while these two extensions
have many common portions (in particular, hiragana, katakana, the
Cyrillic alphabet, and so on), they do not share the same code points
for such characters.
	Appendix G (pp 407-450) of "Developing International Software
for Windows 95 and Windows NT" by Nadine Kano illustrates the Big Five
character set standard by Big Five code (Microsoft calls this Code
Page 950). Code Page 950 incorporates some of the ETen extensions,
namely those in Row 89.


2.3.2: CNS 11643-1992

	CNS 11643-1992 (also known as CNS 11643 X 5012), by
definition, consists of 16 planes of characters, seven of which have
character assignments. Each plane is a 94-row-by-94-cell matrix
capable of holding a total of 8,836 characters. CNS stands for
"Chinese National Standard."
	CNS 11643-1992 specifies characters only in the first seven
planes. A break-down of characters, by plane, is as follows:

o Plane 1:
  - 438 symbols in Rows 1 through 6
  - 213 classical radicals in Rows 7 through 9
  - 33 graphic representations of control characters in Row 34
  - 5,401 hanzi in Rows 36 through 93 (last is 93-43)
o Plane 2: 7,650 hanzi in Rows 1 through 82 (last is 82-36)
o Plane 3: 6,148 hanzi in Rows 1 through 66 (last is 66-38)
o Plane 4: 7,298 hanzi in Rows 1 through 78 (last is 78-60)
o Plane 5: 8,603 hanzi in Rows 1 through 92 (last is 92-49)
o Plane 6: 6,388 hanzi in Rows 1 through 68 (last is 68-90)
o Plane 7: 6,539 hanzi in Rows 1 through 70 (last is 70-53)

The total number of characters in CNS 11643-1992 is a staggering
48,711 characters, 48,027 of which are hanzi. Also note that number of
hanzi in Plane 1 is identical to Level 1 hanzi of Big Five (see
Section 2.3.1). The 2 extra hanzi in Level 2 hanzi of Big Five are
actually redundant, and are therefore not in CNS 11643-1992 Plane 2.
	It is rumored that Plane 8 is currently being defined, and
will add yet more hanzi to this standard.


2.3.3: CNS 5205

	This character set is Taiwan's analog to ASCII and ISO 646,
and is reportedly rarely used. How it differs from ASCII, if at all,
is unknown to this author.


2.3.4: OBSOLETE STANDARDS

	CNS 11643-1986 specified characters only in the first three
planes, as described in Section 2.3.2. Also, Plane 3 of CNS 11643-1992
was called Plane 14 of CNS 11643-1986.


2.4: KOREAN

	The sections below describe the most current Korean character
sets, namely KS C 5636-1993, KS C 5601-1992, KS C 5657-1991, and KS C
5700-1995. "KS" stands for "Korean Standard."


2.4.1: KS C 5636-1993

	This character set (published on January 6, 1993), formerly KS
C 5636-1989 (published on April 22, 1989) and sometimes referred to as
KS-Roman, is the Korean analog to ASCII and ISO 646-1991. The primary
difference is that the ASCII backslash (0x5C) is represented as a Won
symbol.


2.4.2: KS C 5601-1992

	This basic Korean character set standard enumerates 8,224
characters, 4,888 of which are hanja, and 2,350 of which are pre-
combined hangul. The hanja and hangul blocks are arranged by reading.
The following is a break-down of its contents:

o Row 1: 94 symbols
o Row 2: 69 abbreviations and symbols
o Row 3: 94 full-width KS C 5636-1993 characters (see Section 2.4.1)
o Row 4: 94 hangul elements
o Row 5: 68 lowercase and uppercase Roman numerals and lowercase and
  uppercase Greek alphabet
o Row 6: 68 line-drawing elements
o Row 7: 79 abbreviations
o Row 8: 91 phonetic symbols, circled characters, and fractions
o Row 9: 94 phonetic symbols, parenthesized characters, subscripts,
  and superscripts
o Row 10: 83 hiragana
o Row 11: 86 katakana
o Row 12: 66 lowercase and uppercase Cyrillic (Russian) alphabet
o Rows 16 through 40: 2,350 pre-combined hangul (last is 40-94)
o Rows 42 through 93: 4,888 hanja (last is 93-94)

Rows 41 and 94 are designated for user-defined characters.
	There are many similarities with JIS X 0208-1990 and GB
2312-80, such as hiragana, katakana, Greek, and Cyrillic characters,
but they are assigned to different rows.
	There is an interesting note about the hanja block (Rows 42
through 93). Although there are 4,888 hanja, not all are unique. The
hanja block is arranged by reading, and in those cases when a hanja
has more than one reading, that hanja is duplicated (sometimes more
than once) in the same character set. There are 268 such cases of
duplicate hanja in KS C 5601-1992, meaning that it contains 4,620
unique hanja. If you have a copy of the KS C 5601-1992 manual handy,
you can compare the following four code points:

  0x6445
  0x5162
  0x5525
  0x6879

While most of these cases involve two hanja instances, there are four
hanja that have three instances, and one (listed above) that has four!
This is the only CJK character set that has this property of
intentionally duplicating Chinese characters. See Section 4.4 for more
details.
	Annex 3 of this standard defines the complete set of 11,172
pre-combined hangul characters, also known as Johab. Johab refers to
the encoding method, and is almost like encoding all possible three-
letter words (meaning that most are nonsense). See Section 3.3.5 for
more details on Johab encoding.


2.4.3: KS C 5657-1991

	This character set standard provides supplemental characters
for Korean writing, to include symbols, pre-combined hangul, and
hanja. The following is a break-down of its contents:

o Rows 1 through 7: 613 lowercase and uppercase Latin characters with
  diacritics (see note below)
o Rows 8 through 10: 273 lowercase and uppercase Greek characters with
  diacritics
o Rows 11 through 13: 275 symbols
o Row 14: 27 compound hangul elements
o Rows 16 through 36: 1,930 pre-combined hangul (last is 36-50)
o Rows 37 through 54: 1,675 pre-combined hangul (last is 54-77; see
  note below)
o Rows 55 through 85: 2,856 hanja (last is 85-36)

The KS C 5657-1991 manual has a possible error (or at least an
inconsistency) for Rows 1 through 7. The manual says that there are
615 characters in that range, but I only counted 613. The difference
can be found on page 19 as the following two characters:

  Character Code  Character
  ^^^^^^^^^^^^^^  ^^^^^^^^^
  0x2137          X
  0x217A          TM

An "X" doesn't belong there (it is already in KS C 5601-1992 at code
point 0x2358), and the trademark symbol is also part of KS C 5601-1992
at code point 0x2262. This is why I feel that my count of 613 is more
accurate than what is explicitly stated in the manual on page 2.
	Also, page 2 of the manual says that Rows 37 through 54
contains 1,677 pre-combined hangul, but I only counted 1,675 (17 rows
of 94 characters plus a final row with 77 characters -- do the math
for yourself).
	Here's another interesting note. My official copy of this
standard has all of its 2,856 hanja hand-written.


2.4.4: GB 12052-89

	You may be asking yourself why a GB standard is listed under
the Korean section of this document. Well, there is a rather large
Korean population in China (Korea was considered part of China before
the 1890s), and they need a character set standard for communicating
using hangul. GB 12052-89 is a Korean character set standard
established by China (PRC), and enumerates a total of 5,979
characters.
	The following is the arrangement of this character set:

o Row 1: 94 symbols
o Row 2: 72 numerals
o Row 3: 94 full-width ASCII characters
o Row 4: 83 hiragana
o Row 5: 86 katakana
o Row 6: 48 uppercase and lowercase Greek alphabet
o Row 7: 66 uppercase and lowercase Cyrillic (Russian) alphabet
o Row 8: 26 Pinyin and 37 Bopomofo characters
o Row 9: 76 line-drawing elements (09-04 through 09-79)
o Rows 16 through 37: 2,068 pre-combined hangul (Level 1 Hangul, Part
  1; last is 37-94)
o Rows 38 through 52: 1,356 pre-combined hangul (Level 1 Hangul, Part
  2; last is 52-40)
o Rows 53 through 71: 1,779 pre-combined hangul (Level 2 Hangul; last
  is 71-87)
o Rows 71 through 72: 94 "Idu" hanja (71-89 through 72-88)

	There are a few interesting notes I can make about this
character set:

o Rows 1 through 9 are identical to the same rows in GB 2312-80,
  except that 03-04 is a dollar sign, not a Chinese Yuan (currency)
  symbol.

o The GB 12052-89 manual states on pp 1 and 3 that Rows 53 through 72
  contain 1,876 characters, but I only counted 1,873 (1,779 hangul
  plus 94 hanja).

o The total number of characters, 5,979, is correctly stated in the
  manual although the hangul count is incorrect.

o The arrangement and ordering of these hangul bear no relationship to
  that of KS C 5601-1992. Both standards order by reading, which is
  the only way in which they are similar.

	I am not aware to what extent this character set is being
used (and who might be using it).


2.4.5: KS C 5700-1995

	Korea has developed a new character set standard called KS C
5700-1995. It is equivalent to ISO 10646-1:1993, but have pre-combined
hangul as provided (and ordered) in Unicode Version 2.0 (meaning that
all 11,172 hangul are in a contiguous block).


2.4.6: OBSOLETE STANDARDS

	KS C 5601-1986, KS C 5601-1987, and KS C 5601-1989 are the
same, character-set wise, to KS C 5601-1992. The 1992 edition provides
more material in the form of annexes. KS C 5601-1982, the original
version, enumerated only the 51 basic hangul elements in a one-byte 7-
and 8-bit encoding. This information is still part of KS C 5601-1992,
but in Annex 4.
	There were two earlier multiple-byte standards called KS C
5619-1982 and KIPS. KS C 5619-1982 enumerated 51 hangul elements,
1,316 pre-combined hangul, and 1,672 hanja. KIPS (Korean Information
Processing System) enumerated 2,058 pre-combined hangul and 2,392
hanja. Both have been rendered obsolete by KS C 5601-1987.


2.5: CJK

	The only true CJK character sets available today are CCCII,
ANSI Z39.64-1989 (also known as EACC or REACC), and ISO 10646-1:1993.
ISO 10646-1:1993 is unique in that it goes beyond CJK (Chinese
characters) to provide virtually all commonly-used alphabetic scripts.
	Of these three, only ISO 10646-1:1993 is expected to gain
wide-spread acceptance. CCCII and ANSI Z39.64-1989 are still used
today, but primarily for bibliographic purposes.


2.5.1: ISO 10646-1:1993

	Published by ISO (International Organization for
Standardization) in Switzerland, this character set enumerates over
34,000 characters. Its I-zone ("I" stands for "Ideograph") enumerates
approximately 21,000 Chinese characters, which is the result of a
massive effort by the CJK-JRG (CJK Joint Research Group) called "Han
Unification." The CJK-JRG is now called the IRG (Ideographic
Rapporteur Group), and is off doing additional research for future
Chinese character allocations to ISO 10646-1:1993.
	The Basic Multilingual Plane (BMP) of ISO 10646-1:1993 is
equivalent to Unicode. While Unicode is comprised of a single plane of
characters (which doesn't allow much room for future expansion), ISO
10646-1:1993 contains hundreds of such planes.
	One very nice feature of this standard's manual are the CJK
code correspondence tables in Section 26 (pp 262-698). Four columns
are provided for each ISO 10646-1:1993 I-zone code point -- simplified
Chinese, traditional Chinese, Japanese, and Korean. If the ISO
10646-1:1993 Chinese character maps to one of these locales, the
hexadecimal character code, (decimal) row-cell value, and glyph for
that locale is provided. The corresponding tables in Volume 2 of "The
Unicode Standard" provide character codes (sometimes the hexadecimal
character code, and sometimes the row-cell value) and a single
glyph. Quite unfortunate. I hear that a new edition of "The Unicode
Standard" is about to be released. I hope that this problem has been
addressed.
	ISO 10646-1:1993 does not replace existing national character
set standards. It simply provides a single character set that is a
superset of *most* national character sets. For example, only a
fraction of the 48,027 hanzi in CNS 11643-1992 are included in ISO
10646-1:1993. I feel that it is best to think of ISO 10646-1:1993 as
"just another character set." My philosophy is to support the maximum
number of character sets and encodings as possible.
	A note about ordering this standard. If you order through ANSI
in the United States, try to get an original manual. It is not easy,
though. You see, ANSI has duplication rights for ISO documents.
Photocopying Section 26 (pp 262-698) doesn't do the Chinese characters
much justice, and some characters become hard-to-read. Unfortunately,
there is no way to indicate that you want an original ISO document
through ANSI's ordering process, so some post-ordering haggling may
become necessary.
	More information on ISO 10646-1:1993 can be found at the
following URL:

  http://www.unicode.org/

	Japan, China (PRC), and Korea have developed their own
national standards that are based on ISO 10646-1:1993. They are
designated as JIS X 0221-1995 (see Section 2.1.4), GB 13000.1-93 (see
Section 2.2.10), and KS C 5700-1995 (see Section 2.4.5), respectively.
	Note that these national-standard versions of Unicode are
aligned differently with its three versions:

  Unicode Version 1.0
  Unicode Version 1.1 <-> ISO 10646-1:1993, JIS X 0221-1995, GB 13000.1-93
  Unicode Version 2.0 <-> KS C 5700-1995

One of the major changes made for Unicode Version 2.0 is the inclusion
of all 11,172 hangul. Versions 1.1 has 6,656 hangul.


2.5.2: CCCII

	The Chinese Character Analysis Group in Taiwan developed CCCII
(Chinese Character Code for Information Interchange) in the 1980s.
This character set is composed of 94 planes that have 94 rows and 94
cells (94 x 94 x 94 = 830,584 characters). Furthermore, every six
planes constitute a "layer" (6 x 94 x 94 = 53,016 characters). The
following is the contents of each of the 16 layers (the 16th layer
contains only four planes):

o Layer 1: Symbols and Traditional Chinese characters
o Layer 2: Simplified Chinese characters from PRC
o Layers 3 through 12: Variant Chinese character forms
o Layer 13: Japanese kana and kokuji (Japanese-made kanji)
o Layer 14: Korean hangul
o Layer 15: Reserved
o Layer 16: Miscellaneous characters (Japanese and Korean)

	Layers 1 through 12 have a special meaning and relationship.
The same code point in these layers is designed to hold the same
character, but with different forms. Layer 1 code points contain the
traditional character forms, Layer 2 code points contain the
simplified character forms (if any), and Layers 3 through 12 contain
variant character forms (if any). For example, given a Chinese
character with three forms, its encoding and arrangement may be as
follows:

  Character Form  Code Point  Layer
  ^^^^^^^^^^^^^^  ^^^^^^^^^^  ^^^^^
  Traditional     0x224E41    1
  Simplified      0x284E41    2
  Variant         0x2E4E41    3

Note how the second and third bytes (0x4E41) are identical in all
three instances -- only the first byte's value, which indicates the
layer, differs. Needless to say, this method of arrangement provides
easy access to related Chinese character forms. No wonder it is used
for bibliographic purposes.
	The first layer is composed as follows:

o Plane 1/Row 2: 56 mathematical symbols
o Plane 1/Row 3: The ASCII character set
o Plane 1/Row 11: 35 Chinese punctuation marks
o Plane 1/Rows 12 through 14: 214 classical radicals
o Plane 1/Row 15: 41 Chinese numerical symbols, 37 phonetic symbols,
  and 4 tone marks
o Plane 1/Rows 16 through 67: 4,808 common Chinese characters
o Plane 1/Row 68 through Plane 3/Row 64: 17,032 less common Chinese
  characters
o Plane 3/Row 65 through Plane 6/Row 5: 20,583 rare Chinese characters

Note that Row 1 of all planes is reserved, and never assigned
characters. Take this into account when studying the above table
ranges that span planes (that is, skip Row 1).
	In addition to the above, there are 11,517 simplified Chinese
characters in Layer 2 (3,625 are considered PRC simplified forms, and
the remaining 7,892 are regular simplified forms). This provides a
total of 53,940 Chinese characters.
	Further information on CCCII (to include very interesting
historical notes) can be found on pp 146-149 of John Clews' "Language
Automation Worldwide: The Development of Character Set Standards" and
Chapter 6 of Huang & Huang's "An Introduction to Chinese, Japanese,
and Korean Computing."


2.5.3: ANSI Z39.64-1989

	This national standard is designated as ANSI Z39.64-1989 and
named "East Asian Character Code" (EACC), but was originally known as
REACC (RLIN East Asian Character Code), that is, before it became a
national standard. RLIN stands for "Research Libraries Information
Network," which was developed by the Research Libraries Group (RLG)
located in Mountain View, California.
	RLG's Home Page is at the following URL:

  http://www.rlg.org/

	The structure of ANSI Z39.64-1989 is based on CCCII, but with
a few differences. Many consider it to be superior to and a
replacement for CCCII (see Section 2.5.2).
	The ANSI Z39.64-1989 standard is available through ANSI, but
you should be aware that it is distributed in the form of several
microfiche. Not a terribly useful storage medium these days. I had my
set tranformed into tangible printed pages. You can also obtain this
standard through NISO (National Information Standards Organization)
Press Fulfillment. Their URL is:

  http://www.niso.org/

	EACC has been designated by the Library of Congress as a
character set for use in USMARC (United States MAchine-Readable
Cataloging) records, and is used extensively by East Asian libraries
across North America.
	EACC is also being used in Australia for the National CJK
Project. Check out the following URL for more details:

  http://www.nla.gov.au/1/asian/ncjk/cjkhome.html

	Further information on ANSI Z39.64-1989 (to include very
interesting historical notes) can be found on pp 150-156 of John
Clews' "Language Automation Worldwide: The Development of Character
Set Standards" (although a source at RLG tells me that some of Clews'
facts are wrong) and Chapter 6 of Huang & Huang's "An Introduction to
Chinese, Japanese, and Korean Computing."
	The authoritative paper on EACC is "RLIN East Asian Character
Code and the RLIN CJK Thesaurus" by Karen Smith Yoshimura and Alan
Tucker, published in "Proceedings of the Second Asian-Pacific
Conference on Library Science," May 20-24,1985, Seoul, Korea.


2.6: OTHER

	This section includes character set standards that don't
properly fall under the above sections.


2.6.1: GB 8045-87

	GB 8045-87 is a Mongolian character set standard established
by China (PRC). This standard enumerates 94 Mongolian characters. Of
these 94 characters, 12 are punctuation (vertically-oriented), and the
remaining 82 are characters specific to the Mongolian script.
Mongolian is written vertically like Chinese.
	I do not discuss the encoding for GB 8045-87 in Part 3, so
will do it here. The GB 8045-87 manual describes a 7- and 8-bit
encoding. The 7-bit encoding puts these 94 characters in the standard
ASCII printable range, namely 0x21 through 0x7E. Code point 0x20 is
marked as "MSP" which stands for "Mongolian space." The 8-bit encoding
puts these 94 characters in the range 0xA1 through 0xFE, with the
"MSP" character at code point 0xA0. The GB 1988-89 set is then encoded
in the range 0x21 through 0x7E.


2.6.2: TCVN-5773:1993

	TCVN-5773:1993 (also called NSCII, which is short for Nom
Standard Code for Information Interchange) is the Vietnamese analog to
ISO 10646-1:1993, but adds 1,775 Vietnamese-specific Chinese
characters. These 1,775 characters are encoded in the range 0xA000
through 0xA6EE.
	More information on TCVN-5773:1993 can be found at the
following URL:

  ftp://unicode.org/pub/MappingTables/EastAsiaMaps/

There are two files at the above URL that pertain to this standard.
The first is a README, and the second is a Macintosh HyperCard stack
(requires HyperCard):

  TCVN-NSCII.README
  TCVN-NSCIIstack_1.0.sea.hqx


PART 3: CJK ENCODING SYSTEMS

	These sections describe the various systems for encoding the
character set standards listed in Part 2. The first two described,
7-bit ISO 2022 and EUC, are not specific to a locale, and in some
cases not specific to CJK.
	The CJK Character Set Server at the following URL can generate
character sets based on encodings described in this section:

  http://jasper.ora.com/lunde/cjk-char.html

I suggest that you use this as a way to obtain files that illustrate
these encodings in action.
	But first, please take a peek at the following table, which is
an attempt to illustrate how two Chinese characters (that stand for
"kanji/hanzi/hanja") are encoded using the various methods presented
in the following sections (character codes as hexadecimal digits, and
escape sequences or shift sequences as printable characters):

o Japanese (JIS X 0208-1990 & JIS X 0201-1976):
  - 7-bit ISO 2022        <ESC> & @ <ESC> $ B 0x3441 0x3B7A <ESC> ( J
  - ISO-2022-JP           <ESC> $ B 0x3441 0x3B7A <ESC> ( J
  - EUC                   0xB4C1 0xBBFA
  - Shift-JIS             0x8ABF 0x8E9A

o Simplified Chinese (GB 2312-80 & GB 1988-89 or ASCII):
  - 7-bit ISO 2022        <ESC> $ A 0x3A3A 0x5756 <ESC> ( T
  - ISO-2022-CN           <ESC> $ ) A <SO> 0x3A3A 0x5756 <SI>
  - EUC                   0xBABA 0xD7D6
  - HZ (HZ-GB-2312)       ~{ 0x3A3A 0x5756 ~}
  - zW                    zW 0x3A3A 0x5756

o Traditional Chinese (CNS 11643-1992):
  - 7-bit ISO 2022        <ESC> $ ( G 0x6947 0x4773 <ESC> ( B
  - ISO-2022-CN           <ESC> $ ) G <SO> 0x6947 0x4773 <SI>
  - EUC                   0xE9C7 0xC7F3 or 0x8EA1E9C7 0x8EA1C7F3

o Traditional Chinese (Big Five):
  - Big Five              0xBA7E 0xA672

o Korean (KS C 5601-1992 & ASCII):
  - 7-bit ISO 2022        <ESC> $ ( C 0x7953 0x6D2E <ESC> ( B
  - ISO-2022-KR           <ESC> $ ) C <SO> 0x7953 0x6D2E <SI>
  - EUC                   0xF9D3 0xEDAE
  - Johab                 0xF7D3 0xF1AE

o CJK (ISO 10646-1:1993, JIS X 0221-1995, GB 13000.1-93, or KS C
  5700-1995):
  - UCS-2                 0x6F22 0x5B57
  - UCS-4                 0x00006F22 0x00005B57

The above should have given you a taste of what information the
following sections provide.


3.1: 7-BIT ISO 2022 ENCODING

	7-bit ISO 2022 is the name commonly given to the encoding
system that uses escape sequences to shift between character sets.
(ISO 2022 encoded Japanese text is also known as "JIS" encoding, but
is different from ISO-2022-JP and ISO-2022-JP-2, and will be explained
in Section 3.1.3.) This encoding comes from the ISO 2022-1993
standard.
	An escape sequence, as the name implies, consists of an escape
character followed by a sequence of one or more characters. These
escape sequences are used to change character set of the text
stream. This may also mean a shift from one- to two-byte-per-character
mode (or vice versa).
	7-bit ISO 2022 Character sets fall into two types: one-byte
and two-byte. CJK character sets, for obvious reasons, fall into the
latter group.
	One advantage that 7-bit ISO 2022 encoding has over other
encoding systems is that its escape sequences specify the character
set, thus specify the locale. 7-bit ISO 2022 encoding also encodes
text using only seven-bit bytes, which has the benefit of being able
to survive Internet travel (e-mail).


3.1.1: CODE SPACE

	Each byte in the representation of graphic (printable)
characters fall into the range 0x21 (decimal 33) through 0x7E (decimal
126). For one-byte character sets, this means a maximum of 94
characters. For two-byte character sets, this means a maximum of 8,836
characters (94 x 94 = 8,836).

  One-byte Characters                           Encoding Range
  ^^^^^^^^^^^^^^^^^^^                           ^^^^^^^^^^^^^^
  first byte range                              0x21-0x7E

  Two-byte Characters                           Encoding Range
  ^^^^^^^^^^^^^^^^^^^                           ^^^^^^^^^^^^^^
  first byte range                              0x21-0x7E
  second byte range                             0x21-0x7E

White space and control characters (of which the "escape" character is
one) are still found in 0x00-0x20 and 0x7F.


3.1.2: ISO-REGISTERED ESCAPE SEQUENCES

	The following is a table that provides the ISO-registered
escape sequences for various one- and two-byte character sets
mentioned in Part 2 of this document (ISO registration numbers
provided in the fourth column):

  One-byte Character Set  Escape Sequence      Hexadecimal     ISO Reg
  ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^      ^^^^^^^^^^^     ^^^^^^^
  ASCII (ANSI X3.4-1986)  <ESC> ( B            0x1B2842        6
  Half-width katakana     <ESC> ( I            0x1B2849        13
  JIS X 0201-1976 Roman   <ESC> ( J            0x1B284A        14
  GB 1988-89 Roman        <ESC> ( T            0x1B2854        57

  Two-byte Character Set  Escape Sequence      Hexadecimal     ISO Reg
  ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^      ^^^^^^^^^^^     ^^^^^^^
  JIS C 6226-1978         <ESC> $ @            0x1B2440        42
  GB 2312-80              <ESC> $ A            0x1B2441        58
  JIS X 0208-1983         <ESC> $ B            0x1B2442        87
  KS C 5601-1992          <ESC> $ ( C          0x1B242843      149
  JIS X 0212-1990         <ESC> $ ( D          0x1B242844      159
  ISO-IR-165:1992         <ESC> $ ( E          0x1B242845      165
  JIS X 0208-1990         <ESC> & @ <ESC> $ B  0x1B26401B2442  168
  CNS 11643-1992 Plane 1  <ESC> $ ( G          0x1B242847      171
  CNS 11643-1992 Plane 2  <ESC> $ ( H          0x1B242848      172
  CNS 11643-1992 Plane 3  <ESC> $ ( I          0x1B242849      183
  CNS 11643-1992 Plane 4  <ESC> $ ( J          0x1B24284A      184
  CNS 11643-1992 Plane 5  <ESC> $ ( K          0x1B24284B      185
  CNS 11643-1992 Plane 6  <ESC> $ ( L          0x1B24284C      186
  CNS 11643-1992 Plane 7  <ESC> $ ( M          0x1B24284D      187

Note that the first four two-byte character sets do not use an opening
parenthesis (0x28 or "(") in their escape sequences, which means that
they don't follow the 7-bit ISO 2022 rules precisely. They are shorter
for historical reasons, and are retained for backwards compatibility.
Also note that not all of the CJK character set standards described in
Part 2 have ISO-registered escape sequences.
	There are other encoding methods that are similar to 7-bit ISO
2022 in that they are suitable for Internet use, but are locale-
specific. These include HZ and zW encoding, both of which are specific
to the GB 2312-80 character set (see Sections 3.3.2 and 3.3.3).
ISO-2022-JP, ISO-2022-KR, ISO-2022-CN, and ISO-2022-CN-EXT are
described below.


3.1.3: ISO-2022-JP AND ISO-2022-JP-2

	ISO-2022-JP is best described as a subset of 7-bit ISO 2022
encoding for Japanese, and reflects how Japanese text is encoded for
e-mail messages. ISO-2022-JP-2 is an extension that supports
additional character sets.
	There are only four escape sequences permitted in ISO-2022-JP,
indicated as follows:

  One-byte Character Set  Escape Sequence      Hexadecimal
  ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^      ^^^^^^^^^^^
  ASCII (ANSI X3.4-1986)  <ESC> ( B            0x1B2842
  JIS X 0201-1976 Roman   <ESC> ( J            0x1B284A

  Two-byte Character Set  Escape Sequence      Hexadecimal
  ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^      ^^^^^^^^^^^
  JIS C 6226-1978         <ESC> $ @            0x1B2440
  JIS X 0208-1983         <ESC> $ B            0x1B2442

Note the lack of JIS X 0208-1990, JIS X 0212-1990, and half-width
katakana escape sequences. The JIS X 0208-1983 escape sequence is used
to indicate both JIS X 0208-1983 and JIS X 0208-1990 (for practical
reasons).
	ISO-2022-JP-2 permits additional escape sequences, indicated
as follows:

  One-byte Character Set  Escape Sequence      Hexadecimal
  ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^      ^^^^^^^^^^^
  ASCII (ANSI X3.4-1986)  <ESC> ( B            0x1B2842
  JIS X 0201-1976 Roman   <ESC> ( J            0x1B284A

  Two-byte Character Set  Escape Sequence      Hexadecimal
  ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^      ^^^^^^^^^^^
  JIS C 6226-1978         <ESC> $ @            0x1B2440
  JIS X 0208-1983         <ESC> $ B            0x1B2442
  JIS X 0212-1990         <ESC> $ ( D          0x1B242844
  GB 2312-80              <ESC> $ A            0x1B2441
  KS C 5601-1992          <ESC> $ ( C          0x1B242843

With the introduction of ISO-2022-KR (see Section 3.1.4), ISO-2022-CN
(see Section 3.1.5), and ISO-2022-CN-EXT (see Section 3.1.5), the
usefulness of supporting GB 2312-80 and KS C 5601-1992 can be
questioned. However, ISO-2022-JP-2 provides support for JIS X
0212-1990.
	More detailed information on ISO-2022-JP encoding can be found
in RFC 1468. And, more detailed information on ISO-2022-JP-2 encoding
can be found in RFC 1554.


3.1.4: ISO-2022-KR

	ISO-2022-KR is similar to ISO-2022-JP (see Section 3.1.3) in
that it reflects how Korean text is encoded for e-mail messages.
However, its actual implementation is a bit different. Below is a
summary.
	There are only two shift sequences used in ISO-2022-KR,
indicated as follows:

  One-byte Character Set  Shift Sequence       Hexadecimal
  ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^       ^^^^^^^^^^^
  ASCII (ANSI X3.4-1986)  <SI>                 0x0F

  Two-byte Character Set  Shift Sequence       Hexadecimal
  ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^       ^^^^^^^^^^^
  KS C 5601-1992          <SO>                 0x0E

Furthermore, the following designator sequence must appear only once,
at the beginning of a line, before any KS C 5601-1992 characters (this
usually means that it appears by itself on the first line of the
file):

  <ESC> $ ) C             0x1B242943

It almost looks the same as the KS C 5601-1992 escape sequence in
7-bit ISO 2022, but look again. The opening parenthesis (0x28 or "(")
is replaced by a closing parenthesis (0x29 or ")"). This designator
sequence serves a different purpose than an escape sequence. It is
like a flag indicating that "this document contains KS C 5601-1992
characters." The <SO> and <SI> control characters actually perform the
switching between one- (ASCII) and two-byte (KS C 5601-1992) codes.
	More detailed information on ISO-2022-KR encoding can be found
in RFC 1557.


3.1.5: ISO-2022-CN AND ISO-2022-CN-EXT

	ISO-2022-CN and ISO-2022-CN-EXT are similar to ISO-2022-JP
(see Section 3.1.3) and ISO-2022-KR (see Section 3.1.4) in that they
reflect how Chinese text is encoded for e-mail messages.
	Like with ISO-2022-KR, there are only two shift sequences,
indicated as follows:

  One-byte Character Set  Shift Sequence       Hexadecimal
  ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^       ^^^^^^^^^^^
  ASCII (ANSI X3.4-1986)  <SI>                 0x0F

  Two-byte Character Set  Shift Sequence       Hexadecimal
  ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^       ^^^^^^^^^^^
  <Too Many to List>      <SO>                 0x0E

But, unlike ISO-2022-KR, there are single shift sequences. Single
shift means that they are used before every (single) character, not
before sequences of characters.

  Single Shift Type       Shift Sequence       Hexadecimal
  ^^^^^^^^^^^^^^^^^       ^^^^^^^^^^^^^^       ^^^^^^^^^^^
  SS2                     <ESC> N              0x1B4E
  SS3                     <ESC> O (not zero!)  0x1B4F

	ISO-2022-CN supports the following character sets using SO and
SS2 designations:

  Character Set           Type   Designation Sequence  Hexadecimal
  ^^^^^^^^^^^^^           ^^^^   ^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^
  GB 2312-80              SO     <ESC> $ ) A           0x1B242941
  CNS 11643-1992 Plane 1  SO     <ESC> $ ) G           0x1B242947
  CNS 11643-1992 Plane 2  SS2    <ESC> $ * H           0x1B242A48

The designator sequences must appear once on a line before any
instance of the character set it designates. If two lines contain
characters from the same character set, both lines must include the
designator sequence (this is so the text can be displayed correctly
when scroll back in a window). This is different behavior from
ISO-2022-KR where the designator sequence appears once in the entire
file (this is because ISO-2022-KR supports a single two-byte character
set).
	ISO-2022-CN-EXT supports the following character sets using
SO, SS2, and SS3 designations (notice how ISO-2022-CN is still
supported in the same manner):

  Character Set           Type   Designation Sequence  Hexadecimal
  ^^^^^^^^^^^^^           ^^^^   ^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^
  GB 2312-80              SO     <ESC> $ ) A           0x1B242941
  GB/T 12345-90           SO     NOT REGISTERED
  ISO-IR-165              SO     <ESC> $ ) E           0x1B242945
  CNS 11643-1992 Plane 1  SO     <ESC> $ ) G           0x1B242947
  CNS 11643-1992 Plane 2  SS2    <ESC> $ * H           0x1B242A48
  GB 7589-87              SS2    NOT REGISTERED
  GB/T 13131-9X           SS2    NOT REGISTERED
  CNS 11643-1992 Plane 3  SS3    <ESC> $ + I           0x1B242B49
  CNS 11643-1992 Plane 4  SS3    <ESC> $ + J           0x1B242B4A
  CNS 11643-1992 Plane 5  SS3    <ESC> $ + K           0x1B242B4B
  CNS 11643-1992 Plane 6  SS3    <ESC> $ + L           0x1B242B4C
  CNS 11643-1992 Plane 7  SS3    <ESC> $ + M           0x1B242B4D
  GB 7590-87              SS3    NOT REGISTERED
  GB/T 13132-9X           SS3    NOT REGISTERED

Support for character sets indicated as NOT REGISTERED will be added
once they are ISO-registered.
	More detailed information on ISO-2022-CN and ISO-2022-CN-EXT
encodings can be found in RFC 1922.


3.2: EUC ENCODING

	EUC stands for "Extended UNIX Code," and is a rich encoding
system from ISO 2022-1993 that is designed to handle large or multiple
character sets. It is primarily used on UNIX systems, such as Sun's
Solaris.
	EUC consists of four codes sets, numbered 0 through 3. The
only code set that is more or less fixed by definition is code set 0,
which is specified to contain ASCII or a locale's equivalent (such as
JIS X 0201-1976 for Japanese or GB 1988-89 for PRC Chinese).
	It is quite common to append the locale name to "EUC" when
designating a specific instance of EUC encoding. Common designations
include EUC-JP, EUC-CN, EUC-KR, and EUC-TW.


3.2.1: JAPANESE REPRESENTATION

	The following table illustrates the Japanese representation of
EUC packed format:

  EUC Code Sets                                 Encoding Range
  ^^^^^^^^^^^^^                                 ^^^^^^^^^^^^^^
  Code set 0 (ASCII or JIS X 0201-1976 Roman):  0x21-0x7E
  Code set 1 (JIS X 0208):                      0xA1A1-0xFEFE
  Code set 2 (half-width katakana):             0x8EA1-0x8EDF
  Code set 3 (JIS X 0212-1990):                 0x8FA1A1-0x8FFEFE

An earlier version of EUC for Japanese used code set 3 as the user-
defined range.


3.2.2: CHINESE (PRC) REPRESENTATION

	The following table illustrates the Chinese (PRC)
representation of EUC packed format:

  EUC Code Sets                                 Encoding Range
  ^^^^^^^^^^^^^                                 ^^^^^^^^^^^^^^
  Code set 0 (ASCII or GB 1988-89):             0x21-0x7E
  Code set 1 (GB 2312-80):                      0xA1A1-0xFEFE
  Code set 2:                                   unused
  Code set 3:                                   unused

Note how code sets 2 and 3 are unused.
	The encoding used on Macintosh is quite similar, but has a
shortened two-byte range (0xA1A1 through 0xFCFE) plus additional
one-byte code points, namely 0x80 ("u" with dieresis), 0xFD
("copyright" symbol: "c" in a circle), 0xFE ("trademark" symbol: "TM"
as a superscript), and 0xFF ("ellipsis" symbol: three dots).


3.2.3: CHINESE (TAIWAN) REPRESENTATION

	The following table illustrates the Chinese (Taiwan)
representation of EUC packed format:

  EUC Code Sets                                 Encoding Range
  ^^^^^^^^^^^^^                                 ^^^^^^^^^^^^^^
  Code set 0 (ASCII):                           0x21-0x7E
  Code set 1 (CNS 11643-1992 Plane 1):          0xA1A1-0xFEFE
  Code set 2 (CNS 11643-1992 Planes 1-16):      0x8EA1A1A1-0x8EB0FEFE
  Code set 3:                                   unused

Note how CNS 11643-1992 Plane 1 is redundantly encoded in code set 1
(two-byte) and code set 2 (four-byte). The second byte of code set 2
indicates the plane number. For example, 0xA1 is Plane 1 and so on up
until 0xB0, which is Plane 16.


3.2.4: KOREAN REPRESENTATION

	The following table illustrates the Korean representation of
EUC packed format (this is also known as "Wansung" encoding -- the
Korean word "wansung" means "pre-compose"):

  EUC Code Sets                                 Encoding Range
  ^^^^^^^^^^^^^                                 ^^^^^^^^^^^^^^
  Code set 0 (ASCII or KS C 5636-1993):         0x21-0x7E
  Code set 1 (KS C 5601-1992):                  0xA1A1-0xFEFE
  Code set 2:                                   unused
  Code set 3:                                   unused

Note how code sets 2 and 3 are unused.
	The encoding used on Macintosh is quite similar, but has a
shortened two-byte range (0xA1A1 through 0xFDFE) plus additional
one-byte code points, namely 0x81 ("won" symbol), 0x82 (hyphen), 0x83
("copyright" symbol: "c" in a circle), 0xFE ("trademark" symbol: "TM"
as a superscript), and 0xFF ("ellipsis" symbol: three dots).
	See Section 3.3.17 for a description of Microsoft's extension
to this encoding, called Unified Hangul Code.


3.3: LOCALE-SPECIFIC ENCODINGS

	The encoding systems described in the following sections are
considered to be locale-specific, namely that are used to encode a
specific character set standard. This is not to say that they are not
widely used (actually, some of these are among the most widely used
encoding systems!), but rather that they are tied to a specific
character set.


3.3.1: SHIFT-JIS

	Shift-JIS (also known as MS Kanji, SJIS, or DBCS-PC) is the
encoding system used on machines that support MS-DOS or Windows, and
also for Macintosh (KanjiTalk or Japanese Language Kit). It was
originally developed by Microsoft Corporation as a way to support the
Japanese character set on MS-DOS. The following tables provide the
Shift-JIS encoding ranges:

  Two-byte Standard Characters                  Encoding Ranges
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^                  ^^^^^^^^^^^^^^^
  first byte ranges                             0x81-0x9F, 0xE0-0xEF
  second byte ranges                            0x40-0x7E, 0x80-0xFC

  Two-byte User-defined Characters              Encoding Ranges
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^              ^^^^^^^^^^^^^^^
  first byte range                              0xF0-0xFC
  second byte ranges                            0x40-0x7E, 0x80-0xFC

  One-byte Characters                           Encoding Range
  ^^^^^^^^^^^^^^^^^^^                           ^^^^^^^^^^^^^^
  Half-width katakana                           0xA1-0xDF
  ASCII/JIS-Roman                               0x21-0x7E

It is important to note that the user-defined range does not
correspond to code points in other encodings that support Japanese,
such as 7-bit ISO 2022 or EUC. This is a portability problem. It is
also unique in that it does not support the JIS X 0212-1990 character
set standard.
	The encoding used on Macintosh is quite similar to the above
table, but has additional one-byte code points, namely 0x80
(backslash), 0xFD ("copyright" symbol: "c" in a circle), 0xFE
("trademark" symbol: "TM" as a superscript), and 0xFF ("ellipsis"
symbol: three dots).


3.3.2: HZ (HZ-GB-2312)

	HZ is a simple yet very powerful and reliable system for
encoding GB 2312-80 text which was developed by Fung Fung Lee
(lee@umunhum.stanford.edu). HZ encoding is commonly used when
exchanging e-mail or posting messages to Usenet News (specifically, to
alt.chinese.text).
	The actual encoding ranges used for one- and two-byte
characters is almost identical to 7-bit ISO 2022 encoding (see Section
3.1.1). The first-byte range is limited to 0x21 through 0x77. But,
instead of using an escape sequence to shift between one- and two-byte
character modes, a simple string of two printable characters is used.

  One-byte Character Set  Shift Sequence       Hexadecimal
  ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^       ^^^^^^^^^^^
  ASCII                   ~}                   0x7E7D

  Two-byte Character Set  Shift Sequence       Hexadecimal
  ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^       ^^^^^^^^^^^
  GB 2312-80              ~{                   0x7E7B

The tilde character (0x7E) is interpreted as an escape character in HZ
encoding, so it has special meaning. If a tilde character is to appear
in one-byte-per-character mode, it must be doubled (so ~~ would appear
as just ~). This means that there are three escape sequences used in
HZ encoding:

  Escape Sequence  Meaning
  ^^^^^^^^^^^^^^^  ^^^^^^^
  ~~               ~ in one-byte-per-character mode
  ~}               Shift into one-byte-per-character mode
  ~{               Shift into two-byte-per-character mode

There is also a fourth escape sequence, namely ~ plus a newline
character (~\n). This escape sequence is a line-continuation marker to
be consumed with no output produced.
	This method works without problems because the shift sequences
represent empty positions in the very last row of the GB 2312-80 table
(actually, the second- and third-from-last code points). HZ encoding
makes 77 of the 94 rows accessible, and because there are no defined
characters beyond row 77, this causes no problems.
	The complete HZ specification is part of the HZ package,
described in RFC 1843, and available in HTML format. These are
available at the following URLs:

  ftp://ftp.ifcss.org/pub/software/unix/convert/HZ-2.0.tar.gz
  ftp://ftp.ora.com/pub/examples/nutshell/ujip/Ch9/rfc-1843.txt
  http://umunhum.stanford.edu/~lee/chicomp/HZ_spec.html

In addition, RFC 1842 establishes "HZ-GB-2312" as the "charset"
parameter in MIME-encoded e-mail headers. Its properties are identical
to HZ encoding as described in RFC 1843.


3.3.3: zW

	zW encoding, developed by Ya-Gui Wei and Edmund Lai, is older
than and somewhat similar to HZ encoding (HZ is considered to be a
better encoding system, and users are encouraged to switch over to HZ
encoding).
	zW encoding is named by how it encodes each line of GB 2312-80
text, namely lines that contain Chinese text must begin with the two
characters "z" and "W" ("zW"). This encoding method does not permit
the mixture of one- (ASCII) and two-byte (GB 2312-80) characters on a
per-character basis, but rather on a per-line basis. That is, each
line can contain only Chinese or ASCII text, but not both.
	More information on zW encoding can be found as part of the
ZWDOS package available at the following URL:

  ftp://ftp.ifcss.org/pub/software/dos/ZWDOS/


3.3.4: BIG FIVE

	Big Five is the encoding system used on machines that support
MS-DOS or Windows, and also for Macintosh (such as the Chinese
Language Kit or the fully-localized operating system).

  Two-byte Standard Characters                  Encoding Ranges
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^                  ^^^^^^^^^^^^^^^
  first byte range                              0xA1-0xFE
  second byte ranges                            0x40-0x7E, 0xA1-0xFE

  One-byte Characters                           Encoding Range
  ^^^^^^^^^^^^^^^^^^^                           ^^^^^^^^^^^^^^
  ASCII                                         0x21-0x7E

	The encoding used on Macintosh is quite similar to the above,
but has a slightly shortened two-byte range (second byte range up to
0xFC only) plus additional one-byte code points, namely 0x80
(backslash), 0xFD ("copyright" symbol: "c" in a circle), 0xFE
("trademark" symbol: "TM" as a superscript), and 0xFF ("ellipsis"
symbol: three dots).


3.3.5: JOHAB

	Korean hangul characters are typically encoded in what is
known as pre-combined form, namely 2 or 3 hangul elements bound into a
single character. KS C 5601-1992 enumerates 2,350 such pre-combined
forms. While this number is felt to be sufficient for most purposes,
it does not account for the total number of possible permutations. The
encoding system that encodes all possible pre-combined hangul is known
as Johab encoding (also known as "two-byte combination code" -- the
Korean word "johab" means "combine"), and is described in Annex 3 of
the KS C 5601-1992 standard. This encoding is almost like encoding all
possible three-letter words in English -- while all combinations are
possible, only a fraction represent *real* words.
	Pre-combined hangul can be composed of 19 different initial,
21 different medial, and 27 different final hangul elements (28,
actually, if you count the placeholder). This provides a maximum of
11,172 pre-combined hangul. Of these 67 hangul elements, 51 are unique
(some can occur in different positions). Each of these positions are
encoded using five bits each (five bits can encode up to 32 unique
objects). The encoding array looks as follows:

o Bit 1: always on
o Bits 2-6: initial hangul element
o Bits 7-11: medial hangul element
o Bits 12-16: final hangul element

Initial and final elements are consonants, and the medial elements are
vowels. This encoding must be treated as a 16-bite entity because the
bit array of the medial hangul element spans the first and second byte.
	Johab encoding also provides the complete set of KS C 5601-
1992 symbols and hanja, but in different code points. Annex 3 of the
KS C 5601-1992 manual (pp 33-34) contains a complete symbol and hanja
mapping table between EUC and Johab code points. (The KS C 5601-1989
manual did not have this.) The code space ranges for Johab encoding
are as follows:

  One-byte Characters                           Encoding Range
  ^^^^^^^^^^^^^^^^^^^                           ^^^^^^^^^^^^^^
  ASCII or KS C 5636-1993                       0x21-0x7E

  Two-byte Pre-combined Hangul                  Encoding Ranges
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^                  ^^^^^^^^^^^^^^^
  first byte range                              0x84-0xD3
  second byte ranges                            0x41-0x7E, 0x81-0xFE

  Two-byte Symbols and Hanja                    Encoding Ranges
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^                  ^^^^^^^^^^^^^^^
  first byte ranges                             0xD8-0xDE, 0xE0-0xF9
  second byte ranges                            0x31-0x7E, 0x91-0xFE

Note that the second byte ranges encode a total of 188 characters, and
that the second byte ranges for hangul and symbols/hanja are slightly
different (yet the same size, namely 188 characters).
	Here is a summary of the above table, which better describes
what is encoded where. Rows 0x84 through 0xD3 provide 80 rows of 188
characters each (15,040 code points, which is more than enough for the
11,172 pre-combined hangul). Row 0xD8 provides 188 user-defined
positions, the same as Rows 41 and 94 in the standard KS C 5601-1992
table. Rows 0xD9 through 0xDE encode Rows 1 through 12 of the standard
KS C 5601-1992 table (symbols). Rows 0xE0 through 0xF9 encode Rows 42
through 94 of the KS C 5601-1992 table (hanja). The following URL
provides a complete mapping table for the KS C 5601-1992 symbols and
hanja:

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/map/non-hangul-codes.txt

The following URLs provides similar information (they are the same
file), but only for the 11,172 pre-combined hangul:

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/map/hangul-codes.txt
  ftp://unicode.org/pub/MappingTables/EastAsiaMaps/hangul-codes.txt

	Of further interest may be that Microsoft designates Johab
encoding as its Code Page 1361. Microsoft if planning to support Johab
encoding for Korean Windows NT.


3.3.6: N-BYTE HANGUL

	In the days before full two-byte capable operating systems,
each of the 51 basic hangul elements were encoding using a single
(7-bit) byte. The encoding range spans 0x40 through 0x7C, but there
are several unassigned gaps. This is known as the "N-byte Hangul"
code, and is described in Annex 4 (page 35) of the KS C 5601-1992
manual.
	The following table illustrates these 51 one-byte code points
(the pronunciation or meaning of the hangul element is provided in
parentheses) and how they map to the three 5-bit arrays in Johab
encoding (expressed as binary patterns):

  Element        Initial  Medial   Final
  ^^^^^^^        ^^^^^^^  ^^^^^^   ^^^^^
  0x40 ("fill")  00001    00010    00001
  0x41 (g)       00010    *****    00010
  0x42 (gg)      00011    *****    00011
  0x43 (gs)      *****    *****    00100
  0x44 (n)       00100    *****    00101
  0x45 (nj)      *****    *****    00110
  0x46 (nh)      *****    *****    00111
  0x47 (d)       00101    *****    01000
  0x48 (dd)      00110    *****    *****
  0x49 (r)       00111    *****    01001
  0x4A (rg)      *****    *****    01010
  0x4B (rm)      *****    *****    01011
  0x4C (rb)      *****    *****    01100
  0x4D (rs)      *****    *****    01101
  0x4E (rt)      *****    *****    01110
  0x4F (rp)      *****    *****    01111
  0x50 (rh)      *****    *****    10000
  0x51 (m)       01000    *****    10001
  0x52 (b)       01001    *****    10011
  0x53 (bb)      01010    *****    *****
  0x54 (bs)      *****    *****    10100
  0x55 (s)       01011    *****    10101
  0x56 (ss)      01100    *****    10110
  0x57 (ng)      01101    *****    10111
  0x58 (j)       01110    *****    11000
  0x59 (jj)      01111    *****    *****
  0x5A (c)       10000    *****    11001
  0x5B (k)       10001    *****    11010
  0x5C (t)       10010    *****    11011
  0x5D (p)       10011    *****    11100
  0x5E (h)       10100    *****    11101
  0x5F UNASSIGNED
  0x60 UNASSIGNED
  0x61 UNASSIGNED
  0x62 (a)       *****    00011    *****
  0x63 (ae)      *****    00100    *****
  0x64 (ya)      *****    00101    *****
  0x65 (yae)     *****    00110    *****
  0x66 (eo)      *****    00111    *****
  0x67 (e)       *****    01010    *****
  0x68 UNASSIGNED
  0x69 UNASSIGNED
  0x6A (yeo)     *****    01011    *****
  0x6B (ye)      *****    01100    *****
  0x6C (o)       *****    01101    *****
  0x6D (wa)      *****    01110    *****
  0x6E (wae)     *****    01111    *****
  0x6F (oe)      *****    10010    *****
  0x70 UNASSIGNED
  0x71 UNASSIGNED
  0x72 (yo)      *****    10011    *****
  0x73 (u)       *****    10100    *****
  0x74 (weo)     *****    10101    *****
  0x75 (we)      *****    10110    *****
  0x76 (wi)      *****    10111    *****
  0x77 (yu)      *****    11010    *****
  0x78 UNASSIGNED
  0x79 UNASSIGNED
  0x7A (eu)      *****    11011    *****
  0x7B (yi)      *****    11100    *****
  0x7C (i)       *****    11101    *****

	There are utilities to convert N-byte Hangul code to other,
more widely-used, encoding methods. Pointers to these and other code
conversion utilities can be found in Section 4.7.


3.3.7: UCS-2

	UCS-2 (Universal Character Set containing 2 bytes) encoding is
one way to encode ISO 10646-1:1993 text, and is considered identical
to Unicode encoding. Its encoding range, which is quite simple, is as
follows:

  ISO 10646-1:1993 Characters                   Encoding Range
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^                  ^^^^^^^^^^^^^^
  first byte range                              0x00-0xFF
  second byte range                             0x00-0xFF

Yes, folks, the whole range of 65,536 possible code points are
available for encoding characters. The "signature" that indicates a
file using UCS-2 is as follows:

  0xFEFF

	Escape sequences for UCS-2 have already been registered with
ISO, and are as follows:

  ISO 10646-1:1993        Escape Sequence      Hexadecimal     ISO Reg
  ^^^^^^^^^^^^^^^^        ^^^^^^^^^^^^^^^      ^^^^^^^^^^^     ^^^^^^^
  UCS-2 Level 1           <ESC> % / @          0x1B252F40      162
  UCS-2 Level 2           <ESC> % / C          0x1B252F43      174
  UCS-2 Level 3           <ESC> % / E          0x1B252F45      176

So what do these three levels mean? Level 3 means all characters in
ISO 10646-1:1993 with no restrictions (0x0000 through 0xFFFF).
	Level 2 begins to restrict the character set by not including
the following characters or character ranges:

  0x0300-0x0345  0x09D7         0x0BD7         0x11A8-0x11F9
  0x0360-0x0361  0x0A3C         0x0C55-0x0C56  0x20D0-0x20E1
  0x0483-0x0486  0x0A70-0x0A71  0x0CD5-0x0CD6  0x302A-0x302F
  0x093C         0x0ABC         0x0D57         0x3099-0x309A
  0x0953-0x0954  0x0B3C         0x1100-0x1159  0xFE20-0xFE23
  0x09BC         0x0B56-0x0B57  0x115F-0x11A2

These are all combining characters, and represent 364 code points.
	Level 1 further restricts the character set by not including
the following characters or character ranges:

  0x05B0-0x05B9  0x09BE-0x09C4  0x0B47-0x0B48  0x0D02-0x0D03
  0x05BB-0x05BD  0x09C7-0x09C8  0x0B4B-0x0B4D  0x0D3E-0x0D43
  0x05BF         0x09CB-0x09CD  0x0B82-0x0B83  0x0D46-0x0D48
  0x05C1-0x05C2  0x09E2-0x09E3  0x0BBE-0x0BC2  0x0D4A-0x0D4D
  0x064B-0x0652  0x0A02         0x0BC6-0x0BC8  0x0E31
  0x0670         0x0A3E-0x0A42  0x0BCA-0x0BCD  0x0E34-0x0E3A
  0x06D6-0x06E4  0x0A47-0x0A48  0x0C01-0x0C03  0x0E47-0x0E4E
  0x06E7-0x06E8  0x0A4B-0x0A4D  0x0C3E-0x0C44  0x0EB1
  0x06EA-0x06ED  0x0A81-0x0A83  0x0C46-0x0C48  0x0EB4-0x0EB9
  0x0901-0x0903  0x0ABE-0x0AC5  0x0C4A-0x0C4D  0x0EBB-0x0EBC
  0x093E-0x094D  0x0AC7-0x0AC9  0x0C82-0x0C83  0x0EC8-0x0ECD
  0x0951-0x0952  0x0ACB-0x0ACD  0x0CBE-0x0CC4  0xFB1E
  0x0962-0x0963  0x0B01-0x0B03  0x0CC6-0x0CC8
  0x0981-0x0983  0x0B3E-0x0B43  0x0CCA-0x0CCD

These, too, are all combining characters, and represent 586 code
points (222 above plus the 364 characters from the Level 2
restriction).


3.3.8: UCS-4

	UCS-4 (Universal Character Set containing 4 bytes) encoding is
another way to encode ISO 10646-1:1993 text, and is used for future
expansion of the character set. Its encoding range is as follows:

  ISO 10646-1:1993 Characters                   Encoding Range
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^                  ^^^^^^^^^^^^^^
  first byte range                              0x00-0x7F
  second byte range                             0x00-0xFF
  third byte range                              0x00-0xFF
  fourth byte range                             0x00-0xFF

Note that the first byte range only goes up to 0x7F. This means that
UCS-4 is a 31-bit encoding. And, in case you're wondering, 31 bits
provide 2,147,483,648 code points. The "signature" that indicates a
file using UCS-4 is as follows:

  0x0000 0xFEFF

	Escape sequences for UCS-4 have already been registered with
ISO, and are as follows:

  ISO 10646-1:1993        Escape Sequence      Hexadecimal     ISO Reg
  ^^^^^^^^^^^^^^^^        ^^^^^^^^^^^^^^^      ^^^^^^^^^^^     ^^^^^^^
  UCS-4 Level 1           <ESC> % / A          0x1B252F41      163
  UCS-4 Level 2           <ESC> % / D          0x1B252F44      175
  UCS-4 Level 3           <ESC> % / F          0x1B252F46      177

See the end of Section 3.3.7 for a description of these three levels.
But, in the case of UCS-4, simply prepend "0000" to all the values.


3.3.9: UTF-7

	It turns out that *raw* ISO 10646-1:1993 encoding (that is,
UCS-2 or UCS-4) can cause problems because null bytes (0x00) are
possible (and frequent). Several UTFs (UCS Transformation Formats)
have been developed to deal with this and other problems. I must admit
that I don't know too much about UTFs, and what I provide below is
minimal, but does include pointers to more complete descriptions.
	UTF-7 is a mail-safe 7-bit transformation format for UCS-2
(including UTF-16). It uses straight ASCII for many ASCII characters,
and switches into a Base64 encoding of UCS-2 or UTF-16 for everything
else. It was designed to be usable in MIME-compliant e-mail headers as
well as message bodies, and to pass through gateways to non-ASCII mail
systems (like Bitnet). More detailed information on UTF-7 can be found
in RFC 1642, and a UTF-7 converter is available. The following URLs
provide this information:

  http://www.stonehand.com/unicode/standard/utf7.html
  ftp://unicode.org/pub/Programs/ConvertUTF/


3.3.10: UTF-8

	UTF-8 (also known as UTF-2 or FSS-UTF -- FSS stands for "file
system safe") can represent any character in UCS-2 and UCS-4, and is
officially an annex to ISO 10646-1:1993. It is different from UTF-7 in
that it encodes character sets into 8-bit bytes. UCS-2 and UCS-4 have
problems with some file systems and utilities, so this UTF was
developed.
	More detailed information on UTF-8 and its relationship with
ISO 10646-1:1993 can be found at the following URLs:

  http://www.stonehand.com/unicode/standard/utf8.html
  ftp://unicode.org/pub/Programs/ConvertUTF/

	X/Open Company Limited also published a document that
describes UTF-8 in detail (they call it FSS-UTF), and you can find
information about it at the following URL:

  http://www.xopen.co.uk/public/pubs/catalog/c501.htm

The new programming language called Java supports Unicode through
UTF-8. More information on Java is at the following URL:

  http://www.javasoft.com/


3.3.11: UTF-16

	UTF-16 (formerly UCS-2E), like UTF-8, is now officially an
annex to ISO 10646-1:1993. From what I've read, UTF-16 transforms
UCS-4 into a 16-bit form. UTF-16 can then be further encoded in UTF-7
or UTF-8 (but doing this is not according to the standard -- there is
little to gain by doing so).
	More detailed information on UTF-16 and its relationship with
ISO 10646-1:1993 can be found at the following URLs:

  http://www.stonehand.com/unicode/standard/utf16.html
  ftp://unicode.org/pub/Programs/ConvertUTF/


3.3.12: ANSI Z39.64-1989

	The encoding used for ANSI Z39.64-1989 (and CCCII) is three-
byte 7-bit ISO 2022, namely the following code space:

  Three-byte ANSI Z39.64-1989                   Encoding Range
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^                   ^^^^^^^^^^^^^^
  first byte range                              0x21-0x7E
  second byte range                             0x21-0x7E
  third byte range                              0x21-0x7E


3.3.13: BASE64

	Base64 encoding is mentioned here only because of its common
usage in e-mail headers, and relationship with MIME (Multi-purpose
Internet Mail Extensions). It is also a source of confusion. Base64 is
a method of encoding arbitrary bytes into the safest 64-character
ASCII subset, and is defined in RFC 1341 (which adapted it from RFC
1113). RFC 1341 was made obsolete by RFC 1521. RFC 1522 also provides
useful information, particularly for handling non-ASCII text, and
obsoletes RFC 1342.
	Here is how it works. Every three bytes are encoded as a
four-byte sequence. That is, the 24 bits that make up the three bytes
are split into four 6-bit segments (6 bits can encode up to 64
characters). Each 6-bit segment is then converted into a character in
the Base64 Alphabet (see below). There is a 65th character, "=", which
has a special purpose (it functions as a "pad" if a full three-byte
sequence is not found). This all may sound a bit like uuencoding, but
it is different. The Base64 Alphabet is as follows:

  ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

	My name, written in Japanese kanji, is as follows when it is
EUC-encoded (six bytes, expressed as three groups of hexadecimal
values, one group for each character):

  0xBEAE 0xCED3 0xB7F5

When these three EUC-encoded characters are converted to Base64
encoding, they appear as follows (eight bytes):

  vq7O07f1

	Base64 encoding is most commonly used for encoding non-ASCII
text that appears in e-mail headers. Of all the portions of an e-mail
message, its header gets manipulated the most during transmission, and
Base64 encoding offers a safe way to further encode non-ASCII text so
that it is not altered by mail-routing software. This is where Base64
encoding can cause confusion. For example, what goes through your mind
when you see the following chunk o' text?

  From: lunde@adobe.com (=?ISO-2022-JP?B?vq7O07f1?=)

Many folks think that they are seeing ISO-2022-JP encoding. Not
true. The "ISO-2022-JP" portion is just a flag that indicates the
original encoding before Base64 encoding was applied. The actual
Base64-encoded portion is enclosed between question marks (?) as
follows:

  From: lunde@adobe.com (=?ISO-2022-JP?B?vq7O07f1?=)
                                        >^^^^^^^^<

The whole string enclosed in parentheses has several components, and
the following explains their purpose and relationships (using the
above string as an example):

  Component      Explanation
  ^^^^^^^^^      ^^^^^^^^^^^
  =?             Signals start of encoded string
  ISO-2022-JP    Charset name ("ISO-2022-JP" is for Japanese)
  ?              Delimiter
  B              Encoding ("B" is for Base64)
  ?              Delimiter
  vq7O07f1       Example string of type "charset" encoded by "encoding"
  ?=             Signals end of encoded string

	One typically does not need to worry about encoding text as
Base64 (MIME-compliant mailing software usually performs this task for
you). The problem is usually trying to decode Base64-encoded text. A
Base64 decoder is available in Perl at the following URL:

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/perl/b64decode.pl

Note that this program takes "raw" Base64 data as input. Any non-
Base64 stuff must be stripped. I usually run this from within Mule
("C-u M-| b64decode.pl") after defining a region around the Base64-
encoded material. I hope to replace this program soon with one that
automatically recognizes the Base64-encoded portions.
	Most MIME-compliant e-mail software can decode Base64-encoded
text.


3.3.14: IBM DBCS-HOST

	The oldest two-byte encoding system is IBM's DBCS-Host. DBCS
stands for Double-Byte Character Set. DBCS-Host is still in use on
IBM's mainframe computer systems (hence the use of "Host").
	DBCS-Host encoding is EBCDIC-based, and uses Shift characters,
0x0E and 0x0F, to switch between one- and two-byte mode. Its encoding
specifications are as follows:

  Two-byte Characters                           Encoding Range
  ^^^^^^^^^^^^^^^^^^^                           ^^^^^^^^^^^^^^
  first byte range                              0x41-0xFE
  second byte range                             0x41-0xFE

  Two-byte "Space" Character                    Code Point
  ^^^^^^^^^^^^^^^^^^^^^^^^^^                    ^^^^^^^^^^
  first- and second byte                        0x4040

  One-byte Characters                           Encoding Range
  ^^^^^^^^^^^^^^^^^^^                           ^^^^^^^^^^^^^^
  EBCDIC                                        0x41-0xF9

  Shifting Characters                           Code Point
  ^^^^^^^^^^^^^^^^^^^                           ^^^^^^^^^^^^^^
  Two-byte                                      0x0E
  One-byte                                      0x0F

This same encoding specification is shared by all of IBM's CJK
character sets, namely for Japanese, Simplified Chinese, Traditional
Chinese, and Korean.


3.3.15: IBM DBCS-PC

	IBM's DBCS-PC encoding is used on IBM personal computers (that
is where the "PC" comes from). DBCS-PC encoding is ASCII-based, and
uses the values of characters' bytes themselves to switch between one-
and two-byte mode. Its encoding specifications are as follows:

  Two-byte Characters                           Encoding Ranges
  ^^^^^^^^^^^^^^^^^^^                           ^^^^^^^^^^^^^^^
  first byte range                              0x81-0xFE
  second byte range                             0x40-0x7E, 0x80-0xFE

  One-byte Characters                           Encoding Range
  ^^^^^^^^^^^^^^^^^^^                           ^^^^^^^^^^^^^^
  ASCII                                         0x21-0x7E

This same encoding specification is shared by all of IBM's CJK
character sets, namely for Japanese, Simplified Chinese, Traditional
Chinese, and Korean.
	DBCS-PC encoding for Japanese, although conforming to the
above encoding specifications, actually uses the same encoding
specifications for Shift-JIS, to include the full user-defined range
(see Section 3.3.1 for more details on Shift-JIS encoding). One big
accommodation is the half-width katakana range, namely 0xA1 through
0xDF. Further, the DBCS-PC code space that is outside the Shift-JIS
specification is unused.
	DBCS-PC encoding for Korean uses the equivalent of EUC code
set 1 code points (0xA1A1 through 0xFEFE) for those characters that
are common with KS C 5601-1992. Those characters that are not common
with KS C 5601-1992, namely IBM's extensions, are within the DBCS-PC
encoding space, but outside EUC encoding space (0x9A through 0xA0).
Many hanja and pre-combined hangul are part of IBM's Korean extension.
	Note that DBCS-PC is sort of useless without a corresponding
SBCS (Single-Byte Character Set) for the one-byte range. Mixing DBCS
and SBCS results in a MBCS (Multiple-Byte Character Set). How these
are mixed to form MBCSs is detailed in Section 3.4.


3.3.16: IBM DBCS-/TBCS-EUC

	IBM has also developed DBCS-EUC and TBCS-EUC encodings. TBCS
stands for Triple-Byte Character Set. These essentially follow the EUC
encoding specifications, and were developed for use with IBM's AIX
(Advanced Interactive Executive) operating system, which is
UNIX-based.
	Refer to Section 3.2 for all the details on EUC encoding.


3.3.17: UNIFIED HANGUL CODE

	Microsoft has developed what is called "Unified Hangul Code"
(UHC) for its Windows 95 operating system (this was also known as
"Extended Wansung"). It is the optional, not standard, character set
of Win95K.
	UHC provides full compatibility with KS C 5601-1992 EUC
encoding (see Section 3.2.4), but adds additional encoding ranges for
holding additional pre-combined hangul (more precisely, the 8,822 that
are needed to fully support the Johab character set). The following is
a table that provides the encoding ranges for UHC encoding:

  Two-byte Standard Characters                  Encoding Ranges
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^                  ^^^^^^^^^^^^^^^
  first byte range                              0x81-0xFE
  second byte ranges                            0x41-0x5A, 0x61-0x7A,
                                                and 0x81-0xFE

  One-byte Characters                           Encoding Range
  ^^^^^^^^^^^^^^^^^^^                           ^^^^^^^^^^^^^^
  ASCII                                         0x21-0x7E

Note that 0xA1A1 through 0xFEFE in the above encoding is still
identical, in terms of character-to-code allocation, with KS C 5601-
1992 in EUC encoding.
	Appendix G (pp 345-406) of "Developing International Software
for Windows 95 and Windows NT" by Nadine Kano illustrates the KS C
5601-1992 character set standard plus these Microsoft extensions
(8,822 pre-combined hangul) by UHC code (Microsoft calls this Code
Page 949).


3.3.18: TRON CODE

	TRON (The Real-time Operating system Nucleus) is an OS
developed in Japan some time ago. Personal Media Corporation has done
work to develop BTRON (Business TRON), which is unique in that it is
the only commercially-available OS that supports JIS X 0212-1990.
	TRON Code provides a one- and two-byte encoding space and a
method for switching between them.
	The following is how the two-byte space in TRON Code is
allocated:

  A-Zone (8,836 characters; JIS X 0208-1990)    Encoding Range
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^    ^^^^^^^^^^^^^^
  first byte range                              0x21-0x7E
  second byte range                             0x21-0x7E

  B-Zone (11,844 characters; JIS X 0212-1990)   Encoding Range
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   ^^^^^^^^^^^^^^
  first byte range                              0x80-0xFD
  second byte range                             0x21-0x7E

  C-Zone (11,844 characters; unassigned)        Encoding Range
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^        ^^^^^^^^^^^^^^
  first byte range                              0x21-0x7E
  second byte range                             0x80-0xFD

  D-Zone (15,876 characters; unassigned)        Encoding Range
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^        ^^^^^^^^^^^^^^
  first byte range                              0x80-0xFD
  second byte range                             0x80-0xFD

Note how the B-Zone is larger that the conventional 94-by-94
matrix. In fact, the JIS X 0212-1990 portion of the B-Zone is
restricted to 0xA121-0xFD7E (93-by-94 matrix -- 0xFE as a first-byte
value is unavailable, and you will see why in a minute).
	TRON Code implements "language specifying codes" consisting of
two bytes as follows:

  Two-byte Japanese                             0xFE21
  One-byte English                              0xFE80

0xFE21 in a one-byte stream invokes two-byte Japanese mode, and 0xFE80
in a two-byte stream invokes one-byte English mode.
	The following is the one-byte encoding range for TRON Code:

  One-byte Characters                           0x21-0x7E and 0x80-0xFD

Control codes are in 0x00-0x20 and 0x7F (the usual ASCII control code
range). Also, 0xA0 is reserved as a fixed-width space character.


3.3.19: GBK

	GBK is an extension to GB 2312-80 that adds all ISO 10646-
1:1993 (GB 13000.1-93) hanzi not already in GB 2312-80. GBK is defined
as a normative annex of GB 13000.1-93 (see Section 2.2.10). The "K" in
"GBK" is the first sound in the Chinese word meaning "extension" (read
"Kuo Zhan").
	GBK is divided into five levels as follows:

  Level  Encoded Range  Total Code Points  Total Encoded Characters
  ^^^^^  ^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^^^
  GBK/1  0xA1A1-0xA9FE    846                717
  GBK/2  0xB0A1-0xF7FE  6,768              6,763
  GBK/3  0x8140-0xA0FE  6,080              6,080
  GBK/4  0xAA40-0xFEA0  8,160              8,160
  GBK/5  0xA840-0xA9A0    192                166

	There are also 1,894 user-defined code points as follows:

  Encoded Range  Total Code Points
  ^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^
  0xAAA1-0xAFFE  564
  0xF8A1-0xFEFE  658
  0xA140-0xA7A0  672

	GBK thus provides a total of 23,940 code points, 21,886 of
which are assigned.
	Each "row" in the GBK code table consists of 190 characters.
The following describes the encoding ranges of GBK in detail:

  Two-byte Standard Characters                  Encoding Ranges
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^                  ^^^^^^^^^^^^^^^
  first byte range                              0x81-0xFE
  second byte ranges                            0x40-0x7E and 0x80-0xFE

  One-byte Characters                           Encoding Range
  ^^^^^^^^^^^^^^^^^^^                           ^^^^^^^^^^^^^^
  ASCII                                         0x21-0x7E

Note that the sub-range 0xA1A1-0xFEFE in the above encoding is still
identical, in terms of character-to-code allocation, with GB 2312-80
in EUC encoding. GBK is therefore backward-compatible with GB 2312-80
and forward-compatible with ISO 10646-1:1993.
	GBK is the standard character set and encoding for the
Simplified Chinese version of Windows 95.


3.4: CJK CODE PAGES

	Many times one reads about references to "Code Pages" in
material about CJK (and other) character sets and encodings. These are
not literal pages, but rather references to a character set and
encoding combination. In the case of CJK Code Pages, they definitely
comprise more than one page!
	Microsoft refers to its supported CJK character sets and
encodings through such Code Page designations. The following is a
listing of several Microsoft CJK Code Pages along with their
characteristics:

  Code Page  Characteristics
  ^^^^^^^^^  ^^^^^^^^^^^^^^^
  932        JIS X 0208-1990 base, Shift-JIS encoding, Microsoft
             extensions (NEC Row 13 and IBM select characters in
             redundantly encoded in Rows 89 through 92 and Rows 115
             through 119)
  936        GB 2312-80 base, EUC encoding
  949        KS C 5601-1992 base, Unified Hangul Code encoding,
             remaining 8,822 pre-combined hangul as extension (all of
             this is referred to as Unified Hangul Code)
  950        Big Five base, Big Five encoding, Microsoft extensions
             (actually, the ETen extensions of Row 89)
  1361       Johab base, Johab encoding

	IBM also uses Code Page designations, and, in fact, some
designations (and associated characteristics) are nearly identical to
those in the above table, most notably, Code Pages 932 and 936. IBM's
Code Page 932 does not include NEC Row 13 or IBM select characters in
Rows 89 through 92.
	The best way to describe IBM Code Page designations is by
first listing the SBCS (Single-Byte Character Set) and DBCS (Double-
Byte Character Set) Code Page designations (those designated by "Host"
use EBCDIC-based encodings):

  IBM SBCS Code Page          Characteristics
  ^^^^^^^^^^^^^^^^^^          ^^^^^^^^^^^^^^^
  37 (US)                     SBCS-Host
  290 (Japanese)              SBCS-Host
  833 (Korean)                SBCS-Host
  836 (Simplified Chinese)    SBCS-Host
  891 (Korean)                SBCS-PC
  897 (Japanese)              SBCS-PC
  903 (Simplified Chinese)    SBCS-PC
  904 (Traditional Chinese)   SBCS-PC

  IBM DBCS Code Page          Characteristics
  ^^^^^^^^^^^^^^^^^^          ^^^^^^^^^^^^^^^
  300 (Japanese)              DBCS-Host
  301 (Japanese)              DBCS-PC
  834 (Korean)                DBCS-Host
  835 (Traditional Chinese)   DBCS-Host
  837 (Simplified Chinese)    DBCS-Host
  926 (Korean)                DBCS-PC
  927 (Traditional Chinese)   DBCS-PC
  928 (Simplified Chinese)    DBCS-PC

So far there appears to be no relationship with Microsoft's CJK Code
Pages, but when we combine the above SBCS and DBCS Code Pages into
MBCS (Multiple-Byte Character Set) Code Pages, things become a bit
more revealing:

  IBM MBCS Code Page          Characteristics
  ^^^^^^^^^^^^^^^^^^          ^^^^^^^^^^^^^^^
  930 (Japanese)              MBCS-Host (Code Pages 300 and 290)
  932 (Japanese)              MBCS-PC (Code Pages 301 and 897)
  933 (Korean)                MBCS-Host (Code Pages 834 and 833)
  934 (Korean)                MBCS-PC (Code Pages 926 and 891)
  938 (Traditional Chinese)   MBCS-PC (Code Pages 927 and 904)
  936 (Simplified Chinese)    MBCS-PC (Code Pages 928 and 903)
  5031 (Simplified Chinese)   MBCS-Host (Code Pages 837 and 836)
  5033 (Traditional Chinese)  MBCS-Host (Code Pages 835 and 37)

So, you can now see that many of Microsoft's CJK Code Pages are
derived from those established by IBM.
	More detailed information on the encoding specifications for
DBCS-Host and DBCS-PC can be found in Sections 3.3.14 and 3.3.15,
respectively.


PART 4: CJK CHARACTER SET COMPATIBILITY ISSUES

	The sections below provide detailed information about
compatibility issues between CJK character sets, to include tidbits of
useful information.
	One thing to mention first is that conversion to and from
IBM's DBCS-Host (Section 3.3.14) and DBCS-PC (Section 3.3.15)
encodings is table-driven, and fully documented in the following IBM
publication:

o IBM Corporation. "Character Data Representation Architecture - Level
  2, Registry." 1993. IBM order number SC09-1391-01.

Unfortunately, the CJK-related tables are not supplied in machine-
readable format, and must be obtained from IBM directly. The only real
compatibility issue is trying to obtain the conversion tables from
IBM.


4.1: JAPANESE

	In general, when a Japanese character set was revised,
characters were simply added (usually appended at the end). However,
when JIS C 6226-1978 was revised in 1983 (to become JIS X 0208-1983),
a bit more happened (this is still a controversy).
	A detailed treatment of the two main transitions, JIS C 6226-
1978 to JIS X 0208-1983 and JIS X 0208-1983 to JIS X 0208-1990, is
covered in Appendix J of UJIP. I provide machine-readable files that
detail these transitions at the following URL:

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/AppJ/

	An interesting side note here is that there is a reason why
there are many lists that illustrate JIS C 6226-1978 and JIS X 0208-
1983 kanji form differences. While most share the same basic set of
changes, there are some inconsistencies. Well, it turns out that JIS C
6226-1978 had ten printings, and not all of them shared the same kanji
forms. If comparisons between JIS C 6226-1978 and JIS X 0208-1983 were
made using different printings of the JIS C 6226-1978 manual, the
results can differ slightly.
	There are also interesting correspondences between JIS X
0208-1990 and JIS X 0212-1990. 28 kanji that vanished during the JIS C
6226-1978 to JIS X 0208-1983 transition (they were replaced by
simplified versions) were restored in JIS X 0212-1990 (at totally
different code points). Appendix J of UJIP discusses this, and a file
at the following URL details the 28 mappings:

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/AppJ/TJ2.jis


4.2: CHINESE (PRC)

	The basic PRC standard, GB 2312-80, has been revised, but not
through a later version of the standard. Instead, the revisions were
carried out in the form of three other documents. Specifically, they
are (in order of publication):

o GB 6345.1-86 (see Section 2.2.3)
o GB 8565.2-88 (see Section 2.2.6)
o GB/T 12345-90 (see Section 2.2.7)

Unless you are aware of these documents, figuring out what has been
corrected or added to GB 2312-80 is nearly impossible.


4.3: CHINESE (TAIWAN)

	The first question people think of with regard to Big Five and
CNS 11643-1992 is compatibility. It turns out that Planes 1 and 2 of
CNS 11643-1992 are more or less equivalent to Big Five, but a handful
of hanzi are in a different order. The following tables detail the
mapping from Big Five (with the ETen extension) to CNS 11643-1992
(when using this conversion table, keep in mind the encoding space
ranges for both Big Five and CNS 11643-1992):

Big Five Level 1 Correspondence to CNS 11643-1992 Plane 1:

  0xA140-0xA1F5 <-> 0x2121-0x2256
         0xA1F6 <-> 0x2258
         0xA1F7 <-> 0x2257
  0xA1F8-0xA2AE <-> 0x2259-0x234E
  0xA2AF-0xA3BF <-> 0x2421-0x2570
  0xA3C0-0xA3E0 <-> 0x4221-0x4241  # Symbols for control characters
  0xA440-0xACFD <-> 0x4421-0x5322  # Level 1 Hanzi BEGIN
         0xACFE <-> 0x5753
  0xAD40-0xAFCF <-> 0x5323-0x5752
  0xAFD0-0xBBC7 <-> 0x5754-0x6B4F
  0xBBC8-0xBE51 <-> 0x6B51-0x6F5B
         0xBE52 <-> 0x6B50
  0xBE53-0xC1AA <-> 0x6F5C-0x7534
  0xC1AB-0xC2CA <-> 0x7536-0x7736
         0xC2CB <-> 0x7535
  0xC2CC-0xC360 <-> 0x7737-0x782C
  0xC361-0xC3B8 <-> 0x782E-0x7863
         0xC3B9 <-> 0x7865
         0xC3BA <-> 0x7864
  0xC3BB-0xC455 <-> 0x7866-0x7961
         0xC456 <-> 0x782D
  0xC457-0xC67E <-> 0x7962-0x7D4B  # Level 1 Hanzi END
  0xC6A1-0xC6AA <-> 0x2621-0x262A  # Circled numerals
  0xC6AB-0xC6B4 <-> 0x262B-0x2634  # Parenthesized numerals
  0xC6B5-0xC6BE <-> 0x2635-0x263E  # Lowercase Roman numerals
  0xC6BF-0xC6C0 <-> 0x2723-0x2724  # 213 radicals BEGIN
  0xC6C1-0xC6C2 <-> 0x2726, 0x2728
  0xC6C3-0xC6C5 <-> 0x272D-0x272F
  0xC6C6-0xC6C7 <-> 0x2734, 0x2737
  0xC6C8-0xC6C9 <-> 0x273A, 0x273C
  0xC6CA-0xC6CB <-> 0x2742, 0x2747
  0xC6CC-0xC6CD <-> 0x274E, 0x2753
  0xC6CE-0xC6CF <-> 0x2754-0x2755
  0xC6D0-0xC6D1 <-> 0x2759-0x275A
  0xC6D2-0xC6D3 <-> 0x2761, 0x2766
  0xC6D4-0xC6D5 <-> 0x2829-0x282A
  0xC6D6-0xC6D7 <-> 0x2863, 0x286C # 213 radicals END
  0xC6D8-0xC6E6  -> ******         # Japanese symbols
  0xC6E7-0xC77A  -> ******         # Hiragana
  0xC77B-0xC7F2  -> ******         # Katakana
  0xC7F3-0xC875  -> ******         # Cyrillic alphabet
  0xC876-0xC878  -> ******         # Symbols
         0xC87A  -> ******         # Hanzi element
         0xC87C  -> ******         # Hanzi element
  0xC87E-0xC8A1  -> ******         # Hanzi elements
  0xC8A3-0xC8A4  -> ******         # Hanzi elements
  0xC8A5-0xC8CC  -> ******         # Combined numerals
  0xC8CD-0xC8D3  -> ******         # Japanese symbols

Big Five Level 1 Correspondences to CNS 11643-1992 Plane 4:

         0xC879 <-> 0x2123         # Hanzi element
         0xC87B <-> 0x2124         # Hanzi element
         0xC87D <-> 0x212A         # Hanzi element
         0xC8A2 <-> 0x2152         # Hanzi element

Big Five Level 2 Correspondence to CNS 11643-1992 Plane 1:

         0xC94A  -> 0x4442         # duplicate of 0xA461

Big Five Level 2 Correspondences to CNS 11643-1992 Plane 2:

  0xC940-0xC949 <-> 0x2121-0x212A  # Level 2 Hanzi BEGIN
  0xC94B-0xC96B <-> 0x212B-0x214B
  0xC96C-0xC9BD <-> 0x214D-0x217C
         0xC9BE <-> 0x214C
  0xC9BF-0xC9EC <-> 0x217D-0x224C
  0xC9ED-0xCAF6 <-> 0x224E-0x2438
         0xCAF7 <-> 0x224D
  0xCAF8-0xD6CB <-> 0x2439-0x376E
         0xD6CC <-> 0x3E63
  0xD6CD-0xD779 <-> 0x3770-0x387D
         0xD77A <-> 0x3F6A
  0xD77B-0xDADE <-> 0x387E-0x3E62
         0xDADF <-> 0x376F
  0xDAE0-0xDBA6 <-> 0x3E64-0x3F69
  0xDBA7-0xDDFB <-> 0x3F6B-0x4423
         0xDDFC  -> 0x4176         # duplicate of 0xDCD1
  0xDDFD-0xE8A2 <-> 0x4424-0x554A
  0xE8A3-0xE975 <-> 0x554C-0x5721
  0xE976-0xEB5A <-> 0x5723-0x5A27
  0xEB5B-0xEBF0 <-> 0x5A29-0x5B3E
         0xEBF1 <-> 0x554B
  0xEBF2-0xECDD <-> 0x5B3F-0x5C69
         0xECDE <-> 0x5722
  0xECDF-0xEDA9 <-> 0x5C6A-0x5D73
  0xEDAA-0xEEEA <-> 0x5D75-0x6038
         0xEEEB <-> 0x642F
  0xEEEC-0xF055 <-> 0x6039-0x6242
         0xF056 <-> 0x5D74
  0xF057-0xF0CA <-> 0x6243-0x6336
         0xF0CB <-> 0x5A28
  0xF0CC-0xF162 <-> 0x6337-0x642E
  0xF163-0xF16A <-> 0x6430-0x6437
         0xF16B <-> 0x6761
  0xF16C-0xF267 <-> 0x6438-0x6572
         0xF268 <-> 0x6934
  0xF269-0xF2C2 <-> 0x6573-0x664C
  0xF2C3-0xF374 <-> 0x664E-0x6760
  0xF375-0xF465 <-> 0x6762-0x6933
  0xF466-0xF4B4 <-> 0x6935-0x6961
         0xF4B5 <-> 0x664D
  0xF4B6-0xF4FC <-> 0x6962-0x6A4A
  0xF4FD-0xF662 <-> 0x6A4C-0x6C51
         0xF663 <-> 0x6A4B
  0xF664-0xF976 <-> 0x6C52-0x7165
  0xF977-0xF9C3 <-> 0x7167-0x7233
         0xF9C4 <-> 0x7166
         0xF9C5 <-> 0x7234
         0xF9C6 <-> 0x7240
  0xF9C7-0xF9D1 <-> 0x7235-0x723F
  0xF9D2-0xF9D5 <-> 0x7241-0x7244  # Level 2 Hanzi END
  0xF9DD-0xF9FE  -> ******         # Symbols

Big Five Level 2 Correspondence to CNS 11643-1992 Plane 3:

         0xF9D6 <-> 0x4337         # ETen-specific hanzi
         0xF9D7 <-> 0x4F50         # ETen-specific hanzi
         0xF9D8 <-> 0x444E         # ETen-specific hanzi
         0xF9D9 <-> 0x504A         # ETen-specific hanzi
         0xF9DA <-> 0x2C5D         # ETen-specific hanzi
         0xF9DB <-> 0x3D7E         # ETen-specific hanzi
         0xF9DC <-> 0x4B5C         # ETen-specific hanzi

I adapted the above from material Ross Paterson (rap@doc.ic.ac.uk)
kindly made available at the following URL:

  http://www.ifcss.org:8001/www/pub/software/info/cjk-codes/

Check it out. Basically, I just changed the CNS 11643-1992 codes from
decimal row-cell values to hexadecimal codes, and corrected the
mappings to correspond to ETen's Big Five (which is considered to be
the most standard).
	It turns out that corrections were made to Big Five (at least
in the ETen and Microsoft implementations thereof) which made it a bit
closer to CNS 11643-1992 as far as character ordering is concerned.
The following six lines of code correspondences:

  0xCAF8-0xD6CB <-> 0x2439-0x376E
         0xD6CC <-> 0x3E63
  0xD6CD-0xD779 <-> 0x3770-0x387D
         0xD77A <-> 0x3F6A
  0xD77B-0xDADE <-> 0x387E-0x3E62
         0xDADF <-> 0x376F

can now be expressed as the following three lines:

  0xCAF8-0xD779 <-> 0x2439-0x387D
         0xD77A <-> 0x3F6A
  0xD77B-0xDBA6 <-> 0x387E-0x3F69

In essence, the ordering of Big Five characters 0xD6CC and 0xDADF were
reversed. This resulted in the same order as found in CNS 11643-1992
Plane 2.
	As for the two duplicate hanzi in Big Five (as indicated in
the above tables), they have been placed into a compatibility zone in
ISO 10646-1:1993 (this allows for round-trip conversion). The mapping
is as follows:

  Big Five  ISO 10646-1:1993
  ^^^^^^^^  ^^^^^^^^^^^^^^^^
  0xC94A -> 0xFA0C
  0xDDFC -> 0xFA0D

	Speaking of duplicate hanzi, Plane 1 of CNS 11643-1992
contains 213 classical radicals in rows 27 through 29. However, 187 of
them map directly to hanzi code points in Planes 1, 2, and 3 (and
naturally to Big Five). Below is a detailed mapping of these 213
radicals:

  Radical   CNS 11643   Big Five    Radical   CNS 11643   Big Five
  ^^^^^^^   ^^^^^^^^^   ^^^^^^^^    ^^^^^^^   ^^^^^^^^^   ^^^^^^^^
  0x2721 -> 0x4421      0xA440      0x282E -> 0x4678      0xA5D8
  0x2722 -> 0x2121 (3)  ******      0x282F -> 0x4679      0xA5D9
  0x2723 -> 0x2122 (3)  0xC6BF      0x2830 -> 0x467A      0xA5DA
  0x2724 -> 0x2123 (3)	0xC6C0      0x2831 -> 0x467B      0xA5DB
  0x2725 -> 0x4422      0xA441      0x2832 -> 0x467C      0xA5DC
  0x2726 -> 0x2124 (3)	0xC6C1      0x2833 -> 0x2167 (2)  0xC9A8
  0x2727 -> 0x4428      0xA447      0x2834 -> 0x467D      0xA5DD
  0x2728 -> ******	0xC6C2      0x2835 -> 0x467E      0xA5DE
  0x2729 -> 0x4429      0xA448      0x2836 -> 0x4721      0xA5DF
  0x272A -> 0x442A      0xA449      0x2837 -> 0x484C      0xA6CB
  0x272B -> 0x442B      0xA44A      0x2838 -> 0x484D      0xA6CC
  0x272C -> 0x442C      0xA44B      0x2839 -> 0x484E      0xA6CD
  0x272D -> 0x2127 (3)	0xC6C3      0x283A -> 0x484F      0xA6CE
  0x272E -> 0x2128 (3)	0xC6C4      0x283B -> 0x2269 (2)  0xCA49
  0x272F -> ******	0xC6C5      0x283C -> 0x4850      0xA6CF
  0x2730 -> 0x442D      0xA44C      0x283D -> 0x4851      0xA6D0
  0x2731 -> 0x2123 (2)  0xC942      0x283E -> 0x4852      0xA6D1
  0x2732 -> 0x442E      0xA44D      0x283F -> 0x4854      0xA6D3
  0x2733 -> 0x4430      0xA44F      0x2840 -> 0x4855      0xA6D4
  0x2734 -> ******      0xC6C6      0x2841 -> 0x4856      0xA6D5
  0x2735 -> 0x4431      0xA450      0x2842 -> 0x4857      0xA6D6
  0x2736 -> 0x2124 (2)  0xC943      0x2843 -> 0x4858      0xA6D7
  0x2737 -> 0x2129 (3)  0xC6C7      0x2844 -> 0x485B      0xA6DA
  0x2738 -> 0x4432      0xA451      0x2845 -> 0x485C      0xA6DB
  0x2739 -> 0x4433      0xA452      0x2846 -> 0x485D      0xA6DC
  0x273A -> 0x212A (3)  0xC6C8      0x2847 -> 0x485E      0xA6DD
  0x273B -> 0x2125 (2)  0xC944      0x2848 -> 0x485F      0xA6DE
  0x273C -> 0x212B (3)  0xC6C9      0x2849 -> 0x4860      0xA6DF
  0x273D -> 0x4434      0xA453      0x284A -> 0x4861      0xA6E0
  0x273E -> 0x4447      0xA466      0x284B -> 0x4862      0xA6E1
  0x273F -> 0x212A (2)  0xC949      0x284C -> 0x4863      0xA6E2
  0x2740 -> 0x4448      0xA467      0x284D -> 0x226A (2)  0xCA4A
  0x2741 -> 0x4449      0xA468      0x284E -> 0x226F (2)  0xCA4F
  0x2742 -> 0x213A (3)  0xC6CA      0x284F -> 0x4865      0xA6E4
  0x2743 -> 0x444A      0xA469      0x2850 -> 0x4866      0xA6E5
  0x2744 -> 0x444B      0xA46A      0x2851 -> 0x4867      0xA6E6
  0x2745 -> 0x444C      0xA46B      0x2852 -> 0x4868      0xA6E7
  0x2746 -> 0x444D      0xA46C      0x2853 -> 0x2270 (2)  0xCA50
  0x2747 -> 0x213B (3)  0xC6CB      0x2854 -> 0x4B44      0xA8A3
  0x2748 -> 0x4450      0xA46F      0x2855 -> 0x4B45      0xA8A4
  0x2749 -> 0x4451      0xA470      0x2856 -> 0x4B46      0xA8A5
  0x274A -> 0x4452      0xA471      0x2857 -> 0x4B47      0xA8A6
  0x274B -> 0x4453      0xA472      0x2858 -> 0x4B48      0xA8A7
  0x274C -> 0x212B (2)  0xC94B      0x2859 -> 0x4B49      0xA8A8
  0x274D -> 0x4454      0xA473      0x285A -> 0x2524 (2)  0xCBA4
  0x274E -> 0x213C (3)  0xC6CC      0x285B -> 0x4B4A      0xA8A9
  0x274F -> 0x4456      0xA475      0x285C -> 0x4B4B      0xA8AA
  0x2750 -> 0x4457      0xA476      0x285D -> 0x4B4C      0xA8AB
  0x2751 -> 0x445A      0xA479      0x285E -> 0x4B4D      0xA8AC
  0x2752 -> 0x445B      0xA47A      0x285F -> 0x4B4E      0xA8AD
  0x2753 -> 0x213D (3)  0xC6CD      0x2860 -> 0x4B4F      0xA8AE
  0x2754 -> 0x213E (3)  0xC6CE      0x2861 -> 0x4B50      0xA8AF
  0x2755 -> 0x213F (3)  0xC6CF      0x2862 -> 0x4B51      0xA8B0
  0x2756 -> 0x445C      0xA47B      0x2863 -> 0x272F (3)  0xC6D6
  0x2757 -> 0x445D      0xA47C      0x2864 -> 0x4B57      0xA8B6
  0x2758 -> 0x445E      0xA47D      0x2865 -> 0x4B5C      0xA8BB
  0x2759 -> 0x2140 (3)  0xC6D0      0x2866 -> 0x4B5D      0xA8BC
  0x275A -> 0x2142 (3)  0xC6D1      0x2867 -> 0x4B5E      0xA8BD
  0x275B -> 0x212C (2)  0xC94C      0x2868 -> 0x4F5A      0xAAF7
  0x275C -> 0x4540      0xA4DF      0x2869 -> 0x4F5B      0xAAF8
  0x275D -> 0x4541      0xA4E0      0x286A -> 0x4F5C      0xAAF9
  0x275E -> 0x4542      0xA4E1      0x286B -> 0x4F5D      0xAAFA
  0x275F -> 0x4543      0xA4E2      0x286C -> 0x2A7D (3)  0xC6D7
  0x2760 -> 0x4545      0xA4E4      0x286D -> 0x4F63      0xAB41
  0x2761 -> 0x2167 (3)  0xC6D2      0x286E -> 0x4F64      0xAB42
  0x2762 -> 0x4546      0xA4E5      0x286F -> 0x4F65      0xAB43
  0x2763 -> 0x4547      0xA4E6      0x2870 -> 0x4F66      0xAB44
  0x2764 -> 0x4548      0xA4E7      0x2871 -> 0x5372      0xADB1
  0x2765 -> 0x4549      0xA4E8      0x2872 -> 0x5373      0xADB2
  0x2766 -> 0x2169 (3)  0xC6D3      0x2873 -> 0x5374      0xADB3
  0x2767 -> 0x454A      0xA4E9      0x2874 -> 0x5375      0xADB4
  0x2768 -> 0x454B      0xA4EA      0x2875 -> 0x5376      0xADB5
  0x2769 -> 0x454C      0xA4EB      0x2876 -> 0x5377      0xADB6
  0x276A -> 0x454D      0xA4EC      0x2877 -> 0x5378      0xADB7
  0x276B -> 0x454E      0xA4ED      0x2878 -> 0x5379      0xADB8
  0x276C -> 0x454F      0xA4EE      0x2879 -> 0x537A      0xADB9
  0x276D -> 0x4550      0xA4EF      0x287A -> 0x537B      0xADBA
  0x276E -> 0x213F (2)  0xC95F      0x287B -> 0x537C      0xADBB
  0x276F -> 0x4551      0xA4F0      0x287C -> 0x586B      0xB0A8
  0x2770 -> 0x4552      0xA4F1      0x287D -> 0x586C      0xB0A9
  0x2771 -> 0x4553      0xA4F2      0x287E -> 0x586D      0xB0AA
  0x2772 -> 0x4554      0xA4F3      0x2921 -> 0x334C (2)  0xD449
  0x2773 -> 0x2141 (2)  0xC961      0x2922 -> 0x586E      0xB0AB
  0x2774 -> 0x4555      0xA4F4      0x2923 -> 0x334D (2)  0xD44A
  0x2775 -> 0x4556      0xA4F5      0x2924 -> 0x586F      0xB0AC
  0x2776 -> 0x4557      0xA4F6      0x2925 -> 0x5870      0xB0AD
  0x2777 -> 0x4558      0xA4F7      0x2926 -> 0x5E23      0xB3BD
  0x2778 -> 0x4559      0xA4F8      0x2927 -> 0x5E24      0xB3BE
  0x2779 -> 0x2142 (2)  0xC962      0x2928 -> 0x5E25      0xB3BF
  0x277A -> 0x455A      0xA4F9      0x2929 -> 0x5E26      0xB3C0
  0x277B -> 0x455B      0xA4FA      0x292A -> 0x5E27      0xB3C1
  0x277C -> 0x455C      0xA4FB      0x292B -> 0x5E28      0xB3C2
  0x277D -> 0x455D      0xA4FC      0x292C -> 0x6327      0xB6C0
  0x277E -> 0x4668      0xA5C8      0x292D -> 0x6328      0xB6C1
  0x2821 -> 0x4669      0xA5C9      0x292E -> 0x6329      0xB6C2
  0x2822 -> 0x466A      0xA5CA      0x292F -> 0x4155 (2)  0xDCB0
  0x2823 -> 0x466B      0xA5CB      0x2930 -> 0x4875 (2)  0xE0EF
  0x2824 -> 0x466C      0xA5CC      0x2931 -> 0x676F      0xB9A9
  0x2825 -> 0x466D      0xA5CD      0x2932 -> 0x6770      0xB9AA
  0x2826 -> 0x466E      0xA5CE      0x2933 -> 0x6771      0xB9AB
  0x2827 -> 0x4670      0xA5D0      0x2934 -> 0x6B7C      0xBBF3
  0x2828 -> 0x4674      0xA5D4      0x2935 -> 0x6B7D      0xBBF4
  0x2829 -> 0x225B (3)  0xC6D4      0x2936 -> 0x702F      0xBEA6
  0x282A -> 0x225C (3)  0xC6D5      0x2937 -> 0x733E      0xC073
  0x282B -> 0x4675      0xA5D5      0x2938 -> 0x733F      0xC074
  0x282C -> 0x4676      0xA5D6      0x2939 -> 0x6142 (2)  0xEFB6
  0x282D -> 0x4677      0xA5D7


4.4: KOREAN

	The 268 duplicate hanja in KS C 5601-1992 can cause problems
when converting to and from other CJK character sets. When converting
from KS C 5601-1992, two or more hanja can collapse into a single code
point. When converting these 268 hanja to KS C 5601-1992, a decision
about which KS C 5601-1992 code point to map to must be made. The only
exception to this is mapping to and from ISO 10646-1:1993. That
standard encodes these 268 duplicate hanja in a compatibility zone,
namely from 0xF900 through 0xFA0B.
	The following is a listing of 262 hanja that map to two or
more code points (four map to three code points, and one maps to four:
a total of 268 redundantly-encoded hanja) in KS C 5601-1992:

  Standard  Extra     Standard  Extra     Standard  Extra
  ^^^^^^^^  ^^^^^     ^^^^^^^^  ^^^^^     ^^^^^^^^  ^^^^^
  0x4A39 -> 0x4D4F    0x5573 -> 0x6631    0x573C -> 0x6B29
  0x4B3D -> 0x7A22    0x5574 -> 0x6633    0x573E -> 0x6B3A
  0x4C38 -> 0x7A66    0x5575 -> 0x6637    0x573F -> 0x6B3B
  0x4C5A -> 0x4B56    0x5576 -> 0x6638    0x5740 -> 0x6B3D
  0x4C78 -> 0x5050    0x5579 -> 0x663C    0x5741 -> 0x6B41
  0x4D7A -> 0x4E2D    0x557B -> 0x6646    0x5743 -> 0x6B42
  0x4E29 -> 0x7C29    0x557C -> 0x6647    0x5744 -> 0x6B46
  0x4F23 -> 0x4F7B    0x557E -> 0x6652    0x5745 -> 0x6B47
  0x4F4F -> 0x5022    0x5621 -> 0x6656    0x5747 -> 0x6B4C
            0x5038    0x5622 -> 0x6659    0x5748 -> 0x6B4F
  0x5142 -> 0x4B50    0x5623 -> 0x665F    0x5749 -> 0x6B50
  0x5151 -> 0x505D    0x5624 -> 0x6661    0x574A -> 0x6B51
  0x5159 -> 0x547C    0x5625 -> 0x6665    0x574C -> 0x6B58
  0x5167 -> 0x552B    0x5626 -> 0x6664    0x574D -> 0x5270
  0x522F -> 0x5155    0x5627 -> 0x6666    0x574E -> 0x5271
  0x5233 -> 0x657C    0x5628 -> 0x6668    0x574F -> 0x5272
  0x5234 -> 0x6644    0x562A -> 0x666A    0x5750 -> 0x5273
  0x5235 -> 0x664A    0x562B -> 0x666B    0x5752 -> 0x5274
  0x5236 -> 0x665C    0x562D -> 0x666F    0x5753 -> 0x5275
  0x5237 -> 0x6676    0x562E -> 0x6671    0x5754 -> 0x5277
  0x523A -> 0x6677    0x562F -> 0x6675    0x5755 -> 0x5278
  0x523B -> 0x5638    0x5631 -> 0x6679    0x5757 -> 0x6C26
            0x672C    0x5633 -> 0x6721    0x5759 -> 0x6C27
  0x5241 -> 0x564D    0x5634 -> 0x6726    0x575B -> 0x6C2A
  0x5263 -> 0x6871    0x5635 -> 0x6729    0x575D -> 0x6C30
  0x526E -> 0x6A74    0x5637 -> 0x672A    0x575E -> 0x6C31
  0x526F -> 0x6B2A    0x563A -> 0x672D    0x5762 -> 0x6C35
  0x527A -> 0x6C32    0x563B -> 0x6730    0x5765 -> 0x6C38
  0x527B -> 0x6C49    0x563C -> 0x673F    0x5767 -> 0x6C3A
  0x527C -> 0x6C4A    0x563E -> 0x6746    0x576A -> 0x6C40
  0x527E -> 0x7331    0x5640 -> 0x6747    0x576B -> 0x6C41
  0x5321 -> 0x552E    0x5642 -> 0x674B    0x576C -> 0x6C45
  0x5358 -> 0x7738    0x5643 -> 0x674D    0x576E -> 0x6C46
  0x536B -> 0x7748    0x5644 -> 0x674F    0x5770 -> 0x6C55
  0x5378 -> 0x7674    0x5645 -> 0x6750    0x5772 -> 0x6C5D
  0x5441 -> 0x5466    0x5647 -> 0x6753    0x5773 -> 0x6C5E
  0x5457 -> 0x7753    0x5649 -> 0x675F    0x5774 -> 0x6C61
  0x547A -> 0x5154    0x564A -> 0x6764    0x5776 -> 0x6C64
  0x547B -> 0x5158    0x564B -> 0x6766    0x5777 -> 0x6C67
  0x547D -> 0x515B    0x564C -> 0x523E    0x5778 -> 0x6C68
  0x547E -> 0x515C    0x564F -> 0x5242    0x5779 -> 0x6C77
  0x5521 -> 0x515D    0x5650 -> 0x5243    0x577A -> 0x6C78
  0x5522 -> 0x515E    0x5653 -> 0x5244    0x577C -> 0x6C7A
  0x5523 -> 0x515F    0x5654 -> 0x5246    0x5821 -> 0x6D21
  0x5524 -> 0x5160    0x5655 -> 0x5247    0x5822 -> 0x6D22
  0x5526 -> 0x5163    0x5656 -> 0x5248    0x5823 -> 0x6D23
  0x5527 -> 0x5164    0x5657 -> 0x5249    0x5A72 -> 0x5B64
  0x5528 -> 0x5165    0x5658 -> 0x524A    0x5C56 -> 0x5D25
  0x552A -> 0x5166    0x565A -> 0x524B    0x5C5F -> 0x7870
  0x552C -> 0x5168    0x565B -> 0x524D    0x5C74 -> 0x5D55
  0x552D -> 0x5169    0x565C -> 0x524E    0x5D41 -> 0x5B45
  0x552F -> 0x516A    0x565E -> 0x524F    0x5F2F -> 0x616D
  0x5530 -> 0x516B    0x565F -> 0x5250    0x5F52 -> 0x6D6E
  0x5531 -> 0x516D    0x5660 -> 0x5251    0x5F5D -> 0x5F61
  0x5534 -> 0x516F    0x5661 -> 0x5252    0x5F63 -> 0x5E7E
  0x5535 -> 0x5170    0x5662 -> 0x5253    0x6063 -> 0x612D
  0x5536 -> 0x5172    0x5663 -> 0x5254              0x6672
  0x5539 -> 0x5176    0x5665 -> 0x5255    0x607D -> 0x5F68
  0x553D -> 0x517A    0x5666 -> 0x5256    0x6163 -> 0x574B
  0x5540 -> 0x517C    0x5667 -> 0x5257              0x6B52
  0x5541 -> 0x517D    0x566B -> 0x5259    0x6226 -> 0x5E7C
  0x5543 -> 0x517E    0x566C -> 0x525A    0x6326 -> 0x6429
  0x5544 -> 0x5222    0x566F -> 0x525E    0x635B -> 0x723D
  0x5545 -> 0x5223    0x5670 -> 0x525F    0x6427 -> 0x727A
  0x5546 -> 0x5227    0x5671 -> 0x5261    0x6442 -> 0x6777
  0x5547 -> 0x5228    0x5674 -> 0x5262    0x6445 -> 0x5162
  0x5548 -> 0x5229    0x5675 -> 0x6867              0x5525
  0x5549 -> 0x522A    0x5676 -> 0x6868              0x6879
  0x554D -> 0x522B    0x5677 -> 0x6870    0x6534 -> 0x652E
  0x554E -> 0x522D    0x5679 -> 0x6877    0x6636 -> 0x6C2F
  0x5552 -> 0x5232    0x567A -> 0x687B    0x6728 -> 0x6071
  0x5553 -> 0x6531    0x567B -> 0x687E    0x6856 -> 0x6A41
  0x5554 -> 0x6532    0x567E -> 0x6927    0x6C36 -> 0x5764
  0x5555 -> 0x6539    0x5721 -> 0x692C    0x6C56 -> 0x666C
  0x5557 -> 0x653B    0x5723 -> 0x694C    0x6D29 -> 0x7427
  0x5558 -> 0x653C    0x5724 -> 0x5264    0x6D33 -> 0x6E5B
  0x5559 -> 0x6544    0x5726 -> 0x5265    0x6F37 -> 0x746E
  0x555D -> 0x654E    0x5727 -> 0x5266    0x7263 -> 0x6375
  0x555E -> 0x6550    0x5728 -> 0x5267    0x7333 -> 0x4B67
  0x555F -> 0x6552    0x5729 -> 0x5268    0x7351 -> 0x5F33
  0x5561 -> 0x6556    0x572B -> 0x5269    0x742C -> 0x7676
  0x5564 -> 0x657A    0x572C -> 0x526A    0x7658 -> 0x6421
  0x5565 -> 0x657B    0x5730 -> 0x526B    0x7835 -> 0x5C25
  0x5566 -> 0x657E    0x5731 -> 0x6A65    0x786C -> 0x785B
  0x5569 -> 0x6621    0x5733 -> 0x6A77    0x7932 -> 0x5D74
  0x556B -> 0x6624    0x5735 -> 0x6A7C    0x7A3C -> 0x7A21
  0x556C -> 0x6627    0x5736 -> 0x6A7E    0x7B29 -> 0x6741
  0x556F -> 0x662D    0x5738 -> 0x6B24    0x7C41 -> 0x4D68
  0x5571 -> 0x662F    0x573A -> 0x6B27    0x7D3B -> 0x6977
  0x5572 -> 0x6630

The above table represents a weekend of my time (but time well spent,
in my opinion).


4.5: ISO 10646-1:1993

	The Chinese character subset of ISO 10646-1:1993
has excellent round-trip conversion capability with the various
national character sets. Those national character sets with duplicate
characters, such as KS C 5601-1992 (268 hanja) and Big Five (2 hanzi),
have corresponding code points in ISO 10646-1:1993 within
a compatibility zone. See Sections 4.3 and 4.4 for more details.
	Other issues regarding ISO 10646-1:1993 have to do with proper
character rendering (that is, how characters are displayed, printed,
or otherwise imaged). Many (sometimes) subtle character form
differences have been collapsed under ISO 10646-1:1993. Language or
locale was not one of the factors used in performing Han Unification.
This means that it is nearly impossible to create a single ISO 10646-1:
1993 font that meets the character form criteria of each of the four
CJK locales. An ISO 10646-1:1993 code point is not enough information
to render a Chinese character. If the font was specifically designed
for a single locale, it is a non-problem, but if there is any CJK
intent, text must be flagged for language or locale.


4.6: UNICODE

	One of the most interesting (and major) differences between
the current three flavors of Unicode are the number and arrangement of
pre-combined hangul. The following table provides a summary of the
differences:

  Unicode       Number of Pre-combined Hangul   UCS-2 Ranges
  ^^^^^^^       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   ^^^^^^^^^^^^
  Version 1.0   2,350 Basic Hangul              0x3400-0x3D3D

  Version 1.1   2,350 Basic Hangul              0x3400-0x3D3D
                1,930 Supplemental Hangul A     0x3D2E-0x44B7
                2,376 Supplemental Hangul B     0x44BE-0x4DFF

  Version 2.0  11,172 Hangul                    0xAC00-0xD7A3

Of the above three versions, the most controversial is Version 2.0.
Why? Because it is located in the user-defined range of Unicode
(O-Zone: 16,384 code points in 0xA000-0xDFFF), and occupies
approximately two-thirds of its space.
	The information in the above table is courtesy of the
following useful document:

  ftp://unicode.org/pub/MappingTables/EastAsiaMaps/Hangul-Codes.txt

The same file is also mirrored at the following URL:

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/map/hangul-codes.txt


4.7: CODE CONVERSION TIPS

	There are two types of conversions that can be performed. The
first type is converting between different encodings for the same
character set. This is usually without problems (but not always). The
second type is converting from one character set to another (it is not
usually relevant whether the underlying encoding has changed or not).
This usually involves the handling of characters that are in one
character set, but not the other. So, what to do?
	I suggest JConv for handling Japanese code conversion (this
means converting between JIS, Shift-JIS, and EUC encodings). This is
in the category of different encodings for the same character set. The
following URLs provide executables or source code:

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/mac/jconv-30.hqx
  ftp://ftp.ora.com/pub/examples/nutshell/ujip/mac/jconv-dd-181.hqx
  ftp://ftp.ora.com/pub/examples/nutshell/ujip/dos/jconv.exe
  ftp://ftp.ora.com/pub/examples/nutshell/ujip/src/jconv.c

There are other programs available that do the same basic thing as
JConv, such as kc and nkf. They are available at the following URL:

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/unix/

	For software and tables that handles Chinese code conversion
(this includes conversion to and from Japanese), I suggest browsing at
the following URLs:

  ftp://etlport.etl.go.jp/pub/iso-2022-cn/convert/
  ftp://ftp.ifcss.org/pub/software/dos/convert/
  ftp://ftp.ifcss.org/pub/software/mac/convert/
  ftp://ftp.ifcss.org/pub/software/ms-win/convert/
  ftp://ftp.ifcss.org/pub/software/unix/convert/
  ftp://ftp.ifcss.org/pub/software/vms/convert/
  ftp://ftp.net.tsinghua.edu.cn/pub/Chinese/convert/
  ftp://ftp.ora.com/pub/examples/nutshell/ujip/map/
  ftp://ftp.seed.net.tw/Pub/Chinese/DOS/code-convert/
  http://www.yajima.kuis.kyoto-u.ac.jp/staffs/yasuoka/CJK.html

The latter URL has FTP links to tables created by Koichi Yasuoka
(yasuoka@kudpc.kyoto-u.ac.jp).
	The following URLs provide utilities or tables for converting
between various Korean encodings (the last represent the same file):

  ftp://cair-archive.kaist.ac.kr/pub/hangul/code/
  ftp://ftp.ora.com/pub/examples/nutshell/ujip/map/non-hangul-codes.txt
  ftp://ftp.ora.com/pub/examples/nutshell/ujip/map/hangul-codes.txt
  ftp://unicode.org/pub/MappingTables/EastAsiaMaps/Hangul-Codes.txt

A popular Korean code conversion utility seems to be "hcode" by
June-Yub Lee (jylee@cims.nyu.edu).
	Finally, the following URLs provide many Unicode- and CJK-
related mapping tables:

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/map/
  ftp://ftp.ora.com/pub/examples/nutshell/ujip/unicode/
  ftp://unicode.org/pub/MappingTables/
  http://www.yajima.kuis.kyoto-u.ac.jp/staffs/yasuoka/CJK.html

Note that the official and authoritative Unicode mapping tables (from
Unicode values to various international, national and vendor
standards) are maintained by the Unicode Consortium at the following
URL:

  ftp://unicode.org/pub/MappingTables/

Version 2.0 of "The Unicode Standard" (to be published by Addison-
Wesley shortly) will include these mapping tables on CD-ROM.


PART 5: CJK-CAPABLE OPERATING SYSTEMS

	The first step in being able to display CJK text is to obtain
an operating system that handles such text (or an application that
sets up its own CJK-capable environment). Below I describe how
different types of machines can handle CJK text.
	Actually, for the first few releases of CJK.INF, these
subsections will be far from complete (some may even be empty!). The
purpose of CJK.INF is to provide detailed information on character set
standards and encoding systems, so I therefore consider this sort of
information secondary.


5.1: MS-DOS

	I am not aware of any CJK-capable MS-DOS operating system, but
localized versions do exist. CJK support has been introduced with
Microsoft's Windows operating system (see Section 5.2).


5.2: WINDOWS

	Microsoft has CJK versions of its Windows operating system
available. The latest versions of their Windows operating system are
called Windows 95 and Windows NT. Windows 95 supports the same
character sets and encodings as in Windows Version 3.1 -- Windows NT
supports Unicode (ISO 10646-1:1993). Contact Microsoft Corporation for
more details. The URL of their WWW Home Page is:

  http://www.microsoft.com/

Nadine Kano's "Developing International Software for Windows 95 and
Windows NT" provides abundant reference material for how CJK is
supported in Windows 95 and Windows NT. Check it out.
	TwinBridge is a package that adds CJK functionality to non-CJK
Windows. Demo versions of TwinBridge for Japanese and Chinese are at
the following URLs:

  ftp://ftp.netcom.com/pub/tw/twinbrg/Japanese/demo/tbjdemo.zip
  ftp://ftp.netcom.com/pub/tw/twinbrg/Chinese/demo/tbcdemo.zip

	Another useful CJK add-on for Windows 95 is NJWIN (see Section
7.10) by Hongbo Data Systems.


5.3: MACINTOSH

	Macintosh is well-known as a computer that was designed to
handle multilingual texts. There are currently fully-localized
operating systems available for Japanese (KanjiTalk), Chinese
(simplified and traditional available), and Korean (HangulTalk). In
addition, Apple has developed "Language Kits" (*LK) for Chinese (CLK)
and Japanese (JLK). A Korean Language Kit (KLK) will be released
shortly.
	These localized operating systems can usually be installed
together in order to make your system CJK-capable.
	The common portion of these CJK-capable operating systems is a
technology Apple calls "WorldScript II" ("WorldScript I" is for one-
byte scripts). It provides the basic one- and two-byte functionality.


5.4: UNIX AND X WINDOWS

	The typical encoding system used on UNIX and X Windows is EUC
(see Section 3.2). Many systems, such as IBM's AIX, can be configured
to handle both EUC and Shift-JIS (for Japanese). In addition, X11R6 (X
Window System, Version 11, Release 6) has many CJK-capable features.
	If you have a fast PC and a good amount of RAM (more than
4MB), you should consider replacing MS-DOS (and Microsoft Windows,
too, if you have it) with Linux, which is a full-blown UNIX operating
system that runs on Intel processors. You can even run X Windows
(X11R6). "Running Linux" by Matt Welsh and Lar Kaufman is an excellent
guide to installing and using Linux. The companion volume, "Linux
Network Administrator's Guide" by Olaf Kirch is also useful. Because
there is a fine line -- or no line at all -- between a user and System
Administrator when using Linux, "Essential System Administration"
Second Edition by AEleen Frisch is a must-have.
	Linux and Linux information are available at the following
URLs:

  ftp://sunsite.unc.edu/pub/Linux/
  http://sunsite.unc.edu/mdw/linux.html

I personally use Linux, and find it quite useful and powerful. My bias
comes from being a UNIX user. But, you can't beat the price (free),
and all of my favorite text-manipulation tools (such as Perl) are
readily available.


5.5: OTHERS

	No information yet.


PART 6: CJK TEXT AND INTERNET SERVICES

	Part 5 described how CJK text is handled on a machine
internally, but this part goes into the implications of handling such
text externally, namely for information interchange purposes. This
boils down to handling CJK text on Internet services.
	For more detailed information on how these and other Internet
services are used, I suggest "The Whole Internet User's Guide &
Catalog" by Ed Krol. For more information on setting up and
maintaining these and other Internet services, I suggest "Managing
Internet Information Services" by Cricket Liu et al.


6.1: ELECTRONIC MAIL

	The most basic Internet service is electronic mail (henceforth
to be called "e-mail"), which is virtually guaranteed to be available
to all users regardless of their system.
	Several Internet standards (called RFCs, short for Request For
Comments) have been developed to describe how CJK text is to be handled
over e-mail systems (see Section A.3.4).
	The bottom-line is that most e-mail systems do not support
8-bit characters (that is, bytes that have their 8th bit set). Some do
offer 8-bit support, but you can never know what path your e-mail
might take while on route to its recipient. This means that 7-bit ISO
2022 (or equivalent) is the ideal encoding to use when sending CJK
text through e-mail. If your operating system processes another
encoding system, you must convert from that encoding to one that is
compatible with 7-bit ISO 2022.
	However, even 7-bit ISO 2022 encoding can get mangled by
mail-routing software -- the escape character, sometimes even part of
the escape sequence (meaning more than just the escape character), is
stripped. The JConv tool described in Section 4.7 restores stripped
escape sequences for Japanese 7-bit ISO 2022.
	If your mailing software is MIME-compliant, there is a means
to identify the character set and encoding of the message using the
"charset" parameter. Some valid "charset" values include the
following:

o iso-2022-jp     (see Section 3.1.3)
o iso-2022-jp-2   (see Section 3.1.3)
o iso-2022-kr     (see Section 3.1.4)
o iso-2022-cn     (see Section 3.1.5)
o iso-2022-cn-ext (see Section 3.1.5)
o iso-8859-1

Insertion of these values should happen automatically.
	A last-ditch effort to send CJK text through e-mail is to use
uuencode or Base64 encoding (see Section 3.3.13). Base64 is something
that is usually done automatically by mailing software -- explicit
Base64 encoding is not common. The recipient must then run uudecode or
a Base64 decoder to get the original file (if such utilities are
available).


6.2: USENET NEWS

	Usenet News follows many of the same requirements as e-mail,
namely that 7-bit ISO 2022 encoding is ideal. However, some newsgroups
use specific encoding methods, such as:

  alt.chinese.text             (HZ encoding used for Chinese text)
  alt.chinese.text.big5        (Big Five encoding used for Chinese text)
  chinese.flame                (UTF-7)
  chinese.text.unicode         (UTF-8)

Also, the newsgroups in Korean (all begin with "han.*") use EUC (EUC-
KR) because the news-handling software in Korea has been designed to
handle eight-bit characters correctly. Mailing list versions of Korean
newsgroups are likely to use ISO-2022-KR encoding.
	One common problem with Usenet News is that the escape
characters used in 7-bit ISO 2022 encoding are sometimes stripped,
usually by the software used to post the article. This can be quite
annoying. There are programs available, such as JConv, that repair
such files by restoring the escape characters.
	Another common problem are news readers that do not allow
escape characters to function. One simple solution is to "pipe" the
article through a display command, such as "more," "page," "less," or
"cat." This is done by typing a "pipe" character (|) followed by the
command name anywhere within the article being displayed.


6.3: GOPHER

	The World-Wide Web (WWW) has almost eliminated the need for
using Gopher, so I won't discuss it here. Not that I don't appreciate
Gopher servers, but what I mean is that WWW browsing software permits
access to Gopher sites.


6.4: WORLD-WIDE WEB

	First, there are two types of WWW browsers available. The most
common type is the graphics-based browser (examples include Mosaic and
Netscape). Graphics-based browsers have the unfortunate requirement of
a TCP/IP (SLIP and PPP support these protocols) connection. Lynx and
the W3 client for Emacs, which are text-based browsers, can be run
from the host computer through a standard terminal connection. They
don't display all the pretty pictures that folks put into their WWW
documents, but you get all the text (this is, in many ways, a blessing
in disguise -- transferring graphics is what slows down graphics-based
browsers the most). When the W3 client is run using Mule, it becomes a
fully CJK-capable WWW browser. Both Lynx and the W3 client for Emacs
are freely available. A Japanese-capable Lynx is available at the
following URL:

  ftp://ftp.ipc.chiba-u.ac.jp/pub.asada/www/lynx/

There is also a WWW page that provides information on Japanese-capable
Lynx. Its URL is as follows:

  http://www.icsd6.tj.chiba-u.ac.jp/lynx/

	When WWW documents first came online, there was no method for
handling CJK character sets. This has, fortunately, changed. As of
this writing, two commercial WWW browsers support Japanese. They are
Infomosaic by Fujitsu Limited, and Netscape Navigator by Netscape
Communications Corporation (Version 1.1 added Japanese support). Both
are graphics-based browsers. The former can be ordered at the
following URL:

  http://www.fujitsu.co.jp/

The latter can be found at the following URLs:

  http://www.netscape.com/
  ftp://ftp.netscape.com/

	One can also use a delegate server to *filter* Japanese codes
to the one supported by your browser. It is also possible to
"Japanize" existing WWW browsers using assorted tools and patches.
Katsuhiko Momoi (momoi@tigger.stcloud.msus.edu) has authored an
excellent guide to Japanizing WWW browsers. Its URL is:

  http://condor.stcloud.msus.edu:20020/netscape.html

I *highly* suggest reading it.
	Japanese-capable WWW browsers support automatic detection of
the three Japanese encoding methods (JIS, Shift-JIS, and EUC). Hey,
but, what about support for the "C" and "K" of CJK? Attempting to
answer this question provides us an answer to another question: "What
is the best encoding method to use for CJK WWW documents?"
	Encoding methods such as EUC and Shift-JIS provide for mixing
only two character sets. This is because they provide no way to *flag*
or *tag* text for locale (character set) information. Without flagging
information, it is impossible to distinguish Japanese EUC from Chinese
or Korean EUC. However, the escape sequences used in 7-bit ISO 2022
encoding explicitly provide locale information. 7-bit ISO 2022 is
ideal for static documents, which is exactly what one finds on WWW.
	My personal recommendation (for the short-term) is to compose
WWW documents (also called HTML documents; HTML stands for Hyper Text
Markup Language) using 7-bit ISO 2022 encoding. The escape sequences
themselves act as explicit flags that indicate locale. However, some
WWW clients are confused by 7-bit ISO 2022 encoding, but the products
by Netscape Communications and Fujitsu Limited prove that this can
work. See the following URL for a description of this problem:

  http://www.ntt.jp/japan/note-on-JP/LibWWW-patch.html

	Check out the following URLs for information on and proposals
for international support for WWW:

  http://www.ebt.com:8080/docs/multilingual-www.html
  http://www.w3.org/hypertext/WWW/International/Overview/

	There is currently an RFC in the works (called an Internet
Draft) to address the problem of internationalizing HTML by using
Unicode. It is very promising. The latest draft is available at the
following URLs:

  ftp://ds.internic.net/internet-drafts/draft-ietf-html-i18n-04.txt.Z
  ftp://ftp.isi.edu/internet-drafts/draft-ietf-html-i18n-04.txt
  ftp://munnari.oz.au/internet-drafts/draft-ietf-html-i18n-04.txt.Z
  ftp://nic.nordu.net/internet-drafts/draft-ietf-html-i18n-04.txt

Note that some have been compressed.


6.5: FILE TRANSFER TIPS

	Although CJK encoding systems such as Shift-JIS and EUC make
extensive use of 8-bit bytes, that does not mean that you need to
treat the data as binary. Such files are simply to be treated as text,
and should be transferred in text mode (for example, FTP's ASCII mode,
which is also called "Type A Transfer").
	When text files are transferred in binary mode (such as FTP's
BINARY mode, which is also called Type I Transfer"), line termination
characters are left unaltered. For example, when transferring a text
file from UNIX to Macintosh, a text transfer will translate the UNIX
newline (0x0A) characters to Macintosh carriage return (0x0D)
characters, but a binary transfer will make no such modifications.
Text-style conversion is typically desired.
	The most common types of files that need to be handled as
binary include tar archives (*.tar), compressed files (*.Z, *.gz,
*.zip, *.zoo, *.lzh, and so on), and executables (*.exe, *.bin, and so
on).


PART 7: CJK TEXT HANDLING SOFTWARE

	This section describes various CJK-capable software packages.
I expect this section to grow with future versions of this document. I
define "CJK-capable" as being able to support Chinese, Japanese, and
Korean text.
	The descriptions I provide below are intentionally short. You
are encouraged to use the information pointers to obtain further
information or the software itself.


7.1: MULE

	Mule (multilingual enhancement to GNU Emacs), written by
Kenichi Handa (handa@etl.go.jp), is the first (and only?) CJK-capable
editor for UNIX systems, and is freely available under the terms of
the GNU General Public License. Mule was developed from Nemacs
(Nihongo Emacs).
	Mule is available at the following URL:

  ftp://etlport.etl.go.jp/pub/mule/

	Mule, beginning with Version 2.2, includes handy utilities
(any2ps and m2ps) for printing files in any of the encodings supported
by Mule (which is a lot of encodings, by the way). These programs use
BDF fonts. See the beginning of Part 2 for a list of URLs that have
CJK BDF fonts.
	GNU Emacs is a fine editor, and Mule takes it several steps
further by providing multilingual support. I personally use Mule
together with SKK (for Japanese input) -- it is a superb combination.


7.2: CNPRINT

	CNPRINT, developed by Yidao Cai (cai@neurophys.wisc.edu), is a
utility to print CJK text (or convert it to a PostScript file), and is
available for MS-DOS, VMS, and UNIX systems. A wide range of encoding
methods are supported by CNPRINT.
	CNPRINT is available at the following URLs:

  ftp://ftp.ifcss.org/pub/software/{dos,unix,vms}/print/
  ftp://neurophys.wisc.edu/[public.cn]/


7.3: MASS

	MASS (Multilingual Application Support Service), developed at
the National University of Singapore, is a suite of software tools
that speed and ease the development of UNIX-based CJK (actually, more
than just CJK) applications. It supports a wide variety of character
sets and encodings, including ISO 10646-1:1993 (UCS-2, UTF-7, and
UTF-8), EACC, and CCCII.
	More information on MASS, to include contact information for
its developers, can be found at the following URL:

  http://www.iss.nus.sg/RND/MLP/Projects/MASS/MASS.html


7.4: ADOBE TYPE MANAGER (ATM)

	Adobe Type Manager for Macintosh, beginning with Version 3.8,
is CJK-capable (as long as the underlying operating system is CJK-
capable). Actually, ATM generically supports CID-keyed fonts, which
are based on a newly-developed file specification for fonts with large
numbers of characters (like CJK fonts). See Section 7.9 for more
details.
	ATM is very easy to obtain. It is bundled with fonts and
applications from Adobe Systems (chances are you have ATM if you
recently purchased an Adobe product). But what about Windows? The
Windows version of ATM should soon follow with identical
functionality.


7.5: MACINTOSH SOFTWARE

	WorldScript II, a System Extension introduced with System 7,
provides multi-byte script handling, namely CJK support. If a
Macintosh product claims to support WorldScript II, chances are it is
CJK-capable (provided that your operating system has the necessary
extensions loaded).
	The CJK encodings that are supported by WorldScript II capable
applications are the same as made available by the underlying
Macintosh operating system. No import/export of other encodings is
supported at the operating system level. You must run separate
conversion utilities for both import and export. Anyway, below are
some products that are known to be CJK capable.
	Nisus Writer, written by Nisus Software, is fully CJK-capable
as long as you have the appropriate scripts installed (such as CLK for
Chinese or JLK for Japanese). A "Language Key" (read "dongle") is also
required for Chinese and Korean (and some one-byte scripts such as
Arabic and Hebrew). A demo version of Nisus Writer is available at the
following URL:

  ftp://ftp.nisus-soft.com/pub/nisus/demos/

Give it a try! Updates are also available at the same FTP site. Nisus
Software can be contacted using the following e-mail address or
through their WWW page:

  info@nisus-soft.com
  http://www.nisus-soft.com/

I also suggest reading "The Nisus Way" by Joe Kissell. Chapter 13
provides detailed information about using Nisus Writer with
WorldScript, and includes a CD-ROM containing among other things a
trial (expires after 90 days) version of Nisus Writer and a
non-expiring version of Nisus Compact.
	ClarisWorks by Claris Corporation, beginning with Version 4.0,
is compatible with WorldScript II and all Apple language kits. This
translates into full CJK support. The following URL provides a trial
version of ClarisWorks:

  ftp://ftp.claris.com/pub/USA-Macintosh/Trial_Software/

The following URL has detailed information on this and other Claris
products:

  http://www.claris.com/

	The latest version of WordPerfect by Novell Incorporated is
also compatible with WorldScript II. The following URL has detailed
information:

  http://wp.novell.com/tree.htm


7.6: MACBLUE TELNET

	Although MacBlue Telnet (a modified version of NCSA Telnet) is
Macintosh software, I describe it separately because it does not
require the various Apple Language Kits or localized operating
systems. There are also input methods, adapted from cxterm (see
Section 7.7), available that cover the CJK spectrum (Japanese,
Simplified Chinese, Traditional Chinese, and Korean).
	MacBlue Telnet is available at the following URL:

  ftp://ftp.ifcss.org/pub/software/mac/networking/MacBlueTelnet/

Its associated CJK input methods are at the following URL:

  ftp://ftp.ifcss.org/pub/software/mac/input/


7.7: CXTERM

	This program, cxterm, is a CJK-capable xterm for X Windows
(works with X11R4, X11R5, and X11R6). It is based on the X11R6 xterm.
It is available at the following URL:

  ftp://ftp.ifcss.org/pub/software/x-win/cxterm/

	The following URL is for a program that adds Unicode
capability to cxterm:

  ftp://ftp.ifcss.org/pub/software/unix/convert/hztty-2.0.tar.gz

The following URL adds support for other encodings to cxterm:

  ftp://ftp.ifcss.org/pub/software/unix/convert/BeTTY-1.534.tar.gz


7.8: UW-DBM

	UW-DBM, for Windows 3.1, Windows 95, and Windows NT, is a
program that allows users to handle Chinese (Big Five, GB-2312-80, or
HZ code), Japanese (Shift-JIS), and Korean (KS C 5601-1992)
simultaneously. More information on UW-DBM is available at the
following URL:

  http://www.gy.com/ccd/win95/cjkw95.htm

	A demo version of UW-DBM is available at the following URL:

  ftp://ftp.aimnet.com/pub/users/chinabus/uwdbm40.zip


7.9: POSTSCRIPT

	With the introduction of CID-keyed Font Technology, PostScript
has become fully CJK capable.
	Adobe Systems has developed the following CJK character
collection for CID-keyed fonts (font developers are encouraged to
conform to these specifications):

  Character Collection  CIDs   Supported Character Sets & Encodings
  ^^^^^^^^^^^^^^^^^^^^  ^^^^   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  Adobe-GB1-1           9,897  GB 2312-80 and GB/T 12345-90; 7-bit ISO
                               2022 and EUC
  Adobe-CNS1-0         14,099  Big Five (ETen extensions) and CNS
                               11643-1992 Planes 1 and 2; Big Five,
                               7-bit ISO 2022, and EUC
  Adobe-Japan1-2        8,720  JIS X 0208-1990; Shift-JIS, 7-bit ISO
                               2022, and EUC
  Adobe-Japan2-0        6,068  JIS X 0212-1990; 7-bit ISO 2022 and EUC
  Adobe-Korea1-1       18,155  KS C 5601-1992 (Macintosh extensions
                               plus Johab); 7-bit ISO 2022, EUC, UHC,
                               and Johab

Note that Macintosh and Windows do not support any of the encodings
for Adobe-Japan2-0, thus fonts based on that specification are
unusable for those platforms.
	Adobe Systems also have a few things in the works (that is,
they are either proposed or in draft form), all of which are
supplements to above character collections (that is, they add CIDs):

  Character Collection  CIDs   Supported Character Sets & Encodings
  ^^^^^^^^^^^^^^^^^^^^  ^^^^   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  Adobe-CNS1-1         +6,018  Add CNS 11643-1992 Plane 3 support (30
                               of the 6,148 hanzi are in Adobe-CNS1-0)

	To find out more about these CJK character collections or
CID-keyed font technology, contact the Adobe Developers Association.
Several CID-related documents have been published. ADA's contact
information is as follows:

  Adobe Developers Association
  Adobe Systems Incorporated
  1585 Charleston Road
  P.O. Box 7900
  Mountain View, CA 94039-7900
  USA
  +1-415-961-4111 (phone)
  +1-415-967-9231 (facsimile)
  devsupp-person@adobe.com
  http://www.adobe.com/Support/

Adobe Systems has recently developed the CID SDK (CID Software
Developers Kit), which is on a single CD-ROM. Contact the Adobe
Developers Association for information on obtaining a copy.
	The complete CID-keyed font file specification and an overview
document are available at the following URLs (as a PostScript or PDF
[Adobe Acrobat] file, respectively):

  ftp://ftp.adobe.com/pub/adobe/DeveloperSupport/TechNotes/PSfiles/
  ftp://ftp.adobe.com/pub/adobe/DeveloperSupport/TechNotes/PDFfiles/

The file names (not provided above due to URL length) are:

  5014.CMap_CIDFont_Spec.ps    (complete CID engineering specification)
  5014.CMap_CIDFont_Spec.pdf
  5092.CID_Overview.ps         (CID technology overview)
  5092.CID_Overview.pdf

Other related files, most character collection specifications, are
available only in PDF format at the latter URL indicated above:

  5004.AFM_Spec.pdf            (Includes CID-keyed AFM specification)
  5078b.pdf                    (Adobe-Japan1-2 character collection)
  5079b.pdf                    (Adobe-GB1-0 character collection)
  5080b.pdf                    (Adobe-CNS1-0 character collection)
  5093b.pdf                    (Adobe-Korea1-0 character collection)
  5094.pdf                     (Adobe CJK CMap file descriptions)
  5097b.pdf                    (Adobe-Japan2-0 character collection)

If you do not have Adobe Acrobat, there is a freely-available Acrobat
Reader (for Macintosh, Windows, MS-DOS, and UNIX) at the following
URL:

  ftp://ftp.adobe.com/pub/adobe/Applications/Acrobat/

	I have also placed some CJK character collection materials,
including prototype Unicode (UCS-2 and UTF-8) CMap files, at the
following URL:

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/adobe/

A sample (Adobe-Korea1-0) CIDFont is also available at the above URL.
	There is also a somewhat brief description of CID-keyed fonts
at the end of Chapter 6 in UJIP.


7.10: NJWIN

	Hongbo Data Systems has recently release a ShareWare ($49 USD)
product called NJWIN whose purpose is to force the display of CJK text
in non-CJK applications running under US Windows 95. Actually, there
are two versions: full CJK and Japanese only.
	NJWIN and its full description are available at the following
URL:

  http://www.njstar.com.au/njstar/njwin.htm

Other (popular) URLs that carry NJWIN are as follows:

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/windows/
  ftp://ftp.cc.monash.edu.au/pub/nihongo/

	Hongbo Data Systems' e-mail address is:

  hongbo@njstar.com.au

Their WWW Home Page is at the following URL:

  http://www.njstar.com.au/


PART 8: CJK PROGRAMMING ISSUES

	This new section describes issues related to using specific
programming languages to process CJK text.


8.1: C AND C++

	At one time I used C on a regular basis for my CJK programming
needs, and released three tools for others to use: JConv, JChar, and
JCode. While these tools are specific to Japanese, they can be easily
adapted for CJK use. Their source code is available at the following
URL:

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/src/

	I also provided several C code snippets in Chapter 7 of
UJIP. These are available in machine-readable form at the following
URL:

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/Ch7/


8.2: PERL

	Although Perl does not have any special CJK facilities (note
that most implementations of C and C++ do not either), it provides a
powerful programming environment that is useful for many CJK-related
tasks.
	The noteworthy features of Perl are associative arrays and
regular expressions. These are features not found in C or C++, and
allow one to write meaningful code in little time.
	JPerl is an implementation of Perl that provides two-byte
support for Japanese (EUC or Shift-JIS encoding). It is not ideal
because JPerl scripts often cannot run under (non-Japanese) Perl.
	If you often write programs for internal use, I suggest that
you check out Perl to see if it can offer you something. Chances are
that it can. A good place to start looking at Perl are through books
on the subject (see Section A.3.1) and at the following URL:

  http://www.perl.com/

	For those who like additional reading, "The Perl Journal" is
starting up, and information is at the following URL:

  http://work.media.mit.edu/the_perl_journal/


8.3: JAVA

	I am just starting to learn about the Java programming
language (and rightly so since my wife is Javanese!). It seems to have
a lot to offer.
	The most interesting aspects of Java are:

o Built-in support for Unicode and UTF-8.
o The programmer must write code in the object-oriented paradigm.
o Provides a portable way to supply compiled code.
o Security features for Internet use.

More information on Java are at the following URLs:

  http://www.gamelan.com/
  http://www.javasoft.com/

Oh, Gamelan is the name of Javanese music.
	Of the books about Java published thus far, the one I consider
to be the best is "Java in a Nutshell" by David Flanagan.
	One programming feature of Perl that I dearly miss in Java are
regexes (regular expressions). Luckily, some kind person wrote a regex
package for Java based on Perl regexes. Information on this Java regex
package is available at the following URL:

  http://www.win.net/~stevesoft/pat/


A FINAL NOTE

	I hope that the information presented here will prove
useful. I would like to keep the electronic version of this document
as up-to-date as possible, and through readers' input, I am able to
do so.
	Many readers will notice that I am very heavy into UNIX and
Macintosh (well, I recently got my first PC). If anyone has any
information on CJK-capable interfaces for other platforms, please feel
free to send it to me, and I will be sure to include it in the next
version of CJK.INF. Please include sources for the software or
documentation by providing addresses, phone numbers, FTP sites, and so
on.
	Please do not hesitate to ask me further question concerning
any subject presented in this document.


ACKNOWLEDGMENTS

	I would like to express my deepest thanks to Kazumasa Utashiro
of Internet Initiative Japan (IIJ). He taught to me how to send and
receive Japanese text using the 7-bit ISO 2022 codes back in 1989.
With his help I was able to write JAPAN.INF, my book, and this
document in order to inform others about what he has taught me plus
more.
	Next, I thank all the folks at O'Reilly & Associates for
publishing UJIP. Special thanks to Tim O'Reilly for accepting the book
proposal, and to Peter Mui for guiding me through the process. I have
had nothing but good experiences with "them there fine folks."
	I got to know Jack Halpern through UJIP, and he subsequently
translated it into Japanese. Many thanks to him.
	I am also grateful to my employer, Adobe Systems, for letting
me work on interesting CJK-related projects. I really like what I do
here. In particular, I want to thank Dan Mills, my manager, for
putting up with me for these past four years.
	Lastly, I would also like to thank the countless people who
provided comments on JAPAN.INF, UJIP, and CJK.INF. I hope that this
new document lives up to the spirit of my previous efforts.


APPENDIX A: OTHER INFORMATION SOURCES

	One of the most useful types of information are pointers to
other information sources. This appendix provides just that.


A.1: USENET NEWSGROUPS AND MAILING LISTS

	Appendix L of UJIP provided information on a number of mailing
lists. This section supplements that appendix with information on
other useful mailing lists, and points out which ones in UJIP are
relevant to readers of CJK.INF.


A.1.1: USENET NEWSGROUPS

	The following Usenet Newsgroups typically have postings with
information relevant to issues discussed in CJK.INF (in alphabetical
order):

  alt.chinese.computing
  alt.chinese.text                (HZ encoding used for Chinese text)
  alt.chinese.text.big5           (Big Five encoding used for Chinese text)
  alt.japanese.text               (JIS encoding used for Japanese text)
  chinese.flame                   (UTF-7)
  chinese.text.unicode            (UTF-8)
  comp.lang.c
  comp.lang.c++
  comp.lang.java
  comp.lang.perl.misc
  comp.software.international
  comp.std.internat
  fj.editor.mule                  (JIS encoding used for Japanese text)
  fj.kanji                        (JIS encoding used for Japanese text)
  fj.net.infosystems.www.browsers (JIS encoding used for Japanese text)
  fj.news.reader                  (JIS encoding used for Japanese text)
  han.comp.hangul
  han.sys.mac
  sci.lang.japan                  (JIS encoding used for Japanese text)

	If your local news host does not provide a feed of the fj.*
newsgroups (shame on them!), or if you do not have access to Usenet
News, you can alternatively fetch them from the following URL:

  ftp://kuso.shef.ac.uk/pub/News/

The subdirectories correspond to the newsgroup name, but with the
"dots" being replaced by "slashes." For example, the "fj.binaries.mac"
newsgroup is archived in the "fj/binaries/mac" subdirectory. Many
thanks to Earl Kinmonth (jp1ek@sunc.shef.uc.uk) for this service.
	There are some sites that carry full feeds of the fj.*
newsgroups, and permit public access (meaning that you can configure
your news reader to point to it). The only one I know of thus far is
as follows:

  ume.cc.tsukuba.ac.jp


A.1.2: MAILING LISTS

	The following are mailing lists that should interest readers
of this document (some are more active than others). The first line
after each entry indicates the address (or addresses) that can be used
for subscribing. The second line is the address for posting.

o CCNET-L MAILING LIST
  listserv@uga.uga.edu (or listserv@uga)
  ccnet-l@uga.uga.edu

o China Net Mailing List
  majordomo@lists.mindspring.com
  (See http://www.asia-net.com/ or jobs@asia-net.com)

o EASUG (East Asian Software Users Group) Mailing List
  easug-request@guvax.acc.georgetown.edu
  easug@guvax.acc.georgetown.edu

o EBTI-L (Electronic Buddhist Text Initiative) Mailing List
  ebti-l-request@uxmail.ust.hk
  ebti-l@uxmail.ust.hk

o EFJ (Electronic Frontiers Japan) Mailing List
  majordomo@lists.twics.com
  efj@lists.twics.com

o Hangul Mailing List (han.comp.hangul newsgroup)
  majordomo@cair.kaist.ac.kr
  hangul@cair.kaist.ac.kr

o INSOFT-L Mailing List
  majordomo@trans2.b30.ingr.com
  insoft-l@trans2.b30

o ISO 10646 Mailing List
  listproc@listproc.hcf.jhu.edu
  iso10646@listproc.hcf.jhu.edu

o Japan Net Mailing List
  majordomo@lists.mindspring.com
  (See http://www.asia-net.com/ or jobs@asia-net.com)

o KanjiTalk Mailing List
  kanjitalk-request@cs15.atr-sw.atr.co.jp (or kanjitalk-request@crl.go.jp)
  kanjitalk@cs15.atr-sw.atr.co.jp (or kanjitalk@crl.go.jp)

o Mac Mailing List (han.sys.mac newsgroup)
  majordomo@krnic.net
  mac@krnic.net

o Mule Mailing List
  mule-request@etl.go.jp
  mule@etl.go.jp or mule-jp@etl.go.jp

o NIHONGO Mailing List (sci.lang.japan newsgroup)
  listserv@mitvma.mit.edu (or listserv@mitvma)
  nihongo@mitvma.mit.edu

o Nihongo-Hiroba Mailing List
  listproc@mcfeeley.cc.utexas.edu
  nihongo-hiroba@mcfeeley.cc.utexas.edu

o Nisus Mailing List
  listserv@dartmouth.edu
  nisus@dartmouth.edu

o TLUG (Tokyo Linux User's Group) Mailing List
  majordomo@lists.twics.com
  tlug@lists.twics.com

o Unicode Mailing List
  unicode-request@unicode.org
  unicode@unicode.org

o WNN User Mailing List
  wnn-user-request@wnn.astem.or.jp
  wnn-user-jp@wnn.astem.or.jp

o WWW Multilingual Mailing List
  www-mling-request@square.ntt.jp
  www-mling@square.ntt.jp

If the name of the mailing list is part of the subscription address
(such as "easug-request"), the message body should look like this:

  subscribe

Including your name is optional. If username in the subscription
address is "listserv" or "majordomo" (these are names of mailing list
managing software), the mailing list name must appear after
"subscribe" in the message body as follows:

  subscribe ccnet-l

Again, including your name is optional.
	The following URL has information about Japanese-related
mailing lists:

  gopher://gan1.ncc.go.jp/11/INFO/mail-lists/


A.2: INTERNET RESOURCES

	The Internet provides what I would consider to be the greatest
information resources of all. These can be subcategorized into FTP,
Telnet, Gopher, WWW, and e-mail.


A.2.1: USEFUL FTP SITES

	Below are the URLs for useful FTP sites. The directory
specified is the recommended place from which to start poking around
for useful files.

  ftp://cair-archive.kaist.ac.kr/pub/hangul/
  ftp://etlport.etl.go.jp/pub/mule/
  ftp://ftp.adobe.com/pub/adobe/
  ftp://ftp.cc.monash.edu.au/pub/nihongo/
  ftp://ftp.ifcss.org/pub/software/
  ftp://ftp.ora.com/pub/examples/nutshell/ujip/
  ftp://ftp.sra.co.jp/pub/
  ftp://ftp.uwtc.washington.edu/pub/Japanese/
  ftp://kuso.shef.ac.uk/pub/Japanese/
  ftp://unicode.org/pub/

This list is expected to grow.


A.2.2: USEFUL TELNET SITES

	For those who have a NIFTY-Serve account, there is now a very
convenient way to access NIFTY-Serve using telnet. The URL is as
follows:

  telnet://r2.niftyserve.or.jp/

Information about what NIFTY-Serve has to offer (and how to subscribe)
can be found at the following URL:

  http://www.nifty.co.jp/

	Another information service with a similar access mechanism is
CompuServe, whose URL is as follows:

  telnet://compuserve.com/

You will need to press the return key to get the "Host Name:" prompt,
at which time you type "cis" (just follow the menus from this point
on).
	You can also do a search on fj.* newsgroup articles at the
following URL:

  telnet://asahi-net.or.jp/

You login as "fj-db" once you are connected.


A.2.3: USEFUL GOPHER SITES

	I am not too much of a Gopher user. There, of course, is the
following:

  gopher://gopher.ora.com/

Another Gopher site provides information on Japanese-related mailing
lists:

  gopher://gan1.ncc.go.jp/11/INFO/mail-lists/

If you happen to know of others, please let me know.


A.2.4: USEFUL WWW SITES

	Because the World-Wide Web is a constantly changing place (and
more importantly, because I don't want to re-issue a new version of
this document every month!), I will maintain links to useful documents
at my WWW Home Page. Its URL is as follows:

  http://jasper.ora.com/lunde/

If you cannot get to my WWW Home Page, you couldn't get to any that I
would list here anyway.


A.2.5: USEFUL MAIL SERVERS

	In the past (that is, in JAPAN.INF) I included a full list of
the domains in the "jp" hierarchy. That took up a lot of space, and
changes very rapidly. You can now send a request to a mail server in
order to return the most current listing. The mail server is:

  mail-server@nic.ad.jp

The most common command is "send," and the following arguments can be
supplied to retrieve specific documents (and should be in the message
body, not on the "Subject:" line):

  send help
  send index
  send jpnic/domain-list.txt
  send jpnic/domain-list-e.txt

The first sends back a help file, the second sends back a complete
index of files that can be retrieved (use this one to see what other
useful stuff is available), and the last two send back a complete
listing of domains in the "fj" hierarchy (the last one send it back in
English/romanized).


A.3: OTHER RESOURCES

	This section provides pointers to specific documentation
available electronically or in print.


A.3.1: BOOKS

	There are other useful reference materials available in print
or online, in addition to the various national and international
standards mentioned throughout this document. The following are books
that I recommend for further reading or mental stimulus. (Sorry for
plugging my own books in this list, but they are relevant.)

o Clews, John. "Language Automation Worldwide: The Development of
  Character Set Standards." SESAME Computer Projects. 1988. ISBN
  1-870095-01-4.

o Flanagan, David. "Java in a Nutshell." O'Reilly & Associates,
  Inc. 1996. ISBN 1-56592-183-6.

o Frisch, AEleen. "Essential System Administration." Second Edition.
  O'Reilly & Associates, Inc. 1995. ISBN 1-56592-127-5.

o Huang, Jack & Timothy Huang. "An Introduction to Chinese, Japanese
  and Korean Computing." World Scientific Computing. 1989. ISBN
  9971-50-664-5.

o IBM Corporation. "Character Data Representation Architecture - Level
  2, Registry." 1993. IBM order number SC09-1391-01.

o Kano, Nadine. "Developing International Software for Windows 95 and
  Windows NT." Microsoft Press. 1995. ISBN 1-55615-840-8.

o Kirch, Olaf. "Linux Network Administrator's Guide." O'Reilly &
  Associates, Inc. 1995. ISBN 1-56592-087-2.

o Kissell, Joe. "The Nisus Way." MIS:Press. 1996. ISBN 1-55828-455-9.

o Krol, Ed. "The Whole Internet User's Guide & Catalog." Second
  Edition. O'Reilly & Associates, Inc. 1994. ISBN 1-56592-063-5.

o Liu, Cricket et al. "Managing Internet Information Services."
  O'Reilly & Associates, Inc. 1994. ISBN 1-56592-062-7.

o Lunde, Ken. "Understanding Japanese Information Processing."
  O'Reilly & Associates, Incorporated. 1993. ISBN 1-56592-043-0. LCCN
  PL524.5.L86 1993.

o Lunde, Ken. "Nihongo Joho Shori." SOFTBANK Corporation. 1995. ISBN
  4-89052-708-7.

o Luong, Tuoc V. et al. "Internationalization: Developing Software for
  Global Markets." John Wiley & Sons, Incorporated. 1995. ISBN
  0-471-07661-9.

o Schwartz, Randal L. "Learning Perl." O'Reilly & Associates,
  Incorporated. 1993. ISBN 1-56592-042-2.

o Stallman, Richard M. "GNU Emacs Manual." Tenth edition. Free
  Software Foundation. 1994. ISBN 1-882114-04-3.

o Tuthill, Bill. "Solaris International Developer's Guide." SunSoft
  Press and PTR Prentice Hall. 1993. ISBN 0-13-031063-8.

o Unicode Consortium, The. "The Unicode Standard: Worldwide Character
  Encoding." Version 1.0. Volume 2. Addison-Wesley. 1992. ISBN
  0-201-60845-6.

o Vromans, Johan. "Perl 5 Desktop Reference." O'Reilly & Associates,
  Inc. 1996. ISBN 1-56592-187-9.

o Wall, Larry & Randal L. Schwartz. "Programming Perl." O'Reilly &
  Associates, Incorporated. 1991. ISBN 0-937175-64-1.

o Welsh, Matt & Lar Kaufman. "Running Linux." O'Reilly & Associates,
  Inc. 1995. ISBN 1-56592-100-3.

	If you want to get your hands on any of the national or
international standards mentioned in this document, I suggest the
following:

o The American National Standards Institute can provide ISO, KS, and
  JIS standards. Bear in mind that ISO standards will most likely
  arrive as a photocopy of the original.

  ANSI
  11 West 42nd Street
  New York, NY 10036
  USA
  +1-212-642-4900 (phone)
  +1-212-302-1286 (facsimile)

o The International Organization for Standardization can provide
  ISO standards.

  ISO
  1, rue de Varemb
  Case postale 56
  CH-1211, Geneva 20
  SWITZERLAND
  +41-22-749-01-11 (phone)
  +41-22-733-34-30 (facsimile)
  central@isocs.iso.ch (e-mail)
  http://www.iso.ch/ (WWW)

o Chinese (GB and CNS) standards are the hardest to obtain. It is
  quite unfortunate.


A.3.2: MAGAZINES

o "Computing Japan," published monthly, ISSN 1340-7228,
  editors@cj.gol.com.

o "MANGAJIN," published 10 times per year, ISSN 1051-8177.

o "Multilingual Communications & Computing," published bi-monthly,
  ISSN 1065-7657, info@multilingual.com.

o "The Perl Journal," published quarterly, ISSN 1087-903X,
  perl-journal-subscriptions@perl.com.


A.3.3: JOURNALS

o "Chinese Information Processing" (CIP), published bi-monthly, ISSN
  1003-9082. (In Chinese.)

o "Computer Processing of Chinese & Oriental Languages" (CPCOL),
  co-published twice a year by World Scientific Publishing and Chinese
  Language Computer Society (CLCS), ISSN 0715-9048.

o "The Electronic Bodhidharma," published by the International
  Research Institute for Zen (IRIZ) Buddhism, Hanazono University,
  Japan. More information on the organization that publishes this
  journal is available at the following URL:

  http://www.iijnet.or.jp/iriz/irizhtml/irizhome.htm


A.3.4: RFCs

	Many RFCs (Request For Comments) are relevant to this
document. They are:

o RFC 1341: "MIME (Multipurpose Internet Mail Extensions): Mechanisms
  for Specifying and Describing the Format of Internet Message
  Bodies," by Nathaniel Borenstein and Ned Freed, June 1992.

o RFC 1342: "Representation of Non-ASCII Text in Internet Message
  Headers," by Keith Moore, June 1992.

o RFC 1468: "Japanese Character Encoding for Internet Messages," by
  Jun Murai et al., June 1993.

o RFC 1521: "MIME (Multipurpose Internet Mail Extensions) Part One:
  Mechanisms for Specifying and Describing the Format of Internet
  Message Bodies," by Nathaniel Borenstein and Ned Freed, September
  1993. Obsoletes RFC 1341.

o RFC 1522: "MIME (Multipurpose Internet Mail Extensions) Part Two:
  Message Header Extensions for Non-ASCII Text," by Keith Moore,
  September 1993. Obsoletes RFC 1342.

o RFC 1554: "ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP," by
  Masataka Ohta and Kenichi Handa, December 1993.

o RFC 1557: "Korean Character Encoding for Internet Messages," by
  Uhhyung Choi et al., December 1993.

o RFC 1642: "UTF-7: A Mail-Safe Transformation Format of Unicode," by
  David Goldsmith and Mark Davis, July 1994.

o RFC 1815: "Character Sets ISO-10646 and ISO-10646-J-1," by Masataka
  Ohta, July 1995.

o RFC 1842: "ASCII Printable Characters-Based Chinese Character
  Encoding for Internet Messages," by Ya-Gui Wei et al., August 1995.

o RFC 1843: "HZ - A Data Format for Exchanging Files of Arbitrarily
  Mixed Chinese and ASCII Characters," by Fung Fung Lee, August 1995.

o RFC 1922: "Chinese Character Encoding for Internet Messages," by
  Haifeng Zhu et al., March 1996.

These RFCs can be obtained from FTP archives that contain all RFC
documents, such as at the following URLs

  ftp://nic.ddn.mil/rfc/
  ftp://ftp.uu.net/inet/rfc/

But these specific ones are mirrored at the following URL for
convenience:

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/Ch9/


A.3.5: FAQs

	There are several FAQ (Frequently Asked Questions) files that
provide useful information. The following is a listing of some along
with their URLs:

o "Japanese Language Information" FAQ (formerly the "sci.lang.japan"
  FAQ) by Rafael Santos (santos@mickey.ai.kyutech.ac.jp) at:

  http://www.mickey.ai.kyutech.ac.jp/cgi-bin/japanese/

  Update announcements are usually posted to the sci.lang.japan
  newsgroup.

o "Programming for Internationalization" FAQ by Michael Gschwind
  (mike@vlsivie.tuwien.ac.at) at:

  ftp://ftp.vlsivie.tuwien.ac.at/pub/8bit/ISO-programming

  Also posted to the comp.software.international newsgroup. This and
  other internationalization documents are also accessible through the
  following URL:

  http://www.vlsivie.tuwien.ac.at/mike/i18n.html

o Three FAQs about Internet Service Providers in Japan by Taki Naruto
  (tn@panix.com), Jesse Casman (jcasman@unm.edu), and Kenji Yoshida
  (kenny@mb.tokyo.infoweb.or.jp), respectively, at:

  http://www.panix.com/~tn/ispj.html
  http://nobunaga.unm.edu/internet.html
  http://cswww2.essex.ac.uk/users/whean/japan/net.html

o "Internationalization Reference List" by Eugene Dorr
  (gdorr@pgh.legent.com) at:

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/doc/i18n-books.txt

  Note really a FAQ, but quite useful because it is a very complete
  listing of I18N-related books.

o "INSOFT-L Service" by Brian Tatro (btatro@tatro.com) at:

  http://iquest.com/~btatro/in2.html

  This includes a link to the FAQ for the INSOFT-L Mailing List (see
  Section A.1.2).

o "How to Use Japanese on the Internet with a PC: From Login to WWW"
  by Hideki Hirayama (sgw01623@niftyserve.or.jp) at:

  ftp://ftp.ora.com/pub/examples/nutshell/ujip/faq/jpn-inet.FAQ

o "Hangul and Internet in Korea" FAQ by Jungshik Shin
  (jshin@minerva.cis.yale.edu) at:

  http://pantheon.cis.yale.edu/~jshin/faq/
---  END (CJK.INF VERSION 2.1 07/12/96) 185553 BYTES  ---