|
|
2005-8-31 21:22
字符描述语言（CDL----Character Description Language）说明文档
（ISO/IEC JTC1/SC2/WG2 IRG N985）
（本文在有女同车的节译基础上翻译编辑而成，有女同车的原文地址：http://www.pkucn.com/viewthread.php?tid=151934）
（英文原文在：http://www.cse.cuhk.edu.hk/~irg/irg/irg21/IRGN985_CDL_Specs.pdf）
引言
字符描述语言（CDL）是为了精确地描写和显示所有中日韩越（CJKV）汉字“字形”而设计的。作为第一个发表的CDL说明文档，本文将介绍CDL语言的主要特色和句法，并讨论它的一些应用，特别是字符编码标准方面的工作。我们建议采用CDL作为数据处理工具以确保公共字符编码处理的准确度和长期的稳定性。
汉字是一个开放型的字符集，而不象英语只有26个字母构成的封闭集合。各种各样不同写法的古字和异体字数量巨大，根本不能简单的跟现在的编码形式对应起来。现在国际标准化组织的象形文字小组（IRG）正在为千百万个汉字进行分析鉴定，用以包括进CJK统一象形文字扩展集C1。基于以上事实，我们迫切需求一种字符描述语言（CDL）。
字符描述语言（CDL）基于Unicode、XML语言和少量大家熟知的汉字的特特征：
• 大多数的汉字由两个或多个相对简单的“字”或“部件”构成一个方块。
• 基础汉字和部件由笔划构成，所有的笔划皆可按现行正字法传统进行分类。
•笔划类别的确认是笔划数统计的基础。
• 笔划类别、笔划数和部件分析是学习过程、字形识别、索引和异体字较的基础。
不超过50个笔划类型的笔划集就足以构造几乎所有现行印刷体汉字，目前CDL已能对超过4万个汉字的描述，这包括所有基本多文种平面（BMP）汉字和超过1万两千个扩展集（EXT-B）汉字。
CDL字形数据库
一个汉字的CDL描述就是对该字拆解为组成部件和/或笔划进行编码，同时提供字符显示的指示信息。因此，一个CDL描述的集合既是一个数据库又是一个字体。
当CDL被用做字体格式，一个软件解释器可将CDL描述实时转换成字形。对汉字而言CDL还有一些优于传统字符格式的特点。比如它比较小，在压缩状态下，平均每个汉字只用12字节的编码。CDL描述有可变的参数，因此同一个CDL描述可以生成不同风格的字型，从这种意义上说，它是一种“元字体”（meta-font）。新的字形被加入字体文件（数据库）相对要快捷简单许多。由于相关的汉字共享构字部件，因此也很容易确保其字形上的一致性。
作为一种数据库语言，CDL对分类、索引、学习和识别汉字的基本信息加以“编码”。这些信息包括笔划数、笔划类、笔顺、部件拆分、部首和除部首外剩余部分、笔划及部件的坐标。
当这些信息被存储在常规数据库中，CDL的格式能更好地保证一致性。例如。笔划数是按着实际的CDL书写汉字的指示信息一笔笔通过算法计算出来的，而不仅仅是根据个人印象或是从不同的的字典中照抄，这些词典本身对某个具体部件的笔划数互有出入（或单个词典本身缺乏一致性）。
实例
这是一条对汉字“行“的CDL描述，它被分解成部件“彳”和“亍”：
<cdl char="行">
<comp char="彳" points="0,0 40,128" />
<comp char="亍" points="60,12 128,128" />
</cdl>
部件的位置用二维坐标点给出。容纳整个字的方框是一个（X，Y）坐标定位的平面空间，从左上角的0，0到右下角的128，128。这个方框分成两部分，“彳”后面的数字描述了“行”字左半个方框：左上角0，0，右下角40，128。类似的，“亍”后面的数字描述了 “行”右半个方框。
为了使上述CDL描述作为指令集实现（例如，显示字符或计算笔划数），有必要让程序解释器调用部件“彳”和“亍”的单独描述，也就是这两个部件的特定笔划类型和特定坐标的CDL描述。以下是对“彳”的CDL描述：
<cdl char="彳">
<stroke type="p" points="107,0 10,46" />
<stroke type="p" points="128,38 0,83" />
<stroke type="s" points="86,70 86,128" />
</cdl>
“彳”由三笔构成，头两笔都是P类，P代表“撇”，向下的弧线。第三笔属S类，S代表“竖”，下垂的直线。每一个简单笔划只需要两个坐标点。比如第一笔起始点在（107，0），收尾点在（10，46）。
有些CDL描述是部件和笔划的组合。这里，汉字“太“被描述为部件”大“（“大”本身就是一个字，它也拥有自己的描述），和一个笔划类d（点）
<cdl char=" 太">
<comp char="大 " points="0,0 128,123" />
<stroke type="d" points="45,98 66,120" />
</cdl>
语言细节
CDL是XML的应用，这意味着，CDL遵循被广泛使用的XML标准句法（如使用尖括号< >等）。我们已经介绍了大部分组成CDL语言的元素。每条CDL描述包含在<cdl></cdl>元素对里面，<cdl></cdl>对可以包含任意多的部件元素<comp>和/或笔划元素<stroke>。还有一种类型的元素，cdl列表元素<cdl-list>，包含一个描述列表（或文件、字体、或数据库）。现已定义的CDL元素就是如下四个：cdl-list, cdl, comp, 和 stroke。cdl 和 comp元素都具有char（字符）属性，典型的情况是表示为一个汉字——UTF-8编码或任何xml所支持的编码。任何一个字符原则上都可被当成部件使用。
笔划元素<stroke>有一个<type>属性，它的值就是CDL所定义的50来个笔划类的字母代号。本文已介绍了 “P”（撇）等几个。最复杂的一个笔划类是“hzzzg”，名横折折折折钩，如“乃”的折笔。它有6个参考点，包括其试点和结束点之间的4个转折点。每个笔划类的主要特征是：名、所用参考点数和参考点间的曲线的方向和曲率。完整的CDL笔划说明档在另一篇文章中。
CDL暗示着一种递归的模型，比如，“龍”字的描述可能会调用（带部件标记<comp>）“立”的描述，而“立”的描述会依次调用（带另一个部件标记<comp>的）“亠”的描述，而“亠”最终由两个笔划“丶一”来描述。因此，CDL软件解释器通常要使用递归算法推溯部件中的部件中的部件（并且根据方框的包含关系缩放相对坐标），当最终推溯到笔划元素时，递归才算终结。
任何使用了部件元素<comp>的描述都能被自动转换成只包含笔划元素<stroke>的描述。例如，“行”由“彳”和“亍”两个部件的序列来描述，每一个部件进而又依次被三个笔划的序列所描述。换个方式，“行”也可以直接被6个笔划的序列所描述。一个直接的递归算法可以将部件描述转换成“纯笔划”描述，反过来则要困难得多。部件描述有更广泛的应用而且更简洁。
提高字符集的精确度和扩展字符集的广度
跟最大的标准字符集相比较，CDL具有了更高的精确度：具有区分被规范统一了的异体字的能力。它也具有更广的涵盖范围：潜在的无穷个数的汉字。
CDL能够描述和显示在标准汉字集里被认为等同的异体字。比如，在Unicode U+8005有两个形式的“者”，另一个在“日”的上方还多了一点，这两个形式被认为是等同的，但可以用CDL能很容易区分开来。CDL还能用于描述和显示不在任何标准字符集里面定义的汉字，有些可能只是没有被定义，有些可能是新字，也有些可能是使用范围太狭窄了，根本没有必要收进任何标准的字符集里面。
需要时，我们可以编写用于显示汉字的CDL指令（最好使用GUI用户图形界面），并用XML句法包直接括进一个文档里面。当然，显示文本的程序应该有解释CDL语言的能力，也许使用一个插件（PLUG-IN）或者助手（HELPER）的应用程序，人们在阅读文本的时候，看到的只是字符图形，而不是CDL标记。
为字符集标准化提供数据管理
通过同时产生（元）字体和数据库，CDL能够让标准化组织发表代性的、相互一致的字符和笔划数（等等）。而且，该语言能够系统化处理复杂而困难的规范字和异体字问题。现在这种系统化处理因缺乏抽象“字”和具体的“图形字”（或者特别指书写/印刷的例子）之间的中介代表。每一个Unicode编码码位代表一个抽象的字，这相对应于潜在的无穷数量的图形字。图形字作为字的实例是有用处的，但是实践上不可能让一个算法确定一个图形的笔划数，或者根据汉字的规范标准来衡量两个图形之间的相似程度。结果，目前已经有7万多汉字已经编码，很难确定某一个给定的字符是否对应于任何已经编码过的汉字。由于时代、地区等原因，多个异体字可能各自有编码，也可能多个异体字只用一个编码，后者就如上文提到的“者”字。这种一对多、多对一情况确实造成两方面的困难：一是查找某一个字的所有可能的异体字的码位；二是对于每个这样的码位，根据规范原则判定某字符是否属于那个码位隐含的等价类异体字。
CDL能够帮助解决上面提到的这两个困难。CDL可以为所有已经编码的汉字建立数据库。每一个字可能有多个CDL描述，相对应于已经被规范统一的每个变体。然后，当我们遇到一个字符，如果不确定这个字符是否已经有了编码，你可以为这个字建一个CDL描述，并且运行一下程序跟数据库中已经有的描述进行比较，查找最接近的匹配。（几个不同的比较算法可以运用于同一个字，有些根据笔划，有些根据部件。）当然，完 全匹配似乎不太可能，但是一些坐标或者笔划顺序上的细微的差别很容易被认出来，更细微的差别还要求专家的判断，但是CDL将使专家们更容易的一贯的使用规范规则。比如，是否决定将一个新字符作为一个已经编码的字符的隐含变体，尽管这个新字跟已经编码的字符在自行上有一些差别，但是CDL仍然可以将该新字符作为已经编码的老字符的变体加进数据库。因此提供一种先例，从而使统一规范的规则更加清楚明白，同时也便利将来使用该数据库。
起源于现状
CDL最初由本文的作者之一设计并实现（用C编程语言），同时它还是文林公司出版的文林汉语学习软件的一个部分。最初的应用程序是文林的“笔划盒”，它用来为学习者用很慢的动作演示如何一笔一划的写一个汉字。把它作为普通的可以缩放的字体来使用速度也够快。同时它还提供笔划数和笔划类型的信息，甚至还用于手写汉字识别。然而，用户看不到CDL语言本身，只看到一笔一划画好了的汉字。文林实际上用一种压缩了的二进制格式，相当于XML格式，但是更加紧凑和快速的用于机器处理。文林的CDL用于为ABC 汉英理解词典（ABC Chinese-English Comprehensive Dictionary）的9638个汉字创建打印的偏旁和笔划顺序索引，该词典由夏威夷大学出版社出版于2003年（ISBN 0-8248-2766-X）。
到2003年10月份为止，已经有4万多汉字已经有CDL描述，包括所有Unicode 3.0中的所有汉字（加扩展A）和许多属于Unicode 4.0（扩展B）的汉子。这些cdl描述有本文作者写作的。
结论
实践证明，CDL语言对于系统处理汉字是很有用处的。毫无疑问，人有许多有待改善的空间，但是笔者相信（有几位Unicode技术委员会委员的鼓励）它应该为国际社区的福利而公开出版。
参考文献
这篇文章的最近的更新，其他有关CDL（包括笔划类型列表和一个DTD），可以在http://www.wenlin.com/cdl找到。
Unicode协会的网址是http://www.unicode.org，象形文字工作小组（Ideographic Rapporteur Group，简称IRG）的网址是http://www.cse.cuhk.edu.hk/~irg，XML（可扩展标记语言，Extensible Mark-up Language）的http://www.xml.org和http://
www.w3.org/XML两个网址上有说明。
后记
1. 元字体（meta-font）的概念最初来自于METAFONT语言（Donald Knuth的一本书METAFONT里面有详细的论述，1986年出版，书号ISBN 0-201-13445-4）。尽管CDL语言跟元字体并没有紧密关系，不过有一个过程将CDL描述转换成元字体，但目前只在字符轮廓精密确定的低层次。一个相似的过程将CDL转换成PostScript语言（PostScript是Adobe公司的商标；见http://www.adobe.com）
2. 所有的坐标都是在0到128范围内的十进制整数。CDL很容易被扩展成允许浮点数和/或不同的坐标范围。然而，使用小整数和2的幂比如128很容易压缩存储，即使在很慢的机器上也能很快速的处理显示，并且精确度更高。更加复杂CDL语言版本将允许符号变量名、代数表达式来表示坐标点。应该可能从这种“高级”版本的CDL语言自动转换到基本的只使用数值坐标的“低级”版本的CDL语言。为此目的，用较低的精度来描写部件和笔划的位置信息似乎更加方便一些，比如用粗糙的指示信息比如上、左、左上、中，等等；应该有一些工具在这种粗糙的指示信息和精确的坐标数值之间来回转换。
3. 有关坐标和部件空间（bounding rectangle，有界方框）需要一些澄清。一般情况下，一个笔划的参考坐标点会在该笔划里面，大约在一个想象笔划的头部，对于一些较粗的笔划，起笔的位置会离开参考坐标点的中心较远。不同的字体风格，笔划的长短粗细着墨深浅会不同，同一个CDL描述用不同的软件解释器，或者同一个软件解释器但是用不同的参数，显示的结果会不同。我们所指的部件空间仅仅根据参考坐标点；“额外着墨”可能超过这个方框边界大约半个笔划那样粗细。
4. 为了更容易理解，双人旁“彳”的描述已经被稍微简化。更好的描述可能要用到<cdl>标记符的可选属性<points>，也就是用标记<cdl char = “彳” points = “24, 0 104,128”>，而不是用<cdl char = “彳”>。这表示，当一个构字部件单独显示，它不占据整个字符的空间，而是两边都留一些空隙，显得相对较高和较窄。当它（或者任何字符）用作为一个字的组成部件，因为<comp>标记本身有<points>属性，这些点的属性被忽略。笔划坐标点应该总是使一个部件碰到方格子的四个边沿，所以在应用任何缩放以前，部件空间坐标应该是0,0 128,128。对“口”字来说，<points>属性甚至更重要，因为他的四边都占据很大的空间；但是“因”字如果四边留的空间少一点会比较好看。如果任何字符有一个笔划伸出了边界，那一边多留一些空间会比较好看（尤其是并列结构的汉字）；因此“相”可能有一个坐标点属性<points = “0,0 124,128”>。
5. 作为<char>属性的替代，或者作为附加，CDL支持一个<uni>属性，它的数值是一个十六进制Unicode标量值（Unicode Scalar Value，简称USV）。比如，<uni = “592A”跟<char = “太”>的含义是一样的。同时具有<char>和<uni>属性有点冗余，但有使用起来比较方便。如果两个同时使用，那么它们应该是一致的。除<char>或者<uni>属性以外还可以使用一个可选的<variant>属性，用来关联那个用于区分一个USV的多重描述的字符串。
6. 有一个被广泛使用的方法，那就是“札”字法，它将所有汉字的笔划归纳为五大类：一丨丿丶乛（横竖撇捺折）。每一个CDL的笔划类型都属于“扎”字法笔划类别中的一种。
7. 笔划元素有一个<head>和<tail>属性，分别用于描述起笔和终笔的坐标点的细微变化。这种细微的变化对有一些字体风格是很重要的，尤其是在笔划连接处。当然对一些很简单风格的字体和许多CDL应用程序，它完全可以被忽略。
8. 对于一些部件还没有编码的问题，解决方案之一是，用<cdl>标记里面嵌套标记的递归形式来描述。另一个解决方案是，给这个没有编码的部件分配一个用户自定义区码位，并在同一个数据库里用<comp>标记给出不同的描述。后一种解决方案比较有优势，因为同一个部件可以用于多个字符中而不会有多重的描述，最理想的当然有CDL能使用的有标准编码（而非用户自定义）的部件。
9. 另外还有一些可选的属性（比如偏旁属性<radical>用于指定一个汉字里哪些笔划是偏旁），这些问题不在本文的范围。
10. 事实上，在Unicode里跟U+8005“者”相关的包括两个兼容字符，一个是U+FA5B另一个是U+2F97A。它们的区别就在于多了一个点。
11. 如果CDL描述有大差别，我们才将它们区分“变体”。（坐标点的细微差别被看作是细小的差别。）如果一个统一字有两个或更多的不同的CDL描述，我们就称互相称它们为“变体”，没有任何意思要做相关的更正或认为对方不正规，因为这些特点一般来自于不同的地区、不同的文本环境或上下文关系、和/或阅读者的眼睛。
12. 当CDL不能解决汉字规范和变体的所有困难，它能采取主动式原则和程序更具有理性。仅仅是为现在已经编码的汉字制定一套内部统一的偏旁和笔划数的索引的能力就是相对来说比较先进的。认为笔划数总是模糊不清的观点是错误的，当人们查找一个汉字，第一次笔划数计算结果出错，她总是随时准备加一笔或者减一笔重新查找。相反地，在有些地区，比如中华人民共和国，在这方面已经花了不少的功夫。有些政府部门的出版物《现代汉语通用字笔顺规范》（ISBN 7-80126-201-8）不仅为上万个汉字规范了笔划数还规范了笔顺和笔划类型。一个字的笔划数通常跟另一个字的笔划数相关，因为大多数汉字有部件构成，只要这些部件的笔划数确定了，把这些部件的笔划数相加起来得到一个组合的笔划数应该是没有任何困难的。因此，一个标准定义了少数几千个汉字的笔划数，也就等于定义了剩余的汉字的笔划数。
13. 在不同的国家，甚至在同一个国家有一些互相冲突的汉字笔划的写法，在Unicode里却被统一了。在字符属性<char>（或则<uni>）之外使用一个变体的属性<variant>，一个标准的CDL数据库能够包括一个统一汉字的数个变体，这些变体可能有不同的部件或笔划。有一些“变体选择器（variant selector）可以用这种方法给出精确的含义。是否要将某一个变体跟特定的地区联系起来是另一个问题，也许最好由各地区分的应用程序分别确定；一个国际的标准之简单的指定变体选择器对英语CDL的那条描述。
14. 一些使一个小型的DTD（文本类型定义Document Type Deinition）; 它省略了一些本文提到的可选的或者试验性的的属性。
<?xml encoding="UTF-8"?>
<!ELEMENT cdl-list (cdl)+>
<!ELEMENT cdl (comp|stroke)+>
<!ELEMENT comp EMPTY>
<!ELEMENT stroke EMPTY>
<!ATTLIST cdl
char CDATA #IMPLIED
uni CDATA #IMPLIED
variant CDATA #IMPLIED
points CDATA #IMPLIED
>
<!ATTLIST comp
char CDATA #IMPLIED
uni CDATA #IMPLIED
variant CDATA #IMPLIED
points CDATA #IMPLIED
>
<!ATTLIST stroke
type CDATA #IMPLIED
points CDATA #IMPLIED
head (cut|long|corner|vertical)#IMPLIED
tail (cut|long) #IMPLIED
>
（盛金标编译于2005年8月31日星期三） |
|
