简繁转换工具的设计与实现

  简繁转换工具的设计与实现

简繁转换工具主要需要完成两个功能：1)简体转繁体。2)繁体转简体。从OMC-S以及公司其他应用系统目前的需求来看，主要是有简体转繁体的需求。那么，下面我们就着重介绍简体转繁体功能，繁体转简体方法可以举一反三，基本雷同。

正如本文开篇所言，简体转繁体需要解决以下两个问题：1)语义问题。2)编码问题。

3.1编码问题

在研究简繁转换问题的过程中，我们惊喜地发现一个非常简单的方法。我们似乎可以从GB2312、GBK、Big5这三种编码的异同点发现些什么。

从字符集的角度简单的看，GB2312只包括简体汉字，Big5只包含繁体汉字，而GBK字符集是GB2312和Big5字符集的超集，则包括了简体汉字和繁体汉字。UCS字符集则是GBK的超集，包括了所有国家的字符集。由此可以看出，GBK字符集包含了Big5的字符集，Big5中的繁体字和GBK中的繁体字存在着一一对应得关系。如下图所示：

图3.1　各种字符集包含的字符的包含关系

从编码原理的角度看，GB2312、GBK、Big5编码最终都对应着相应的机器码，同时，在Unicode编码中，三者的字符在Unicode中的对应的字符也有相应的编码。如下图所示：

                                                                      图3.2　各种字符编码的对应关系

我们知道，GBK中的简体字编码和GB2312中的简体字编码完全一致，对应的Unicode编码也完全一致。但是GBK中繁体字和Big5中的繁体字属于两个编码体系，编码完全不同，那么，会不会GBK中的繁体字和Big5中的繁体字对应的Unicode编码会是一样呢？通过实验证明：的确一样！

以“我”、“们”这两个字为例，“我”字在gb2312、gbk、big5字符集中的字型完全一样，所以GB2312、GBK、big5这三种编码中的“我”字对应的unicode都是[/u6211]。“们”字情况就不同了，gb2312的“们”和GBK简体的“们”对应的unicode一样，都为[/u4eec]，而GBK繁体和Big5繁体对应的unicode一样，都为[/u5011]。如下表所示：

 

	GB2312	GBK简体	GBK繁体	Big5
中文字符	我	我	我	我
对应的Unicode编码	/u6211	/u6211	/u6211	/u6211

 

	GB2312	GBK简体	GBK繁体	Big5
中文字符	们	们	們	們
对应的Unicode编码	/u4eec	/u4eec	/u5011	/u5011

 

根据上面的分析，再通过归纳法证明，可以得出如下结论：

1)         GBK字符集中的繁体中文和Big5字符集中的繁体中文，他们在UCS字符集中是重叠的。

2)         对同一繁体中文字符，GBK编码和Big5编码所对应的Unicode编码是一致的。

如下图所示的几大编码的内在关联关系：

                                               图3.3　各种字符对应的Unicode编码

由以上分析可见，我们可以用以下代码实现GBK繁体->Big5繁体编码的转换，非常简单的解决简繁转换的编码问题。

BufferedReader srcbuffer = new BufferedReader(new InputStreamReader(

                                      new FileInputStream(inputfile), "gbk"));

BufferedWriter outbuffer = new BufferedWriter(new OutputStreamWriter(

                                     new FileOutputStream(outputfile),"big5"));

while ((dataline = srcbuffer.readLine()) != null) {       　

outbuffer.write(dataline);                                  

　　　outbuffer.newLine();

}

值得注意的是，以上简繁转换的前提是：所有GB2312或者GBK的简体字都必须先转换成GBK的繁体字，然后才可以利用上面的代码自动完成GBK繁体到Big5繁体的内码转换。

 

3.2语义问题

正如文章开篇所言，简体中文与繁体中文之间并非简单的一对一的关系。根据转换的精确等级，简繁转换大概可以分成4个层次：

   

 1. 字符或者码表的一对一映射。 比如：  

简体	GBK	繁体	BIG5	其他可能
出	B3F6	出	A558	齣
发	B7A2	發	B56F	髮

 

   2. 对于一对多单字，根据词语识别进行转换。

简体词语	繁体词语
老板	老闆
黑板	黑板

    

3. 对词语表达方式差异的转换。

英文	简体表达方式	繁体表达方式
bit	位	位元
byte	字节	位元組

 

     4. 根据上下文的词汇翻译。

有一些词，是需要根据上下文才能够准确地决定如何翻译的。比如在中国大陆的语言习惯中，“文件”可以是通常意义上的“文件”，也可以表达计算机磁盘中存取的“文件”（document）。但是，在繁体用户的语言习惯中，这两个东西就是分别用两个词来表达，通常意义上的“文件”和在电脑磁盘中保存的“档案”。

