【图】使用m17n实现对各国语言间的代码移植和转换

为了让 Linux® 应用程序在全世界范围都可以使用，而不会在西方语言与世界上其他语言之间产生任何区别，我们应该发行一些本地化后的版本，它们可以输入、存储、提取或呈现任何语言，而不管这些语言是多么复杂。多语言库，或称为 m17n，为类 UNIX® 平台上的所有语言提供了一个国际化解决方案。

在很短的时间之内 —— 总共还不到 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 在解决自己用途不够广泛方面有一些限制。请参看侧栏 pango 的问题）。其他 GUI 工具包提供了对 i18n 的支持，但却并不总是能兼容这些标准。当然，Linux 上的图形应用程序也需要 X Window System 的基本显示库 Xlib，它提供了两种绘图（形状和线条）和字符显示原语。不幸的是，Xlib 只能显示西欧语言。

Pango 的问题

Pango 可以放置（布局）并显示一些复杂的手稿，但是不能对多字节的文本进行排序或搜索功能。Pango 假设底层库 —— 通常是使用 C 语言编写的，可以对使用 Unicode 标准指定的所有语言都进行操作 —— 可以执行基本的文本处理操作。

一个库显示所有语言

要让应用程序在全球都可以使用 —— 而不会在西方国家和世界上其他很多语言之间产生不公平的现象 —— 我们必须要能够输入、存储、提取并显示任何语言，而不管这究竟会多么复杂。正如上面介绍的一样，有一些广为认可的标准为多字节存储和可移植性提供了一些便利；然而，现在还没有为输入和显示制定标准。更加糟糕的是，即使是最好的多语言文本编辑器也会被迫混合使用简单的国际化库和私有 GUI 工具包。添加一种语言可能会需要另外一种（很可能是新的）定制库。

Multilingualization Library 或 m17n 库会尽力为类 UNIX 平台上多种语言书写的文本的输入、处理和显示提供一