oracle_characterset环境变量仅在首次初始化数据库时生效，对已有数据库无效；修改已有库字符集须用internal_use强制变更，且需同步调整nls_lang及客户端配置。
ORACLE_CHARACTERSET 环境变量只在首次初始化数据库时生效，容器已运行、数据库已创建后，直接改这个变量完全无效。
ORACLE_CHARACTERSET 只对新库起作用
- 官方镜像（如
container-registry.oracle.com/database/express:21.3.0-xe）启动时若带ORACLE_CHARACTERSET=UTF8，会调用内部脚本在CREATE DATABASE阶段设置字符集。 - 一旦数据库文件（
SYSTEM表空间、控制文件等）已存在，再重启容器并修改该变量，startup读取的是原有控制文件里的字符集定义，不会重新生成或覆盖。 - 常见误操作：停容器 → 改
docker run -e ORACLE_CHARACTERSET=ZHS16GBK→ 启动 → 发现select userenv('language') from dual;仍返回AMERICAN_AMERICA.AL32UTF8。
修改已有数据库字符集必须走 SQL 操作流程
核心是绕过 Oracle 的字符集校验限制，用 internal_use 强制变更（仅限测试/开发环境，生产慎用）：
- 进入容器并以
oracle用户执行：sqlplus / as sysdba
- 执行以下命令序列（顺序不能错）：
shutdown immediate;startup mount;alter system enable restricted session;alter system set job_queue_processes=0;alter system set aq_tm_processes=0;alter database open;-
alter database character set internal_use ZHS16GBK;（或AL32UTF8，按需替换） shutdown immediate;startup;
⚠️ 注意：
internal_use跳过字符集兼容性检查，如果原库含无法映射到目标字符集的 Unicode 字符（比如 emoji、生僻汉字），后续查询可能报ORA-12712或显示乱码/问号。
客户端连不上中文？重点查三处 NLS 设置
服务端字符集改完，客户端乱码大概率不是服务端问题，而是本地环境没对齐：
- 容器内
oracle用户的 shell 环境变量（~/.bash_profile或/etc/profile.d/oracle.sh）必须设：NLS_LANG=AMERICAN_AMERICA.ZHS16GBK（与数据库字符集一致） - 宿主机连接工具（如 DBeaver、SQL*Plus）启动前，要确保其进程继承了正确的
NLS_LANG—— Windows 下常被注册表值覆盖，Linux/macOS 下依赖 shell 启动方式。 - 执行
select * from nls_database_parameters where parameter in ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');确认实际生效值，别只信userenv('language')。
真正麻烦的从来不是改字符集那几条 SQL，而是改完之后——应用代码里硬编码的 String.getBytes("GBK")、JDBC URL 缺少 ?useUnicode=true&characterEncoding=GBK、甚至前端页面没声明 charset=GBK，都会让“已改好”的字符集形同虚设。
