时间戳

首页 > 解决方案 > 使用 CODEUNITS32 更改表以支持 unicode 行为后，应用程序行为会发生什么变化？

db2 - 使用 CODEUNITS32 更改表以支持 unicode 行为后，应用程序行为会发生什么变化？

问题描述

我们正处于将一些表从 AS400 DB 迁移到 DB2 LUW(V11.1) 的阶段。迁移时，我们在源数据库 (AS400)-（带有 CHAR 的列）中发现了一些特殊字符 (€)，如果我们无法使用 CODEUNITS32、DB2 LUW 数据库配置字节编码设置为 UTF-8 更改表列，则会导致错误.

我们想了解，将 char 列更改为 CODEUNITS32 后应用程序的行为是什么，我是否需要在应用程序级别（C 和 Java 应用程序）更新任何配置以处理字符编码集？

更改为 CODEUNITS32 后 - 我的 C 应用程序能够编译并能够处理字符字节从每字符 8 位（UTF-8）到每字符 4 字节（CODEUNITS32）的变化？- 我的 Java 应用程序能够处理字符字节从每字符 8 位 (UTF-8) 到每字符 4 字节 (CODEUNITS32) 的变化吗？

在将列定义从 CHAR 设置为 CODEUNITS32 并测试成功后，我们通过手动向表中插入特殊字符进行了一些试点测试。

标签： db2db2-luw

解决方案

对列使用字符串单位规范CODEUNITS32不会更改列的编码，对于 CHAR/VARCHAR 列，数据仍以 UTF-8 存储。

它将列的物理长度 ( CHAR) 或最大长度 ( VARCHAR) 更改为 4 倍。

它还在某些函数中启用“字符语义” ，例如 ，以便它们在处理列SUBSTR()时处理字符，而不是字节。CODEUNITS32（SUBSTRING()将始终使用字符语义（除非处理FOR BIT DATA列））

所以 a CHAR(4)isCHAR(4 OCTETS)有 4 个字节长，如果它们都是 UTF-8 中的单字节，则最多可以容纳 4 个字符。对于 3 字节长的 €，它只能容纳 say€4而不是€42

A 的CHAR(4 CODEUNTIS32)长度为 16 个字节，最多可容纳 4 个字符。它可以保持€€€€但不能€2345

值得考虑避免CHAR(x CODEUNITS32)和偏爱VARCHAR(x CODEUNITS32)。UTF-8对于固定宽度的数据类型并不能很好地发挥作用。更常见的 UTF-8 字符长度为 1 或 2 个字节，因此通常一CHAR(x CODEUNITS32)列将容纳超过 50% 的空间填充。

https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0008470.html

CODEUNITS32

表示长度属性的单位是 Unicode UTF-32 代码单位，近似于字符计数。

这个长度单位不影响数据类型的底层代码页。

数据值的实际长度是通过计算 UTF-32 代码单元来确定的，就像数据被转换为 UTF-32 一样。

CODEUNITS32 的字符串单元只能在 Unicode 数据库中使用。

CODEUNITS32 可以根据环境设置明确指定或确定。

另外，出于兴趣，GRAPHIC/VARGRAPHIC和列以 UTF-16 存储，默认为CODEUNITS16，但也可以使用CODEUNITS32.

https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0008471.html

推荐阅读