Db2 在使用CODEUNITS32修改表以支持unicode行为之后，应用程序行为会有什么变化？

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

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

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

---

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

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

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

它还可以在某些函数（如SUBSTR）中启用字符语义，以便它们在处理CODEUNITS32列时处理字符，而不是字节。除非处理位数据列，否则子字符串将始终使用字符语义

所以一个CHAR4是CHAR4，八位字节是4字节长，如果它们在UTF-8中都是单字节，那么最多可以容纳4个字符。对于3字节长的欧元，它只能容纳4欧元，不能容纳42欧元

ACHAR4 CODEUNTIS32的长度为16字节，最多可容纳4个字符。它可以持有欧元，但不能持有2345欧元

值得考虑的是避免使用CHARx代码单元32，而选择VARCHARx代码单元32。UTF-8不能很好地处理固定宽度的数据类型。更常见的UTF-8字符的长度为1或2字节，因此通常CHARx CODEUNITS32列的填充空间将超过50%

代码单元32

指示长度属性的单位为Unicode UTF-32代码单位，近似以字符为单位计数

此长度单位不影响数据类型的基础代码页

数据值的实际长度通过计算UTF-32来确定 将单位编码为数据转换为UTF-32

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

代码单元32可以是 根据环境设置明确指定或确定

此外，出于兴趣，图形/变量图形和列存储在UTF-16中，默认为CODEUNITS16，但也可以使用CODEUNITS32

---

在VARCHARX八位字节数据类型中使用欧元字符没有任何问题。您应该记住，不应该使用substr之类的面向字节的字符串函数来处理此类字符串。使用此角色时，确切的命令/语句是什么？确切的错误消息是什么？这很有帮助，那么，在编译CODEUNITS32定义的表列的数据时，是否需要更改应用程序codeC application/Java？我没有想到so@MOHAMMADSHAMSHADHUSSAINJava代码（no.C）取决于代码的编写方式。但这并不取决于代码单元32。这取决于您的代码是否适合UTF-8。