UIL 中文man页面

NAME

Unicode - 16 位统一超级字符集  

描述 (DESCRIPTION)

国际标准 ISO 10646 定义了 通用字符集 (Universal Character Set, UCS). UCS 包含所有别的字符集标准里的字符,并且保证了 互换兼容性 (round-trip compatibility), 也就是说，当一个字符串在 UCS 和任何别的字符集之间转换时, 转换表可以保证不会有信息丢失现象发生．

UCS 包含了表示几乎所有已知的语言所必需的字符．该字符集既包括那些使用扩展拉丁语的语言,也包括下面的这些语言: Greek, Cyrillic, Hebrew,Arabic, Armenian, Gregorian, Japanese, Chinese, Hiragana, Katakana, Korean, Hangul, Devangari, Bengali, Gurmukhi, Gujarati, Oriya, Tamil, Telugu, Kannada, alayam, Thai, Lao, Bopomofo,等等.而另外的语言,例如 Tibetian, Khmer, Runic, Ethiopian, Hieroglyphics, 各种 Indo-European 语言, 还有许多其他的语言, 正在被加入其中.1993 年发布该标准的时候, 还不清楚怎样才能对后面加入的这些语言中的大部分作更好的编码. 另外, 这些语言所需的字符, 以及由 TeX, PostScript, MS-DOS, Macintosh, Videotext, OCR, 还有很多字处理系统所提供的大量的图形, 印刷体, 数学和科学符号, 都已被包括进来, 还包括了一些特别编码以保证和所有其它已存在字符集标准的可逆转换兼容性.

UCS 标准 (ISO 10646) 描述了一个 31 位字符集的体系, 不过, 目前只使用了前面 65534 个编码位置 (0x0000-0xfffd, 它们被称为 基本多语言块 (Basic Multilingual Plane,BMP)), 分配给了字符, 而且我们估计只有那些很古怪的字符(比如． Hieroglyphics)为了专门的科学目的, 才会在将来的某个时候, 需要 16 位的 BMP 之外的部分.

从 0x0000 到 0x007f 之间的 UCS 字符和经典 US-ASCII 字符集是一样的, 而从 0x0000 到 0x00ff 之间的字符等于 ISO 8859-1 Latin-1 字符集．  

组合字符 (COMBINING CHARACTERS)

一些 UCS 编码被分配给了 组合字符(combining characters). 这样的情形有点类似于打字机上的重音键. 一个组合字符只是给前面的字符添加一个重音. 在 UCS 里最重要的重音字符都有他们自己的编码, 不过, 组合字符机制允许给任一字符添加重音和其他的可识别记号. 组合字符总是跟在那些他们所修饰的字符后面. 例如,德语符号 Umlaut-A (带分音符的大写拉丁字母 A)既可以表示为 UCS 编码 0x00c4, 也可以用一个正常的"大写拉丁字母 A"后面跟一个"组合分音符号": 0x0041 0x0308 来表示．  

实现级别 (IMPLEMENTATION LEVELS)

由于不是所有系统都支持象组合字符这样的高级机制, ISO 10646 指明了 UCS 的三种实现级别:

级别 1 (Level 1)

不支持组合字符和 Hangul Jamo 字符(朝鲜语的一种更复杂的专用的编码, Hangul 音节编码成两或三个亚字符).

级别 2 (Level 2)

类似于级别1, 却在一些语言里面也支持一些组合字符. (比如． Hebrew, Arabic, Devangari, Bengali, Gurmukhi, Gujarati, Oriya, Tamil, Telugo, Kannada, Malayalam, Thai 和 Lao).

级别 3 (Level 3)

支持所有 UCS 字符.

Unicode 协会发布的 Unicode 1.1 标准和 ISO 10646 所描述的那样, 在第 3 执行级别只包括了 UCS (基本多语言块 Basic Multilingual Plane). Unicode 1.1 还为一些 ISO 10646 的字符定义加入了一些语义定义.  

LINUX 下的 UNICODE (UNICODE UNDER LINUX)

在 Linux 下, 为了降低组合字符的实现复杂性, 目前只包括了执行级别 1 下的 BMP. 更高的执行级别更适合于专门的字处理格式, 而不是一个普通的系统字符集. 在 linux 下 C 的类型 wchar_t 是一个有符号位的 32 位整型并且其值解释为 UCS4 编码．

本地化设置指明系统字符编码是使用诸如 UTF-8 还是 ISO 8859-1这样的编码． 象库函数 wctomb, mbtowc, 或者 wprintf 就可以用于内部 wchar_t 字符及字符串与系统字符编码之间做转换.  

私有区 (PRIVATE AREA)

在 BMP 里, 0xe000 到 0xf8ff 的范围被标准保留做私用因而永远不会被分配给任何字符. 对于 Linux 社区, 该私有区被再细分为可以被任何终端用户独立使用的 0xe000 到 0xefff 的范围, 以及从 0xf000 到 0xf8ff 给所有 linux 用户所共用的 linux 区.H. Peter Anvin(<Peter.Anvin@linux.org>, Yggdrasil Computing,Inc) 现在维护登记分配到 linux 区的字符. 该区包括一些 Unicode 中缺少的 DEC VT100 的图形字符, 这使控制台的字体缓冲区可以直接获得这些字符, 该区还包括一些象 Klingon 这样的古老语言所使用的字符.  

