非 Unicode 数据库中的 XML

核心提示： 当数据库服务器收到这条 SQL 语句并将其转换到数据库代码页时会遇到一个问题，中文字符都不能在数据库代码页（只由 ISO-8859-1 中的 ASCII 字符组成）中表示，非 Unicode 数据库中的 XML(8)，这时，DB2 用一个替换字符来替代这些缺失的字符，抛出一个错误（-20429）

当数据库服务器收到这条 SQL 语句并将其转换到数据库代码页时会遇到一个问题，中文字符都不能在数据库代码页（只由 ISO-8859-1 中的 ASCII 字符组成）中表示。这时，DB2 用一个替换字符来替代这些缺失的字符。取决于目标代码页，这个替换字符的代码点可能有所不同，但是对于代码页 819 (ISO-8859-1)，它是十六进制字符 0x1A。在客户机上，这通常显示为一个问号（'?'）。

替换字符的存在意味着数据完整性已经丢失。原始文档的中文字符被丢失，通过将数据流发回客户机不能获得这些字符。在任何其他代码页中，替换字符总是被转换为另一个替换字符。

在以上 XML 文档中，XML 解析器将书的本地题目解析为 "????"（每个 ? 字符为 0x1A 代码点）。这时一个合法的 XML 字符流，解析器并不会抛出错误，但是 XML 列中的数据现在却被毁坏。选择这个文档只能导致替换字符串被传回客户机。

注意，如果数据库是以代码页 943 创建的，由于该代码页支持 Shift-JIS 编码代码点，上述 INSERT 语句是安全的，并且文档会被插入到数据库中。对于俄文的例子，只有将 XML 文档插入支持 ISO-8859-5 (Cyrillic) 编码的数据库才是安全的。

如果用户经常使用包含大量数据库代码页中不能表示的代码点的 XML 文档，那么最完美的解决方案是使用 Unicode 数据库。在服务器上，解析或串行化不会引入替换字符。注意，将数据返回到非 Unicode 数据库仍然可能引入替换字符。但是，数据库中的 XML 文档不受影响。

使用 ENABLE_XMLCHAR 参数

在 Viper 2 版中，有一个新的 DBA 配置参数，该参数可以防止在 CHAR 类型的主机变量或字符串上执行 XML 解析。这个参数作用范围为整个数据库，它的名称为 ENABLE_XMLCHAR。默认情况下，所有数据库创建时 ENABLE_XMLCHAR 被设置为 TRUE，但是也可以将它设置为 FALSE，以便当用户在 CHAR、VARCHAR 或 CLOB 类型且非 BIT DATA 类型的主机变量上执行进行隐式或显式 XMLPARSE 操作的查询时，抛出一个错误（-20429）。在这个场景中，CHAR FOR BIT DATA、VARCHAR FOR BIT DATA 和 BLOB 都被接受。 更改这个数据库参数值的命令是：