随处访问数据库：为 DB2 UDB for Linux, UNIX, and Windows 提供 Unicode 支持的实用方法

简介

当今的应用程序常常设计为供国际化使用。这些应用程序可能需要处理不同语言的字符串。而 Unicode 正是一种与语言无关的字符表示标准。

由于 Java 编程语言已经在内部使用 Unicode 来表示字符，所以国际化应用程序的开发已经容易多了。但是，不能只考虑应用程序端。后端的数据库也必须能够处理 Unicode 字符。本文将讨论几个主题，帮助开发人员实现供国际化使用的 DB2 UDB 应用程序。

DB2 中支持何种 Unicode 标准？

只有一种 Unicode 标准，但是存在不同的 Unicode 字符编码方案。最常用的 Unicode 字符编码是 UTF-8 和 UCS-2：

UTF-8：使用 1 到 4 字节来表示每个字符的编码。这个编码方案可以用一个字节对 ASCII 字符进行编码，用多个字节（最多 4 字节）对非 ASCII 字符进行编码。

UCS-2：每个 Unicode 字符都编码为 2 字节。这种编码方案可以表示超过 65000 个字符，这覆盖了世界上最重要的语言的大多数字符。Java 内部也使用 UCS-2。

正如前面提到的，完整的 Unicode 标准由超过 65000 个字符组成。在此范围之外的其他字符基本上属于可能不再使用的语言，或者使用的情况有限。例如，某些亚洲字符只在名字中使用。这些额外字符也称为补充字符，可以在 UTF-8 中用 4 字节表示。另外，还有一种称为 UTF-16 的编码方案，它也可以用来表示补充字符。为此，UTF-16 使用 2 x 2 字节。

DB2 UDB 只支持 UTF-8 和 UCS-2 编码。尽管 DB2 不支持补充字符，但是补充字符可以存储在 DB2 UDB 中。应该注意，超过 65000 个字符对于大多数应用程序足够了。在 Java 应用程序中处理补充字符需要特殊的机制。因此，处理补充字符不但需要数据库支持，还需要应用程序支持。

在 DB2 中如何使用 Unicode 编码方案来存储数据

可以将 Unicode 数据存储在 DB2 Unicode 数据库中。在 Unicode 数据库中，所有的表都使用 Unicode 编码方案存储字符数据。DB2 还允许在非 Unicode 数据库中的 Unicode 表中使用 Unicode 格式存储字符数据。

定义 Unicode 数据库

Unicode 数据库只以 Unicode 格式存储字符数据，并不以 Unicode 格式显示数据。在创建数据库时，DB2 决定数据库的编码页。数据库的编码页可以隐式或显式地决定。

DB2 UDB for Linux, UNIX, and Windows 可以根据一个环境变量来隐式地决定编码页。在使用 CREATE DATABASE 语句创建数据库时，将从操作系统的地区设置推导出数据库的编码页。对于 Windows 操作系统，将从注册表中的 ANSI 编码页设置推导出数据库的编码页。对于 UNIX 操作系统，将从地区设置推导出环境，包括语言、区域和编码集。应该注意，注册表变量 DB2CODEPAGE 可以用来覆盖编码页。但是，如果 DB2CODEPAGE 注册表变量设置为不正确的值，那么可能会造成不可预期的结果和潜在的数据损失。

还可以在 CREATE DATABASE 语句中使用 USING CODESET 子句显式地指定编码页。带 USING CODESET UTF-8 子句的 CREATE DATABASE 语句表示数据库可以包含 UTF-8 或 UCS-2 编码的字符数据。为了清楚起见，建议显式地定义 Unicode 数据库：

CREATE　DATABASE　db_name　USING　CODESET　codeset　
TERRITORY　territory_name　COLLATE　USING　collating　sequence　

其中的 codeset 应该以大写字符指定，比如 UTF-8，territory_name 是提供区域特定支持的编码，collating sequence 表示对字符数据进行比较的方法。

例如，

CREATE　DATABASE　UCSAMPLE　USING　CODESET　UTF-8　TERRITORY　US　

对于 DB2 for Linux, UNIX, and Windows V8.2 中的 Unicode 排序次序，可能的排序器如下：

IDENTITY 排序器实现基于编码点的字符比较。

IDENTITY_16BIT 排序器实现 CESU-8（一种 8 位的兼容 UTF-16 的编码方案）。这个排序器确保所有字符（补充字符和非补充字符）采用与 UTF-8 一样的二进制排序次序。

UCS400_NO 排序器实现 Unicode Collation Algorithm（UCA），这基于 Unicode Standard 4.00 版，隐式打开了规范化。细节请参见 Unicode Technical Consortium 上的 Unicode Technical Report #10。

