时间：2022-03-30 03:33:00
(中国科学院 软件研究所 开放系统与中文信息处理中心，北京 100080)
摘 要：国内藏文软件开发普遍使用的是基于垂直预组合字符的实现方案，但是缺乏统一的编码标准。藏文编码字符集扩充集的推出，对于国内藏文软件的标准化、国际化具有重要意义。本文通过分析ISO／IEC 10646藏文编码字符集基本集、藏文编码字符集扩充集国家标准，区分它们描述字丁的差异，分析由编码方案所导致的实现上的关键问题。最后，针对藏文扩充集B的特殊性，提出并实现了基于Linux国际化架构下支持藏文扩充集标准的解决方案。
关键词：计算机应用；中文信息处理；藏文字丁；扩充集；OpenType；扩充QT方案
中图分类号：TP391 文献标识码：A
1 引言
为了推动藏文信息处理技术的标准化，国家有关部门先后推出了多个信息技术藏文编码字符集标准，包括藏文编码字符集基本集标准GBl6959[7]和即将的藏文编码字符集扩充集A标准(本文简称“藏文扩充集A”)、藏文编码字符集扩充集B标准(本文简称“藏文扩充集B”)。目前，国外软件厂商普遍采用藏文编码字符集基本集(本文简称“藏文基本集”)来实现藏文支持，国内也已经有针对藏文基本集的研究工作，参见文献[1]；而藏文扩充集A、藏文扩充集B由于推出时间较晚，并且受编码空间所限，现有软件体系结构在支持藏文扩充集时存在一些问题。
本文首先描述了藏文文字特点、藏文字符集标准的差异性，然后从藏文扩充集字符的输入、存储、显示的角度，讨论了实现藏文扩充集的技术途径。最后，针对藏文扩充集B的特殊性，讨论了其在QT上的实现。
2 文字特性
藏文分为现代藏文和梵源藏文[5]。藏文是拼音文字：现代藏文是用来拼写现代藏族语言的文字符号系统，有30个辅音，4个元音；梵源藏文是根据梵文字形新创藏文字母或规则来转写梵文的系统[5]，有33个辅音，12个元音。藏文字形结构均以一个字母为核心，其余字母均以此为基础前后附加和上下叠写，组合成一个完整的字表结构。依据它们在拼音时所起的作用和在文字结构中的位置，可以分为基字、上加字、下加字等，更详细描述可以参考文献[2,11]。
为了下文讨论的方便，定义如下名词：
定义1 藏文字丁：现代藏文和梵音藏文中的字符，可由一个辅音字母(可加元音字母)构成；也可由两个或两个以上辅音字母上下叠加构成(可加元音字母)。称这样纵向叠加而成的图形符号，为藏文字丁。
藏文字丁一般由一个单独的辅音(可加元音修饰)，或是一个辅音及上下叠加多个辅音(可加元音修饰)来构成的。根据ISO／IEC10646：2003标准，按照从上到下的顺序观察藏文字丁，称最上面一层辅音字母为头层辅音(Head Position Consonant)；头层辅音之下的若干辅音称为附加辅音(SubjoinedConsonant)，按照其位置依次称为第一附加辅音(First Subjoined Consonant)、第二附加辅音(Sec―ond Subjoined Consonant)等等；最后，是修饰用的元音字母。
藏文字丁的书写顺序是：头层辅音(Head Po―sition Consonant)、第一附加辅音(First SubjoinedConsonant)、……(中间各层辅加辅音)、最后的附加辅音(Last Subjoined Consonant)、修饰用的元音(Subjoined Vowel)。
定义2 藏文字：一个藏文音节对应的字符串称为一个藏文字。藏文音节由前加字、基字、上加字、下加字、元音符号、后加字、再后加字构成。藏文字之间，用分字符(Tshec，也称音节点)分隔。
3 藏文编码字符集标准
藏文编码字符集标准是计算机实现文字信息处理与交换的基础。目前，已经形成了两种藏文信息表示方案：(1)基于藏文基本集的方案；(2)基于藏文基本集+藏文扩充集的方案。下面将对编码字符集标准及藏文信息表示方案进行比较。
3.1 藏文编码字符集标准制定的历史
藏文信息技术标准化的问题首先由国际标准化组织(ISO)于1992年提出，包括3个方面工作：第一，制定藏文编码字符集标准(交换码，包括基本集和扩充集)；第二，制定藏文字符键盘布局标准；第三，制定藏文字形标准[6]。
1997年7月，ISO/IEC JTC1/SC2通过了藏文编码国际标准方案。国家技术监督局于1997年了藏文编码字符集国家标准GBl6959―1997[7]]、点阵字形标准GB／T16960．1―1997[8]和藏文编码字符集(基本集)藏文字符键盘布局GB/T 17543[9]。2004年9月、2005年8月，国内藏文信息处理专家相继完成了《信息技术、信息交换用藏文编码字符集基本集的扩充集A》、《信息技术、信息交换用藏文编码字符集基本集的扩充集B》的编制、审定工作。
3.2 ISO／IECl0646国际标准中的藏文基本集
ISO／IECl0646：2003标准为藏文分配编码空间是0F00-0FDl，其中定义了195个藏文字符，包括：辅音字符、元音字符、数字、标点、其他符号、藏文转写梵文来源辅音符号、藏文转写梵文来源元音符号。
ISO／IEC10646标准规定：藏文字丁的编码顺序(Coding Order)与藏文字丁的书写顺序一致[10]。
以藏文字丁“ ”为例，来说明ISO／IEC10646标准对藏文字丁的编码顺序，如图1所示：
其中，字丁(1)的编码为0x0F66+0x0F92+0x0FB2+0x0F72。在基本集中使用“组合用字符”(Combining Character，文献[10]第2．10节)来表示附加辅音，图2中的②、③、④是组合用字符。
3.3藏文编码字符集扩充集国家标准
藏文编码字符集扩充集(本文简称“藏文扩充集”)，包括3个部分：藏文基本集中的非组合用字符、藏文扩充集A的字符、藏文扩充集B的字符。藏文扩充集可以表示和交换所有现代藏文和99％以上的古代藏文为载体的信息[12]。
按照Unicode4．1使用字符平面[10](Planes ofCharacters)对码点空间的分配情况的描述，可供使用的字符平面有5个：基本多文种平面(BMP，Basic Multilingual Plane)、辅助多文种平面(SMP)、 辅助表意字符平面(SIP)、辅助特殊用途平面(SSP)、专用平面A(Supplementary Private UseArea－A)、专用平面B(Supplementary Private UseArea-B)。
与藏文基本集最大的不同是，藏文扩充集在ISO／IEC10646编码体系结构的框架内，对藏文中由基本字符纵向叠加而成，具有稳定结构且使用频繁的藏文和梵文藏字字丁进行编码。藏文扩充集A收录了1536个纵向叠加字丁，编码范围为0xF300～0xF8FF，位于BMP平面的专用区(Private UseArea)内；藏文扩充集B是藏文扩充集A的补充，收录了5702个基本字符纵向叠加而成的结构稳定的梵文藏字字符，使用专用平面A，其编码位置是0xF0000～0xFl645。
以藏文字“
”为例，来说明藏文扩充字符集标准对藏文字符的编码方式，如图2所示：
藏文字丁(1)、(2)、(3)和(4)的字符编码分别是0x0F56、0xF393、0x0F42、0x0F66。
3.4藏文字符集标准的差异
藏文基本集、藏文扩充集对藏文字丁的编码方式不同。从理论上说，这两种方式都可以描述全部藏文字丁：用藏文基本集表示字丁，只需要对构成藏文字丁的图形元素进行编码，码点空间的占用量很少；藏文扩充集则需要为每一个不同字丁分配一个独立的码点，需要较大的编码空间。
从藏文存储的角度来说：采用藏文基本集对藏文字丁编码，每个字丁的编码长度取决于构成字丁的元音、辅音的数目，一般需多个编码字符组合而成；采用藏文扩充集对藏文字丁编码，每个字丁对应一个码点。因此，采用藏文基本集编码藏文字丁，较藏文扩充集来说，需要使用更多存储空间。
4 支持藏文字符集标准的软件实现分析
藏文基本集、藏文扩充集编码标准，对软件实现提出了不同的要求。
4.1 关键实现问题的对比分析
(1)从文本处理的角度分析：采用藏文基本集对藏文字丁编码，编码长度不定，对于字处理软件的常见操作(如，光标移动、字符的删除等)来说，必须正确地识别字丁的编码序列的边界。光标移动操作必须对每个字丁的编码序列作为一个整体来对待：上一个光标位置，对应于前一个字丁的编码序列的第一个编码之前；下一个光标位置，对应于下一个字丁的编码序列的最后一个编码之后。同理，字符的删除操作，其操作单位是一个字丁的编码序列：必须将当前光标位置的前一个字丁的编码序列作为整体进行删除。
对于藏文扩充集表示的字丁，其编码与字符之间是一一对应的关系，因此字处理软件实现起来较为容易。
(2)从藏文显现角度分析：藏文扩充集是对藏文垂直预组合的字丁进行编码，藏文字丁编码与字丁是一一对应的。在设计藏文扩充集字库时，字库中藏文字丁的字形与藏文字丁编码也是一一对应的。因此，传统字体技术就可以满足显示藏文扩充集字丁的需要。
传统字体技术将字符码点，映射成字形(glyph)ID。这是一对一的映射方式。由于藏文扩充集的编码方式的特点，传统字体技术对藏文扩充集A、藏文扩充集B是适用的。
藏文基本集标准没有为具有多层纵向叠加结构的字丁分配码点，即：多层纵向叠加的字丁在IS010646标准中没有码位，因此在字形光栅化之前就必须要做特殊处理，实现字丁编码与字丁之间的映射和藏文字丁的选形功能，通过国际化文本处理引擎、OpenType字库技术来实现，详细的解决方案参见文献[1]。
4.2 Linux的国际化支持架构
Linux系统对藏文字的支持需要建立在其国际化机制的基础上，国际化机制的一个重要方面就是对字符编码标准的支持。总体上看，Linux国际化框架呈现如图3所示的层次结构，Linux内核与国际化基本不相关，在其之上，基本库、x Window系统和图形构件库之间存在单向依赖关系，又共同构成了系统的国际化基础设施，GUI应用程序通过综合使用这些层次提供的功能实现用户界面[3]。
基本库(Glibc)、X核心系统已经对Unicode字符编码标准提供了较完整的支持，参考文献[3,4]。图形构件库目前还存在较多问题，其中，QT是Linux／KDE桌面系统的图形构件库的著名开源项目(本文针对QT3．3版本)。QT提供了兼容不同国家文字的国际化文本处理流程，即QT国际文本处理引擎。但是，由于QT内部编码系统使用UCS－2，QT国际文本引擎不支持非BMP平面的字符。扩充QT系统不仅对于支持藏文扩充集B是必要的，而且对于支持非基本平面的其他字符集，如CJK Extension B字符集也是必要的。
5 在QT上添加藏文扩充集B的支持
藏文扩充集B相对藏文扩充集A、藏文基本集来说，具有一定的特殊性：藏文扩充集B位于ISO／IEC 10646标准OF平面，这对于软件系统的编码空间支持提出了较高的要求。对于仍采用16位编码系统的软件来说，由于其编码空间的局限(最多容纳216个字符)，这类软件系统无法支持藏文扩充集B。
实现ISO／IECL0646标准辅助平面的支持通常采用UTF-8、UTF-16和UTF-32三种不同的内码方案，编码范围都是0x0～0x10FFFF。UTF-8和UTF-16是变长的编码方式，UTF-32是定长的编码方式：UTF-8占用1～4个8位编码单元；UTF-8占用1～2个16位编码单元；UTF-32占用1个32位编码单元。
UCS-2编码是定长的编码，通常在计算机中占用2个字节。UTF-16兼容UCS-2编码，即：同一字符的UCS-2编码与UTF-16编码相同。UCS-2和UTF-16的编码单元长度虽然都是16位的，但是它们的编码范围存在很大不同。UTF-16通过sur―rogate pair[10]机制来表示0x100000～0x10FFFF码点区间，其具体映射关系如下：
其中WWWW＝uuuuu－1。码点区间0xD800～0xDFFF被保留来构成surrogate pair。扩充平面的第一个码点Ox10000的UTF-16内码是0xD800DC00；扩充平面最后一个码点0x10FFFF的UTF-32内码是0xDBFFDFFF；由此我们可以看出，surrogate pair的高2个字节(High Pair)变化范围是0xD800～0xDBFF，低2两个字节(Low Pair)的变化范围是0xDC00～0xDFFF。
下面我们通过分析如下的QT代码段，找出其 中存在的问题，并研究对QT系统进行扩充的方案。
上述的代码对字符数组str中的每个元素依次调用visit函数，程序中使用了2个重要操作。
(1)字符定位操作：在UCS-2的情况下，定位后一个字符通过++运算符来完成。
(2)取字符操作：在UCS-2的情况下，取字符编码的操作通过*运算符来完成。
这个程序存在的问题是：
(1)程序中使用了++运算符、*运算符，但是这样的程序书写格式，通常只适用于定长的编码方式，不适用于变长编码的处理。
(2)数组str元素的类型是unsigned short，编码长度通常为16位。因此，该程序使用的是UCS-2编码。受编码长度的限制，该程序无法兼容Uni―code非基本平面字符。
下面我们来分析UTF-16和UTF-32两种方式扩充示例程序的复杂度。
5.1 使用UTF-16扩充QT的复杂性
从Unicode编码方案的兼容性角度来说，UTF―16是兼容UCS-2，并扩展了UCS-2的编码方案。因此，将QT内码改造成为UTF-16应该是可行的，并且保持与原有系统的兼容性。但是，从实际可操作性上来说，此方案存在较大的软件实现复杂性。
(a)字符定位操作
UTF-16是变长的编码方式：对于基本平面内字符，需要1个16位编码单元；对于扩充平面字符，需要2个16位编码单元。因此，不能使用++运算符来实现字符的定位操作。
对于UTF-16编码来说，定位后一字符的接口定义如下。
(b)取字符操作
在处理UTF-16时，插入符位置和光标移动是常见的问题。在显示时，需要进行调整以避免将4字节的surrogate pair显示成为两个双字节字符。对于UTF-16编码来说，需要提供单独的接口来实现取字符编码的功能。
对于UTF-16编码来说，取字符编码的接口定义如下。
使用UTF-16编码方式，应用自定义接口utf16_next_char、utf16_get_char来实现指针定位操作和取字符操作，QT代码段改写如下。
采用UTF-16编码方式，需要将程序中原来的处理UCS-2定长编码的操作符，替换为处理UTF-16的变长编码的用户接口。这样的扩充方法导致代码修改量非常巨大，扩充难度很高。究其原因，是由于将处理定长编码程序升级到处理变长编码程序所带来的复杂性。
5.2使用UTF-32扩充QT
为了避免上述复杂性，我们使用Unicode标准的定长编码方式UTF-32来实现QT对非BMP平面字符的支持。UTF-32使用4字节来表示Uni―code中的码点。需要改变的是数据类型的声明，而无须改变程序细节：通常，使用unsigned short来表示UCS-2编码；使用unsigned int来表示UTF-32编码。
下面是使用UTF-32编码方式，对QT代码段进行的修改。
在QT中，需要修改类型的地方包括：程序参数类型、函数局部变量类型等。原有QT程序中的对UCS-2编码的一切操作，如：指针操作(如++，--运算符)、取字符操作(*运算符)，对于UTF-32编码表示的字符类型，同样是有效的。
采用UTF-32编码方式扩充QT，使升级的复杂度大大地降低。
5.2.1数据结构的变化
字符在QT中的表现形式是QChar对象，即：每一个QChar对象对应着一个UCS-2的字符。QChar类的定义如下所示。
每个QChar对象代表一个用UTF-32的字符。不难发现，这种修改方案保持了QChar类的语义，即：一个QChar对象代表一个字符。对于使用QChar的程序，其程序语义保持不变，扩充代价较小。
5．2．2补充非基本平面Unicode字符的属性
在处理文本时，不仅需要明确文本中的各个字符的码点，还需要知道文本中各个字符的属性值。IS010646标准定义了一系列字符属性：文字属性(Script)、方向属性(bc)、组合属性(CCC)、gc属性(General_Category)、Ib(Line_Break)属性等。更详细的描述可以参考文献[10，14]。文本处理程序使用字符的属性值，来实现双向算法(BidirectionalAlgorithm)、格式化文本等的处理。
QT并没有提供非BMP平面字符的属性值，而藏文扩充集B位于非BMP平面，为了满足IS010646标准的字符语义要求，需要补充藏文扩充集B的字符属性。
5.2.3字体匹配
QT文本处理引擎先根据Unicode字符的方向属性(bc)和文字属性(Script)对文本分段(Itemiza―tion)，然后再分别处理这些段[13,15]=(Item)。每个段(Item)是按照相同方向(如：LTR、RTL)来输出的、具有某种文字属性的文本块。通常不同的段所使用的字体不同，在光栅化之前，需要先确定输出段(Item)时所用的字体。QT利用段(Item)中的字符的sc属性，来匹配输出该段的字体，具体步骤是：由该段中字符的sc属性，获取与sc文字所对应的特征字符；然后用这个特征字符，去遴选输出该段(Item)的字体文件。在QT中，藏文的特征字符是OxOF00，汉字的特征字符是0x4E00。
这样的字体匹配逻辑有较大缺陷，分析原因有以下两点：
(1)由于字符集标准仍处于不断修订中，因此每个字库一般都不可能包含某种语言的全部字符。按照特征字符匹配的字体文件很可能只包含该语言的部分字符。
(2)处理同一文字的文本信息，可能使用不同的字体技术。例如，藏文标准集、藏文扩充集收录的都是藏语字符，但是这两个字符集对字体技术要求是不同的。前者需要OpenType字体技术处理连字(Ligature)；后者只需要传统的字体技术。
我们的修改策略是：不仅要考虑字符的sc属性，并且依据输出该字符所用的字体来分段。即：每个段(Item)，它所包含的字符的sc属性相同，并且输出时使用的字体一致；字体匹配是在分段的过程中进行。字体匹配逻辑进行了较大的调整与修改，主要体现在：(1)用将要输出的字符遴选字库，而不是用固定的特征字符遴选字库；(2)添加了对复杂文字[16]的OpenType字体检查。
6 总结
本文首先介绍了藏文字符集标准，比较了两个字符集在软件实现上的差异性，然后针对藏文扩充集标准，分析了两种不同编码方案(UTF－16、UTF－32)及其实现的代价，最终给出了基于UTF-32编码的系统扩充方案，阐明了字体匹配的修改策略。
我们基于QT国际化文本处理引擎，应用UTF-32编码方案，实现了国家标准藏文扩充集A、藏文扩充集B的支持。本系统的运行环境是Red―hat Fedora 3.0，使用的底层库是QT-3.3.2，开发完成后经过大量测试。由于QT已经可以处理藏文基本集字符，集成了该系统后，在Linux上已经可以正确支持藏文基本集、藏文扩充集字符的文本，并且支持CJK Extension B字符集、其他非BMP平面字符。
注：“本文中所涉及到的图表、注解、公式等内容请以PDF格式阅读原文”