LANG=en_US.UTF-8仅规避乱码而非修复，因Oracle 11g runInstaller硬编码加载LucidaSans.ttf中文字体缺失，设该环境变量使Swing跳过中文渲染路径转用英文界面，但dbca、netca等后续工具仍乱码，且X11转发下常无效。
lang=en_us.utf-8 只是绕过乱码，不是修复乱码
Oracle 11g 的 runInstaller 是基于 Swing 的 Java 应用，它显示方块的根本原因不是字符编码错，而是 JVM 启动时找不到能渲染中文的字体文件——它硬编码只加载 jre/lib/fonts/LucidaSans.ttf，而 Oracle 自带的 JRE 里这个文件只有西文字形。设 LANG=en_US.UTF-8 的作用，是让 Swing 跳过所有中文字符串的绘制逻辑，直接走英文资源路径，自然不触发缺字 fallback。但代价也很明显：
- 整个安装向导变成英文，对非英语用户不友好
-
dbca、netca等后续图形工具仍会乱码，因为它们各自启动新的 JVM 实例，同样缺字体 - 在 X11 转发场景（如 ssh -X 或 Xmanager）下，该设置常无效——界面渲染实际由远端 X Server 控制，LANG 对其无影响
所以这不是一个“解决”，而是一个“规避”。如果你只是想快速跑通安装流程，它确实管用；但若要后续工具也正常，或部署环境必须中文界面，就得往下看。
为什么 export NLS_LANG 或 chcp 936 完全没用
NLS_LANG 是 Oracle 客户端层的字符集协商变量，只影响 sqlplus、exp 这类命令行工具的数据编解码，和图形界面的字体渲染完全无关。chcp 936 是 Windows 控制台代码页切换，只改 cmd 窗口的终端编码，对 runInstaller 启动的独立 Java 进程零影响。
常见错误现象包括：
- 在终端执行
export NLS_LANG=AMERICAN_AMERICA.ZHS16GBK后运行./runInstaller，界面仍是方块 - Windows 注册表里改了
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_*下的NLS_LANG，双击setup.exe依然乱码 - 误以为
LC_ALL=C比LANG=en_US.UTF-8更彻底，结果 Swing 连抗锯齿都禁了，文字更糊
这些操作都在错误的方向上使劲——它们动的是字符集协议层，而问题出在字体文件加载层。
LANG=en_US.UTF-8 生效的前提条件
即使只是临时规避，LANG=en_US.UTF-8 也不是设了就一定起效。它依赖几个隐性前提：
- 必须在运行
runInstaller前设置，且不能被后续脚本覆盖（比如某些封装过的启动脚本会重置 LANG） - 不能和
LC_ALL冲突：如果LC_ALL已设（尤其设为C），它会强制覆盖 LANG，导致设置失效 - X Server 端需支持英文 locale：远程连接时，服务端
locale -a | grep en_US要能查到en_US.utf8，否则 X11 字符映射可能出错 - 不要用
sudo ./runInstaller：sudo 默认重置环境变量，应改用sudo -E ./runInstaller保留当前 LANG
验证是否生效：运行前加一句 echo $LANG，确保输出确实是 en_US.UTF-8；再检查 locale 输出中 LC_CTYPE 和 LC_MESSAGES 是否也被正确继承。
真正修复乱码必须动字体文件
绕开 LANG 的临时方案终究治标，要根治，必须让 LucidaSans.ttf 这个名字指向一个真实支持中文的字体。实操要点很具体：
- 找到安装包解压后的
jre/lib/fonts/目录（Linux 多在stage/jre/，Windows 在install/jre/） - 备份原
LucidaSans.ttf，然后把simhei.ttf、wqy-microhei.ttc或NotoSansCJKsc-Regular.otf重命名为LucidaSans.ttf并覆盖进去 - 执行
chmod 644 jre/lib/fonts/LucidaSans.ttf：JVM 加载字体时静默跳过权限不对的文件，不报错也不提示 - Linux 下还需在系统级刷新字体缓存：
sudo fc-cache -fv，否则 X Server 端仍无中文字可渲
最容易被忽略的是：字体替换后没删旧文件，导致同名冲突；或者忘了 chmod，JVM 打开文件失败却一声不吭——你看到的还是方块，但原因已从“缺字体”变成“有字体但读不了”。