该层次的翻译需要根据上下文的意思对文章进行断句，分析。因此，是属于繁简互译中最难做的，而且消耗的系统资源也最大。

 

简繁工具中对语义问题的解决方案为：应用一个匹配词库，再应用一种匹配算法，根据词库应用“最大匹配法”将大陆简体翻译成台湾繁体。这种方案至少可以做到前三个层次的翻译准确度。对于需要上下文才能确定如何翻译的问题，简繁工具的解决方法是，用尽量能包括上下文语境的短句作为词库的词条，然后再用最大匹配法来优先翻译该短句。从原理上讲，只要我们能找到所有语境上下文短句，我们就能保证翻译的正确性。所以，解决语义问题最终需要涉及做好两方面工作。

1)       匹配词库

2)       匹配算法

3.2.1匹配词库

为了解决语义问题，我们需要建立一个词库，来记录大陆和台湾的语言差异。

词库需要包括两部分:

1)       一对一的单字匹配

2)       词组匹配和短句匹配

词库的格式可以简单的表示为：

后	後
板	板
皇后	皇后
老板	老闆
因特网	網際網路
数据库	資料庫
用户	用户
用户手册	使用者手冊
…	…

 

由此可以看出，要维护好这个词库的工作量非常大：

1)       需要覆盖到所有常用简体汉字到繁体汉字的一对一单字匹配

2)       需要覆盖到所有大陆和台湾语言差异的词组和短句

有了这个词库，我们就可以很好的解决大陆和台湾的语言差异问题。解决一对多问题的方法是，对每一个简体汉字，默认的对应一个繁体汉字，该字”一对多”问题对应的繁体汉字，则通过词组优先匹配（最大匹配算法）来解决。比如，“后”字，默认对应“後”，但是如果出现“皇后”这个词，则优先将皇后匹配成”皇后”。

如果出现需要语境才能确定的翻译，我们可以根据经验，逐步将语境短句加入词库中，然后采用最大匹配法优先匹配。比如，词库中有一词条为：

选中->點選

但是我们翻译这句话：“目前正值台湾大选中…”这句话就会出错，会翻译成“目前正值臺灣大 點選…”，避免的方法就是将“大选”也作为一个词条加入词库，如果大选还不能代表语义，我们可以更细化到用“台湾大选”来作为一个词条。

所幸的是，目前网络上已经流传了一些比较经典的词库，比如一位名叫kiiali的网友提供的cpatch词库，基本涵盖了目前常用IT行业的词库。我们只需要根据实际需求再往这个词库里面增加完善即可。

3.2.2匹配算法

有了匹配词库，我们还需要设计一种匹配算法，来实现把大陆简体中文替换变成台湾繁体中文。

简繁转换工具借鉴了目前在搜索领域（比如Lucene）比较流行的“正向最大匹配法”来实现，设计匹配算法必须考虑以下几个问题：

1)      词库中的词条存在关联关系。

比如，词库中有这样两条：

进程->程序

程序->程式

如果我们碰到进程这个词，如果一条一条的根据词库来翻译，那么进程-〉程序-〉程式，最后进程将翻译成程式，这和我们的初衷不符合。

解决方案： 对原始字符串寻找匹配对象，一旦发现了匹配的词组，那么就必须跳过这个词，则跳过从这个词组的下一个字符开始继续寻找。如果没有寻找到任何匹配的词组，则跳过这个单字。

2)      词库中简体中文和繁体中文的词条长度不等。

比如词库中有一条词库为：

门限-〉臨界值

如果我们匹配到门限后，将其替换成臨界值，然后再向后移两位，从”值”字开始，这是错误的。

解决方案： 匹配到词库后，向后移的位数必须以台湾词条的长度为准。比如本例匹配成功就往后移三位，因为”臨界值”的长度为三。

3)      词库中存在同一个词组长短不一的两个词条。

比如词库中存在两条词库：

用户-〉用户

用户手册-〉使用者手册

如果我们先将用户匹配成用户，那么用户手册可能就会翻译成用户手册，而不是使用者手册。

解决方案： 采用“最大匹配算法” ，需要先匹配词库中较长的词条，如果没有匹配到，再去寻找短一个字符的词条，直到匹配完以这个字符开始的所有长度的字符串（子字符串的最大长度不超过词库中最长的词条的长度），当然，如果一旦寻找到匹配的词库，则跳出本次寻找过程。

3.3.3匹配算法流程

图3.4　匹配算法流程

经过这个转换，我们可以把类似“老板皇后后面是黑板”的句子转换成“老闆皇后後面是黑板”，然后我们再根据３．１节讨论的方法，轻松的将结果由GBK编码转为BIG5编码，达到我们翻译的最终需求了。所以，简繁转换工具对字符串转换的总体流程可以表示为：