文献 (LITERATURE)

*

Information technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane. International Standard ISO 10646-1, International Organization for Standardization, Geneva, 1993.

这是 UCS 的正式规范, 非常正式, 也很厚, 还非常贵. 如果要定购信息, 去看看 www.iso.ch.

*

The Unicode Standard - Worldwide Character Encoding Version 1.0. The Unicode Consortium, Addison-Wesley, Reading, MA, 1991.

Unicode 已经有 1.1.4 版可用,与 1.0 版的差别可以在 ftp.unicode.org 找到. Unicode 2.0 也将在 1996 年出版一本书.

*

S. Harbison, G. Steele. C - A Reference Manual. Fourth edition, Prentice Hall, Englewood Cliffs, 1995, ISBN 0-13-326224-3.

一本很好的 C 语言编程参考书. 现在的第四版包含了 1994 年对标准 ISO C 的***次修正 (ISO/IEC 9899:1990), 添加了大量处理多种字符集的新的 C 库函数.

缺憾 (BUGS)

在写这个手册页的时候,linux 对 UCS 的 C 语言库支持远未完成.  

作者 (AUTHOR)

Markus Kuhn <mskuhn@cip.informatik.uni-erlangen.de>  

又见(SEE ALSO)

utf-8(7)， http://www.linuxforum.net/books/UTF-8-Unicode.html

#p#

NAME

Unicode - the Universal Character Set  

DESCRIPTION

The international standard ISO 10646 defines the Universal Character Set (UCS). UCS contains all characters of all other character set standards. It also guarantees round-trip compatibility, i.e., conversion tables can be built such that no information is lost when a string is converted from any other encoding to UCS and back.

UCS contains the characters required to represent practically all known languages. This includes not only the Latin, Greek, Cyrillic, Hebrew, Arabic, Armenian, and Georgian scripts, but also also Chinese, Japanese and Korean Han ideographs as well as scripts such as Hiragana, Katakana, Hangul, Devanagari, Bengali, Gurmukhi, Gujarati, Oriya, Tamil, Telugu, Kannada, Malayalam, Thai, Lao, Khmer, Bopomofo, Tibetan, Runic, Ethiopic, Canadian Syllabics, Cherokee, Mongolian, Ogham, Myanmar, Sinhala, Thaana, Yi, and others. For scripts not yet covered, research on how to best encode them for computer usage is still going on and they will be added eventually. This might eventually include not only Hieroglyphs and various historic Indo-European languages, but even some selected artistic scripts such as Tengwar, Cirth, and Klingon. UCS also covers a large number of graphical, typographical, mathematical and scientific symbols, including those provided by TeX, Postscript, APL, MS-DOS, MS-Windows, Macintosh, OCR fonts, as well as many word processing and publishing systems, and more are being added.

The UCS standard (ISO 10646) describes a 31-bit character set architecture consisting of 128 24-bit groups, each divided into 256 16-bit planes made up of 256 8-bit rows with 256 column positions, one for each character. Part 1 of the standard (ISO 10646-1) defines the first 65534 code positions (0x0000 to 0xfffd), which form the Basic Multilingual Plane (BMP), that is plane 0 in group 0. Part 2 of the standard (ISO 10646-2) adds characters to group 0 outside the BMP in several supplementary planes in the range 0x10000 to 0x10ffff. There are no plans to add characters beyond 0x10ffff to the standard, therefore of the entire code space, only a small fraction of group 0 will ever be actually used in the foreseeable future. The BMP contains all characters found in the commonly used other character sets. The supplemental planes added by ISO 10646-2 cover only more exotic characters for special scientific, dictionary printing, publishing industry, higher-level protocol and enthusiast needs.

The representation of each UCS character as a 2-byte word is referred to as the UCS-2 form (only for BMP characters), whereas UCS-4 is the representation of each character by a 4-byte word. In addition, there exist two encoding forms UTF-8 for backwards compatibility with ASCII processing software and UTF-16 for the backwards compatible handling of non-BMP characters up to 0x10ffff by UCS-2 software.

The UCS characters 0x0000 to 0x007f are identical to those of the classic US-ASCII character set and the characters in the range 0x0000 to 0x00ff are identical to those in ISO 8859-1 Latin-1.  

COMBINING CHARACTERS

Some code points in UCS have been assigned to combining characters. These are similar to the non-spacing accent keys on a typewriter. A combining character just adds an accent to the previous character. The most important accented characters have codes of their own in UCS, however, the combining character mechanism allows us to add accents and other diacritical marks to any character. The combining characters always follow the character which they modify. For example, the German character Umlaut-A ("Latin capital letter A with diaeresis") can either be represented by the precomposed UCS code 0x00c4, or alternatively as the combination of a normal "Latin capital letter A" followed by a "combining diaeresis": 0x0041 0x0308.

