根本原因是Oracle自带JRE缺少CJK字体，需将simhei.ttf等中文字体重命名为LucidaSans.ttf并放入jre/lib/fonts目录，同时刷新字体缓存、设置JVM参数，Windows还需禁用Beta版UTF-8支持。
Oracle安装界面中文显示为方块，根本原因是JRE内置字体不支持CJK
oracle安装程序（runinstaller）本质是java swing应用，启动时依赖jre的字体渲染能力。oracle自带的jre（如jre/1.8.0目录下）通常精简过，lib/fonts里只有lucidasans.ttf这类西文字体，遇到中文就fallback成方块——这不是编码问题，也不是lang没设对，是字体缺失本身。
实操建议：
- 别碰
LANG临时改环境变量：它只影响终端字符集和部分本地化行为，对Swing字体加载无实质作用 - 优先替换JRE字体：进Oracle安装包解压目录（或已解压的
stage/jre），定位到jre/lib/fonts，删掉原有字体文件，放入支持中文的simhei.ttf或NotoSansCJKsc-Regular.otf - 必须重命名新字体为
LucidaSans.ttf（保留原名）：Swing硬编码查找该文件名，换名无效 - 替换后执行
chmod 644 jre/lib/fonts/LucidaSans.ttf，避免权限导致加载失败
Linux下runInstaller仍乱码？检查X11字体缓存与Java系统属性
即使替换了字体，runInstaller可能仍用X Server的本地字体渲染路径，尤其在远程X11转发（如ssh -X）场景下。
实操建议：
- 运行前先刷新字体缓存：
sudo fc-cache -fv，确保系统级字体配置生效 - 强制Java使用本地字体渲染：在
runInstaller命令前加JVM参数：export JRE_OPTIONS="-Dawt.useSystemAAFontSettings=lcd -Dswing.aatext=true" - 如果用
ssh -X连接，服务端需装xorg-x11-fonts-misc等中文字体包，否则X Server端无字可渲 - 验证是否生效：临时跑个Swing小demo，比如
java -Dfile.encoding=UTF-8 -cp . TestFont，看能否正常drawString中文
Windows上Oracle 19c安装乱码，别动注册表，改javaw.exe启动参数
Windows版Oracle安装包（setup.exe）最终调用的是javaw.exe，但它的JVM参数被封装在install\oraparam.ini里，直接改这里比折腾系统区域设置更可靠。
实操建议：
- 编辑
install/oraparam.ini，在[JRE]段末尾追加：JRE_MEMORY_OPTIONS = "-Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8" - 确认
javaw.exe所在JRE的lib/fonts目录已替换为中文字体（同Linux步骤），且文件权限允许读取 - 禁用Windows“Beta版UTF-8支持”（设置→时间和语言→区域→管理语言→更改系统区域设置→取消勾选）：开启后反而导致JRE字符集解析错乱
- 不要双击
setup.exe，改用命令行启动：setup.exe -jreLoc "D:\oracle\jre"，显式指定已修复的JRE路径
LANG变量真有用吗？只在极少数终端直连场景下起效
LANG=zh_CN.UTF-8对runInstaller本身几乎无影响——它不读取locale做字体选择，也不靠locale决定UI语言。唯一可能起作用的，是当安装脚本（如ssh会话中）调用echo、grep等命令输出日志时，这些日志里的中文能正确显示。但UI乱码问题完全不在此链路。
实操建议：
- 临时设
LANG仅用于排查：比如LANG=zh_CN.UTF-8 ./runInstaller -debug，看控制台日志是否变中文，但这和图形界面无关 - 别把它当解决方案写进
.bashrc或/etc/environment：全局改LANG可能干扰其他Java应用的日期/数字格式 - 真正要改的永远是JRE字体+JVM参数，不是系统语言环境
字体替换这事看着简单，但LucidaSans.ttf这个文件名、fc-cache刷新时机、JVM参数位置，三个点错一个就白忙。最常漏的是Windows下忘了关Beta版UTF-8支持，或者Linux下没给新字体加读权限。
