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免费学习笔记（深入）”；
