summaryrefslogtreecommitdiffstats
path: root/tools/encoding/cjk.inf
diff options
context:
space:
mode:
authorstanton <stanton>1999-04-16 00:46:29 (GMT)
committerstanton <stanton>1999-04-16 00:46:29 (GMT)
commit97464e6cba8eb0008cf2727c15718671992b913f (patch)
treece9959f2747257d98d52ec8d18bf3b0de99b9535 /tools/encoding/cjk.inf
parenta8c96ddb94d1483a9de5e340b740cb74ef6cafa7 (diff)
downloadtcl-97464e6cba8eb0008cf2727c15718671992b913f.zip
tcl-97464e6cba8eb0008cf2727c15718671992b913f.tar.gz
tcl-97464e6cba8eb0008cf2727c15718671992b913f.tar.bz2
merged tcl 8.1 branch back into the main trunk
Diffstat (limited to 'tools/encoding/cjk.inf')
-rw-r--r--tools/encoding/cjk.inf4467
1 files changed, 4467 insertions, 0 deletions
diff --git a/tools/encoding/cjk.inf b/tools/encoding/cjk.inf
new file mode 100644
index 0000000..9fbe527
--- /dev/null
+++ b/tools/encoding/cjk.inf
@@ -0,0 +1,4467 @@
+--- 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 ---