代码页是字元集编码的别名，也有人称"内码錶"。早期，代码页是IBM称呼电脑BIOS本身支持的字元集编码的名称。当时通用的作业系统都是命令行界面系统，这些作业系统直接使用BIOS供应的VGA功能来显示字元，作业系统的编码支持也就依靠BIOS的编码。现在这BIOS代码页被称为OEM代码页。图形作业系统解决了此问题，图形作业系统使用自己字元呈现引擎可以支持很多不同的字元集编码。

早期IBM和微软内部使用特别数字来标记这些编码，其实大多的这些编码已经有自己的名称了。虽然图形作业系统可以支持很多编码，很多微软程式还使用这些数字来点名某编码。

对于字元和Unicode数据的位模式的定义，此模式代表特定字母、数字或符号（例如 0x20 代表一个空格，而 0x74 代表字元“t”）。一些数据类型每个字元使用一个位元组；每个位元组可以具有 256 个不同的位模式中的一个模式。

在计算机中，字元由不同的位模式（ON 或 OFF）表示。每个位元组有 8 位，这 8 位可以有 256 种不同的 ON 和 OFF 组合模式。对于使用 1 个位元组存储每个字元的程式，通过给每个位模式指派字元可表示最多 256 个不同的字元。2 个位元组有 16 位，这 16 位可以有 65,536 种唯一的 ON 和 OFF 组合模式。使用 2 个位元组表示每个字元的程式可表示最多 65,536 个字元。

单位元组代码页是字元定义，这些字元映射到每个位元组可能有的 256 种位模式中的每一种。代码页定义大小写字元、数字、符号以及 !、@、#、% 等特殊字元的位模式。每种欧洲语言（如德语和西班牙语）都有各自的单位元组代码页。虽然用于表示 A 到 Z 拉丁字母表字元的位模式在所有的代码页中都相同，但用于表示重音字元（如"é"和"á"）的位模式在不同的代码页中却不同。如果在运行不同代码页的计算机间交换数据，必须将所有字元数据由传送计算机的代码页转换为接收计算机的代码页。如果源数据中的扩展字元在接收计算机的代码页中未定义，那幺数据将丢失。如果某个资料库为来自许多不同国家的客户端提供服务，则很难为该资料库选择这样一种代码页，使其包括所有客户端计算机所需的全部扩展字元。而且，在代码页间不停地转换需要花费大量的处理时间。

仅靠单位元组字元集存储许多语言所使用的字元也是不够的。例如，一些亚洲语言包含上千个字元，所以每个字元必须使用双位元组。双位元组字元集正是为这些语言定义的。但是，这些语言都有各自的代码页，在运行不同双位元组代码页的计算机之间传输数据也存在困难。

1258 越南语

1257 波罗的语

1256 阿拉伯语

1255 希伯来语

1254 土耳其语

1253 希腊语

1252 拉丁 1 字元 (ANSI)

1251 西里尔语

1250 中欧语言

950 繁体中文

949 朝鲜语

936 简体中文

932 日语

874 泰国语

850 多语种 (MS-DOS Latin1)

437 MS-DOS 美国英语

为解决在网路中支持多种代码页时出现的字元转换和解释问题，ISO 标準化组织和称为 Unicode Consortium 的团体定义了 Unicode 标準。Unicode 使用四个位元组存储每个字元。由于 4,294,967,296 个字元足以涵盖世界上所有语言常用的字元，因此 Unicode 标準适用于所有的主要语言。如果网路中的所有计算机和程式都使用 Unicode，则无需进行任何字元转换，每个用户与所有其它用户看到的字元完全相同，并且不会丢失任何字元。

在运行 Microsoft Windows 作业系统的计算机上，作业系统和 Windows 应用程式使用的代码页由 Windows 区域设定定义。区域设定是在安装作业系统时选择的。Windows 应用程式使用由 Windows 区域设定定义的代码页来解释数据。Windows 应用程式还支持宽字元数据，即 Unicode 数据。

支持两类字元数据类型：

Unicode 数据类型

nchar、nvarchar 和 ntext。这些数据类型使用 Unicode 字元表示法。代码页不适用于这些数据类型。

非 Unicode 字元数据类型