UCS400_Thai 排序器实现 UCA 4.00 版，但是对于所有 Thai 字符按照 Royal Thai Dictionary 次序进行排序。

在 DB2 UDB V8.2 之前，Unicode 数据库只能定义为排序次序 IDENTITY，这意味着按照字节编码对字符进行比较。总的来说，这个排序器采用的排序次序与对语言的自然预期不同。对于大写和小写的字母 A 到 C，排序次序 IDENTITY 采用的次序如下：

IDENTITY: A B C a b c

在 V8.2 中，可以用排序次序 UCA400_NO 获得正确的 次序。排序器 UCA400_NO 采用以下次序：

UCA400_NO: a A b B c C

在选择排序次序时，还应该考虑性能影响。细节请参见 Unicode Technical Consortium 上的 Unicode Technical Report #10 的性能部分。

在创建了数据库之后，修改数据库编码页的惟一方法是删除数据库并用新的编码页重新创建数据库。

在 Unicode 数据库中创建 Unicode 表

在 Unicode 数据库中创建表时，表采用的 Character Code Set ID（CCSID）为 UNICODE。DB2 可以使用 UTF-8 或 UCS-2 格式存储 Unicode 数据。应该注意，UCS-2 格式与不带补充字符支持的 UTF-16 格式相同。DB2 的 Unicode 格式的特征如下：

UTF-8 格式：

在 Unicode 数据库中，CHAR、VARCHAR、LONG VARCHAR 或 CLOB 中存储的数据采用 UTF-8 格式。

一个 UTF-8 格式的字符占用 1 到 4 字节。一个 ASCII 字符占用 1 字节，一个非 ASCII 字符可以占用 2 到 4 字节。因此，如果涉及非 ASCII 字符，那么列中可以存储的最大字符数可能会减少。应该注意，列的字符容量不足会造成字符截断。

UCS-2 格式：

在 Unicode 数据库中，GRAPHIC、VARGRAPHIC、LONG VARGRAPHIC 或 DBLOB 中存储的数据采用 UCS-2 格式。

图形化字符都采用固定长度，每字符 2 字节。

DB2 总是采用 big-endian 次序（即 UCS-2BE）存储图形化 Unicode，尽管 UCS-2 既可以采用 Big Endian（BE）次序，也可以采用 Little Endian（LE）次序。

DB2 UDB for Linux, UNIX, and Windows 是补充字符安全的，但是不感知补充字符。

UTF-8 和 UCS-2 的字符长度总结如下：

表 1. UTF-8 和 UCS-2 的字符长度

例如，如果以 UTF-8 格式存储以下 5 个中文字符，那么至少需要用 CHAR(15) 定义一个表列：

图 1. UTF-8 中文字符

如果以 UCS-2 格式存储同样的文本，那么只占用 10 字节：

图 2. UCS-2 中文字符

可以用 GRAPHIC(5) 定义一个表列来存储这 5 个中文字符。应该注意，ASCII 中的所有字符在 UCS-2 中也是每字符占用 2 字节。

在非 Unicode 数据库中创建 Unicode 表

在非 Unicode 数据库中创建表时，表的默认 CCSID 是 ASCII。要想在非 Unicode 数据库中创建 Unicode 表，可以使用带 CCSID UNICODE 的 CREATE TABLE 语句。

不能在特定的列上指定 UNICODE，也不能在 DB2 for Linux, UNIX, and Windows 中的 Unicode 数据库中创建非 Unicode（ASCII）表。用 CCSID UNICODE 创建的表必须不包含图形化数据类型。这意味着非 Unicode 数据库中的 Unicode 表只能存储 UTF-8 编码的字符串。

在 DB2 UDB SQL Reference 中记录了几个限制（参见对 CREATE TABLE 命令的说明）。

在非 Unicode 数据库中创建 Unicode 表之前，必须先激活一个数据库配置参数 ALT_COLLATE（表示 Alternate Collating Sequence）。ALT_COLLATE 参数为 Unicode 表指定排序次序，目前只能是 IDENTITY_16BIT。如果不设置 ALT_COLLATE 参数，就不允许在非 Unicode 数据库中创建 Unicode 表，并会收到以下错误消息：

SQL0622N The clause clause is invalid for this database.

要设置 ALT_COLLATE，可以使用以下命令：

DB2 UPDATE DB CFG FOR TEST2 USING ALT_COLLATE IDENTITY_16BIT

