前言
Spring对国际化这一块支持还是蛮友好的，上手也是蛮简单，但是加载流程还是需要大家掌握的，不然会少定义一个资源文件会让你莫名其妙的出现一些bug。接下来主要分享一下关于这一块的基本知识。
MessageSource
public interface MessageSource {
@Nullable
String getMessage(String code, @Nullable Object[] args, @Nullable String defaultMessage, Locale locale);
String getMessage(String code, @Nullable Object[] args, Locale locale) throws NoSuchMessageException;
String getMessage(MessageSourceResolvable resolvable, Locale locale) throws NoSuchMessageException;
}
顶层接口一共提供了三个获取信息的方法：
- 提供默认值
defaultMessage参数，当根据code无法从相应的ResourceBundle中查询出数据时，会将defaultMessage的值返回。 - 当根据
code无法从相应的ResourceBundle中查询出数据时，直接抛出NoSuchMessageException异常。 - 通过自定义
MessageSourceResolvable解析器去获取信息，MessageSourceResolvable也就是封装了code,args,defaultMessage三个参数，用法上并没有什么不同。只不过code参数为String[]数组形式，通过遍历调用的方式去获取信息，只要其中一个code能够获取到值，便直接返回。查询不出数据时且defaultMessage为空时，直接抛出NoSuchMessageException异常。
在获取对应信息时，里面还有些许流程，我下面将会结合例子来进行说明，得先熟悉下该接口的主要实现类。
从类图结构中可以看出，顶层接口MessageSource下面有个抽象类AbstractMessageSource，三个基本实现类ResourceBundleMessageSource,ReloadableResourceBundleMessageSource,StaticMessageSource。
-
ResourceBundleMessageSource：支持对.properties的解析，解析完成后也是用map进行封装，最后数据存储在PropertyResourceBundle的成员变量private Map<String,Object> lookup;中。 -
ReloadableResourceBundleMessageSource：可以解析.properties和.xml文件，解析完成利用PropertiesHolder进行封装，底层还是Properties结构。 -
StaticMessageSource：这个相对来说最容易理解，内部就是直接用map封装了咱们需要的信息。
以上三个实现类均可以对返回信息做格式化处理。
下面我将拿ResourceBundleMessageSource这个类进行分析，先对其几个属性值进行分析一下：
-
alwaysUseMessageFormat：默认值为false,即默认不对返回信息做格式化处理。 -
useCodeAsDefaultMessage：默认值为false，设置成true时，当无法通过code参数返回信息时，会默认将code的值进行返回。 -
fallbackToSystemLocale：默认值为true，当根据code和locale参数无法获取对应的ResourceBundle时，会根据当前的环境设置获取defaultLocale，然后获取对应的ResourceBundle。
注入spring容器：
可以选择配置文件或者注解的方式进行配置到spring容器中,例如下方的注解方式：
@Bean
MessageSource messageSource() {
ResourceBundleMessageSource resourceBundleMessageSource = new ResourceBundleMessageSource();
resourceBundleMessageSource.setBasename("exception");
resourceBundleMessageSource.setDefaultEncoding("UTF-8");
return resourceBundleMessageSource;
}
而spring 容器在初始化时，会在refresh方法中调用initMessageSource方法：
protected void initMessageSource() {
ConfigurableListableBeanFactory beanFactory = getBeanFactory();
if (beanFactory.containsLocalBean(MESSAGE_SOURCE_BEAN_NAME)) {
//从容器中获取name为 "messageSource"，类型为MessageSource的bean
this.messageSource = beanFactory.getBean(MESSAGE_SOURCE_BEAN_NAME, MessageSource.class);
if (this.parent != null && this.messageSource instanceof HierarchicalMessageSource) {
HierarchicalMessageSource hms = (HierarchicalMessageSource) this.messageSource;
if (hms.getParentMessageSource() == null) {
hms.setParentMessageSource(getInternalParentMessageSource());
}
}
if (logger.isTraceEnabled()) {
logger.trace("Using MessageSource [" + this.messageSource + "]");
}
}
else {
DelegatingMessageSource dms = new DelegatingMessageSource();
dms.setParentMessageSource(getInternalParentMessageSource());
this.messageSource = dms;
beanFactory.registerSingleton(MESSAGE_SOURCE_BEAN_NAME, this.messageSource);
if (logger.isTraceEnabled()) {
logger.trace("No '" + MESSAGE_SOURCE_BEAN_NAME + "' bean, using [" + this.messageSource + "]");
}
}
}
上面这段代码逻辑很清晰，先判断当前是否有该bean的BeanDefinition,若存在，则对MessageSource进行初始化并赋值给其成员变量messageSource。如果不存在该bean的BeanDefinition，则赋值一个空的MessageSource，也就是DelegatingMessageSource，以便能够正常的进行getMessage方法的调用。
具体使用：
有以下两种方式可以获取到容器中的MessageResource:
//方式一：
@Autowired
private MessageSource messageSource;
//方式二：
@Component
public class MessageResourceConfiguration implements MessageSourceAware {
private MessageSource messageSource;
@Override
public void setMessageSource(MessageSource messageSource) {
this.messageSource = messageSource;
}
}
PS：其实用ApplicationContext也可以，ApplicationContext实现了MessageSource接口，并且在refresh方法中也对messageSource进行了注入，不熟悉的可以回顾下上面的注入spring容器环节。
使用案例：
如下图所示先定义好这三个配置文件（文件名需要和上面定义MessageSource的baseName属性值一致）：
exception.properties我们称之为基类文件，它可以作为exception_en.properties和exception_zh.properties两种配置文件的父类，联想一下spring的子父容器的概率，相信不难理解。
1.String app = messageSource.getMessage("0000", null, Locale.ENGLISH); //en_exception
2.String app = messageSource.getMessage("0001", null, Locale.ENGLISH); //base_exception
3.String app = messageSource.getMessage("0000", null, Locale.CHINESE); //zh_exception
4.String app = messageSource.getMessage("0000", null, Locale.JAPAN); //zh_exception
分别执行这四句代码，出现这个四个结果：
- 能够从
exception_en.properties中获取”0000“对应的值：en_exception。 - 无法从
exception_en.properties中获取”0001“对应的值，在其父类exception.properties中获取对应的值：base_exception。 - 能够从
exception_zh.properties中获取”0000“对应的值：zh_exception。 - 无法获取
Locale.JAPAN对应的ResourceBundle，但由于fallbackToSystemLocale值默认是true，所以会根据环境设置获取defaultLocale，然后获取对应的ResourceBundle。当前环境通过System.getProperty("user.language")去获取，目前是该值是zh，所以会从exception_zh.properties中获取”0000“对应的值：zh_exception。
假设在注入bean时将fallbackToSystemLocale改成false：
运行上面的代码，会发现前面三个结果一致，但是最后一个结果有些许变化：
String app = messageSource.getMessage("0000", null, Locale.JAPAN); //exception
由于没有匹配到对应国家的ResourceBundle，直接从基类文件中获取结果。其实这里直接将exception_zh.properties配置文件移除也会获取相同的结果，都会从基类文件中获取。
假设在注入bean时将useCodeAsDefaultMessage改成true：
运行代码：
String app = messageSource.getMessage("0003", null, Locale.CHINESE); //0003
返回结果为“0003”，正是查询时用的code参数。“0003”不存在于咱们的exception_zh.properties和exception.properties文件对应的ResourceBundle中，所以直接将code作为默认结果进行返回了。
总结：
对上面的基本流程进行简单的总结，可以分为三步：
- 检测是否有对应
locale的配置，有的话则从当前locale配置中读取信息，并且可以追踪到基类文件中。 - 若没有对应
locale的配置，如果fallbackToSystemLocale为true,则获取默认defaultLocale的配置，并且可以追踪到基类文件中。 - 如果
fallbackToSystemLocale为false，则直接到基类文件中获取信息。
目前只是接触到根据不同的国家响应不同的异常状态码，后面会对页面这一块的国际化进行分享一下，SpringMVC也提供有对国际化这一块的支持。测试案例均在github中。
