GNU/Linux 的 I18N 环境的发展，到了glibc-2.2 系列正式问世后，才算完全成熟。它不仅完全支持 Unicode 环境，同时在 I18N 与 L10N 方面还拥有许多先进的特色述如下:1. glibc 内部的编码转换系统 (iconv) 拥有共同的「基底字集」，该基底字集采用 UCS4 编码，目前仍持续扩编当中，理论上将可以函盖世界上所有已知的编码系统的转换对应。透过基底字集，可以达到完善的转码机制。同时，由于在各语系下其多字节编码转成宽字符时，其实就是转成 UCS4，这在将来 Unicode通行时，将有利于数据的处理。2. glibc 内部拥有数量庞大的编码转换表，大部分是各编码系统与 UCS4 的转换用，也有一些是用于不同编码间直接转换。所有的转换表皆采动态模块加载的方式供应用程序使用，故只有在需要时系统才会自动加载所需的转换表来执行，使用完毕后可以卸下，不会浪费内存空间。3. glibc 拥有完整的 I18N 过程调用接口，以及完整的 Unicode 输出入与处理的呼叫接口。4. 在地区环境方面，glibc 将「字集」与「编码」的概念分开。一个地区环境资料库有一个明确的字集，代表这个地区语文可能会使用到的所有文字符号，而这个字集可以自由选择一个编码系统来套用。例如我们台湾地区的字集包含所有的中文字 (简繁体都有)，如果我们选用 Big5 编码，则地区环境数据库名称就是 zh_TW.Big5；若我们选用 EUC-TW 编码，则名称就是 zh_TW.euctw；当然我们甚至可以选用 GB2312 或 Unicode 等编码来套用。·然而，由于各编码所能包含的字数是固定的，同时它们也只能包含特定的字集，因此，仅管我们的中文字集包含了所有的中文字，但一旦选定编码系统后，其所能使用的中文字自然仅限于该编码系统所包含的范围。因此，假如我们选用Big5，就表示在此环境下无法使用简体字；反之若选用GB2312 亦然。5. glibc 中各地区环境预设的编码系统与传统的 UNIX 系统稍有不同。所谓的「预设编码系统」指的是在 "_" 这样的地区环境数据库名称中，所采用的编码系统。传统的 UNIX 系统中所采用的预设编码系统多半是依照官方或业界的标准，例如在台湾地区就是 EUC-TW。而在 glibc 中，则是以当地最广泛流通的编码系统做为预设。· 更进一步地，glibc 会自动将未登录的编码系统名称，改以其地区环境的预设编码系统来取代。例如我们将语系环境设定为 zh_TW.euctw，由于 "euctw"在 glibc 内部已有登录，故它就会采用 EUC-TW 做为此环境下的编码系统。万一我们将语系环境设定为 zh_TW.unknown，由于 "unknown" 一字没有登录，故glibc 会自动以 zh_TW 预设的编码系统 Big5 来取代。6. 在讯息显示方面，各应用程序的讯息翻译只需依各语文地区分别保留一份即可，不需要分别为不同的编码系统都保留一份。以台湾地区中文为例，我们只需要一份 zh_TW 的讯息即可，至于它是用 Big5 写成的，或 EUC-TW 写成的都没关系。假如它原来是以 Big5 写成的，但我们却希望以 EUC-TW 来显示时，glibc会自动为我们做好转码的工作。·也许有人会问，那我们只需要保留一份 zh (即中文) 的讯息就好了嘛，这样岂不是两岸三地都可使用了？然而这么做并不恰当，原因是两岸三地因历史背景与文化的隔阂，各自发展成独特的语文，或称「地区性方言」，对同一个句子的翻译，可能两岸三地的翻法都各自不同。故我们不能单纯用转码的方式，直接将台湾地区的翻译转成简体字供对岸使用，而必须为他们分别保留一份他们自己的讯息翻译。7. 在讯息翻译的维护工作，以及系统函式的呼叫接口上，各 UNIX 系统的实作方式都不尽相同。而在 glibc (或所有的 GNU 系统、程序) 中，则统一使用 GNUgettext，以方便程序撰写以及后续的翻译维护。8. 在地区环境数据库中，除了上述那几个传统的类别之外，新一代的 glibc-2.2还扩增了以下的类别:LC_PAPER,LC_NAME,LC_ADDRESS,LC_TELEPHONE,LC_MEASUREMENT,LC_IDENTIFICATION这些是根据 ISO/IEC JTC1/SC22/WG20 N690 (1999/06) 的新规范而来，用以描述更多的地区性惯例，如住址格式、电话号码格式、抬头称位 .... 等等。
（出处：http://www.sheup.com）