利用非 Unicode 数据库中的 Unicode 表，DB2 支持一个区段编码页，SQL 语句可以在这个编码页下执行。尽管 Unicode 表和非 Unicode 表可以共存于一个数据库中，但是它们不能在一个 SQL 语句中相互交互，因为在同一个 SQL 语句中只能引用一种编码方案，要么是 ASCII，要么是 Unicode。如果一个 SQL 语句同时引用 ASCII 和 Unicode，就会接收到以下 DB2 SQL 错误：

SQLCODE:　-873,　
SQLSTATE:　53090,　
SQLERRMC:　Different　encoding　schemes　in　one　statement　　　

在 Unicode 表上创建索引

在 Unicode 表中的 VARCHAR 或 VARGRAPHIC 列上创建索引时，需要注意索引键限制。当使用 VARCHAR 或 VARGRAPHIC 数据类型时，索引键限制可能减少。应该注意，DB2 索引键的大小限制为 1024 字节，而且索引键限制包括占用的所有字节。例如，在 Unicode 数据库中创建一个可空的 VARCHAR(1024) 列，然后在这个 VARCHAR(1024) 列上创建索引。会遇到以下错误：

SQL0614N　The　index　or　index　extension　VARCHAR1024　cannot　be　
created　or　altered　because　the　combined　length　of　the　specified　columns　is　too　long.　
　　SQLSTATE=54008　
　　Explanation　.　.　.　.　
　　sqlcode　:　-614　
　　sqlstate　:　54008　

造成这个错误的原因是，变化的长度占用 2 字节，null 占用 1 字节。只能在用 VARCHAR(1021) 定义的列上定义索引。

如果使用可空的 VARCHAR 列并只涉及 ASCII 字符（在 UTF-8 格式中每字符 1 字节），那么可以建立索引的最大字符长度是 1021 个字符。当对非 ASCII 字符建立索引时，最大字符长度将减少。

如果使用可空的 VARGRAPHIC 列，那么 1021 字节的索引限制仍然是对的。因为图形化字符总是 2 字节长的，所以可以建立索引的最大图形化字符长度是 510 个字符，列可以定义为 VARGRAPHIC(510)。索引键大小限制也应用于通过索引施加的那些约束。

在使用不同的 Unicode 格式时的考虑因素

使用 UTF-8 既有优点，也有缺点：

优点：

在从非 Unicode 数据库迁移到 Unicode 数据库时，对于 UTF-8 编码的情况，数据类型 CHAR、VARCHAR、LONG VARCHAR 和 CLOB 仍然可以使用。

UTF-8 只用 1 字节对 ASCII 字符进行编码。因此，如果使用 UTF-8 而且数据库中主要存储 ASCII 字符，那么可以节省存储空间。

缺点：

对于数据库设计，必须考虑到列大小是按照字节数定义的，而不是按照字符数。因此，如果想定义一个最多存储 10 个字符的 VARCHAR 列，那么必须将这个列定义为 VARCHAR(40)，因为一个字符占用 1 到 4 字节。因此，在将非 Unicode 数据库迁移到 Unicode 数据库时，应该记住 CHAR、VARCHAR、LONG VARCHAR 和 CLOB 数据类型的长度会有变化。

在与使用 UTF-8 编码的数据类型结合使用时，SUBSTR 和 LENGTH 等函数仍然处理字节而不是字符。因为在 UTF-8 编码中字符需要不同数量的字节（1 到 4 字节），所以很难处理这些函数。可以改用用户定义函数（UDF）。例如，可以定义一个 SUBSTRING UDF，它接受一个 CHAR 值作为参数，将它转换为 GRAPHIC 值，再对这个 GRAPHIC 值调用 SUBSTR 函数，最后将 GRAPHIC 结果转换回 CHAR 值。SUBSTR 和 LENGTH 等函数仍然可以正确地处理 GRAPHIC 数据类型，所以这样的实现是有效的。但是请注意：当涉及大量数据时，这样的实现的性能可能不好。

使用 UCS-2 既有优点，也有缺点：

优点：

使用 UCS-2 的数据类型（GRAPHIC、VARGRAPHIC、LONG VARGRAPHIC 和 DBCLOB）的大小按照字符数进行定义，而不是按照字节数，这与 UTF-8 数据类型正好相反。这简化了存储估算，进而简化了物理数据库设计。

当用 UCS-2 数据类型调用时，SUBSTR 和 LENGTH 等函数处理字符。因此，使用它们时不会出问题。

在 Java 应用程序和使用 UCS-2 编码的 Unicode 数据库之间，不需要进行编码页转换。但是，根据运行的平台，Java 应用程序中可能有 Edian 转换。

缺点：

