我们正处于将一些表从 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后，我们通过手动将特殊字符插入表进行了一些试点测试，并且测试成功。
对列使用CODEUNITS32的字符串单位规范不会更改列的编码，对于 CHAR/VARCHAR 列，数据仍以 UTF-8 格式存储。
它改变色谱柱的物理长度(CHAR(或最大长度(VARCHAR(4倍。
它还在某些函数(例如SUBSTR()(中启用"字符语义"，以便它们在处理CODEUNITS32列时处理字符而不是字节。(SUBSTRING()将始终使用字符语义(除非处理FOR BIT DATA列((
因此，CHAR(4)是CHAR(4 OCTETS)长度为 4 个字节，如果它们都是 UTF-8 的单字节，则最多可以容纳 4 个字符。对于 3 个字节长的 €，它只能保存€4而不是€42
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