Oracle 9i 与 19c 跨版本字符集乱码（US7ASCII ↔ AL32UTF8）DBLink 解决方案

项目对接中遇到了棘手的字符集乱码问题：甲方老旧Oracle 9i数据库字符集为SIMPLIFIED CHINESE_CHINA.US7ASCII ，我方部署的Oracle 19c字符集为SIMPLIFIED CHINESE_CHINA.AL32UTF8 。通过DBLink互通数据时，双方查询到的汉字均显示为?????乱码。由于甲方系统老旧且为核心业务方，无法调整其环境，只能由我方自主解决，经过多方调研验证，整理出完整解决方案及核心原理。

一、Oracle字符集核心基础（必知）

Oracle字符集属于全球化支持（Globalization Support） 范畴，也叫国家语言支持（NLS），核心作用是按本地语言、格式完成数据的存储、处理与检索，支持多语言、多地域适配。

1. 字符集命名规则

Oracle字符集统一遵循：<语言><比特位数><编码> 格式

• 例：AL32UTF8 → AL（All，全语言支持）+32（32位）+UTF8（Unicode编码）

• NLS_LANG格式：语言_地区.字符集（如American_America.AL32UTF8）

2. UTF8 与 AL32UTF8 关键区别

• UTF8：Oracle 8i引入，对应Unicode 3.0，兼容性强，支持老旧版本（8i及以下）；

• AL32UTF8：Oracle 9i引入，对应Unicode 5.0，字符支持更全，不兼容8i及以下版本；

• 生产建议：9i及以上版本优先用AL32UTF8，需兼容8i则用UTF8（Oracle 11g后UTF8已非推荐字符集）。

3. 字符集乱码核心原因

数据库服务端字符集 、客户端字符集 、会话字符集不一致，是跨库/跨版本乱码的根本原因。

---

二、Oracle字符集查询方法

1. 查询数据库服务端字符集（核心）

-- 方式1（简洁）
select userenv('language') from dual;

-- 方式2（详细）
select * from nls_database_parameters;

2. 查询客户端字符集

select * from nls_instance_parameters;

3. 查询当前会话字符集

select * from nls_session_parameters;

4. Oracle字符集优先级

会话级修改(alter session) > 系统环境变量 > 注册表 > 数据库参数文件

---

三、三种可行解决方案（适配甲方场景）

方案一：统一字符集（最优、推荐优先尝试）

核心思路：通过修改客户端字符集，让两端字符集兼容，不改动数据库核心配置。

1. 修改客户端字符集（安全无风险）

• Windows注册表修改：

运行regedit打开注册表，路径：

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraDb10g_home1

修改NLS_LANG值，与目标库保持一致（如甲方为SIMPLIFIED CHINESE_CHINA.US7ASCII）。

• 环境变量修改（注册表无效时备用）：

CMD执行临时生效：

set nls_lang=SIMPLIFIED CHINESE_CHINA.US7ASCII

永久生效：在系统环境变量中新增NLS_LANG并配置对应值。

2. 修改服务端字符集（严禁随意操作）

服务端字符集修改会影响全库数据，仅极端场景使用，操作步骤：

shutdown immediate;
startup mount;
alter session set sql_trace=true;
alter system enable restricted session;
alter system set job_queue_processes=0;
alter system set aq_tm_processes=0;
alter database open;
alter database character set internal_use utf8;
alter session set sql_trace=false;
shutdown immediate;
startup;

---

方案二：C#程序中转（适配应用层对接）

通过微软Oracle驱动（OleDb）做数据中转，规避原生字符集转换问题。

实现步骤：

1. 添加引用：System.Data.OracleClient、System.Data.OleDb；

2. 依赖文件：将oraocixe10.dll、oci.dll、ociw32.dll放入系统System32目录；

3. 核心代码：

using System.Data.OleDb;

// 数据库连接字符串
string connString = "Provider=MSDAORA.1;User ID=用户名;Password=密码;Data Source=(DESCRIPTION = (ADDRESS_LIST= (ADDRESS = (PROTOCOL = TCP)(HOST = 数据库IP)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = 服务名)))";
OleDbConnection conn = new OleDbConnection(connString);

try
{
    conn.Open();
    // 数据查询/写入逻辑
}
catch (Exception ex)
{
    // 异常处理
    Console.WriteLine(ex.Message);
}
finally
{
    conn.Close();
}

---

方案三：UTL_RAW包编码转换（DBLink直接查询用）

无需修改环境，通过Oracle内置UTL_RAW包做十六进制与字符串转码，解决跨库乱码。

核心转换步骤：

1. 字符串转十六进制原始码：

V_COLUMN_MID := UTL_RAW.CAST_TO_RAW(V_COLUMN);

1. 原始码转回字符串：

V_COLUMN_STR := UTL_RAW.CAST_TO_VARCHAR2(V_COLUMN_MID);

1. 目标字符集转码（适配本地环境）：

-- 参数：待转字符串, 目标字符集
CONVERT(V_COLUMN_STR, 'ZHS16GBK');

四、项目特殊坑点（关键注意）

本次场景存在三层字符集交互，极易忽略导致解决方案失效：

1. 甲方Oracle 9i：SIMPLIFIED CHINESE_CHINA.US7ASCII

2. 我方Oracle 19c：SIMPLIFIED CHINESE_CHINA.AL32UTF8

3. 我方应用服务器客户端：SIMPLIFIED CHINESE_CHINA.ZHS16GBK

所有解决方案必须同时兼容三方字符集转换，否则仍会出现乱码。

总结

1. 优先用方案一（修改客户端字符集），成本最低、无侵入性；

2. 应用层对接用方案二（C#中转），稳定性强；

3. DBLink直查用方案三（UTL_RAW转码），灵活适配；

4. 核心规避点：务必兼顾数据库服务端、客户端、应用服务器三层字符集兼容。