根本原因是Oracle 11g的runInstaller使用定制JRE，硬编码加载LucidaSans.ttf中文字体缺失导致方块乱码；改LANG=en_US.UTF-8仅使界面退至英文路径规避问题，不解决字体本身；必须将中文字体（如simhei.ttf）重命名为LucidaSans.ttf并替换到jre/lib/fonts/下，权限设为644，且X Server端需安装中文字体包并刷新fc-cache。
oracle 11g 安装界面显示方块或乱码，根本不是编码没设对、lang 没 export 对，而是 runinstaller 启动的 java swing 界面压根找不到中文字体——它硬编码查找 lucidasans.ttf，而 oracle 自带的 jre（比如 jre/1.8.0）里只有西文字体，没中文，fallback 就是方块。
为什么改 LANG=en_US.UTF-8 有时管用？
它不解决字体问题，只是让界面退回到英文字符串渲染路径：Swing 不再尝试 drawString 中文，自然不触发缺字 fallback。但代价是整个安装向导变成英文，且对 dbca、netca 等后续工具无效——它们仍会因字体缺失而乱码。
-
LANG只影响本地化字符串加载逻辑，不影响字体文件搜索路径 - 在远程 X11 场景（如 Xmanager / VNC）下，
LANG改了也常无效，因为字体由 X Server 端提供 - 临时生效命令是：
export LANG=en_US.UTF-8，不是LC_ALL=C（后者可能让 Swing 直接禁用 AA 渲染，反而更糊）
为什么必须替换 LucidaSans.ttf 而不是加字体？
Oracle 的 JRE 是定制精简版，font.properties 文件被固化，不读取系统字体目录；Swing 组件默认只加载 jre/lib/fonts/LucidaSans.ttf，连 fallback 目录（如 fallback/）都可能被忽略。
- 必须把中文字体（如
simhei.ttf或NotoSansCJKsc-Regular.otf）重命名为LucidaSans.ttf，否则不认 - 替换前先删掉原
jre/lib/fonts/LucidaSans.ttf，避免同名冲突 - 权限必须是
644：chmod 644 jre/lib/fonts/LucidaSans.ttf，否则 JVM 加载失败静默跳过
Linux 下 runInstaller 仍乱码？检查 X Server 字体缓存与 JVM 参数
即使 JRE 字体替换了，runInstaller 在 X11 转发环境下（比如 ssh -X）仍可能走 X Server 的字体渲染链，而非 Java 自带字体。
- 服务端（即你连过去的那台 Linux）必须装中文字体包，例如：
yum install gnu-free-sans-fonts xorg-x11-fonts-misc - 刷新系统字体缓存：
sudo fc-cache -fv，否则新字体不进 X Server 的 font path - 强制 Java 使用本地字体渲染：
export JRE_OPTIONS="-Dawt.useSystemAAFontSettings=lcd -Dswing.aatext=true" - 验证是否生效：写个最小 Swing 示例
TestFont.java，编译后用同一 JRE 运行，看Graphics2D.drawString("测试", ...)是否正常
最容易被忽略的是：Windows 上别去改注册表 NLS_LANG 或“Beta 版 UTF-8 支持”，这些对 setup.exe 调用的 javaw.exe 几乎无影响；真正起作用的是 install/oraparam.ini 里的 JRE_MEMORY_OPTIONS 和 JRE 自身的 lib/fonts 目录——字体没放对位置、没重命名、没给读权限，其他所有设置都是白忙。