如果 Unicode 数据库中主要存储 ASCII 字符，那么使用 UCS-2 时存储需求会增加。这是因为每个字符用 2 字节进行编码。

在将非 Unicode 数据库迁移到 Unicode 数据库时，对于 UCS-2 编码的情况，字符串数据类型必须转换。这可能会影响 UDF 和存储过程的定义。如果应用程序是用 Java 之外的编程语言编写的，那么一般需要在源代码中调整字符串数据类型。

如何从非 Unicode 数据库迁移到 Unicode 数据库

因为编码集和区域只能在创建数据库时定义，之后不能修改这些设置，所以没有将非 Unicode 数据库迁移到 Unicode 数据库的简便方法。需要先创建一个使用编码集 UTF-8 的新 Unicode 数据库。然后从非 Unicode 数据库导出数据并将数据导入新的 Unicode 数据库。为了简化这个过程，DB2 数据转移实用程序（即 EXPORT、IMPORT 和 LOAD）可以执行自动化的编码页转换。但是，有一些应该注意的问题。如果没有考虑到这些问题，那么就可能遇到问题，甚至可能丢失数据。

对于数据转移，可以选择以下文件格式之一：

Integrated Exchange Format（IXF）

Delimited ASCII Format（DEL）

IXF 是一种二进制格式，不但包含数据，还包含对应表结构的信息。DEL 是一种定界的文本格式，其中的列由一个定界符分隔，行由换行符分隔。

IXF 格式的优点和缺点如下：

优点：

因为 IXF 格式没有用定界符分隔列和行，所以数据中可以使用任何字符。因此，不需要检查选择的定界符是否出现在数据本身中。当数据包含换行符时，这就更重要了。

总的来说，对于 EXPORT、IMPORT 或 LOAD 实用程序，更容易处理 IXF 文件，因为 IXF 是二进制格式，而且元数据还可以简化 IMPORT/LOAD 语法。

缺点：

IXF 文件包含的信息指出一个列是单字节字符列（CHAR/VARCHAR），还是多字节字符列（GRAPHIC/VARGRAPHIC）。在使用 IXF 文件时，不支持将 CHAR/VARCHAR 列导入 GRAPHIC/VARGRAPHIC 列。这是一个问题，尤其是在迁移到使用 UCS-2 格式（这种格式使用 GRAPHIC/VARGRAPHIC 数据类型）存储字符数据的 Unicode 数据库时。

DEL 格式的优点和缺点如下：

优点：

DEL 文件并没有记录数据原来是存储为 CHAR/VARCHAR，还是 GRAPHIC/VARGRAPHIC。所以，对于装载或导入 CHAR/VARCHAR 或 GRAPHIC/VARGRAPHIC 列中的数据没有限制。

缺点：

必须选择不出现在数据本身中的列定界符。行定界符总是换行符，不能自由选择。因为有这个限制，数据字符串必须不包含任何换行符。

与 IXF 文件相比，用 EXPORT、IMPORT 或 LOAD 处理 DEL 文件往往比较复杂，因为 DEL 是一种文本格式，不包含元数据（表结构）。这导致比较复杂的 IMPORT/LOAD 语法。

如果将 DEL 文件中的数据导入或装载到 DB2 数据库中，在 IMPORT 和 LOAD 实用程序之间有一点重要的差异。IMPORT 实用程序总是执行数据文件编码页和数据库编码页之间的转换，而 LOAD 实用程序在默认情况下认为数据文件和数据库采用同样的编码页。如果编码页实际上不一样，那么就会将错误的 数据装载到数据库中。因此对于数据文件和数据库的编码页不同的情况，必须显式地将数据文件的编码页告诉 LOAD 实用程序，这要使用选项 MODIFIED BY CODEPAGE=codepage。这确保正确地执行编码页转换。

如果已经有了一个 Unicode 数据库，希望将数据传输到另一个 Unicode 数据库中，那么必须确保在数据传输过程中信息不受损。正如前面提到的，数据转移实用程序 EXPORT、IMPORT 和 LOAD 在数据文件和数据库之间执行自动化的编码页转换。如果将来自 Unicode 数据库的数据导出到一个客户机，但是这个客户机并不使用 Unicode 作为它的标准编码页，那么在写数据文件时可能会丢失数据。

例如，如果从 Windows 命令行调用 EXPORT 实用程序，命令行在默认情况下使用 Windows 编码页 1252。因此，数据文件也是用编码页 1252 创建的。EXPORT 实用程序执行从 Unicode（数据库编码页）到 1252（客户机编码页）的自动编码页转换。因为编码页 1252 只包含所有 Unicode 字符的一个子集，在编码页 1252 中没有对应编码的那些 Unicode 字符由一个所谓的替换字符来替代。

