现在搞藏文拉丁转写的事儿，大家通常关注的都是那些大字符集的方案，可这还留下了个小字符集的空白。咱们干脆弄一套基于小字符集的藏文拉丁转写算法，再把程序在Windows平台上跑通，这不就是给藏文信息处理增添了个新工具嘛？咱们先来聊聊藏文的音节结构和编码特征。 藏文一个字里头其实藏着30个辅音、10个梵音字母还有5个元音符号，音节又是由基字、前加字、后加字这些东西组成的。两个音节中间用个小点儿隔开，句子是个单垂符，段落干脆来个双垂符。除了那个最中间的基字不能空着，别的位置都能空缺，这就形成了横向和纵向同时拼写法的特性。 再说说编码上的事儿，大字符集把那些上下叠在一起的字母给全包进去编成一个号了，预组合的数据量太大了。而小字符集就聪明多了，它把辅音、元音还有上下加字都拆成一个个单独的构件，按照ISO/IEC 10646的标准动态拼合在一起。这可是现在国际上大家都在用的主流做法啊。 现在的技术都这么先进了，小字符集根本就没有办不成的事，以前那种大字符集早就被大多数系统给抛弃了。咱们这个系统的架构挺简单的，分成知识库管理、文本预处理、部件分解和拉丁转写这四大模块。 先把文本预处理这一步给做好。那些非藏文的字符像英文缩略词、数字或者符号啥的，得先换成规范写法，不然后续处理肯定出错。咱们只要建个规则库把那些不规范的字符给替换掉就行。 还有个特别的处理就是黏写字符。古代藏文为了省笔画常把格助词黏在后加字上，看着很奇怪但其实是合法的。系统得识别出来“s”、“ka”、“la”、“a”这些黏着的词并把它们分开还原成标准的音节字。 知识库管理也得跟上节奏，维护藏文正字规则库、特殊符号特征库和拉丁转写规则库这三套东西。不管哪个规则改了都能立马生效保证数据一致。 重头戏来了是部件分解算法。小字符集里每个竖着叠起来的字只占一个辅音的宽度。咱们得先找到那个占位置的辅音字符串；再看k值（不占位置辅音的数量）来判断基字在哪儿；如果k等于0了就靠元音来定基字；一旦基字确定了就倒着往前推前加字、上加字、下加字；最后再看看后加字和重后加字在哪。 规则部分也简单点： 按照声韵母的顺序读部件分别转写声母和韵母； 输出全都小写； 没有元音符号的时候默认补个“a”； 如果基字是“ng”就直接转写成“a”，当零声母处理。 最后咱们在Windows平台上测了测新闻和博客的文本数据。结果挺不错的，系统能正确转写98%的音节。主要出的错也就两类：要么文本本身就不合现代正字法导致基字判定不准；要么就是黏写字符或者规范化规则还没覆盖到的新现象。 这些错误的地方系统会高亮提示出来，人工稍微校对一下就能修正了。这次测试基本算是通过了。 最后总结一下这套算法吧： 只需要维护个声母和韵母的对照表就行，库小方便移植； 那些梵文和外来的新造词得以后再完善部件识别规则； 到时候就能实现全自动藏文—拉丁转写了。