Combining characters are essential for instance for encoding the Thai script or for mathematical typesetting and users of the International Phonetic Alphabet.  

IMPLEMENTATION LEVELS

As not all systems are expected to support advanced mechanisms like combining characters, ISO 10646-1 specifies the following three implementation levels of UCS:

Level 1

Combining characters and Hangul Jamo (a variant encoding of the Korean script, where a Hangul syllable glyph is coded as a triplet or pair of vovel/consonant codes) are not supported.

Level 2

In addition to level 1, combining characters are now allowed for some languages where they are essential (e.g., Thai, Lao, Hebrew, Arabic, Devanagari, Malayalam, etc.).

Level 3

All UCS characters are supported.

The Unicode 3.0 Standard published by the Unicode Consortium contains exactly the UCS Basic Multilingual Plane at implementation level 3, as described in ISO 10646-1:2000. Unicode 3.1 added the supplemental planes of ISO 10646-2. The Unicode standard and technical reports published by the Unicode Consortium provide much additional information on the semantics and recommended usages of various characters. They provide guidelines and algorithms for editing, sorting, comparing, normalizing, converting and displaying Unicode strings.  

UNICODE UNDER LINUX

Under GNU/Linux, the C type wchar_t is a signed 32-bit integer type. Its values are always interpreted by the C library as UCS code values (in all locales), a convention that is signaled by the GNU C library to applications by defining the constant __STDC_ISO_10646__ as specified in the ISO C 99 standard.

UCS/Unicode can be used just like ASCII in input/output streams, terminal communication, plaintext files, filenames, and environment variables in the ASCII compatible UTF-8 multi-byte encoding. To signal the use of UTF-8 as the character encoding to all applications, a suitable locale has to be selected via environment variables (e.g., "LANG=en_GB.UTF-8").

The nl_langinfo(CODESET) function returns the name of the selected encoding. Library functions such as wctomb(3) and mbsrtowcs(3) can be used to transform the internal wchar_t characters and strings into the system character encoding and back and wcwidth(3) tells, how many positions (0-2) the cursor is advanced by the output of a character.

Under Linux, in general only the BMP at implementation level 1 should be used at the moment. Up to two combining characters per base character for certain scripts (in particular Thai) are also supported by some UTF-8 terminal emulators and ISO 10646 fonts (level 2), but in general precomposed characters should be preferred where available (Unicode calls this Normalization Form C).  

PRIVATE AREA

In the BMP, the range 0xe000 to 0xf8ff will never be assigned to any characters by the standard and is reserved for private usage. For the Linux community, this private area has been subdivided further into the range 0xe000 to 0xefff which can be used individually by any end-user and the Linux zone in the range 0xf000 to 0xf8ff where extensions are coordinated among all Linux users. The registry of the characters assigned to the Linux zone is currently maintained by H. Peter Anvin <Peter.Anvin@linux.org>.  

LITERATURE

*

Information technology --- Universal Multiple-Octet Coded Character Set (UCS) --- Part 1: Architecture and Basic Multilingual Plane. International Standard ISO/IEC 10646-1, International Organization for Standardization, Geneva, 2000.

This is the official specification of UCS. Available as a PDF file on CD-ROM from http://www.iso.ch/.

*

The Unicode Standard, Version 3.0. The Unicode Consortium, Addison-Wesley, Reading, MA, 2000, ISBN 0-201-61633-5.

*

S. Harbison, G. Steele. C: A Reference Manual. Fourth edition, Prentice Hall, Englewood Cliffs, 1995, ISBN 0-13-326224-3.

A good reference book about the C programming language. The fourth edition covers the 1994 Amendment 1 to the ISO C 90 standard, which adds a large number of new C library functions for handling wide and multi-byte character encodings, but it does not yet cover ISO C 99, which improved wide and multi-byte character support even further.

*

Unicode Technical Reports.

http://www.unicode.org/unicode/reports/

*

Markus Kuhn: UTF-8 and Unicode FAQ for Unix/Linux.

http://www.cl.cam.ac.uk/~mgk25/unicode.html

Provides subscription information for the linux-utf8 mailing list, which is the best place to look for advice on using Unicode under Linux.

*

Bruno Haible: Unicode HOWTO.

ftp://ftp.ilog.fr/pub/Users/haible/utf8/Unicode-HOWTO.html

BUGS

When this man page was last revised, the GNU C Library support for UTF-8 locales was mature and XFree86 support was in an advanced state, but work on making applications (most notably editors) suitable for use in UTF-8 locales was still fully in progress. Current general UCS support under Linux usually provides for CJK double-width characters and sometimes even simple overstriking combining characters, but usually does not include support for scripts with right-to-left writing direction or ligature substitution requirements such as Hebrew, Arabic, or the Indic scripts. These scripts are currently only supported in certain GUI applications (HTML viewers, word processors) with sophisticated text rendering engines.  

AUTHOR

Markus Kuhn <mgk25@cl.cam.ac.uk>  

SEE ALSO

utf-8(7), charsets(7), setlocale(3)