char、varchar 和 text。这些数据类型使用单位元组或双位元组代码页中定义的字元表示法。

有关字元数据的存储方式以及代码页、Unicode 和排序次序操作的更多信息，请参见在 MSDN 页中的 Developing International Software for Windows 95 and Windows NT 4.0。

国际化数据和 Unicode

当只使用字元数据和代码页时，在一个资料库内很难以多种语言存储数据。很难为资料库找到一种代码页，能够存储所需全部语言特有的字元。对于运行各种代码页的不同客户端所读取和更新的特殊字元，要确保正确地转换也很困难。支持国际化客户端的资料库应始终使用 Unicode 数据，而不应使用非 Unicode 数据类型。

例如，北美洲客户的资料库必须处理三种主要语言：

墨西哥使用的西班牙文名称和地址。

魁北克使用的法文名称和地址。

加拿大的其余地区和美国使用的英文名称和地址。

当只使用字元列和代码页时须小心，以确保资料库所安装的代码页能够处理这三种语言的字元。当其中一种语言的字元由运行另一种语言的代码页的客户端读取时，必须更加小心以确保能够正确转换字元。

在DOS下可以通过mode命令来设定代码页。

选定代码页:　 MODE CON[:] CP SELECT=yyy

代码页状态:　 MODE CON[:] CP [/STATUS]

按Windows+R组合键，然后输入cmd或者command打开命令提示符。

比如输入：mode con cp select=936，则表示显示简体中文。如果输入mode con cp select=437，则表示显示MS-DOS 美国英语，而中文显示将会是?。

方法一：

通过system函式调用dos命令，该函式的头档案是stdlib.h。

例：system("mode con cp select=936");

方法二：

通过API函式SetConsoleOutputCP来实现

程式例：

#include <windows.h>

#include <stdio.h>

int main( void )

{

SetConsoleOutputCP(936);

printf("简体中文\n");

return 0;

}

输出：

简简体体中中文文

Press any key to continue

如果将代码页设定为437，那幺无法正常输出简体中文：

╝≥╠σ╓╨╬─

Press any key to continue

随着 Internet 的发展，支持众多运行不同区域设定的客户端计算机变得日益重要。很难选择这样一种代码页，使其包含的字元数据类型能够支持全球範围用户所需的全部字元。

管理国际化资料库中的字元数据的最简单方法是始终使用 Unicode nchar、nvarchar 和 ntext 数据类型，代替对应的非 Unicode 数据类型（char、varchar 和 text）。如果所有使用国际化资料库的应用程式也採用 Unicode 变数而不是非 Unicode 变数，那幺在系统中的任何地方都无须进行字元转换。每个客户端与所有其它客户端看见的字元数据都完全相同。

对于可使用单位元组代码页的系统，Unicode 数据需要的存储空间是非 Unicode 字元数据的两倍，但却消除了在代码页间转换扩展字元的必要，因此至少部分弥补了上面的不足。使用双位元组代码页的系统没有这个问题。

SQL Server 2000 将所有的文本化系统目录数据都存储在包含 Unicode 数据类型的列中。资料库对象（如表、视图和存储过程）的名称存储在 Unicode 列中。这样就可以只使用 Unicode 开发应用程式，从而避免了所有的代码页转换问题。

排序次序

排序次序指定 SQL Server 解释、排序、比较和显示字元数据所使用的规则。例如，排序次序定义"a"是小于、等于还是大于"b"。排序次序定义排序规则是否区分大小写，例如"m"和"M"是否相同。另外还定义排序规则是否区分重音，例如"á"和"&auml;"是否相同。

SQL Server 2000 对每种排序规则使用两种排序次序，一种用于 Unicode 数据，另一种用于字元代码页。

许多 SQL Server 排序规则使用相同的代码页，但是代码页的排序次序不同。这使站点得以选择：

是否仅根据位模式所表示的数字值来排序字元。二进制排序的速度最快，这是因为 SQL Server 不用做任何调整并可使用快速、简单的排序算法。二进制排序次序始终区分大小写。由于代码页中的位模式可能不按照特定语言的字典规则所定义的序列排列，二进制排序有时并不按照使用该语言的用户所期待的序列对字元进行排序。