在使用DB2存储中文、日文等多字节字符数据时，除了普通的VARCHAR类型，很多应用会用到NCHAR、NVARCHAR这类国家字符类型。这类数据到底采用什么字符集存储，取决于数据库的国家字符映射设置，也就是常说的nchar_mapping相关配置。如果对这个参数理解不到位，很容易出现字符存储异常、长度计算不对，甚至插入数据报错的问题。本文将围绕DB2的国家字符映射机制展开，讲解它的取值规则、配置方法和常见问题的排查方式。
什么是国家字符映射以及它与代码页的关系
在DB2中，每个数据库都有一个数据库代码页（database code page），它决定了普通字符类型如CHAR、VARCHAR的编码方式。除此之外，数据库还有一个图形字符集的概念，专门服务于GRAPHIC、VARGRAPHIC、NCHAR、NVARCHAR这些图形字符类型。这两套编码体系是相互独立的，也就是说，数据库代码页是GBK，图形字符集完全可能是UTF-16，反之亦然。
国家字符映射的本质，就是定义NCHAR系列类型底层使用的编码。DB2内部维护了代码页与图形字符集之间的映射规则。比如当数据库代码页为1208（UTF-8）时，图形字符数据通常映射到UCS-2（代码页1200）进行存储；当代码页是1386或1388等双字节代码页时，图形字符集会映射到对应的DBCS代码页。这个映射关系在创建数据库那一刻就固定下来了，事后无法通过alter database之类的命令修改。
需要特别注意的是，在DB2 LUW中，这个映射更多体现为建库参数产生的隐式结果，而在连接JDBC、ODBC等客户端驱动时，驱动层面也有自己的图形字符集转换逻辑。理解这一点有助于区分问题是出在数据库端还是客户端编码转换环节。
如何查看和指定国家字符映射的取值
查看当前数据库的字符集配置，最直接的方式是查询目录表或者使用get db cfg命令。下面两条命令分别查看数据库配置和代码页信息：
-- 查看数据库配置中的代码页信息 db2 get db cfg for sample | grep -i code -- 通过SYSCAT目录表确认代码页 SELECT CODEPAGE, TERRITORY, COLLATE FROM SYSCAT.DATATYPES WHERE TYPESCHEMA = 'SYSIBM' FETCH FIRST 1 ROWS ONLY;
输出中的codepage字段就是数据库代码页。对于UTF-8数据库，该值为1208，此时NCHAR、NVARCHAR数据将以UCS-2形式存储，每个字符固定占用两个字节，这也是为什么NVARCHAR(10)可以稳定存放10个任何语言的字符，而不像VARCHAR那样受字节长度限制。
如果希望明确控制图形字符的编码，可以在创建数据库时通过CODESET和TERRITORY子句来约定，例如：
-- 创建UTF-8数据库，图形字符隐式映射为UCS-2 CREATE DATABASE mydb USING CODESET UTF-8 TERRITORY CN COLLATE USING SYSTEM; -- 创建GBK数据库，图形字符映射为对应DBCS代码页 CREATE DATABASE mydb2 USING CODESET GBK TERRITORY CN COLLATE USING SYSTEM;
两个库创建完成后，NCHAR数据的实际存储编码是不同的。UTF-8库中NVARCHAR按UCS-2处理，而GBK库中则按GBK双字节处理。应用层选型时要考虑这一点，尤其是数据需要跨库迁移或通过复制工具同步时，两侧的映射不一致会引发字符转换开销甚至数据损坏。
常见乱码问题与排查思路
实际运维中，与国家字符映射相关的问题多数表现为中文乱码或长度溢出。典型的场景是客户端应用编码与数据库图形字符集不一致。例如数据库是GBK映射，而JDBC连接串中未指定正确的字符集属性，驱动会按默认规则转换，结果中文写入后变成问号。排查的第一步是确认三端编码：客户端操作系统编码、应用连接串编码、数据库代码页和图形字符集，三者对齐后再测试。
第二类问题是长度计算混淆。NCHAR类型按字符计数而非字节计数，一些从Oracle或SQL Server迁移过来的应用习惯性地按字节估算长度，导致字段定义过短。DB2提供了LENGTH和OCTET函数分别返回字符数和字节数，可以用来验证实际占用情况：
-- 创建图形字符测试表 CREATE TABLE t_nchar_test ( id INT, name NVARCHAR(20) ); -- 插入中文数据 INSERT INTO t_nchar_test VALUES (1, '数据库字符映射测试'); -- 分别查看字符数与字节数 SELECT name, LENGTH(name) AS char_len, OCTET(name) AS byte_len FROM t_nchar_test;
在UTF-8数据库上执行上面的查询，char_len返回7而byte_len返回14，正好印证了UCS-2双字节的存储特征。如果查询结果与预期不符，就说明数据库的映射关系与你的假设有出入，需要回到建库参数去核实。
第三类注意点是DB2兼容Oracle特性（开启ORA兼容矢量）后，NCHAR行为会向Oracle靠拢，字符集语义可能与纯DB2模式存在细微差异。建议在启用兼容特性前后分别做一轮字符类回归测试，把NCHAR字段的读写、长度、比较排序都覆盖到，避免上线后才发现映射行为不符合预期。
总结来看，DB2的国家字符映射在建库时即已确定，核心是理解数据库代码页与图形字符集的对应关系。做好应用编码、连接串编码与数据库编码三者统一，再配合LENGTH与OCTET这类函数做验证，绝大多数字符存储问题都能定位清楚。
DB2nchar_mapping国家字符映射修改时间：2026-09-14 07:12:32