首先要明确一个核心观点：Oracle 存储过程返回结果集出现中文乱码，绝大多数情况下并非存储过程本身的逻辑错误。问题的根本原因，通常在于数据库字符集与客户端（包括 JDBC、PL/SQL Developer、SQL*Plus 以及 .NET 环境）所使用的字符集不匹配。中文数据在传输和解析过程中被错误编码，自然就会显示为乱码。
解决思路并非修改存储过程中的 SQL 语句，而是将两端的字符集协商机制彻底对齐。先理解这一点，后续的优化工作就会顺畅许多。
确认数据库实际字符集与会话字符集
许多问题卡在同一个地方：自以为配置正确，实际上并未生效。因此，不要依赖于猜测，直接使用查询语句进行验证：
- 查询数据库级别的字符集：
SELECT value FROM nls_database_parameters WHERE parameter = 'NLS_CHARACTERSET';。该值（例如AL32UTF8或ZHS16GBK）是基础，会话无法覆盖。 - 查询当前会话的字符集：
SELECT value FROM nls_session_parameters WHERE parameter = 'NLS_CHARACTERSET';。该值受客户端环境变量或连接参数影响，经常与数据库端不一致。
这里有一个关键细节：NLS_LANG 环境变量决定了会话的默认字符集。但其格式必须为 LANGUAGE_TERRITORY.CHARACTERSET，例如 SIMPLIFIED CHINESE_CHINA.AL32UTF8，三个部分缺一不可。写错或遗漏，等同于未设置。
JDBC 连接必须显式指定 charset 参数
Oracle 的 JDBC 驱动（ojdbc8.jar 及更高版本）默认不会读取系统环境变量 NLS_LANG。因此，必须在连接 URL 或 Properties 中硬编码字符集设置。
存在一个常见的误区：在 URL 中添加 characterEncoding=UTF-8，这在 MySQL 中有效，但 Oracle 官方不识别该参数。正确的做法是在 Properties 对象中传递 charset 键：props.put("charset", "AL32UTF8");。
如果使用 Spring Boot，可以在数据源配置中通过 spring.datasource.hikari.data-source-properties.charset=AL32UTF8 完成设置。另外提醒一点，像 props.put("NLS_LANG", "AMERICAN_AMERICA.AL32UTF8") 这样的写法对 JDBC 无效，因为它根本不解析该参数。
PL/SQL Developer 或 SQL*Plus 的字符集设置陷阱
图形化工具常常会自动“猜测”字符集，反而可能掩盖真实问题。处理时需要分情况：
- PL/SQL Developer：打开菜单 Tools → Preferences → Oracle → Connection → Character set，此处必须手动选择与数据库一致的字符集（例如
AL32UTF8），不要留空，也不要选择Auto Detect。 - SQL*Plus：启动前必须先设置环境变量。Windows 下执行
set NLS_LANG=SIMPLIFIED CHINESE_CHINA.AL32UTF8，Linux 下执行export NLS_LANG=AMERICAN_AMERICA.AL32UTF8。设置完成后再启动 sqlplus，否则会话字符集很可能仍然是US7ASCII。
如何验证设置是否生效？连接数据库后立即执行：SELECT * FROM nls_session_parameters WHERE parameter = 'NLS_CHARACTERSET';，结果必须与数据库字符集一致。
存储过程中无需修改 SQL，但需注意 UTL_RAW 和 NCHAR 类型
乱码问题通常不出现在存储过程执行过程中，而是出现在结果集向外传输时。不过有两种特殊情况需要特别留意：
- 如果存储过程中使用了
UTL_RAW.CAST_TO_RAW()这类函数（某些 .NET 场景下为了绕过乱码问题会采用），那么应用端必须使用对应的编码进行反向解析。例如 C# 中需要写成Encoding.UTF8.GetString((byte[])dr["name"])。这种做法属于“带病运行”，并非根本解决方案。 - 避免混用
VARCHAR2和NVARCHAR2。VARCHAR2遵循数据库字符集（NLS_CHARACTERSET），而NVARCHAR2遵循国家字符集（NLS_NCHAR_CHARACTERSET）。建议查询SELECT value FROM nls_database_parameters WHERE parameter = 'NLS_NCHAR_CHARACTERSET';，确保该值也是AL32UTF8，否则NVARCHAR2字段会单独出现乱码。 - 当函数返回
REF CURSOR时，游标本身不携带任何字符集信息，完全依赖会话级的NLS_CHARACTERSET进行解码。因此，统一会话字符集比修改存储过程本身更为重要。
最后再强调一个最容易忽略的点：数据库字符集在创建数据库时就已固定，客户端的字符集设置（尤其是 JDBC 的 charset 属性）必须与之严格匹配。差一个字母都不行，例如 UTF8 和 AL32UTF8 在 Oracle 中并非同义词——AL32UTF8 是 Oracle 对 UTF-8 的实现名称，写成 UTF8 相当于未设置，乱码问题依旧存在。