linux
如果不将
linux配置为使用UTF-8编码，多语言支持可能会变得非常混乱。为什么会这样？以
中国大陆的中文支持为例，在Windows系统中，由于有完善的双字节字符集（DBCS）支持，因此能够很好地处理GBK编码（涵盖简体和繁体中文），并且提供了前进/后退一个字符的相关API。然而，在早期的
linux系统（例如Red Hat 9，并非RHEL）上，却找不到类似的API。结果，
linux上的许多应用程序直接忽略了这个问题。那么，如何
移动到前一个或后一个字符？这只能由应用程序自行解决。而那些懒得处理的应用程序则干脆不做任何处理，从而导致整体情况混乱不堪。这里需要指出的是，为什么UTF-8让这一切变得简单了。在UTF-8普及之前，支持多国语言的常见方案包括双字节字符集（DBCS）、Unicode（UCS-2以及后来的UTF-16），以及用于标识当前字符集的代码页（code page）。代码页可以被视为同时关联了字符集与编码方式的一种机制。实际上，当我们提到DBCS时，通常也已经包含了字符集和编码方式这两者之间的关联，因此对用户而言，两者的概念并没有本质区别。单字节字符集的代码页示例包括：CP437（即扩展ASCII）、CP850（一种适用于德语、法语等
欧洲语言的字符编码）和CP1252（Windows西欧字符集）。其中，CP1252与ISO-8859-1西欧字符集大部分相似，但也存在一些差异。双字节字符集的例子则有：GB2312（
中国大陆简体中文）、GBK（支持
中国大陆的简体和繁体中文）、Big-5（港台地区繁体中文）以及Shift-JIS（日文）等。然而，DBCS存在几个显著的缺点。首先，不同语言往往需要不同的字符集。例如，GBK可以表示简体和繁体中文，也能涵盖部分日文字母，但无法表示韩文或法文等其他语言。其次，对于像GBK这样范围较大的字符集，无法保证在常数时间（O(1)）内确定前一个字符的位置。无论是GBK还是GB2312，如果直接使用标准库中的strstr函数（用于在字符串中查找子串），都可能返回错误的结果，因此需要重写该函数以适应这些字符集。相比之下，UTF-8展现出了更好的向下兼容性。例如，strstr函数无需修改即可正常使用。此外，在查找前一个或后一个字符时，操作的时间复杂度可控（最多检查4个字节即可完成）。这些特性使得UTF-8成为现代多语言环境下的理想选择。
