如何防止Oracle PL/SQL导出CSV出现中文乱码

PL/SQL Developer导出CSV中文乱码的根本原因是NLS_LANG环境变量与数据库字符集不一致，必须严格匹配（如AL32UTF8或ZHS16GBK），且导出时需手动选择“UTF-8 with BOM”，同时Excel应通过“数据→从文本/CSV”导入并显式指定UTF-8编码。

导出前必须确认 NLS_LANG 与数据库字符集一致

PL/SQL Developer 导出 CSV 时是否乱码，根本上取决于客户端环境变量 NLS_LANG 是否匹配数据库实际字符集。如果数据库是 AL32UTF8，但你的 NLS_LANG 设为 ZHS16GBK，导出过程就会强制做错误的字符转换——哪怕 SQL 查询结果在 PL/SQL 界面里显示正常，写入文件时已悄然损坏。

验证方式很简单：

1. 执行 SELECT USERENV('language') FROM DUAL;，返回值形如 SIMPLIFIED CHINESE_CHINA.AL32UTF8，其中点号后就是你要对齐的字符集
2. Windows 下检查系统环境变量：变量名必须是 NLS_LANG，值必须严格等于查询结果（大小写敏感，不能多空格）
3. 修改后务必重启 PL/SQL Developer——环境变量不是热加载的，旧进程不会读取新值

导出向导里别依赖“自动编码”，手动选 UTF-8 with BOM

PL/SQL Developer 的「导出向导」默认可能用系统 ANSI 编码（即 GBK/GB2312），尤其在中文 Windows 上。即使 NLS_LANG 正确，导出步骤里若没指定编码，仍会走 fallback 路径，生成无 BOM 的 UTF-8 文件——而 Excel 打开时无法识别，直接当 ANSI 解析，中文就变乱码。

实操要点：

1. 右键表 →「导出向导」→ 第二步「导出设置」中，找到「字符集」下拉框
2. 不要选 System Default，明确选 UTF-8 with BOM（注意带 BOM）
3. 如果列表里没有这个选项，说明 PL/SQL 版本太老（低于 13.0），需升级或改用其他方式导出
4. 导出后用 VS Code 或 Notepad++ 打开，状态栏确认编码显示为 UTF-8 with BOM，不是 UTF-8

Excel 打开乱码？不是导出问题，是打开方式错了

很多用户导出文件本身没问题，但双击用 Excel 直接打开就乱码——这和 PL/SQL 无关，纯属 Excel 的编码嗅探机制缺陷。它对无 BOM 的 UTF-8 文件一律按本地 ANSI 解码，而带 BOM 的文件才能被正确识别。

绕过这个问题的可靠做法：

1. Excel 新建空白工作簿 →「数据」选项卡 →「从文本/CSV」→ 选中导出的 CSV 文件
2. 在导入向导中，「文件原始格式」下拉框手动选 UTF-8（即使文件带 BOM，也建议显式指定）
3. 预览确认中文正常后再点击「加载」
4. 切忌用「文件 → 打开」直接双击，那是 Excel 最不可靠的编码猜测路径

用 UTL_FILE 或外部表导入时，文件编码必须与 NLS_LANG 严格对应

如果你后续要用 UTL_FILE 或外部表把 CSV 再导回 Oracle，那导出时的编码选择就不仅是“让 Excel 能看”，更是“让 Oracle 能读”。Oracle 读文件时，完全依赖当前会话的 NLS_LANG 去解码字节流。

举例：

1. 导出时用了 UTF-8 with BOM，但数据库会话的 NLS_LANG 是 ZHS16GBK，UTL_FILE.GET_LINE 就会把 UTF-8 字节当 GBK 解，一个汉字变成两三个乱码字符
2. 安全组合只有一对：NLS_LANG=*.AL32UTF8 + 文件存为 UTF-8 with BOM；或 NLS_LANG=*.ZHS16GBK + 文件存为 GBK
3. 用 iconv 或 Notepad++ 转换文件编码时，务必验证转换后内容是否完整——有些工具转 GBK 会静默丢弃 UTF-8 中无法映射的字符

真正麻烦的不是设置本身，而是三处编码要同时对齐：数据库字符集、客户端 NLS_LANG、导出文件编码。少对一环，中文就断在某个环节里，还很难定位到底是哪一环出了问题。