Oracle 数据库中，文本数据并不是以文件编码形式直接存放，而是按照数据库字符集统一编码后写入数据块。迁移数据时，源库字符集、导出工具、客户端环境变量和导入工具共同构成一条转换链路，任意两个环节的字符集假设不一致，都可能把正常的中文备注变成问号、倒三角或无法解析的字节序列。处理这类问题时，不能只盯着应用代码，还要回到字节层面确认数据究竟在哪个环节被错误转换。

一、先确认两端字符集与NLS_LANG环境

排查乱码的第一步不是急着修改数据，而是确认源数据库和目标数据库各自使用的字符集。Oracle 中数据库字符集决定了 VARCHAR2、CLOB 等类型文本的存储编码，查询语句如下：

SELECT parameter, value
FROM v$nls_parameters
WHERE parameter IN ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');

如果源库是 ZHS16GBK，中文通常占两个字节；目标库是 AL32UTF8，中文通常占三个字节。仅看这个差异还不够，因为导出与导入工具是否执行转换，很大程度上受客户端环境变量 NLS_LANG 控制。Linux 环境下可以这样设置：

export NLS_LANG=SIMPLIFIED CHINESE_CHINA.AL32UTF8

需要注意的是，NLS_LANG 的第三段表示客户端程序使用的字符集，它应当与客户端工具实际读取或写入文件的编码保持一致。很多人误以为把 NLS_LANG 设成目标库字符集就能保证导入正确，实际上如果客户端文件本身是 GBK 编码，而 NLS_LANG 设成 AL32UTF8，Oracle 会按照 UTF-8 去解释 GBK 字节流，这一步就可能已经破坏了原始数据。

判断数据是否真的损坏，可以借助 DUMP 函数查看某个中文字段实际存储的字节码。例如源库为 GBK 时，汉字「中」的存储字节应为 d6,d0；迁移到 UTF-8 后正常应变为 e4,b8,ad。如果看到的是 3f，说明字符已经被替换为问号，这种情况基本不可逆；如果看到的是其他异常的字节组合，则可能还有通过字符集映射找回的机会。

SELECT dump(note, 1016) AS byte_dump, note
FROM note_table
WHERE rownum = 1;

二、从导出到导入的编码转换链路拆解

传统 exp 工具导出时，会在 dmp 文件头记录当时的客户端字符集。导入时 imp 读取 dmp 文件记录的字符集，再根据目标库字符集决定是否需要转换。也就是说，exp 阶段的 NLS_LANG 如果和源库不一致，dmp 文件里的文本字节可能已经不是源库原始编码。更稳妥的做法是让导出时的客户端字符集与源库完全一致：

export NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16GBK
exp user/pass@source file=source.dmp tables=note_table

导入端同样要显式指定 NLS_LANG。如果目标库是 UTF-8，导入时 Oracle 会自动把 GBK 字节转换为 UTF-8；如果目标库也是 GBK，则转换不会发生。问题常常出在导出和导入使用了不同的 NLS_LANG，导致数据在 dmp 文件里先被转换一次，导入时又转换一次，虽然有时结果看起来正常，但遇到生僻字或繁体字就可能丢失信息。

export NLS_LANG=SIMPLIFIED CHINESE_CHINA.AL32UTF8
imp user/pass@target file=source.dmp fromuser=src touser=tgt

与 exp/imp 不同，Data Pump 工具 expdp/impdp 的字符集转换主要在服务端完成，受客户端 NLS_LANG 影响较小。但 Data Pump 也并非完全绕开编码问题，如果源库和目标库字符集不同，导入阶段依然会进行转换，并且遇到无法映射的字符时可能报错。因此在使用 Data Pump 前，同样需要确认两端字符集，并检查是否有超长字段因转换后字节数增加而导致失败。

SQL*Loader 加载文本文件时，控制文件可以通过 CHARACTERSET 参数显式声明数据文件编码：

