Oracle 服务端字符集 AL32UTF8 支持中文，乱码源于 JDBC 连接层或 Java 应用层编码未对齐：需使用 ojdbc8+ 驱动、JVM 启动加 -Dfile.encoding=UTF-8，并避免在 URL 中添加 Oracle 不识别的 characterEncoding 参数。
Oracle 服务端字符集确实是 AL32UTF8，但 Java 查出来还是乱码
这说明问题不在数据库本身，而在于 jdbc 连接层或 java 应用层的编码协商没对上。al32utf8 是 oracle 对 utf- 8 的内部命名，它本身支持中文，但 jdbc 驱动默认不强制使用 utf- 8 传输，尤其在老版本驱动或未显式配置时，会退回到数据库 nls_lang 隐含的字符集（比如 zhs16gbk），导致字节解码错位。
- 检查实际连接使用的 JDBC URL 是否带
characterEncoding=utf8（MySQL 风格）——Oracle 不认这个参数，加了也无效 - 确认 JDBC 驱动版本：低于
ojdbc8的驱动（如ojdbc6）对 UTF- 8 支持不完整，setCharacterStream或getString()可能静默截断或转义 - 运行时打印
System.getProperty("file.encoding")，如果输出不是UTF-8，JVM 启动参数必须加-Dfile.encoding=UTF-8，否则String.getBytes()等操作会用错默认编码
正确的 JDBC 连接参数配置（ojdbc8+）
Oracle JDBC 驱动不通过 URL 参数控制字符集传输，而是依赖 JVM 环境、驱动行为和 Oracle 服务端 NLS 设置三者协同。关键点是让驱动走 UTF- 8 路径，而不是依赖 NLS_LANG。
- URL 里不要加
characterEncoding、这类 MySQL 参数，它们被忽略且可能引发警告 - 必须设置 JVM 启动参数：
-Doracle.jdbc.defaultNChar=true，它强制驱动对CHAR/VARCHAR2列使用 Unicode 语义读写（等效于 NCHAR 类型处理） - 连接池（如 HikariCP）中建议显式设
connectionInitSql=ALTER SESSION SET NLS_LANGUAGE='AMERICAN' NLS_TERRITORY='AMERICA'，避免会话级 NLS 设置干扰字符解释 - 验证是否生效：执行
SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET'，确认返回AL32UTF8；再查SELECT DUMP('你好', 1016) FROM DUAL，结果应为TYP=1 LEN=6: 60,0,4f,60,0,4f（UTF- 8 十六进制）
ResultSet.getString()返回？ 号或方块，但 DBA 说数据存得没问题
这是典型的“传输层解码失败”，数据从 Oracle 发出来是 UTF- 8 字节流，但 JDBC 驱动或 JVM 用 ISO-8859- 1 或 GBK 去解，一个中文占 3 字节变成 3 个非法字符，最终显示为 ? 或□。不是数据损坏，是解码链断在中间。
- 别急着改数据库字段类型，先确认驱动日志：启用
oracle.jdbc.Trace=true，看日志里是否有Convert to Unicode failed类报错 - 临时绕过：用
rs.getBytes(columnIndex)拿到原始字节数组，再手动new String(bytes, StandardCharsets.UTF_8)——如果这样能正确显示，就 100% 确认是驱动解码逻辑问题 - 注意
PreparedStatement.setString()写入时也要同步：确保传入的是 UTF- 8 源字符串，且驱动版本支持自动编码转换；否则写入时就已乱码，后续查只是重放错误
Spring Boot + MyBatis 环境下字符集失效的隐蔽原因
框架层可能覆盖底层 JDBC 行为，尤其是 MyBatis 的 TypeHandler 或 Spring 的 JdbcTemplate 字符集推断逻辑。AL32UTF8 在 MyBatis 里不会自动触发 UTF- 8 绑定，除非显式干预。
- MyBatis 的
configuration.variables里加defaultScriptingLanguage=org.apache.ibatis.scripting.xmltags.XMLLanguageDriver无用，字符集与此无关 - 真正要配的是 MyBatis 的
TypeHandler：自定义一个继承BaseTypeHandler<string></string>的处理器，在getNullableResult(ResultSet rs, String columnName)里用rs.getBytes()+new String(……, UTF_8)兜底 - Spring Boot 的
application.yml中spring.datasource.hikari.connection-init-sql必须包含ALTER SESSION SET NLS_NCHAR_CONV_EXCP = 'FALSE'，否则某些 NCHAR 字段转换异常会被静默吞掉
最麻烦的不是配置项本身，而是 AL32UTF8 在 Oracle 里允许混合 NLS 设置（比如数据库字符集是 AL32UTF8，但客户端 NLS_LANG 设成 AMERICAN_AMERICA.ZHS16GBK），这种组合下 JDBC 驱动行为会降级——它宁可相信 NLS_LANG 也不信 AL32UTF8，所以连驱动版本升级都救不了。务必清空所有 NLS_LANG 环境变量、注册表项、甚至 IDE 的 Run Configuration 里的环境变量。
立即学习“Java 免费学习笔记（深入）”；