图3.5　字符串转换总体流程

3.3.5匹配算法问题

最大匹配法在搜索领域是用来切割分词的，尽管最大匹配法是很好的解决的方案，但是无疑它存在很多明显的缺陷，最大匹配法的问题有以下几点：

1)       　　长度限制　

由于最大匹配法必须首先设定一个匹配词长的初始值，这个长度限制是最大匹配法在效率与词长之间的一种妥协。

ü        词长过短，长词就会被切错。

ü        词长过长，效率就比较低。

2)       效率问题

效率低是最大匹配法必然会来的问题，因此我们必须要在词长与效率之间进行妥协，既要求匹配尽量准确，又要求我们的词长不能太长。我们可以取一个中间值来操作（比如８），但是无疑，这同样需要浪费很多次匹配，特别是大多数词条可能是２个字的词组时，至少有６次匹配算法是浪费掉的。

3.3.5匹配算法优化方案

1)       根据词库中的最长词条来确定最大匹配法的最大长度。这样可以保证所有翻译的正确性（在效率和正确性出现冲突的时候，以正确性优先）。

2)       利用层次网状结构存储词库。如下图所示

这种存储结构类似于层次数据库，每一个节点存放有父亲节点和根节点，查询的时候，根据首字符来进行匹配，知道匹配到有蓝色底纹的字符。这样存储方法，可以直接排出对其他字符的寻找。从而节省时间。

 

4．       OMC-S繁体中文版的实现

OMC-S 即公司的网络管理系统交换部分，OMC-S系统繁体中文版文字主要采用以下两种方式保存：

1)       Bundle 资源文件

2)       SQL 脚本

另外有部分代码由于历史原因存在硬代码，需要单独处理。

4.1 Bundle资源文件转换

                                     图4.1　 Bundle资源文件转换

　OMC-S系统绝大部分资源文字都是存放在资源文件中的，从上图可以看出来，系统采用了java.util.ResourceBundle这个类来实现多语言的支持。ResourceBundle可以根据Locale的取值来判断选择对应得资源文件。同一个语义资源按语言分为三个文件来存放，按照文件结尾来区分：

1)       英文资源文件的文件结尾为en_US.properties

2)       中文简体资源的文件结尾为zh_CN.properties

3)       中文繁体资源的文件结尾为zh_TW.properties

有了GBK2Big5 Converter这个工具后，我们可以轻松的通过简体中文版自动生成繁体中文版。

GBK2Big5 Converter 在这里充当的是翻译功能，可以将简体中文的资源文件翻译成big5编码的繁体中文资源文件，然后再利用JDK自带的native2ascii工具自动生成unicode编码的文件。Client通过Locale来判断使用那一个资源文件。

GBK2Big5 Converter 不仅完成了编码的转换，还进行了语义翻译。

从实现方式上讲，以后需要增加其他语言版本，只需要增加相应的资源文件即可。

4.2 SQL脚本转换

OMC-S 系统中有些资源文件是写在SQL脚本中插入到数据库的。对于这种情况，OMC-S繁体中文版中采用直接把SQL脚本转成big5编码的脚本的方式来解决。

图4.1　SQL脚本的翻译

4.3硬代码修改

由于历史原因，系统中存在一些硬代码，需要手工来修改。例如：

 

图4.2　硬代码的修改

5．       结束语

简繁转换工具对我们开发繁体中文版系统起着非常重要的作用。目前很多人做简繁转换都借助于第三方工具，比如“简繁大师”来完成翻译和转码工作。“简繁大师”虽然也提供了词库转义，同时也能实现转码，但是“简繁大师”效率比较低，也没有一个很好的转换匹配算法，所以往往需要配置修正词库，二次转换，正确性得不到保证。同时简繁大师也没有开放的接口，不能和我们自己的程序集成，也没有诸如native2ascii的功能，所以翻译工作必须当作一个独立的工作来完成。

如果能用我们自己开发的工具，并根据实际工作完善好词库，程序进一步优化，并将native2ascii工作、和Clearcase资源文件的checkout checkin等功能集成，那么我们很多工作都可以自动化，我们可以在短短几分钟内完成整个系统的翻译工作，大大减少了做繁体中文版的繁琐工作。而且无论以后简体资源文件发生怎样的变化，只需要运行一次程序，就可以生成最新版的繁体中文版。以OMC-S为例，我们只需要关心和维护好简体中文的资源文件，然后运用工具自动生成全部或者个别繁体中文资源文件，从此不再为系统的繁体版发愁！

 

参考书目：

《Java 编程语言（第三版）》Ken Amold、James Gosling、David Holmes 著，虞万荣等译，

中国电力出版社，2003

《常用字符集编码的概要特性》 http://www.cnlei.org/blog/article.asp?id=454