LOAD DATA
CHARACTERSET AL32UTF8
INFILE 'data.txt'
INTO TABLE note_table
FIELDS TERMINATED BY ','
TRAILING NULLCOLS
(id, note)

如果数据文件是 UTF-8 且带有 BOM，加载后第一列的值前面可能会出现不可见字符。此时可以先用系统命令去掉 BOM，再执行加载：

sed -i '1s/^\xEF\xBB\xBF//' data.txt

在整个链路中，原则是尽量减少不必要的字符集转换次数。源库、导出客户端、dmp 文件、导入客户端、目标库这五个位置，能保持一致就保持一致；必须跨字符集时，也只在一个环节完成转换，不要反复转换。

三、常见乱码场景与SQL级修复方法

乱码表现不同，根因也不同。问号通常是 Oracle 在转换过程中遇到无法映射的字符时使用了替换字符，原始信息已经丢失。倒三角符号则很多时候只是客户端显示层的问题，实际存储的字节可能仍然正确。判断方法还是使用 DUMP，如果字节为 3f，就是不可恢复的问号；如果字节组合看起来符合 UTF-8 规则但客户端显示异常，可以尝试更换客户端的字符集设置。

另一种常见问题是字段长度不足。源库使用 GBK 时，VARCHAR2(20) 可以存 20 个中文字符；迁移到 UTF-8 后，一个中文字符需要 3 个字节，理论上最大写入长度不变，但 Oracle 按字节限制字段长度时，实际能容纳的字符数会减少。如果应用继续写入原来的数据量，就可能报 ORA-12899 或出现截断。解决方法是将目标字段改成按字符定义长度：

ALTER TABLE note_table MODIFY (note VARCHAR2(4000 CHAR));

如果怀疑数据只是被错误映射，还没有被替换为问号，可以在测试环境尝试用 CONVERT 函数做反向转换。例如某个字段从 GBK 导入到 UTF-8 时被错误地当作另一字符集解释，可以尝试：

SELECT CONVERT(note, 'AL32UTF8', 'ZHS16GBK') AS fixed_note
FROM note_table
WHERE rownum = 1;

不过 CONVERT 的恢复能力有限，它依赖于当前存储的字节是否还保留原始编码特征。如果字节已经被替换为问号，再执行任何转换都只能得到问号。因此对于重要数据，迁移前一定要保留可恢复的备份或导出文件，不能只依赖数据库内的数据本身进行修复。

四、大数据量迁移避免二次转换的策略

对于大表迁移，建议优先使用 expdp/impdp，并配合 REMAP_SCHEMA、REMAP_TABLESPACE 等参数完成对象重映射。Data Pump 的字符集处理比传统 exp 更透明，也更适合服务端自动化执行。迁移前应在测试环境验证源库字符集、目标库字符集以及需要转换的字段范围，尤其是包含历史数据或生僻字的列。

如果必须通过文本文件中转，比如跨平台或无法直接建数据库链路，建议从源库导出 CSV 时指定客户端字符集与源库一致，并在目标库用 SQL*Loader 加载时显式指定相同或目标字符集。这样可以避免文件编码和 NLS_LANG 不一致带来的二次转换。导出脚本、控制文件和加载脚本最好统一维护，保证每次执行的字符集参数不变。

迁移完成后，不要只看行数是否一致，还要对文本列做抽样校验。可以对比源库和目标库同一主键记录的 DUMP 字节，如果源库和目标库字符集不同，字节不会完全相同，但转换后的字符内容应当一致。对于关键业务字段，还可以统计非 ASCII 字符的比例、检测问号数量，判断是否存在替换型丢失。

Oracle 文本数据迁移中的编码问题，本质上是一系列字符集假设是否匹配的问题。把源库字符集、客户端环境变量、文件编码、目标库字符集每个环节都显式确认清楚，就能避免绝大多数乱码。即使已经出现乱码，也可以通过字节级判断先区分可恢复与不可恢复两类，再决定是重新导入、反向转换，还是回退到备份重新抽取。