Oracle客户端连接后中文显示为问号或方块
根本原因是客户端 nls_lang 环境变量未正确设置，导致 oracle 客户端无法告诉服务端“我用的是什么字符集”。服务端按默认（比如 al32utf8）发数据，客户端却用 zhs16gbk 解，或者反过来，必然乱码。
实操建议：
先查清数据库实际字符集：SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = ‘NLS_CHARACTERSET’; —— 常见值是 AL32UTF8 或 ZHS16GBK再确认你用的客户端环境（SQL*Plus / PL/SQL Developer / Python cx_Oracle / JDBC）是否受 NLS_LANG 控制：命令行工具和 OCI 驱动都认这个变量；JDBC 通过连接串参数控制，不看它NLS_LANG 格式必须是 LANGUAGE_TERRITORY.CHARACTERSET，比如中文 Windows + UTF8 数据库应设为 AMERICAN_AMERICA.AL32UTF8；若数据库是 ZHS16GBK，客户端也得配成 AMERICAN_AMERICA.ZHS16GBK，不能混用Windows 下在系统环境变量里设 NLS_LANG，Linux/macOS 在 shell 启动文件中 export NLS_LANG=…，设完重启终端或客户端进程才生效
Python cx_Oracle 连接 Oracle 中文乱码
cx_Oracle（v8+）默认使用 Unicode，但底层仍依赖 OCI，NLS_LANG 设错时会触发隐式字符转换，插入/查询中文出错——尤其在字段为 VARCHAR2 且数据库字符集非 UTF8 时。
实操建议：
优先不设 NLS_LANG，让 cx_Oracle 自动协商：它会读取 Python 源文件编码（# -*- coding: utf-8 -*-）并匹配数据库字符集，成功率更高如果必须显式指定，用 cx_Oracle.init_oracle_client() 的 config_dir 或 lib_dir 参数配合 tnsnames.ora，比靠环境变量更可控插入前检查 connection.encoding 和 connection.nencoding 值，它们反映实际协商结果；若与数据库字符集不一致，说明协商失败，需排查 tnsnames.ora 或监听器配置避免用 str.encode(‘gbk’).decode(‘utf-8’) 这类手动转码——cx_Oracle 不吃这套，反而引入二次乱码
PL/SQL Developer 中文显示正常但导出 SQL 文件后乱码
这是工具级字符集切换问题：PL/SQL Developer 显示时用了正确的 NLS_LANG，但“导出到文件”功能默认用系统 ANSI 代码页（Windows 上常为 GBK），而文件本身没带 BOM 或编码声明，编辑器打开时猜错编码。
实操建议：
导出时勾选 UTF-8 with BOM（不是纯 UTF-8），VS Code、Notepad++ 都能正识别不要依赖工具自动保存编码，导出后用 file -i xxx.sql（Linux/macOS）或 PowerShell 的 Get-Content -Encoding UTF8 验证实际编码如果导出内容含 NLS_LANGUAGE 相关 DDL（如 ALTER SESSION SET NLS_DATE_FORMAT），注意这些语句本身不含字符集信息，乱码只影响可读性，不影响执行
Java JDBC 连接 Oracle 中文乱码（非 Spring Boot 场景）
JDBC 驱动（ojdbc8.jar）完全忽略 NLS_LANG，所有字符集行为由连接串参数和 JVM 启动参数共同决定。常见错误是只改了 -Dfile.encoding=UTF-8 却漏掉 JDBC 参数。
实操建议：
连接 URL 必须显式加参数：?useUnicode=true&characterEncoding=UTF-8（MySQL 风格写法对 Oracle 无效）→ 正确写法是：?oracle.jdbc.defaultNChar=true（启用 Unicode 绑定）+ &oracle.jdbc.convertNcharLiterals=true（确保 N’xxx’ 字面量正确）JVM 启动参数加 -Doracle.jdbc.defaultNChar=true，否则即使连接串写了，某些版本驱动仍走默认字节路径数据库字符集为 ZHS16GBK 时，不要强行用 UTF-8 连接：JDBC 会尝试转码，但 ZHS16GBK 不是 AL32UTF8 的子集，部分生僻汉字会变成 ?验证方式：执行 SELECT DUMP(‘测试’, 1016) FROM DUAL，看返回值是否与 Java 端 "测试".getBytes(StandardCharsets.UTF_8) 的十六进制一致
最麻烦的其实是混合环境：开发机 Win10（GBK）、测试库 Linux（AL32UTF8）、中间件容器（locale=C）。这时候光调一个 NLS_LANG 没用，得逐层确认每个环节的编码协商是否真正达成一致——尤其是那些不声不响就做隐式转换的地方。
评论(0)