LANG=en_US.UTF-8 仅能规避乱码而非根本修复，因为 Oracle 11g 的 runInstaller 硬编码加载的 LucidaSans.ttf 中文字体缺失，设置该环境变量可使 Swing 跳过中文渲染路径转而显示英文界面。但 dbca、netca 等后续工具依然会出现乱码，且在 X11 转发环境下通常无效。先说一个核心判断：在 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 对它没用。 所以，别被“设置后不乱码了”的假象迷惑，这只是个临时规避手段。如果只想快速跑通安装流程，它确实管用；但后续工具也要正常，或者必须保留中文界面，那就得往下看真正的方法。
Oracle 11g安装乱码解决：临时设置LANG为en_US
Oracle11g安装界面中文乱码因runInstaller硬编码的LucidaSans ttf字体缺失中文字形。设置LANG=en_US UTF-8仅临时规避，使界面转为英文，但后续dbca等工具仍乱码，且X11转发下常失效。真正修复需用中文字体文件替换LucidaSans ttf并调整权限。
来源：https://www.php.cn/faq/2683724.html
本站内容用于信息整理与展示，如有侵权或内容问题请及时联系处理。
相关推荐
补充同频道和同主题内容，方便继续浏览更多相关内容。
同类最新
继续查看同栏目最近更新的文章。
Redis 7.0增量AOF重写RDB前导码配置详解
先说一个几乎所有人都踩过的典型误区：很多人把 aof-use-rdb-preamble yes 当作开启“增量重写”的开关。实际上，这个配置只干了一件事——让重写后的 AOF 文件头部带上 RDB 快照。它解决的是加载速度问题，跟“增量重写”本身的概念压根不是一回事。真正的增量重写，依赖的是 Red
在Python Tornado异步框架中安全执行SQL命令的方法与最佳实践
直接在Tornado里用SQLAlchemy同步执行SQL，结果就是阻塞IOLoop，所谓“异步框架里写同步数据库代码”，等于白搭。安全执行的关键不是“怎么写SQL”，而是“怎么不卡住事件循环”。 为什么不能在RequestHandler里直接调用session execute() 因为sessio
利用SQL触发器实现在INSERT数据时自动同步到审计表
先说结论：可以用触发器把 INSERT 数据同步到审计表，但必须用 AFTER INSERT，并且审计表的字段顺序、类型、字符集得和源表严格一致。否则，轻则写入错位、数据截断，重则直接报错、丢数据。下面把这些坑一个一个掰开说。 能，但必须用 AFTER INSERT，且审计表字段顺序、类型、字符集要
如何用SQL编写按不同工作日统计员工出勤率
在实际业务中，统计不同工作日的出勤率是HR系统里的高频需求。如果直接按日期函数分组，很容易掉进语言环境、索引失效或分母口径的坑里。下面就来拆解具体的实现要点。 必须用 CASE WHEN 将日期映射为固定 weekday 标签（如 Mon ）再分组，避免语言环境导致的分组断裂；需过滤 DOW IN
Spring Boot 3动态拼接SQL为何引发严重安全漏洞
SQL注入漏洞的核心成因，本质上是因为用户输入直接参与了SQL语句的字符串拼接，而未采用参数化绑定机制。在MyBatis中使用${}、QueryWrapper中调用apply()与last()、JPA的@Query注解进行拼接等操作，都会绕过PreparedStatement的安全防护。动态字段必须