在java应用中支持接口的多语言响应需配置localeresolver和messagesource。1. 配置localeresolver使用acceptheaderlocaleresolver解析请求头语言，默认设置中文。2. 配置messagesource加载多语言资源文件，指定资源前缀及编码。3. 创建对应语言的.properties文件存放文本。4. 在controller中注入messagesource，通过getmessage方法获取对应语言文本。此方式实现文本与代码分离，便于维护和翻译。其他方式如url参数、session、cookie、数据库也可用于语言偏好设定。国际化（i18n）是设计应用以支持多语言的基础，本地化（l10n）是将应用适配到具体语言和文化的过程，前者为后者提供前提和基础。
在Java应用中支持接口的多语言响应，并根据请求头设置输出语言，核心在于利用国际化（i18n）机制，特别是Spring框架提供的LocaleResolver和MessageSource组合。这能让你将界面文本、错误信息等与代码逻辑分离，根据客户端的Accept-Language请求头动态加载对应语言的文本资源。
解决方案
要在Java，特别是Spring Boot项目中实现基于请求头（Accept-Language）的多语言响应，你需要配置LocaleResolver和MessageSource。
-
配置
LocaleResolver： Spring的LocaleResolver负责解析当前请求的语言环境。对于基于Accept-Language头的需求，AcceptHeaderLocaleResolver是理想选择。立即学习“Java免费学习笔记（深入）”；
import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.web.servlet.LocaleResolver; import org.springframework.web.servlet.i18n.AcceptHeaderLocaleResolver; import java.util.Locale; @Configuration public class I18nConfig { @Bean public LocaleResolver localeResolver() { AcceptHeaderLocaleResolver localeResolver = new AcceptHeaderLocaleResolver(); // 设置默认语言，当请求头不明确或不支持时使用 localeResolver.setDefaultLocale(Locale.SIMPLIFIED_CHINESE); // 例如，默认中文 return localeResolver; } // ... 后面还需要MessageSource的配置 } -
配置
MessageSource：MessageSource负责加载和解析多语言资源文件（通常是.properties文件）。import org.springframework.context.MessageSource; import org.springframework.context.support.ResourceBundleMessageSource; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; @Configuration public class I18nConfig { @Bean public LocaleResolver localeResolver() { // ... 同上 AcceptHeaderLocaleResolver localeResolver = new AcceptHeaderLocaleResolver(); localeResolver.setDefaultLocale(Locale.SIMPLIFIED_CHINESE); return localeResolver; } @Bean public MessageSource messageSource() { ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource(); // 指定资源文件的前缀，例如 messages_en.properties, messages_zh.properties messageSource.setBasenames("i18n/messages", "i18n/errors"); messageSource.setDefaultEncoding("UTF-8"); // 缓存时间，-1表示永不缓存，0表示不缓存 messageSource.setCacheSeconds(3600); return messageSource; } } -
创建多语言资源文件： 在
src/main/resources/i18n目录下创建.properties文件。-
messages.properties(默认语言，如果请求头没有匹配项或没有指定默认语言)greeting=Hello welcome.message=Welcome to our service!
-
messages_en.propertiesgreeting=Hello welcome.message=Welcome to our service!
-
messages_zh.propertiesgreeting=你好 welcome.message=欢迎使用我们的服务！
-
errors_en.propertieserror.invalid.param=Invalid parameter.
-
errors_zh.propertieserror.invalid.param=参数无效。
-
-
在代码中使用
MessageSource： 在你的Controller或Service中注入MessageSource，并使用它来获取对应语言的文本。import org.springframework.beans.factory.annotation.Autowired; import org.springframework.context.MessageSource; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RestController; import java.util.Locale; @RestController public class GreetingController { @Autowired private MessageSource messageSource; @GetMapping("/greet") public String greet(Locale locale) { // Spring会自动注入当前请求的Locale // 使用messageSource.getMessage(code, args, defaultMessage, locale) // code: 资源文件中的键 // args: 占位符参数 (例如 {0}, {1}) // defaultMessage: 如果找不到键的默认消息 // locale: 当前请求的语言环境 String greeting = messageSource.getMessage("greeting", null, "Default Greeting", locale); String welcome = messageSource.getMessage("welcome.message", null, "Default Welcome", locale); return greeting + ", " + welcome; } @GetMapping("/error-example") public String errorExample(Locale locale) { String errorMessage = messageSource.getMessage("error.invalid.param", null, "Unknown error", locale); return errorMessage; } }
当客户端发送请求时，例如GET /greet，并带上Accept-Language: zh-CN，Spring的AcceptHeaderLocaleResolver就会解析出Locale.SIMPLIFIED_CHINESE，然后MessageSource会加载messages_zh.properties中的内容。如果请求头是Accept-Language: en-US，则会加载messages_en.properties。
为什么我们不直接在代码里写死多语言字符串？
说实话，我个人觉得直接把多语言字符串写死在代码里，简直就是给自己挖坑。这事儿吧，短期看可能觉得省事，毕竟不用搞什么配置文件，直接if/else或者switch一下locale参数，然后返回不同的字符串。但长远来看，这简直是维护的噩梦。
你想想看，一个项目如果需要支持多种语言，比如中、英、法、德、日。每个页面、每个提示、每个错误信息，你都要在代码里写五遍？这不仅代码量爆炸，而且可读性极差。更要命的是，如果翻译有变动，或者新增一种语言，你得去翻遍所有代码文件，改动起来小心翼翼，生怕漏掉或者改错。这简直是灾难性的。
再者，把业务逻辑和展示文本混在一起，这本身就违反了“关注点分离”的基本原则。翻译这种事，往往是产品或者专门的翻译人员来做，他们可不懂代码，也不应该去碰代码。而外部化（也就是放到.properties文件里）之后，翻译人员可以直接修改这些文件，不需要触碰任何一行Java代码，这大大提高了效率和安全性。而且，如果你未来想用一些自动化翻译工具或者平台，它们也更倾向于处理这种外部化的文本资源。所以，别偷懒，把文本抽出来，这是正道。
除了请求头，还有哪些方式可以决定语言偏好？
除了最常见的Accept-Language请求头，其实决定用户语言偏好的方式还挺多的，各有各的适用场景，有时候甚至需要多种方式组合使用，形成一个优先级链。
-
URL路径或参数： 这是很多网站会用的，比如
yourdomain.com/en/products或者yourdomain.com/products?lang=en。这种方式直观，而且有利于SEO，因为不同语言版本有独立的URL。缺点是URL会变长，而且每次切换语言可能需要重定向。 - 用户会话（Session）： 当用户登录后，你可以在他们的会话中存储一个语言偏好设置。这样，只要用户保持登录状态，无论他们从哪个设备访问，都能保持一致的语言体验。这很适合有用户系统的应用。但缺点是，如果用户没有登录，或者会话过期，就无法使用了。
- Cookie： 类似于会话，但更持久。你可以把用户的语言选择保存在一个Cookie里，这样即使关闭浏览器再打开，或者下次访问，系统也能记住他们的偏好。这对于非登录用户来说非常友好。但用户清除Cookie或者禁用Cookie就没辙了。
- 用户数据库配置： 对于有用户账户的系统，最可靠的方式是允许用户在个人设置中选择并保存语言偏好，然后把这个偏好存储在数据库里。每次用户登录时，从数据库加载这个设置。这是最持久和个性化的方案，但需要用户主动设置。
- 浏览器默认设置（Fallback）： 当上述所有方式都无法确定语言时，最终可以回退到服务器端预设的默认语言，或者尝试根据请求IP地址进行粗略的地理位置判断（虽然不推荐，因为IP地址不总是可靠的语言指示器）。
实际项目中，我倾向于将Accept-Language作为首选，因为它最符合HTTP协议的约定，也是浏览器自动发送的。然后，如果用户在网站上明确选择了语言（比如通过下拉菜单），就通过Cookie或者用户设置（如果登录了）来覆盖Accept-Language的默认行为。这样既能满足大部分用户的无感体验，也能提供个性化定制。
处理多语言时，国际化（i18n）和本地化（l10n）有什么区别和联系？
这俩词儿啊，听起来很像，但实际上是两个不同阶段的概念，又紧密相连，缺一不可。
国际化（Internationalization，简称i18n），这个“18”指的是“i”和“n”之间有18个字母。它关注的是设计和开发你的软件产品，使其能够适应不同的语言和地区，而无需对代码进行大的改动。简单来说，就是让你的应用具备“多语言能力”的潜力。这包括：
-
文本外部化： 不把文本写死在代码里，而是放到资源文件（比如
.properties文件）里。 - 日期、时间、货币、数字格式的通用处理： 不要假设所有地区都用“MM/DD/YYYY”或“$”。
- 避免硬编码的文化假设： 比如图片、颜色、图标等，可能在不同文化中有不同含义。
- 支持多种字符编码： 比如UTF-8。
- 布局和UI的灵活性： 考虑文本长度变化（德语单词通常比英语长），阅读方向（从左到右或从右到左）。
国际化是一次性投入，它让你的代码库变得“语言无关”，为未来的多语言支持打下基础。
本地化（Localization，简称l10n），这个“10”指的是“l”和“n”之间有10个字母。它关注的是将已经国际化好的产品，具体地适配到某个特定的语言和文化环境。简单来说，就是把“潜力”变成“现实”。这包括：
- 翻译： 将资源文件中的文本翻译成目标语言。
- 文化适配： 调整日期、时间、货币、数字的显示格式，符合目标地区的习惯。
- 图像和媒体的替换： 如果某个图片或图标在目标文化中不合适，进行替换。
- 法律和合规性审查： 确保内容符合当地的法律法规。
- 用户界面布局调整： 根据翻译后的文本长度调整UI元素的大小和位置。
本地化是持续进行的，每增加一种新的目标语言或地区，就需要进行一次本地化工作。
它们的关系是： 国际化是本地化的前提和基础。没有经过国际化的产品，你很难对其进行有效的本地化。就好比你得先设计一个可以换轮子的汽车（国际化），然后才能根据不同路况换上雪地胎、越野胎或公路胎（本地化）。一个好的国际化设计能极大降低未来本地化的成本和复杂性。反之，如果一开始没有做国际化，后期要增加多语言支持，那基本就是重构的节奏。
