标题:
使用 m17n 实现各国语言间代码移植(1)
[打印本页]
作者:
look_w
时间:
2018-5-19 15:08
标题:
使用 m17n 实现各国语言间代码移植(1)
在很短的时间之内 —— 总共还不到 20 年 —— 个人计算机已经成为我们工作和生活中的一种必需设备。受到半导体和处理器快速发展的推动,大量的供应商使得计算机的价格一落千丈,Internet 也已经在全球广为分布,个人计算机现在已经不再是一种奢侈品,而是一种常见的家用电器了。
实际上,在很多富裕的国家(例如美国、日本、英国),每两个家庭就会拥有一台计算机,并且会使用宽带服务。就全世界来看,虽然家庭收入可能会有很大的不同,但是个人计算机都很容易购买了,即使在马尔代夫,我们也很容易购买到笔记本。另外,如果我们碰巧说的是 Dhivehi 方言(马尔代夫的一种方言),微软也为我们提供了一个这种版本的 Microsoft® Windows® XP 操作系统。
就全球广泛接受的个人计算机来说,大部分现代操作系统都提供了一些编程库来促进
国际化
的发展,或者将软件调整为支持多种语言的。国际化(通常简写为 i18n,节选自
i-nternationalizatio-n
)库通常都会将应用程序的文本资源(按钮标签、用户界面[UI] 提示和菜单选项)保存成多种语言的。在启动国际化后的应用程序后显示哪种语言,这要取决于用户的区域设置 —— 通常,这是一个可配置的系统或个人帐号首选项。
理想来说 —— 至少对于独立软件供应商来说 —— 相同的可执行程序以日语或希腊语运行时都能运行得一样好。然而,构建 “本地方言” 版本的应用程序的情况远远没有这么理想。包括被广泛认可的 ISO(International Standards Organization)/IEC(International Engineering Consortium)10646 和 Unicode,没有哪种字符编码可以解决如何实现任意语言的输入和呈现问题。ISO/IEC 10646 和 Unicode 只指定了如何存储、检索和排序字符以及字符的特殊组合。例如,这些标准并没有规定统一的格式、嵌入式数据或标识来让使用泰国语书写的文档怎样才能按照泰国语的规范规则正确地呈现出它们的样子来。是的,Unicode 可以维护使用泰国语书写的文档的内容,也可以保证这种文件在所有使用 Unicode 的平台上都可以很好地进行移植,但是它并不能保证我们可以正确查看文件,也不能保证文档所呈现出来的样子与作者的意图一致。
我们来考虑一下这种情况:尽管 Linux GNU C 库(glibc)提供了一些函数来处理 ISO 10646 兼容的 31 位字符,但是它并不能保证这些字符可以在显示设备上正确进行显示。有些 glibc 字符串函数,例如 strcat() 和 strlen(),都可以正确地处理多字节的问题,但是要正确显示阿拉伯语,需要双向(bidi)显示的功能,这种功能只有在图形用户界面(GUI)工具包和专用字符串显示库中才能找到。
例如,GNOME 需要 GTK+ 工具包和 Pango(一个文本显示库)来实现对 i18n 的完整支持(然而,Pango 在解决自己用途不够广泛方面有一些限制。请参看侧栏 )。其他 GUI 工具包提供了对 i18n 的支持,但却并不总是能兼容这些标准。当然,Linux 上的图形应用程序也需要 X Window System 的基本显示库 Xlib,它提供了两种绘图(形状和线条)和字符显示原语。不幸的是,Xlib 只能显示西欧语言。
Pango 的问题Pango 可以放置(布局)并显示一些复杂的手稿,但是不能对多字节的文本进行排序或搜索功能。Pango 假设底层库 —— 通常是使用 C 语言编写的,可以对使用 Unicode 标准指定的所有语言都进行操作 —— 可以执行基本的文本处理操作。
一个库显示所有语言要让应用程序在全球都可以使用 —— 而不会在西方国家和世界上其他很多语言之间产生不公平的现象 —— 我们必须要能够
输入
、存储、提取并
显示
任何语言,而不管这究竟会多么复杂。正如上面介绍的一样,有一些广为认可的标准为多字节存储和可移植性提供了一些便利;然而,现在还没有为输入和显示制定标准。更加糟糕的是,即使是最好的多语言文本编辑器也会被迫混合使用简单的国际化库和私有 GUI 工具包。添加一种语言可能会需要另外一种(很可能是新的)定制库。
Multilingualization Library 或 m17n 库会尽力为类 UNIX 平台上多种语言书写的文本的输入、处理和显示提供一种单一的解决方案。另外,m17n 的目标是充分利用现有且大家都可以很好地理解的典型 UNIX 应用程序框架,而不是利用软件开发人员的其他模型。
最后,m17n 会努力使国际化的内容更加丰富,而不仅仅是简单地从英语移植到另外一种语言上。使用 m17n,同一个二进制文件可以在一个系统上显示法语,在另外一个系统上显示蒙古语,甚至在同一个屏幕上就可以显示多种语言的文本。更好的是,m17n 可以(令人信服地)实现诸如文本数据库之类的功能,这使它可以存储并处理大量的国际化内容。
m17n 库是在日本 Tsukuba 的 National Institute for Advanced Science and Technology 工作的 4 个日本程序员编写的。很多年以来,日本都一直走在了国际化的前端,部分原因是日语学者一直在试图为人文学科探索一种百科全书式的方法 —— 尤其对世界上各种语言更为关注(有关历史上的一些内容,请参看侧栏 。)
亚洲语言的起源世界上很多国家的手写语言(这也是用户使用的最多的形式)都是在全世界最重要的宗教之一 —— 佛教(也是日本最重要的宗教信仰)之内产生并不断演进的。
印度、中国以及缅甸的语言和手稿很多都是有关佛经的历史的。日本的佛教学者也需要学习梵语、巴利语、古汉语、古藏语、中日语以及古日语的几个变种,另外在深入研究佛教之前,还需要学习 3 本日语手稿(如果它们可以称为手稿的话)。熟悉梵语、古汉语以及几种古日语的变种对于佛教学者来说只是工作的一个最低需求。而且他们常常还需要了解现有佛教所使用的一些语言,例如僧伽罗人语、泰国语、现代韩语等。
在以佛教文化为根基的外向型经济中,要想了解世界,仅仅使用一种语言是不可想像的。
m17n 库是由 3 个库和一个存储单一脚本以及正确显示脚本所需要的元数据的数据库构成的:
m17n C 库可以类似地实现 glibc (以及各种风格的 libc )的一些基本的文本处理功能。
m17n X 库与 Xlib 是紧密对应的。它提供了基本的绘制字符的功能,并且对呈现所做的假设很少。
m17n 工具包提供了一些功能,可以对复杂的脚本进行处理,使它们可以准备好在屏幕上进行显示。例如,泰国语在显示之前,必须进行排序、合成和重新排序。
最后,m17n 数据库存储了每种语言所特有的一些数据。例如,某种特有语言可能会需要自己的字体、一种特定的编码以及一些特殊的机制来输入自己的数据。m17n 库是与语言无关的;m17n 数据库中保存了所有与语言有关的信息。
图 1 给出了 m17n 的 4 个部分,以及这些库是如何与现有的系统组件对应的。m17n 组件和传统 UNIX 库之间存在惊人的类似之处并不意外:m17n 的创建者希望能够让多语言的应用程序的编写尽量简单。我们只要使用一个等效的多语言库来替换相同语义的函数即可。
图 1. m17n 库的层次结构
(从侧面来看,m17n C 和 X 库就预示着 X 服务器可以提供国际化功能。不过,m17n 对底层操作系统和呈现机制的假设较少,因此我们可以将 m17n 移植到其他窗口系统上。实际上,将 m17n 集成到跨平台的 GUI 工具包(例如类 UNIX 系统上使用的 Qt)正是当前的工作重点,m17n 团队正在将自己的代码加入 GTK 的修正版本中。)
欢迎光临 电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)
Powered by Discuz! 7.0.0