一、达梦数据库字符集那些事儿
第一次接触达梦数据库的朋友，可能会被它的字符集问题搞得晕头转向。比如明明在MySQL里跑得好好的SQL脚本，到达梦这儿就报错，或者显示一堆乱码。这就像你带着北方口音去广东点菜，老板听得一头雾水——本质上就是编码没对上。
举个实际例子：我们有个Java应用要迁移到达梦数据库，原库用的是UTF-8，而达梦默认是GB18030。直接导入数据时，中文字符全变成了"???"。
// Java JDBC连接示例（技术栈：Java + DM8）
String url = "jdbc:dm://localhost:5236/SAMPLE";
Properties props = new Properties();
props.put("user", "SYSDBA");
props.put("password", "SYSDBA123");
props.put("charsetEncoding", "GB18030"); // 关键参数
Connection conn = DriverManager.getConnection(url, props);
这个charsetEncoding参数就像翻译官，告诉JDBC驱动程序如何转换字符。如果不设置，就会遇到经典的"锟斤拷"乱码问题。
二、字符集冲突的典型症状
达梦数据库的字符集问题通常表现为三种症状：
- 导入导出乱码：从其他数据库导出的SQL文件到达梦执行后出现乱码
- 应用程序显示异常：Java/Python等程序读取的数据变成问号或火星文
- 排序比较失效：中文字符串的WHERE条件匹配失败
比如这个Python连接示例：
# Python示例（技术栈：Python3 + dmPython）
import dmPython
conn = dmPython.connect(
user='SYSDBA',
password='SYSDBA123',
server='localhost',
port=5236,
charset='gb18030' # 必须与服务端一致
)
cursor = conn.cursor()
cursor.execute("SELECT '中国'") # 正常显示中文
如果不指定charset参数，返回的中文可能会变成\xe4\xb8\xad\xe5\x9b\xbd这样的字节串。
三、解决方案实战手册
3.1 服务端配置调整
达梦数据库安装时就可以指定字符集，但很多人会忽略这个步骤。如果已经安装完成，可以通过以下SQL修改：
-- 查看当前字符集配置
SELECT * FROM V$PARAMETER WHERE NAME LIKE '%CHARACTER%';
-- 修改字符集（需要重启生效）
ALTER SYSTEM SET CHARACTER_SET = 'UTF-8' SCOPE=SPFILE;
注意：字符集修改是"牵一发而动全身"的操作，必须评估对现有数据的影响。
3.2 客户端连接方案
不同编程语言需要采用对应的解决方案：
Java方案
// 完整连接示例
String url = "jdbc:dm://127.0.0.1:5236/test?charSet=gb18030&compatibleMode=mysql";
// compatibleMode可以让达梦兼容MySQL的语法行为
.NET方案
// C#连接示例（技术栈：.NET 6）
var builder = new DmConnectionStringBuilder {
Host = "localhost",
Port = 5236,
UserId = "SYSDBA",
Password = "SYSDBA123",
Encoding = "gb18030" // 关键参数
};
using var conn = new DmConnection(builder.ConnectionString);
四、避坑指南与最佳实践
迁移前的检查清单：
- 源数据库的字符集（MySQL的
show variables like 'character%'） - 目标达梦的字符集（
SELECT * FROM V$NLS_PARAMETERS） - 应用程序使用的编码（特别是HTTP接口的Content-Type）
- 源数据库的字符集（MySQL的
ETL工具配置： 使用Kettle等ETL工具时，要在转换步骤中明确指定编码：
输入步骤 → 设置源字符集为UTF-8 输出步骤 → 设置目标字符集为GB18030极端情况处理： 当遇到无法转换的特殊字符时，可以考虑使用二进制中间格式：
-- 使用HEX函数处理特殊字符 INSERT INTO test VALUES(HEX('特殊字符串')); -- 读取时转换 SELECT UNHEX(content) FROM test;
五、技术深潜：字符集背后的原理
达梦数据库的字符集处理分为三个层次：
- 数据库实例级：通过参数文件(dm.ini)配置
- 表空间级：创建表空间时可指定
- 列级：建表时列的CHAR/VARCHAR定义
这种多层次的设置带来了灵活性，但也增加了复杂度。比如同一个数据库里可以存在不同编码的表：
CREATE TABLE table1 (
name VARCHAR(20) CHARACTER SET utf8
) TABLESPACE ts_utf8;
CREATE TABLE table2 (
name VARCHAR(20) CHARACTER SET gb18030
) TABLESPACE ts_gb18030;
六、应用场景全解析
6.1 政务系统迁移
某省政务平台从Oracle迁移到达梦时，遇到大量存储过程因字符集报错。解决方案是：
- 使用DM DTS工具转换时勾选"强制字符转换"
- 对CLOB字段单独处理
- 在应用层增加字符校验过滤器
6.2 金融数据交换
银行核心系统要求GB18030编码，而外围系统使用UTF-8。达梦的解决方案是：
-- 创建专门做编码转换的视图
CREATE VIEW v_convert AS
SELECT CONVERT(name USING GB18030) AS name
FROM utf8_table;
七、技术选型的思考
达梦字符集方案的优点：
- 支持国家标准的GB18030编码
- 提供多种兼容模式（MySQL/Oracle等）
- 细粒度的字符集控制
需要注意的缺点：
- 与开源生态的默认UTF-8存在兼容成本
- 部分字符串函数的行为差异
- 跨字符集JOIN可能带来性能问题
八、终极解决方案
经过多个项目的实践，我们总结出"三步走"策略：
评估阶段：
- 使用
dmdbcvt工具分析编码差异 - 统计各表的字符类型分布
- 使用
过渡阶段：
- 建立双字符集兼容环境
- 开发转码中间件
稳定阶段：
- 统一为GB18030编码
- 建立编码规范文档
示例转码中间件的核心代码：
// 编码转换过滤器（技术栈：Spring Boot）
public class EncodingFilter implements Filter {
@Override
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException {
request.setCharacterEncoding("GB18030");
response.setContentType("text/html;charset=GB18030");
chain.doFilter(request, response);
}
}
九、写给开发者的建议
所有SQL脚本头部显式声明编码：
-- -*- coding: GB18030 -*- CREATE TABLE...在连接池配置中强制指定字符集：
<!-- Druid连接池示例 --> <property name="connectionInitSqls" value="set names gb18030"/>对字符串字段建立校验规则：
ALTER TABLE users ADD CONSTRAINT chk_name CHECK(name = CONVERT(CONVERT(name USING binary) USING gb18030));
记住，字符集问题就像做菜时的火候——前期配置越仔细，后期就越不会"糊锅"。
十、总结与展望
处理达梦数据库字符集问题的核心在于"一致性"：客户端、服务端、应用程序三位一体。随着达梦8.0版本的发布，对Unicode的支持更加完善，但在与国际化系统对接时，仍然建议：
- 新项目统一采用UTF-8编码
- 历史系统保留GB18030但要明确边界
- 在API网关层做编码转换
最后送大家一个检查清单：
✓ 连接字符串带字符集参数
✓ 数据库服务端配置验证
✓ 应用程序响应头检查
✓ ETL工具转换设置
✓ 定期编码一致性校验
评论