例如，一个 VARCHAR 列包含小写希腊字母 alpha（UTF-8=0xCEB1）。这个列的内容被导出到采用编码页 1252 的 DEL 文件中。用十六进制编辑器查看这个 DEL 文件，会显示以下值：

　22　1A　22　0D　0A　
　0x22　=　double　quotes　
　0x1A　=　replacement　character　
　0x0D　=　carriage　return　
　0x0A　=　line　feed

字符 alpha 被替换为替换字符（0x1A）；在导出过程中信息（数据）就丢失了。为了避免这个问题，可以使用 DB2 注册表变量 DB2CODEPAGE 覆盖默认的客户机编码页。为了避免数据损失，应该将 DB2CODEPAGE 设置为 1208（Unicode）。重要的是，要在连接数据库之前设置 DB2CODEPAGE，因为数据转移实用程序会在建立数据库连接时判断编码页。再次进行同样的导出，但是在导出之前显式地将客户机编码页设置为 Unicode：db2set DB2CODEPAGE=1208。结果是：

　22　CE　B1　22　0D　0A　
　0x22　=　double　quotes　
　0xCEB1　=　small　greek　alpha　(in　UTF-8　encoding)　
　0x0D　=　carriage　return　
　0x0A　=　line　feed

在这种情况下，字符 alpha 会正确地导出。在这个例子中，使用 DEL 文件作为导出的目标，但是对于 IXF 文件也是一样的。

如何手动输入 Unicode 字符

与 ASCII 字符不同，输入 Unicode 字符可能有问题，因为许多字符不能通过键盘直接输入。在 Windows 中，可以使用 DB2 Command Center 和 Windows Character Map 在 Unicode 数据库中手动输入 Unicode 字符。

如果安装了必要的字体，DB2 Command Center 就能够表示 Unicode 字符。DB2 Technote #1200211 - How to display Unicode characters (including DBCS) in DB2 Control Center on an English Windows environment 解释了如何安装 DB2 Command Center 可以使用的其他字体。

在 DB2 Command Center 的结果集选项卡中可以修改查询的结果集，并添加其他行。要通过 DB2 Command Center 的结果集选项卡输入 Unicode 字符，可以使用 Windows Character Map。可以通过执行命令 charmap 启动 Character Map。

图 3. Windows Character Map

在 Character Map 中，如果选择选项 Advanced View，那么可以选择 Unicode 作为 Character Set，然后可以搜索某些字符。另外，还可以在列表中寻找字符。但是，并不是每种字体都包含每个 Unicode 字符的表示。所以，可能必须选择另一种字体，才能找到某一 Unicode 字符。找到了想要的字符之后，可以使用 Copy 和 Paste 将它放到 DB2 Command Center 中。

图 4. DB2 Command Center 查询结果选项卡

如果不可能通过 DB2 Command Center 访问 Unicode 数据库，那么至少可以使用 Windows Character Map 查明 Unicode 字符的十六进制编码，并可以通过 DB2 CLP 输入它们。这种做法只对 UCS-2 编码的情况（即 GRAPHIC/VARGRAPHIC 列）有效，因为 Windows Character Map 只显示 UCS-2 的十六进制编码。可以使用以下语法在 SQL 语句中用十六进制编码输入字符：

GX'十六进制编码'　
其中的　G　表示图形化字符串，X'.　.　.'　表示插入与十六进制值对应的字符。

例如，以下 INSERT 语句将由 alpha、beta 和 gamma 组成的字符串存储在 UCTABLE_1 表的 GRAPHIC 列 UCS2COL 中：

INSERT INTO UCTABLE_1 (UCS2COL) VALUES (GX'03B103B203B3')

如果知道字符的 UTF-8 编码，也可以用这种方法在 CHAR 或 VARCHAR 列中输入 Unicode 字符。在这种情况下，语法 X'十六进制编码' 就足够了，因为并不处理图形化列。所以 UTF-8 的 INSERT 语句像下面这样：

INSERT INTO UCTABLE_2 (UTF8COL) VALUES (X'C3B1C3B2C3B3')

如果只知道 UCS-2 十六进制编码，还有另一种方法可以在 UTF-8 列中输入 Unicode 字符。可以先用 UCS-2 十六进制编码将字符存储在 UCS-2 列中，然后用带 SELECT 的 INSERT 语句填充 UTF-8 列。此时，DB2 自动执行从 UCS-2 到 UTF-8 的转换。

INSERT INTO UCTABLE_2 (UTF8COL) SELECT UCS2COL FROM UCTABLE_1

