Oracle 11g安装界面中文乱码方块？设置LANG=en_US解决

先说一个核心判断：在 Oracle 11g 安装界面遇到中文方块时，设置 `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 端仍然没有中文字体可用。 最容易踩的两个坑是：字体替换后没有删除旧文件，导致同名冲突；或者忘记修改权限，JVM 打开文件失败却一声不吭——你看到的仍然是方块，但原因已经从“缺字体”变成了“有字体但读不了”。