Unicode字符编码标准
-
Unicode
字符编码标准
1.
编码知识
1.1
文本和字符
在计算机程序中或者数据文件里,文本(
text
)是作为数字序列存储的。序列中的数字是具有不同大小、取值和解释的<
/p>
整数。如何解释这些整数是由字符集(
character se
t
)
、编码(
encoding
)决定的。
文本
主要是由字符(
character
)组成。在格式文本
(
fancy text, or rich text
)中包括显示属性,如颜色、斜体字、
上标等,
但仍
然是以字符组成的纯文本
(
plain text
)
为基础的。
有时,
格式文
本与纯文本之间的区别很复杂,
依赖于具体的应用。
什么是字符?典型地,是字母。也可以是数字、句点、连字号
、标点符号和数学符号,对于中文,也可以是汉字。还
包括定义行尾和段落等的控制字符
(一般不可见)
。
有了字符,就可以为它们分配数字编码。为字符分配什么数字值,依赖于具体情况。一个简单的字符,如
字母
,在
不同的程序或者数据文件中可
能具有不同的整数值。
1.2
字符集:具有数字编码的字符
p>
在信息处理中,所使用的整数总有上限,依赖于存储整数的位的数目。这也决定了可以同时区
分的字符的数量。
在设计字符集时
,首先要决定所需字符的数目,并确定所需字符的清单。根据字符的数目,可以设定整数值的上限,
这个整数范围称为编码空间(
code space
)
,其中的一个特定整数称为一个码点(
code
point
)
。
然后,为字符清单中的每个字符指定一个整数值,也就是一个
码点。这样就得到一个字符集,称作编码字符集(
Coded
Character
Set
)
。
1.3
编码单元、字节和编码
在计算机系统的实现中,整数以特定大小的单元表示,通常为
8
位(
1
字节
)
,
16
位,或
32
位。在字符编码中,这样
的单元称为编码单元(
code unit
)
。根据编码空间的大小和
具体要求,来选择合适的编码单元。通常,所选择编码单元
对应的整数范围要大于编码空
间的整数范围,这样每个码点就只需一个编码单元表示,并且在字符码点与编码单元间
的
转换非常简便,因为字符码点对应的整数值与相应编码单元的整数值相同。如果编码单元对应的整数范围小于编码
空间的整数范围,就需要多个编码单元表示一个码点。
字节是计算机系统中最基本的表示单元,无论是存储在内存中
,还是将文本写入文件或通过网络发送,总是要读写若
干字节。因此,在实际应用中,还
需要将编码单元进一步表示为字节序列。
< br>将字符表示为字节序列的过程就称为编码(
encoding
)
,更重要的是,还包括如何对字节序列进行解释以取得字符。
1.4
不同的字符集
在一些常用的编码中,每个字符只使用一个字节表示,称单字节字符集(
singl
e-byte character set, SBCS
)
。
这些字符集
都仅限于
256
个字符。<
/p>
在
ASCI
I
之后,目前应用最广泛的单字节字符集是
ISO-8859-
1
。它是
ASCII
的一个
8
位超集,并且提供西欧语言所需
的大多数字符。
它的一个改进的版本,
ISO-8859-15
,还包括新的欧
元符号和更多的一些法语和芬兰语字母。
双字节字符集(
double-byte character
set, DBCS
)用于为东亚书写系统中所使用成千上万个表意字符提供足够空间。
这里的编码仍是基于字节的,不过是两个字节一起表示一个单一的字符。
即使在东亚,文
本中也会包含小字母表中的字母,如拉丁字母表。这些字母使用单字节表示的效率会更高。因此,
提出了多字节字符集(
multi-byte character set,
MBDC
)
,使用可变数目的字节来表示字符。多字节字符集通
常与
ASCII
兼容,也就是说,在这种编码中,拉丁字母使用
与
ASCII
中相同的字节来表示。一些不常用的字符可能会使
用三个甚
至四个字节编码。
1.4
常见字符集
1.4.1 ASCII: The American
Standard Code form Information Interchange
ASCII
是一个使用
7
位单元的字符集,及针对
7
位字节的简单编码方式。尽管局限于很少的一些字符,
ASCII
是最
重要的一种字符集,因为它是目前大多数字符
集的基础。
ASCII
只提供了
128
个数字值(也可称作码点,
code point
)
,其中
33
个被保留用作特殊功能。只有
95
个码点用作
真正的
文本字符。这些图形字符大多时大写和小写拉丁字母,数字和标
点符号,外加一些特殊的括号、下划线和重音
符号。
1.4.2 EBCDIC: The Extended
Binary-Coded Decimal Interchange Code
EBCDIC
是由
IBM
设计的编码格式,使用
8
位字节,被一些字符集用于
大型机。
EBCDIC
在与
ASCII
相近的时期开发
的,具有一些相似的特性。
1.4.3 Unicode
Unicode
标准定义了一个字符
集和几种编码。
Unicode<
/p>
最有吸引力的特点是它涵盖了几乎世界上的所有字符,可以只通过一个唯一的数字(
Unicode
码点)来访问和
操作字符。<
/p>
2.
Unicode
介绍
2.1
为什么使用
Unicode?
在创造
Unicode
之前,有数百种编码系统。但是,没有任何一个编码可以包含足够的字符。例如,仅欧州共同体就需<
/p>
要好几种不同的编码来包括所有的语言。即使是单一的一种语言,如英语,也没有哪一个编
码可以适用于所有的字母,
标点符号,和常用的技术符号。
这些编码系统也会互相冲突。也就是说,两种编码可能使用相
同的数字代表两个不同的字符,或使用不同的数字代表
相同的字符。
任何一台特定的计算机
(
特别是服务器
)
都需要支持许多不同的编码,
但是,
不论什么时候数据通过不同的
编码或平台之间,那些数据总会有损坏的危险。
而
Unicod
e
正在改变所有这一切!
在
Unicode
标准中,提供了
1,114,112
个码点,不仅可以包含当今世界使用的所有语言文字和其
他符号,也足够容纳绝
大多数具有历史意义的古文字和符号。并且,
Unicode
给每个字符提供了一个唯一的数字,不论是什么平台,不论是什
p>
么程序,不论什么语言。
Unicode
标准已经被工业界的领导们所采用,例如:
Apple,
HP
,
IBM,
JustSystem,
Microsoft,
Oracle,
SAP
,
Sun,
Sybase,
Unis
ys
等等。
最新的标准都需要
Unic
ode
,
例如
XML, Java,
ECMAScript , LDAP
, CORBA
3.0, WML
等等,
并且,
Uni
code
是实现
ISO/IEC 10646
< br>的正规方式。许多操作系统,所有最新的浏览器和许多其他产品都支持它。
Uni
code
标准的出现
和支持它工具的存在,是近来全球软件技术
最重要的发展趋势。
2.2
Unicode
与国际化
直到最近,国际化的常用方法是,假定任何给定的可执行程序同时只和一种语言工作。如果在英文
环境下安装,它就
只处理英文文本;如果在中文环境下安装,就只处理中文文本。
在这种模型下,针对不同的书写系统和语
言,使用的字符集和字符编码不同。
在
Windows
和大型机环境下,术语
代码
页
Page)
用于描述如何将二进
制值映射到人类可读得字符(字形)
。一个运行的程序处在单一的代码页,该代码
页确定二进制值如和与字形关联。
简便的国际化是
Unicode
的另一项优势
。
在内部使用
Unicode
的应用程
序,
能够同时存储和处理世界上所有的字符,
这
消除了传统的国际化方法所面临的一些困难。
p>
当然,
成功的国际化不仅仅是在应用程序中采用
Unicode
,
还需要谨慎的屏幕布局设计
(不同的语言具有不同的书写习
惯)
、翻译和文化理
解。
2.3
设计原则
Unicode
的设计反映了十大基本原则,
但这些原则并不是
可以同时满足。
整个设计是在保证简便高效和保持与已有编码
标
准兼容之间的平衡。
(
1
)广泛性(
Universality
)
Unicode
标准对一个单一的大字符集进行编码,包括满足世界范围需求的所有字符。
(
2
< br>)高效(
Efficiency
)
在
Unicode
的字符编码模型中没有换码符
(escape
ch
aracter)
,每个字符编码与其它字符编码具有相同的状态。使高效率
的实现成为可能。
所
有
Unicode
编码方式都是自同步的,并且相互不重叠。使
在字符流中随机访问和查找操作高效。
同一书写字母体系中的字符被放置在一起,不仅方便字符的查找,并且使实现更紧凑压缩方法更高效。
(
3
)针对字符编码,而不是字形(
Character, Not
Glyph
)
字符是书写语言中具有语义的最小组件的抽象表示。字符是以驻留在内存中的码点表示。
字形是字符被显示时具有的形状。与字符相比,字形出
现在屏幕或纸张上作为一个或多个字符的特定表示。字形的集
合构成一种字体。
字符和字形间存在多种关系:一个字形可以
对应一个字符;一个字形也可以对应几个字符;多个字形也可能出自一个
字符。
(
4
)语义(
Semantic
)
在
Unicode
中,字符都有明确定义的语义。字符属性表可用于解析、排序等需要有关码点语义知识的算法中。
p>
Unicode
中定义的属性包括数字、间隔、组合和方向属性。<
/p>
(
5
)纯文本(
Plain
Text
)
纯文本或无格式文本,
仅仅是字符编码的序列。
纯
Unicode
文本就是
Unicode
编码的序列。
而格式文本
(
styled text, or rich
text
)
是由纯文本添加一些附加信息(如语言标识、字体大小、颜色等)组成的文本表示。
Unicode
标准针对的是纯文本。
(
6
)逻辑
顺序(
Logical Order
)
Unicode
文本在内存表示中以
逻辑顺序存储,
大致对应于借助键盘输入文本的顺序。
在一些情
况下,
当显示或打印文本
时,字符顺序与逻辑顺序不同。
(
7
)统一(
Unification
)
Unicode
标准为
避免对字符重复编码,
对不同语言书写方式中的字符进行统一,
相同的字符分配唯一的一个编码。
普通
字母、标点符号、标记,
和变音符都只分配一个编码,而不管语言;同样的还有中日韩使用的表意字符。
(
8
)动态
组合(
Dynamic
Composition
)
Unicode
标准允许加重音符好的形式和
Hangul
音节的动态组合。
<
/p>
(
9
)等价序列(
Equivalent Sequences
)
一些文本元素即可以使用静态的预先组合好的形式,
也可使用动态组合的形式。
Unicode
字符
的不同表示序列被认为是
等价的。
如果两个或多个序列被认为是等价的,
Unicode
标准不规定哪一种特定的序列是正确的,
而认为每一个序列只不过与其<
/p>
它序列等价。
如果需要一种单一的单一的表示方式,
可以使用一种规范化的
Unicode
文本形式来减少不想要区别。
Unicode<
/p>
标准定义
了四种规范化形式:
Normalization Form D
(NFD)
,
Normalization Form KD
(NFKD)
,
Normalization Form C
(NFC)
,和
Normalization Form KC
(NFKC)
。大约来说,
NFD
和<
/p>
NFKD
将可能的字符进行分解,而
NF
C
和
NFKC
将可能的字符进
行组合。
(
10
)可转换性(
Convertibili
ty
)
在
Unicode
标准和其他字符集
标准之间可以实现准确的转换。一般说,在其他标准中的一个码点对应于
Unicode
标准
中一个单一的码点。
然而,
有时在其他标准中的一个码点对应于
Unicode
< br>标准中一个码点的序列。
在
Unicode
文本和其
他字符编码文本间的转换一般是通过明确的表映射过程完成的。
p>
2.4
Unicode
的码点、编码格式、编码方案
2.4.1
Unicode
编码空间和码点
<
/p>
在
Unicode
标准中,编码空间的整
数范围是从
0
到
10FFFF
(
16
进制)
,共
p>
1,114,112
个可用的码点。
为了与已有的编码标准兼容,一些抽象字符可能会与多个分别
编码的字符关联。而在其他一些情况下,一个抽象字符
可能会用两个(或更多)编码字符
序列来表示,如带重音符的字母。
2.4.2 Unicode
编码格式
在
Unicode
< br>字符编码模型中,
编码格式
(
e
ncoding form
)
指定如何将每个码点表示为一个或
多个编码单元序列。
Unicode
标准提供了三种不同的编码
格式,使用
8
位、
16
位和
32
位编码单元,分别为
UTF-8
、
UTF-16
、
UTF-32
。
<
/p>
(
1
)
UTF-
32
UTF-32
是一种最简单的
Unicode
编码格式。每个
Uni
code
码点被直接表示为一个
32
位
的编码单元。
UTF-32
是一种固
定
宽度的字符编码格式。
每个
UTF-32
编码单元的值与
Unicode
码点的值完全相同。
(
2
)
UTF-16
在
UTF-16
中,
在范围
U+0000
到
U+FFFF
间的码点使用一个单一的
16<
/p>
位编码单元表示;
而,
在范围
U+10000
到
U+10FFFF
间的码点则使用一对
16
位编码单元表示,称作代理
对
(surrogate
pair)
。
UTF
-16
优化了基本多语言平面
(Basic
Multilingual Plane)
中字符的表示,即位于
U+0000
到
U+FFFF
范围内
的字符。该
范围包含了目前世界上所使用的书写系统中的绝大多数字符,每个字符只需要
一个
16
位的编码单元。对于基本多语言
平面,
UTF-16
可作为固定宽度的编码格式来有效使用。
但对于增补字符,
UTF-16
需要两个
16
位
的编码单元,意味着正式的
UTF-16
是一个变宽的编码格式
。
UTF-16
< br>是早期
Unicode
遗留下的历史产物,原本被设计成
具有固定宽度的
16
位编码格式。为支持超过
< br>U+FFFF
的增
补字符,设立了代理机制。
(
3
)
UTF-8
为满足基于
ASCII
,面向字节的系统的需要,
Unicode
标准中定义了第三种编码格式
UTF-8
。它是一种使用
8
位编码单
< br>元的变宽的编码格式。
在<
/p>
UTF-8
的编码单元种,一些高位用于指示当前字节在编码单元
序列中的那一部分。
8
位编码单元的取值的一部分范
围保留给
UTF-8
的编码单元序列的首字节;<
/p>
另一部分完全奋力的范围保留给序列中的后续字节,
以保证
UTF-8
不重叠。
UTF
-8
编码格式对所有
ASCII
码点具有透明性。在
U+0000
到
U+007F
范围内的
Unicode
码点,被转换为
UTF-8
中单
一的字节
0x00
到
0x7F
,与
ASCII
码没有区别。并且,从
0x00
到
0x7F
不会出现在其他<
/p>
Unicode
码点的
UTF-8
表示中
的任一字节中,保证了不存在歧义。
Unicode
中超出
ASCII
范围的其他一些非表意字母,每个都在
U
TF-8
种使用量各字节表示;位于
U+0800
到
U+FFFF
范围内的非代理码点使用三字节表示
;超出
U+FFFF
的增补码点则需要四字节表示。
UTF-8
是
Internet
中
HTML
和类似协议偏好的编码格式。
UTF-8
同其他的多字节编码方式相比具有以下特点:
a) UTF-8
的编码单元序列的
第一个字节指明了后面所跟的字节的数目。对前向解析非常有效。
b)
从
U
TF-8
字节流的任意位置开始可以有效的找到一个字符的其实位置。
< br>
c)
UTF-8
中不存在字节取值的重叠。
2.4.3
Unicode
编码方案
在
Unicode
标准中,
用于
Unicode
数据字节串行化的各种不同类型的规范
被称为
Unicode
编码方案
(
p>
encoding
scheme
)
。
在计算机系统中,大数值类型(如整型)使用多个字节表示,
不同体系结构采用的字节排列顺序不同。其中,部分采
用由高字节到低字节的排列顺序,
称为
big-endian
;其他则采用由低字节到高字节的排
列顺序,称
little-
endian
。
< br>对于
UTF-16
和
UTF-3
2
,字节串行化规范必须考虑当前表示数据的系统采用的是
bi
g-endian
还是
little-
endian
结构。
一个字符编码方案包括指定的字符编码格式,以及如何将编码单元串行化为字节的规范。在
Unicode
标准中,还规定
了初始的字节顺序
标志(
byte order mark,
BOM
)的使用,用于显示区分
big-
endian
和
little-
endian
数据。
对于
UTF-8
,在序列中只包括
< br>UTF-8
的编码单元(
1
字节
)
,因此,
UTF-8
中的数据表示不
存在字节顺序的问题。但对
于
16
位和
32
位的编码方案,字节串行化过程必须将编码单元分解为两个
或四个字节,并且必须清楚的定义这些字节
的顺序。
因此,
Unicode
标准中定义的三种编码格式,导致总共七种
Unicode
< br>编码方案,分别为:
UTF-8
、
UTF-16
、
UTF-16BE
、
UTF-16LE
、
UTF-32
p>
、
UTF-32BE
、
UTF-32LE
。
必须明确,字符编码格式
(character
encoding form)
指在内存或
API
中的整数数据单元,与字节顺序不相关;字符编码方
案
(character encoding scheme)
指字节串行化的数据,如
I/O
流或者文件,必须制定字节顺序。
2.4.4
Unicode
编码空间分配
p>
根据在语言学上和功能上的类别,
Unicode
< br>标准中的编码字符被分成组。
Unicode
编码空间的范围为
0
到
10FFFF
,可以被划分为字符平
面(
planes
of characters
)
,每个平面包含
64K
各
码点。
因此,最底层的平面为基本多语言平面(
Basic
Multilingual Plane
)
,
< br>包括范围从
0000
到
FFFF
;下一个平面为增补多语
言平面(
Su
pplementary Multilingual Plane
)
< br>,也被称为第一平面(
Plane 1
)
,包括范围
10000
到
1F
FFF
;以及,第二平面
(
Plane
2
)
,增补表意字符平面(
Suppl
ementary Ideographic Plane
)
,
包括范围
20000
到
2FFFF
p>
;等等。基本多语言平面
有时也被称为
Pl
ane 0
。
基本多语言平面(
BMP
, or
Plane 0
)包含目前世界上使用的所有书写系统中的全部常用字符,以及一些历史
上的不常用
字符。
增补多语言平面(
SMP
, or
Plane 1
)用于一些较少使用的历史上的书写系统,针对特殊目的创建的书写系统
,和特殊的
标记系统,它们要么无法放入基本多语言平面中,要么特别不常用。
增补表意字符平面(
SIP
, or
Plane 2
)用于无法放入基本语言平面众所分配区域中
/
日
/
韩字符
(
CJK character)
。尽管在
SIP
中包含少量的常用
CJK
字符(例如,用于粤语)
p>
,其中绝大多数字符是仅具有历史意义的不常用字符。
增补专用平面
(Supplementary
Special-purpose Plane, SSP
, or Plane 14
)
用于无法放入基本多语言平面众所分配区域的格式
控制字符。
3.
一致性
符
合
Unicode
一致性要求的实现必须满足本部分定义的标准
,以便与其他规范的实现进行交互。
3.1
一致性要求
3.1.1
未分配的码点(
Unassigned Code
Points
)
C4
处理过程不应该把高代理码点(
high-surrogate
code point
)或者低代理码点(
low-
surrogate code
point
)解释为抽象
字符。
C5
处理过程不应该把非字符码点解释为抽象字符。
C6
处理过程不应该将未分配的码点解释为抽象字符。
3.1.2
解释(
< br>Interpretation
)
C7
如果处理过程要解释编码字符
的表示,就必须根据标准中确立的字符语义进行解释。
C8
不要求处理过程对任何特定的编码字符都作解释。
允许处理过程只解释
Unicode
字符中的一个子集;不需要解释所有
Unicode
字符。
标准中不涉及任何指定字符子集的方法。
标准中不涉及自定义区中码点的语义。
C9
处理过程不应认为对两个具有
规范等价性字符序列(
canonical-equivalent
character sequence
)的解释会不同。
该条款包含两层意义:
(一)
处理过程不应该对两个不同但又具有规范等价性的字符序列由不同
的解释;
(二)
任何处
理过程不应假设
其他处理过程会对两个不同但具有规范等价性的字符序列进行不同的解释。
3.1.3
修改(
Modification
)
C10
如果一个处理过程声称不会
修改对一个正确的编码字符表示的解释,则它不能对编码字符的表示进行任何修改,
除非
是用具有规范等价性的字符序列进行替换,或者是删除非字符的码点。
用具有规范等价性的字符序列替
换原有字符序列不会修改对文本的解释。
替换或者删除处理过程不能会不进行解释的字符序列,不修
改对文本的解释。
当在不同计算机体系结构间转换字符序列时,对字符序列位或者字节顺序的改变,不修改对文本的解 释。
将一个正确的编码字符的表示从一种
Unicode
字符编码格
式转换为另一种编码格式时,不修改对文本的解释。
将编码单元序列的字节串行化从一种
Unicode
字符编码方案转换为另一种编码方案时,不修改对文本的解释。
如果在处理
过程中意外遇到一个没有明确内部用途的非字符,
在实现中可以发出错误,
或者删除或忽略该非字符。
如
果没有采取这些选择,
这个非字符应该被作为一个为分配的码点。
3.1.4
字符编码格式(
Character Encoding
Forms
)
C11
当处理过程对一个声称以某种
Unicode
字符编码格式存在的编码单元序列进行解释时,必须按照相应的码点序列
进行解释。
C12
当处理过程以某种
Unico
de
字符编码格式生成编码单元序列时,不应生成形式错误
(i
ll-formed)
的编码单元序列。
C12a
当处理过程对一个声称以
某种
Unicode
字符编码格式存在的编码单元序列进行解释
时,
应该将形式错误的编码单
元序列看作错误条件,而不能将序
列解释为字符。
3.1.5
字符编码方案(
Character Encoding
Schemes
)
C12b
当处理过程对一个具有某种
Unicode
字符编码方案的字节序列进行处理时,
应该根据
字节顺序和标准中针对字符
编码方案设立的字节顺序标记
(by
te order mark)
使用规范,进行解释。
3.1.6
双向文本(
Bidirectional
Text
)
C13
用于显示包含从右到左的字符文本的处理过程,当没有
高层协议时,必须以对文本应用双向算法后同样的顺序显
示所有具有可见表示的字符(不
包括格式字符)
。
3.1.7
正规化形式(
Normalization
Forms
)
C14
以某种正规化形式生成
Uni
code
文本的处理过程,必须与
Unicode
Standard
Annex
#15
Normalization
Forms
中定义的规范相符合。
C15
测试
Unicode
文本是否具有某种正规化形式的处理过程,必须与必须与
Unicode Standard Annex
#15
中定义的规范
相符合。
C16
将文本转换为某种正规化形
式的处理过程必须生成
Unicode Standard Annex
#15
中规定的结果。
3.1.8
标准的引用(
Normative
References
)
C17
对标准、属性别名、属性值别名或者
< br>Unicode
算法的标准引用,必须依照
Unicod
e
标准种指定的格式。
C18
高层协议不能对临时属性进行标准引用。
3.1.9
Unicode
算法
(Unicode
Algorithms)
C19
如果处理过程声称实现某个
Unicode
算法,则必须符合标
准中定义的算法规范,除非被高层协议改变。
3.2
术语定义
以下是对一致性条款中所使用术语的准确定义。
3.2.1
字符的身份和语义(
Character Identity
and Semantics
)
D1
标准的行为
(
normative b
ehavior
)
:
Unicode<
/p>
标准中的标准行为包括以下列表,
以及在一致性条款种指定的其他
行为。
1.
2.
3.
4.
字符组合;
规范化的分解;
兼容的分解;
规范的排序行为;
5.
双向行为;
6.
联合
jamo
行为
(conjoining jamo
behavior);
7.
变化选择;
8.
正规化。
D2a
字符身份(
character identity
)
:一个字符的身份是由它的字符名称、表示的字形确定的。
D2b
字符语义(
character semantics
)
:一个字符的语义是由它的身份、标准的属性和行为决定的。
3.2.2
字符与编码(
Characters and
Encoding
)
D3
抽象字符(
abstract
character
)
:信息的单元,用于文本数据的组织、控
制或表示。
抽象字符没有具体的形状,不应与字形混淆。
Unicode
标准中没有直接编码的抽象字符经常可以使用组合字符序列表示。
D4
抽象字符序列:抽象字符的有序序列。
D4a
Unicode
编码空间(
Unicode codespac
e
)
:从
0
到
10FFFF
的整数空间(十六进制)
。
D4b
码点(
code point
)
:
Unicode
编码空间中的任何一个整数
值。
一个码点也称为一个编码位置。
D5
编码字符(
encoded c
haracter
)
:在一个抽象字符和一个码点间的关联。<
/p>
在
p>
Unicode
中,为了与其它标准兼容,一个单个的抽象字符可能
与多个码点对应。
一个单个的抽象字符也可能使用一个码点序列表示。
D6
编码字符表示(
coded character repre
sentation
)
:一个码点序列。通常,是由编码字符的
序列组成,但也可能包含非
字符或保留的码点。
编码字符表示也称为编码字符序列(
coded
character
sequence
)
。
在内部,
处理过程可能会在编码字符表示中使用非字符码点。
但是,
这
些非字符码点可能不会被解释成抽象字符;
并
且,如果这些非字
符码点被具有一致性的处理过程删除,不构成对编码字符表示解释的修改。
D7a
不赞成使用的字符(
deprecated characte
r
)
:强烈不鼓励使用的编码字符。
在标准中保留不赞成使用的字符
,以便使以前相容的数据仍然与今后的
Unicode
标准保持
一致性。
D7b
非字符(
noncharacter
)
:被永久保留做内部使用的码点,不应用于交换。非字符包括值
U+nFFFE
和
U+nFFFF
(
< br>n
表示十六进制整数从
0
到
p>
10
)
,以及值从
U+FDD0
到
U+FDEF
。
D7c
保留的码点(
reserved code point
)
:
Unicode
标准中保留的,用于今后分配的码点。也称为位分配码点(
unassigned
code
point
)
。
代理码点和非字符码点是已分配的码点,但不是分配给字符。
D8
高层协议(
higher-level protocol
p>
)
:任何超出
Unicode
标准范围,对
Unicode
字符进行解释协议。<
/p>
D8a
Unicode
算法(
Unicode Algorithm<
/p>
)
:对处理过程的逻辑描述,用于获得涉及
Unicode
字符的指定结果。
3.2.3
属性(
Properti
es
)
(
1
)标准的和指示性属性(
Norma
tive and Informative
Properties
)
Unicode
字符属性可以分为标准的和指示性的。
< br>
D9
标准属性(
normative property
)
:
Unicode
字符
属性,它的取值必须为与标准相一致。
D9a
指示性属性(
Informative property
p>
)
:
Unicode
字符属性,它的取值仅仅是为了提供更多信息。
D9b
临时的属性(
provisional property
p>
)
:
Unicode
字符属性,它的取值未被批准、试验性的,也可能是不完全的。
(
2
)简单
的和衍生出的属性(
Simple and Derived
Properties
)
D9c
简单属性(
simple p
roperty
)
:
Unicode<
/p>
字符属性,它的取值在
UCD
,
the
Unicode Character Database
p>
(或标准中的
其他地方)直接指定,并且它的取值无法从其他简单属
性中衍生出来。
D9d
衍生属性(
derived property
)
:
Unicode
字符属性
,它的取值可通过算法从一些简单属性的组合中衍生出来。
(
3
)属性别名(
Property Aliases
)
D10
属性别名(
property alias
)
:特定
Unicode
字符属性
的一个唯一标示名。
用于属性别名的标示名中仅包含
ASCII
中的
字母、数字和下划线。
为每个属性别名分别定义了长、
短两种形式的名称。
< br>短的形式一般只有两个或三个字符长,
便于在标记语言中用于标
< br>记属性。
D10a
属性值别名(
property value alias
p>
)
:为
Unicode
字符属性的特定取值定义的唯一标示名。
用于属性值别名的标示名中仅包含
ASCII
中的字母、数字和下划线,或者是特殊的值
。
为每个属性值别名分别定义了长、短两种形式的名称。
属性值别名仅在相关联的特定属性环境中唯一。
(
4
)却省
属性值(
Default Property
V
alue
)
D11
却省属性值(
default property value
)
:针对一个给定的
Unicode<
/p>
属性,用于指派给未分配的码点或没有明确指定其
他属性值的属性
值。
(
5
)私用(
Private
Use
)
D12
私用码点
(private-
use
code
point)
:在
范围
U+E000
到
U+F8FF
p>
、
U+F0000
到
U+FFFFD
和
U+100000
到
U+10FFFD
内的码点。
私用码点被认为已分配给字符,
但标准中没有指定对私用码点相关联的抽象字符的解释。
私用码点可能会被赋予却省的属性值,但这些却省值可以被
对私用码点进行解释的高层协议替换。
3.2.4
组合(
Combinat
ion
)
D13
基字符(
base char
acter
)
:在书写上,不与前面的字符进行组合的字符,它
既不是控制字符也不是格式字符。
D14
组合字符(
combining character
)
:在书写上,与前面的基字符进行组合的字符。称组合字符应用于基字
符。
组合字符不单独使用。它们包括重音符、变音符、希伯莱文中的点、阿拉伯文元音符号等。
尽管组合字符用来与基字符
组合显示的,但可能出现两种情况
(1)
在组合字符前没有基字
符;
(2)
处理过程无法执行组
合操作
。在这两种情况下,处理过程可能会不进行书写上的合并而显示组合字符。
在编码表中,
< br>组合字符的表示使用虚线圆圈描绘。
当与前面的基字符组合显示时,
基字符要出现在虚线圆圈的位置上。
组合字符一般具有它们的基字符的属性,同时保留它们的组
合属性。
控制字符和格式字符,如
tab
和
right-left mark
不是基字符。
D15
非间距标记(
nonspacing mark
)
:在显示时,位置取决于基字符的组合字符。这些字符一般在可视基线上不占
用空
间。
这些字符可能会很大,影响它们的基字符相对于前后基字符的放置。
D16
间距标记(
spacing mark
)
:不是非间距标记的组合字符。
一般来说,间距标记的行为与基字符没有太大区别。
D17
组合字符序列(
combining
character
sequence
)
:一个字符序列,由一个基字符后跟了一个或多个组合字符组成,
< br>或者是一个或多个组合字符的组成的序列。
D17a
不良的组合字符序列
(defective
combining character
sequence)
:一个不是以基字符开始的组合字符序列。
当组合字符序列出现在串的开始
位置,或者跟在控制字符或格式字符后出现时,产生不良的组合字符序列。
3.2.5
分解(
Decomposition
)
D18
可分解字符(
decomposable character
)
:根据分解映像表,与一个或多个字符组成的序列等价的字符
。也被称作预
组合字符(
precomposed
character
)或复合字符(
composite
character
)
。
D19
分解(
decomposition
)
:与一个可分解字符等价的
一个或多个字符组成的序列。一个字符序列的完全分解,是对序
列中每个字符进行分解直
到没有字符可以进一步分解。
(<
/p>
1
)兼容的分解
(Compatibil
ity Decomposition)
D20
兼容的分解
(compatibility
< br>decomposition)
:递归应用
Charac
ter
Names
List
中的兼
容映像表和规范映像表,以及
Conjoining Jamo Behavior
p>
中的定义,对字符进行分解,直到没有任何字符可以进一步分解,并根据
Canonical Ordering
Behavior
中的定义对非间距标记进行重新排序。
D21
兼容的可分解字符
(compatibility
decomposable character)
:兼容分解的结果与规范分解结果不
相同的字符。
(
< br>2
)规范的分解
(Canonical
Decomposition)
D23
规范的分解
(canonical
d
ecomposition)
:递归应用
Character
Names
List
中的规范映像表
,以及
Conjoining
Jamo
Behavior
中的定义,对字符进行分解,直到没有任何字符可以进一步分解,
并根据
Canonical Ordering Behavior
中的定
义对非间距标记进行重新排序。
D21
规范的可分解字符
(compatibility
decomposable
character)
:与规范分解结果不相同的字符。
D24
规范等价性
(canonical equivalent)<
/p>
:如果两个字符序列的完全规范分解结果相同,称它们具有规范的等价性。
3.2.6
代理(
p>
Surrogates
)
D25
高代理码点(
high-surrogate code po
int
)
:位于范围
U+D800
p>
到
U+DBFF
内的
Unicode
码点。
D25a
高代理编码单元(
high-surrogate
code
unit
)
:在范围
D800
到
DBFF
内的
16
位编码单元,作为
UTF-16
中代理对
的起始编码单元。
D26
低代理码点(
low-surrogate code poi
nt
)
:位于范围
U+DC00
到
U+DFFF
内的
Unicode
码点。
D26a
低代理编码单元
(
low-
surrogate code unit
)
:
在范围
DC00
到
DFFF<
/p>
内的
16
位编码单元,
< br>作为
UTF-16
中代理对的
结
尾编码单元。
D27
代理对
(
surrogate pai
r
)
:
由两个
16
位编码单元组成的序列来表示单个的抽象字符,
其中,
p>
代理对的第一部分为高
代理编码单元,第二部分为低代理编码单元。
代理
对仅用于
UTF-16
。
孤立的代理编码单元自身没有解释。
3.2.7
Unicode
编码格式(
Unicode Encoding
Forms
)
D28
Unicode
标量值(
Unicode scalar va
lue
)
:除了高代理和低代理码点外的其他所有
Unicode
码点。
D28a
编码单元(
code un
it
)
:为了处理和交换,表示编码文本单元的最小的位组合。
编码
单元是计算机存储中的特定单元。
Unicode
标准在
UTF-8
中使用
8
位编码单元,在
UTF-16
中使用
1
6
位编码单
元,在
UTF-32
中使用
32
位编码单元。
在
Unicode
标准中,一些编码单元的特定值不能单独用于表示编码字符。该限制条
件应用于
UTF-16
中孤立的代理码
点,以及
UTF-8
中的字节
80-F
F
。
D28b
编码单元序列(
code
unit sequence
)
:一个或多个编码单元的有序序
列。
当编码单元是
8
位时,编码单元序列也可被称作字节序列。
p>
一个编码单元序列可能只有一个单个的编码单元。
在程序设计语言中,字符串类型的值基本由编码单元序列组成。
依赖字符编码标准的结构,可能
要使用编码单元序列(包含多个编码单元)来表示一个单个的编码字符。
D29 Unicode
编码格式将
每个
Unicode
标量值分配给一个唯一的编码单元序列。<
/p>
由于历
史原因,
Unicode
编码格式也被称作
Unicode
(
or
UCS
)
transformation formats
(
UTF
)
。
在
Un
icode
标量值集合与针对
Unicode
< br>编码格式的编码序列集合间的映射是一对一的。
对给定的编码格式,存在编码单元序列没有相关联的
Unicode
标量值。
D29a
Unicode
串(
Unicode string
)
:由
Unicode
编
码格式中编码单元组成的编码单元序列。
D29b 8
位
Unicode
串(
Unicode 8-bit string
)
:只包含
UTF-8
编码单元的
Unicode
串。
D29c 16
位
< br>Unicode
串(
Unicode 16-bit s
tring
)
:只包含
UTF-16<
/p>
编码单元的
Unicode
串。
D29d 32
位
Unicode
串(
Unicode
32-bit string
)
:只包含
UTF-32
编码单元的
Unicode
串。
D30
形式不良的(
ill-formed
)
:如果具有
Unicode
编码格式的
Unicode
编码单元序列没有遵照
Unicode
编码格式规范,
就称为形式不良的。
如果编码单元序
列对应的码点位与
Unicode
标量范围之外,就是形式不良
的。
UTF-8
对起始字节和后续字节的字节范围有严格的约束。
违
反这些约束,
将使生成的编码单元序列无法映射到
Unicod
e
标量值上,产生一个形式不良的编码单元序列。
D30a
形式良好的(
well-formed
)
:遵照
Unicode
编码格式规范
的
Unicode
编码单元序列,就成为形式良好的。
D30b
形式良
好的
UTF-8
编码单元序列(
wel
l-formed UTF-8 code unit
sequence
)
D30c
形式良好的
UTF-16<
/p>
编码单元序列(
well-formed UTF-16
code unit sequence
)
D30d
形式良好的
UTF-32
编码单元序列(
well-
formed UTF-32 code unit
sequence
)
D30e
具有
Unicode
编码格式(
in a Unicode encoding form
)
:如果一个
Unicode
串是由某个特定的
Unicode
编码格式的<
/p>
形式良好的编码单元序列组成,称该
Unicode
字符串具有
Unicode
编码格式。
UTF-32
D31
UTF-32
编码格式(
UTF-32 encoding f
orm
)
:一种
Unicode
编码格式,为每个
Unicode
标量值分配
一个单一的无符
号的
32
位编码单元,
编码单元的数字值与
Unicode
标量值相同。
因为代理码点没有
包括在
Unicode
标量值集合中,所以位与范围
0000D800
到
0000DFFF
间的
UTF-32
编码单元使形
< br>式不良的。
任何大于
0010FFFF
的
UTF-32
编码单元是形式不良的。
UTF-16
D35
UTF-16
编码格式(
UTF-16
encoding
form
)
:一种
Unicode
编码格式,为处在范围
U_0000
到
U+D7FF
和
U+E000
到
U+
FFFF
内的每个
Unicode
标量
值分配一个单一的无符号的
16
位编码单元,编码单元的数字值
与
Unicode
标量值相
同;位处在
范围
U+10000
到
U+10FFF
F
内的每个
Unicode
标量值分配
一个代理对。
因为代理码点不是
Unicode
标量值,位于范围<
/p>
D800
到
DFFF
间单独的
UTF-16
编码单元是形式不良的。
UTF-16 Bit
Distribution
Scalar
V
alue UTF-16
xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx
000uuuuuxxxxxxxxxxxxxxxx
110110wwwwxxxxxx110111xxxxxxxxxx
wwww=uuuuu-1
UTF-8
D36
UTF-8
编码格式
(UTF-8 encoding for
m)
:一种
Unicode
编码格式,
位每个
Unicode
标量值分配一个由一到四个无符
号字节组成的序列。
UTF-8 Bit Distribution
Scalar V
alue 1st Byte 2nd
Byte 3rd Byte 4th Byte
00000000 0xxxxxxx 0xxxxxxx
00000yyy yyxxxxxx 110yyyyy 10xxxxxx
zzzzyyyy yyxxxxxx 1110zzzz
10yyyyyy 10xxxxxx
000uuuuu
zzzzyyyy yyxxxxxx 11110uuu 10uuzzzz 10yyyyyy
10xxxxxx
编码格式转换
(Encoding Form
Conversion)
D37
编码格式转换:在一种
Unicode
编码格式的编码单元序列
与另一种
Unicode
编码格式的编码单元序列间,直接定<
/p>
义的转换。
*
在
Unicode
标准实现中,一个典型的
API
在逻辑上,将输入的编
码单元序列转化为
Unicode
标量值(码点)
,然后
将标量值转化为输出的编码单元序列。然而,可以直接在不同编码格式
间进行转换,以获取更高的效率。
*
具有一致性的编码格式转换过程应将任何形式不良的编码单
元序列作为一个错误条件。
3.2.8
Unicode
编码方案
(Unicode Encoding
Schemes)
D38 Unicode
编码方案:针对
Unicode
编码格式的一种指定的
字节串行换,也可包括处理字节顺序标记
(byte order mark,
BOM)
的规范。
D39
UTF-8
编码方案
(UTF-8 encoding sch
eme)
:
对
UTF-8
编码单元序列进行串行化的
Unicode
编码方案
,
字节序列与编
码单元序列本身完全一致。
D40
UTF-16BE<
/p>
编码方案
(UTF-16BE
encoding
scheme)
:
将
UTF-16
编码单元序列串行化为
big-endian
格式字节序列的
Unicode
编码方案。
D41
UTF-16LE
编码方案
(UTF-16LE
encoding scheme)
:将
UTF-16
编码单元序列串行化为
little-endian
格式字节序列的
Unicode
编码方案。
D42
UTF-16
编码方案
(UTF-16 encoding s
cheme)
:将
UTF-16
编码单
元序列串行化为
big-
endian
或者
little-endian
格式字
节序列的
Unicode
编码方案。
在
UTF-16
编码方案中,与
U+FEFF
对应的初始字节序列,被解释为字节顺序标记
(
BOM)
,用于区分两种字节顺序。
初始字节顺序
表明是
big-
endian
顺序,
表明是
little-endian
顺序。
BOM
不是文本内容的一部分。
UTF-16
编码方案可能以
BOM
开始,也可能没有。然而,
如果没有
BOM
,也没有高层协议指示,
UTF-16
编码方案
的字节顺序为
big-endian
。
D43
UTF-32BE
编码方案<
/p>
(UTF-32BE
encoding
scheme)
:将
UTF-32
编
码单元序列串行化为
big-endian
格式字节序列的
p>
Unicode
编码方案。
D44
UTF-32LE
编码方案
(UTF-16LE
encoding scheme)
:将
UTF-32
编码单元序列串行化为
little-endian
格式字节序列的
Unicode
编码方案。
D45
UTF-32
编码方案
(UTF-32 encoding s
cheme)
:将
UTF-32
编码单
元序列串行化为
big-
endian
或者
little-endian
格式字
节序列的
Unicode
编码方案。
在
UTF-32
编码方案中,与
U+FEFF
对应的初始字节序列,被解释为字节顺序标记
(
BOM)
,用于区分两种字节顺序。
初始字节顺序
<00 00 FE FF>
表明是
big-
endian
顺序,
表明是
little-endian
顺序。
BOM
不是文本内容的一
部
分。
UTF-32
编码方案可能以
BOM
开
始,也可能没有。然而,如果没有
BOM
,也没有高层协议指示
,
UTF-16
编码方案
的字节顺序为
big-endian
。
3.2.9
规范排序行为
(Canonical Ordering Behavior)
p>
用于对组合字符序列提供无歧义的解释,以便能按照可预知的方式创建和交换包含组合字符的
序列。正规化是规范排
序行为的另一个重要应用。
在
Unicode
< br>标准中,组合字符序列中字符的顺序按照以下原则解释:
所有组合字符必须跟在所应用的基字符后面。
封闭的标记
(enclosing mark)
将包围基字符以及标记之前的所有组合字符。也包围它之前的其他封闭标记。
double diacrit
ic
的结合程度比其他非间距标记
(nonspacing
mark)
要松。当显示时,
double diacriti
c
的位置在其他变音符
之上,不包括封闭的变音符。
具有相同组合类别
(combining
class)
的组合标记在书写上的位置一般是由所修饰的基字符向外排列。一些特
定的非间
距标记将改变却省的排列行为,与相邻的非间距标记并行排列。当并行排列时,
编码的顺序与书写中占支配的顺序有
关。
如果组合字符的组合类别不同,
将不会有显示形式或语义上的差别。
(
1
)组合类别
(Combinin
g Class)
D46
组合类
别:分配给每个
Unicode
组合字符的数字值,用于确定与
那些组合字符在排字上相互作用。
如果组合字符间在排字上相互作用,则具有相同的组合类别;否则,具有不同类别。
p>
封闭字符和间距组合字符的组合类别与它们的基字符相同。
组合类别具有的特定数字没有特
别的重要性,只是用来比较是否相等,区分不同的组合类别。
(
2
)规范排序
(Canonical Ordering)
对一个被分
解的字符序列的规范排序,是根据组合类别对每个组合字符序列进行排序来完成的。字符序列的规范排序
不反映任何语言正确性或偏好。
对被分解的字符序列
D
进行规范排序的算法为:<
/p>
R1
对<
/p>
D
中的任意字符
x
,定义
p(x)
为字符
x
的组合类别。
R2
如果在
D
中存在想的字符对
(A,B)
,并且
p(B)
不为零,
p(A)>p(B)
,则交换两个字符。
R3
重复执行
p>
R2
,直到在
D
中
没有发生任何交换。
(
3
)
Conjoining Jamo
Behavior
在
Unicod
e
标准中包含了一套预组合的
Hangual
< br>音节,以及一套用于表示古老的韩文音节和现代韩文音节的
jamo
。
4.
实现指南
4.1
编码转换(
Transcoding to Other
Standards
)
一般,在
Unicode
标准和其他编码标准间的
映射需要通过表
(table)
来完成,而不是算法转换。使用
表查找常常具有比简
单算法转换更高的效率。
(
1
)多级
表(
Multistage
Tables
)
< br>转换表需要空间。即使是很小的字符集也经常会映射到
Unicode
标准中几个不同的区块中,因此,至少在一个转换方
向上(从
Unicode
标准到其他编码标准或相反)
,可能
会包含多至
64K
个项(针对
BMP<
/p>
)或
1,088K
个项(针对全部编
p>
码空间)
。有多个方法用于减少映射表的内存空间需求,这些方法不
仅可用于转换表,也可用于其他实现
Unicode
标准
的表结构,包括字符属性数据、
case
映射
等等。
(
2
)
Flat Tables
p>
如果磁盘空间不是问题,
虚拟内存体系可以为
flat table
安排可接受大小的工作集,
因为各字符
的使用频率有很大不同,
即使是小字符集也包含一些不常使用的字符。并且,需要转换为
给定字符集的数据中的字符一般不会来自
Unicode
标
p>
准中的所有区块。
(
3
)
Ranges
提供一个精心创建的嵌套范围判断对表进行优化,可能比较吸
引人。但由于分支损失,这种方法会对现代的高度流水
线式的处理器体系造成不必要的性
能耗费。一种快速的解决方案是采用优化的两级表,可以在编码中不包含任何测试
或分支
指令。尽管哈希表的速度不如多级表,但也可用于空间优化。
(
4
)两级表
(Two-Stage Tables)
两级表示常用的一
种减少表的大小的机制。两级表使用一个指针和却省值的数组。如果指针为空
NULL<
/p>
,查找返回却
省值。否则,指针指向用于第二级查找的数值块。对
于
BMP
字符,按照高字节和低字节值来组织这样的两级表非常
有
效,第一级是由
256
个指针组成数
组,每个第二集区块中包含
256
个值。对于增补字符,应采取
不同的方法构造指针
和二级数组,以便充分考虑增补字符在剩余编码空间中稀疏的散布。
(
5
p>
)优化的两级表
(Optimized Two-Stage
Table)
当任何区块相同时,对应的指针只需其中一个
区块。对编码转换表而言,这种情况一般出现在当区块中的字符仅仅映
射到
却省
或
无法匹配
的字符时。不是使用空指
针
NULL
和一个却省值,而是创建了一个却省项的
共享
块。由于避
免使用测试和分支,这种策略可以提供接近于简单数租访问的速度,却大大节省了存储空间。
p>
(
6
)多级表调节
(Multistage Table Tuning)
给定一个具有任意大小和内容的表,可以较容易的创建一个小
的应用程序,来计算多级表的最佳级数和它们的宽度。
通过调节级数和它们的索引指针数
组的宽度,可以在表大小和平均访问时间之间进行折衷。
4.2 ANSI/ISO C wchar_t
在
ANSI/ISO C
中,为固定宽
度的宽字符定义了类型
wchar_t
,
ANSI/ISO
C
将宽字符集语义的定义留给了特定的实现。
wchar_t
的宽度是由编译器指
明的,
可以只有
8
位大小。
因此,
需要在不同
C
或<
/p>
C++
编译器间可移植的程序不应该使用
wchar_t
存储
Unicode
文
本。
对于
UTF-16
的实现,
可以使用宏
ma
cro
或者类型定义
typedef
(
如
UNICHAR
)
,
编译为
unsigned short
或者
wchar_t
(
依
赖于
目标编译器和平台)
。对
UTF-32
的实现可以使用编译为
unsigned int
或
wchar_t
的宏或者是类型定义。这样的选择
使在不同的系统平台和编译其中可以正确编译。
4.3
未知和缺少的字符
(Unknown and Missing
Characters)
4.3.1
保留的和私用的字符编码
(Reserved and
Private-Use Character Codes)
有两类码点,即使是完全的
Unicode
标准实现也无法
正确解释: