|
提供了不包括带重音符号字母的附加拉丁字元集，但最终内码表的较高的128个字元还是包括了完整的非拉丁字母，例如希伯来语、希腊语和斯拉夫语。自然，如此多样会导致内码表变得混乱；如果少数带重音的字母未正确显示，那么整个文字便会混乱不堪而不可阅读。
内码表的扩展正是基於所有这些原因，但是还不够。斯拉夫语的MS-DOS内码表855与斯拉夫语的Windows内码表1251以及斯拉夫语的Macintosh内码表10007不同。每个环境下的内码表都是对该环境所作的标准字元集修正。IBM
OS/2也支援多种EBCDIC内码表。
但等一下，你会发现事情变得更糟糕。
双位元组字元集
迄今为止，我们已经看到了256个字元的字元集。但中国、日本和韩国的象形文字符号有大约21,000个。如何容纳这些语言而仍保持和ASCII的某种相容性呢？
解决方案（如果这个说法正确的话）是双位元组字元集（DBCS：double-byte character
set）。DBCS从256代码开始，就像ASCII一样。与任何行为良好的内码表一样，最初的128个代码是ASCII。然而，较高的128个代码中的某些总是跟随著第二个位元组。这两个位元组一起（称作首位元组和跟随位元组）定义一个字元，通常是一个复杂的象形文字。
虽然中文、日文和韩文共用一些相同的象形文字，但显然这三种语言是不同的，而且经常是同一个象形文字在三种不同的语言中代表三件不同的事。Windows支援四个不同的双位元组字元集：内码表932（日文）、936（简体中文）、949（韩语）和950（繁体汉字）。只有为这些国家（地区）生产的Windows版本才支援DBCS。
双字元集问题并不是说字元由两个位元组代表。问题在於一些字元（特别是ASCII字元）由1个位元组表示。这会引起附加的程式设计问题。例如，字串中的字元数不能由字串的位元组数决定。必须剖析字串来决定其长度，而且必须检查每个位元组以确定它是否为双位元组字元的首位元组。如果有一个指向DBCS字串中间的指标，那么该字串前一个字元的位址是什么呢？惯用的解决方案是从开始的指标分析该字串！
Unicode解决方案
我们面临的基本问题是世界上的书写语言不能简单地用256个8位元代码表示。以前的解决方案包括内码表和DBCS已被证明是不能满足需要的，而且也是笨拙的。那什么才是真正的解决方案呢？
|