Java 编程语言也允许以 UCS-2 十六进制编码的形式输入字符。在 Java 中与 DB2 CLP INSERT 语句等效的代码如下：

java.sql.PreparedStatement　pstmt　=　con.prepareStatement("INSERT　INTO　UCTABLE　
　(UCS2COL)　VALUES　(?)");　
　pstmt.setString(1,　Character.toString('\u03B1')　+　
　Character.toString('\u03B2')　+　Character.toString('\u03B3'));　
pstmt.executeUpdate();

与 DB2 CLP 版本相反，Java 版本独立于目标列的编码，这意味着无论对于 GRAPHIC 或 VARGRAPHIC 列（UCS-2 编码），还是 CHAR 或 VARCHAR 列（UTF-8 编码），INSERT 命令都可以执行。这是因为在将 UCS-2 十六进制编码发送到 Unicode 数据库（此时发生编码页转换）之前 Java 会解释它们。

理解 Java 应用程序如何访问 DB2 Unicode 数据

在演示 Java 应用程序如何访问 Unicode 数据库之前，需要确保应用程序正确地显示数据。因此，设置客户机环境是很重要的。

设置客户机环境

在默认情况下，应用程序编码页源自编译和绑定应用程序时所在的操作系统的设置。例如，为了在 Windows 上显示中文字符，需要设置 Windows 地区和语言。步骤如下：

图 5. 设置系统地区

可以在 DOS 提示下输入 chcp 来检查活动的编码页。

　C:\Program　Files\IBM\SQLLIB\java\jdk\jre\lib>chcp　
　Active　code　page:　936

客户机应用程序编码页由活动环境变量决定。可以用 DB2CODEPAGE 值覆盖应用程序编码页。如果客户机采用正确的地区设置和语言设置，那么应该不需要使用 DB2CODEPAGE 变量。如果 DB2CODEPAGE 注册表变量设置为不正确的值，那么可能会造成不可预期的结果和潜在的数据损失。如果应用程序编码页与 Unicode 数据库不同，那么数据库管理器会将字符串从应用程序编码页转换为数据库 Unicode 编码页。Java 在内部按照 UCS-2 格式存储字符串。

希伯来语和阿拉伯语等语言的方向与一般语言不同，对于这些语言，还应该设置 DB2BIDI 环境变量。

Java 数据库连接性

在客户机-服务器体系结构中，当 Java 应用程序访问数据库时，需要 Java Database Connectivity™（JDBC）。JDBC 是一个应用程序编程接口（API），Java 应用程序使用它本地或远程访问关系数据库。

DB2 Universal JDBC Driver 包含 JDBC Type 2 连接性、JDBC Type 4 连接性以及 SQLJ 支持。当应用程序装载 DB2 Universal JDBC Driver 时，装载一个驱动程序实例来提供 Type 2 和 Type 4 实现。在应用程序中，可以使用这个驱动程序实例建立 Type 2 和 Type 4 连接。

在安装 DB2 UDB for Linux, UNIX, and Windows 时，就安装了 JDBC。Type 4 驱动程序的 db2jcc.jar 和 sqlj.zip 文件安装在 sqllib/java 目录中，这些文件应该添加到 CLASSPATH 中。Universal Type 2 Connectivity 需要的 db2jcct2.dll 将安装在 sqllib/bin 目录中。

Java Development Kit（JDK）

在安装 DB2 UDB Version 8.2 时，还会安装最新的 IBM Java Development Kit（JDK）（如果还没有安装的话）。如果 DB2 UDB 安装是对以前 DB2 版本的更新，那么需要手动安装 JDK。IBM 提供了 Java Runtime Environment（JRE）的一个版本，其中包含所有字符转换代码。从 IBM JDK 1.4 开始，用于编码页转换的库存储在几个 JAR 文件中（比如 core.jar、graphics.jar、xml.jar 和 server.jar），而不是像其他 JDK 实现中那样存储在单个 rt.jar 文件中。在默认情况下，IBM JDK 安装在 sqllib/java 目录下。

如果考虑使用其他 JDK，那么可以将 JDK 安装在其他目录中，并在 PATH 和 CLASSPATH 变量中指定 JDK 目录。应该注意，所有平台的 Sun JDK V1.3.1 以及 Solaris 和 Linux 的 JRE V1.3.1 标准版支持大多数 IBM 编码。Windows 的 Sun JDK V1.3.1 有两个不同版本：US-only 和 International。基本编码集存储在 rt.jar 中，其中包括表 2 中的编码方案。

表 2. rt.jar 中的基本编码集字符

扩展编码集存储在 charsets.jar 中。如果考虑使用 US-only JDK 和扩展编码集，那么需要安装国际版或者将 charsets.jar 文件包含在 $JAVAHOME/JRE/LIB/ 目录中。

对于 JDK 1.3 和 JDK 1.3 以前的版本，字符转换器内置在 sun.io 中，比如 ByteToCharCp1250。java.util.String、java.io.InputStreamReader 和 java.io.OutputStreamWriter 在内部调用这些转换器。在 JDK 1.4 中，有几个新的公共类，用于将 16 位 Unicode（Java char）转换到其他编码页。这些类是：

java.nio.charset.Charset：这个类定义了用于创建解码器和编码器的方法，以及用于获取与字符集相关联的各种名称的方法。

java.nio.charset.CharsetDecoder：这个类定义了一个引擎，这个引擎可以将采用特定字符集的字节序列转换为 16 位 Unicode 字符序列。

java.nio.charset.CharsetEncoder：这个类定义了一个引擎，这个引擎可以将 16 位 Unicode 字符序列转换为采用特定字符集的字节序列。

Type 2 和 Type 4 连接性

使用 DB2 Universal JDBC Type 4 驱动程序的 Java 应用程序不需要在客户计算机上安装 DB2 客户机。如果使用 DB2 Universal JDBC Type 2 驱动程序，应用程序就需要 DB2 客户机。要使用 Universal JDBC Type 2 驱动程序，db2jcct2.dll（Windows）或 libdb2jcct2.so（UNIX）或 libdb2jcct2.sl（HP-UNIX）需要分别安装在 sqllib\bin 或 sqllib/lib 中。当客户机上的 Java 应用程序使用 universal JDBC 驱动程序访问 DB2 服务器上的 Unicode 数据库时，DB2 Universal JDBC Driver（Type 2 或 Type 4）采用 UCS-2 格式将数据发送到数据库服务器；因此，对于 Unicode 数据库，不需要编码页转换。使用 Java 内置的字符转换器对从数据库服务器发送到客户机的字符数据进行转换。DB2 Universal JDBC Driver 支持的转换受到底层 JRE 实现的限制。

访问 DB2 Unicode 数据的 Java 应用程序示例

访问 Unicode 数据库中 Unicode 表的 Java 应用程序

在这个示例中，使用以下 CREATE DATABASE 和 CREATE TABLE 语句定义一个 Unicode 数据库：

Create　database　test2　using　codeset　UTF-8　territory　US　
Create　table　test_table(record_no　integer,　description　varchar(50),　comment　CLOB)

对于以上定义，还可以使用以下命令从数据库 TEST2 的数据库配置中找到编码页信息：

　DB2　GET　DB　CFG　FOR　TEST2

数据库编码集、数据库编码页和区域值如下：

　Database　Configuration　for　Database　
　Database　configuration　release　level　　　　　　=　0x0a00　
　Database　release　level　　　　　　　　　　　　　=　0x0a00　
　Database　territory　　　　　　　　　　　　　　　=　US　
　Database　code　page　　　　　　　　　　　　　　　=　1208　
　Database　code　set　　　　　　　　　　　　　　　　=　UTF-8　
　Database　country/region　code　　　　　　　　　　=　1

在这个示例中，我们演示如何让 Java 应用程序将中文（非 ASCII）字符输入到 Unicode 数据库中。为了显示和输入中文字符，将系统语言地区设置为 Chinese Simplified（GB2312，编码页 936）。细节见图 5。如果希望输入中文字符，还需要设置 Input Locales。可能需要插入 Windows 安装光盘并重新启动计算机。

图 6. 设置 Windows 地区和语言

以下 Java 程序将一个混合字符串（包含英语和中文字符）插入 TEST_TABLE 的 DESCRIPTION 列，并在屏幕上显示结果：

图片看不清楚？请点击这里查看原图（大图）。

应该注意，如果 Windows 环境没有设置为中文编码页，那么示例程序中就显示不出中文字符，而是显示一系列问号。

在执行这个程序时，结果如下：

图 7. 程序结果 1

让我们输入 chcp 1252，将活动编码页改为 1252，并再次运行这个程序。结果如下：

图 8. 程序结果 2

现在看不到中文字符了。这是因为活动编码页 1252 不包含非 ASCII 中文字符的编码点。因此，如果没有正确地设置客户机编码，就不能正确地显示。

现在，可以重新设置活动编码页 936 并在字符串末尾加 4 个中文字符。这会使字符串的长度增加 12 字节，然后重新编译并运行 Java 程序。您会遇到以下的 SQLCODE -443：

图 9. 程序结果 3

这是因为每个中文字符占用 3 字节。原来的字符串占用 48 字节。现在，修改后的字符串占用 60 字节，这超过了 DESCRIPTION 的定义。因此，一定要确保列定义的长度足够处理 Unicode 数据。

访问非 Unicode 数据库中 Unicode 表的 Java 应用程序

DB2 Sample 数据库是使用默认的 OS 编码页 1252 定义的。要想在 Sample 数据库中创建 Unicode 表，需要通过执行以下命令，将数据库配置 ALT_COLLATE 设置为 IDENTITY_16BIT：

　Update　database　configuration　using　alt_collate　identity_16bit

数据库配置中的 ALT_COLLATE 必须更新。

　Update　database　configuration　using　alt_collate　identity_16bit
　Database　territory　　　　　　　　　　　　　　　=　US　
　Database　code　page　　　　　　　　　　　　　　　=　1252　
　Database　code　set　　　　　　　　　　　　　　　=　IBM-1252　
　Database　country/region　code　　　　　　　　　　=　1　
　Database　collating　sequence　　　　　　　　　　=　UNIQUE　
　Alternate　collating　sequence　　　(ALT_COLLATE)　=　IDENTITY_16BIT

然后可以像下面这样创建 Unicode 表：

Create　test　Unicode_table　(record_no　integer,　description　varchar(50))　CCSID　UNICODE

以下程序仅仅读取非 Unicode 数据库中的 Unicode 表。

public　class　UnicodeExample_T4　
{　
　　public　static　void　main(String[]　args)　{　
　　　　try　{　
　　　　　　//　create　data　source　
　　　　　　com.ibm.db2.jcc.DB2SimpleDataSource　ds　=　
　　　　　　　　new　com.ibm.db2.jcc.DB2SimpleDataSource();　
　　　　　　//　set　connection　properties　
　　　　　　ds.setServerName("localhost");　
　　　　　　ds.setPortNumber(50000);　
　　　　　　ds.setDatabaseName("sample");　
　　　　　　ds.setDriverType(4);　
　　　　　　//　get　connection　
　　　　　　java.sql.Connection　con　=　ds.getConnection("userid",　"passw");　
　　　　　　java.sql.Statement　stmt　=　con.createStatement();　　　　　　　
　　　　　
　　　　　　String　query　=　"select　record_no,　description,　comment　from　unicode_table";　
　　　　　　java.sql.ResultSet　rs　=　stmt.executeQuery(query);　
　　　　　　while　(rs.next())　{　
　　　　　　　　System.out.println("\n"　+　rs.getString(1)+"　　　"+rs.getString(2));　
　　　　　　}　
　　　　　　rs.close();　
　　　　　　stmt.close();　
　　　　　　con.close();　
　　　　}　catch　(Exception　e)　{　
　　　　　　e.printStackTrace();　
　　　　}　
　　}　
}

以上程序的结果是：

　C:\Program　Files\IBM\SQLLIB\java\jdk>chcp　
　Active　code　page:　1252　
　
　C:\Program　Files\IBM\SQLLIB\java\jdk>bin\java　UnicodeExample_T4　
　
　1　　　Test　data　for　unicode　table　
　C:\Program　Files\IBM\SQLLIB\java\jdk>

将以上代码修改为同时访问 Unicode 表和非 Unicode 表，如下所示：

　//　execute　a　query　
java.sql.Statement　stmt　=　con.createStatement();　　　　　　　
　　　　　
String　query　=　"select　employee.lastname,　Unicode_table.description　from　employee,　
　Unicode_table";　
　　　　　　java.sql.ResultSet　rs　=　stmt.executeQuery(query);　
　.　.　.

正如前面提到的，会接收到以下错误，因为不能在同一个 SQL 语句中同时访问 Unicode 表和非 Unicode 表：

　C:\Program　Files\IBM\SQLLIB\java\jdk>chcp　
　Active　code　page:　1252　
　
　C:\Program　Files\IBM\SQLLIB\java\jdk>bin\java　UnicodeExample_T4　
　com.ibm.db2.jcc.c.SqlException:　DB2　SQL　error:　SQLCODE:　-873,　SQLSTATE:　53090,　S　
　QLERRMC:　Different　encoding　schemes　in　one　statement

结束语

本文解释了 DB2 UDB for Linux, UNIX, and Windows 如何支持 Unicode。根据实践中遇到的问题，我们讨论了 DB2 UDB Unicode 支持的几个方面。利用我们提供的信息，您可以开始开发访问 DB2 UDB Unicode 数据库的国际化应用程序。

下载