Java里的java.util.ResourceBundle怎么实现多语言

ResourceBundle加载失败主因是类路径中资源文件位置错误，需确保properties文件置于classpath根目录或与包路径严格匹配，且文件名全小写、UTF-8无BOM编码保存，并通过自定义ResourceBundle.Control解决乱码，同时缓存ResourceBundle实例避免重复加载。

java里的java.util.resourcebundle怎么实现多语言_i18n配置

ResourceBundle 加载失败：找不到 properties 文件

最常见的问题是 ResourceBundle.getBundle() 报 MissingResourceException，根本原因不是文件名写错，而是类路径（classpath）里压根没放对位置的资源文件。

实操建议：

properties 文件必须放在 classpath 根目录下，或与指定包路径严格匹配 —— 比如调用 ResourceBundle.getBundle("i18n.messages")，就要求存在 i18n/messages.properties（主语言）和 i18n/messages_zh_CN.properties 等，且这些路径在编译后位于 target/classes/ 或 classes/ 下对应位置
文件名大小写敏感：Windows 上可能不报错，Linux/macOS 上 Messages.properties ≠ messages.properties，JVM 只认小写 baseName
不要把 properties 放进 src/main/resources/META-INF/ 或任意子目录里“藏起来”，除非你显式用 ClassLoader.getResource() 手动加载 —— ResourceBundle 不走这个逻辑

Locale 匹配不生效：为什么总是 fallback 到 default？

调用 ResourceBundle.getBundle("messages", locale) 后返回的仍是英文内容，不是因为你 locale 构造错了，而是 JVM 找不到完全匹配的 bundle，又没按规则回退到可用变体。

关键点：

匹配顺序是：精确匹配（zh_CN）→ 语言匹配（zh）→ 默认（messages.properties），但前提是对应文件真实存在且命名合规 —— messages_zh_CN.properties 和 messages_zh.properties 是两个独立文件，不能缺
Locale 构造别用字符串拼接：new Locale("zh", "CN") 正确，new Locale("zh_CN") 错误（会被当语言代码，没有国家字段）
避免依赖系统默认 locale：Locale.getDefault() 在服务器上常是 en_US，别让它偷偷覆盖你传进去的 locale

中文乱码：properties 文件保存格式和读取机制冲突

明明写了中文，运行时却显示为 \u4f60\u597d 或方块 —— 这不是 ResourceBundle 的锅，是 JDK 对 properties 文件的默认编码假设（ISO-8859-1）和你编辑器保存格式不一致导致的。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

解决方式很直接：

所有 .properties 文件必须用 UTF-8 无 BOM 编码保存，然后用 native2ascii（已过时）或更靠谱的：改用 ResourceBundle.Control 自定义加载逻辑
推荐做法：继承 ResourceBundle.Control，重写 newBundle()，用 InputStreamReader 指定 UTF-8 读取文件流，再交给 Properties.load()
别信 IDE “自动转义”提示 —— 它只帮你把中文存成 \uXXXX，但运行时仍需按 ISO-8859-1 解析，一旦你手动删了转义，又没配好 Control，就必然乱码