国际化解决方案.docx

SPRING MVC国际化问题解决方案1 解决途径（1）将所有包含中文的资源文件（包括JS、图片、JSP等），翻译成多套；（2）使用属性文件（Properties文件）配置JSP文件的语言，JS和图片等资源使用多套；第一种解决方案较为简单，但对于业务逻辑变动较频繁的应用来说不是很适用；第二种解决方案，虽然会对开发进度有一定的影响，但相对比较灵活。本文以第二种解决方案为主线进行讨论。2 网络解决方案对于SPRING MVC国际化的问题，网络上提供的解决方案大致如下：一、基于浏览器语言的国际化配置使用Spring的MVC，并且配置中有配置Resource文件。 其中，message-info是properties文件的通用名。如：我的配置文件叫message- perties,message-info_zh_CN.properties等等,只要有了这个配置，然后配置JSP渲染器为JSTL 支持的，那么在你的JSP文件中使用fmt标记就可以实现客户浏览器语言国际化了。如：其中的info.login.title和你的资源文件对应.另外一种方式是使用spring自带的标签显示国际化信息，如：input type=button value=/二、基于动态加载的国际化配置1、基于请求的国际化配置基于请求的国际化配置是指，在当前请求内，国际化配置生效，否则自动以浏览器为主。配置方式如下：首先配置拦截器 这个配置呢，是不论请求级别的国际化，还是Cookie级别的国际化，再或者Session级别的国际化，都必需有配置这个拦截器，否则会不能使用。配好上面的拦截器之后，就将拦截器注入到你的UrlHandlerMapping中，例如: 1 这个时候，但凡有了符合UrlMapping的请求，就会被拦截，并且开始配置国际化参数默认的参数名为locale主意大小写。里面放的就是你的提交参数。如:en_US，zh_CN之类的，这个时候，你在页面上加一句简体中文如果你的资源中，饱含建议中文的配置，那么就会变成你确定的简体中文啦。2、基于Session的国际化配置拦截器和基于请求的相同Session的配置如下： 在你的处理的Controller中，将提交上来的locale字段信息生成真正的Locale对象，然后将对象保存在Session中，默认保存的ID是SessionLocaleResolver.LOCALE_SESSION_ATTRIBUTE_NAME这样，当你的Session不过期，那么语言种类始终保持正确的说。我一直是这样子用的，我觉得还是Session的好，老外们用了很满意。3、基于Cookie的国际化配置三、注意事项如果不用默认的浏览器语言国际化方式，那么拦截器一定要配置，如果你有多个UrlMapping，那么就每个都配上拦截器。至于配置的LocaleResolver的名字，一定要用上面的配置中的名字localeResolver当然了，这个是默认的名字来的，自己设置成别的也可以，但是就是麻烦，反正我用默认的就感觉不错。3 网络解决方案的BUG及局限性对于网络解决方案中提到的“基于请求的国际化配置”，与基于浏览器语言的国际化配置是等价的。通过分析AcceptHeaderLocaleResolver的源码，发现“基于请求的国际化配置”调用的并不是浏览器上传递的locale参数，而是request.getLocale()方法，即浏览器的语言配置。事实上，当按照“基于请求的国际化配置”的方法进行配置后，在浏览器端传递locale参数时，系统会提示如下错误：Cannot change HTTP accept header - use a different locale resolution strategy此异常是由AcceptHeaderLocaleResolver的setLocale方法抛出的。由此可见，设置AcceptHeaderLocaleResolver起不到任何效果，不如直接使用基于浏览器端的国际化配置比较好。此外，对于上面几种解决方案来说，重点解决的是显示层面的国际化问题，即通过locale参数来控制国际化语言，session和cookie只是存储locale参数的介质。有些需求，通过上面提到的解决方案则无法解决。（1）系统安装时，选择一个默认安装语言。不论浏览器语言的版本如何，默认均显示此语言；且通过locale参数，可以手动调整显示的语言；（2）系统安装时，为不同语言的版本配置不同的URL；当访问此URL时，不管浏览器语言的设置如何，均显示此URL对应的语言版本；4 SPRING MVC国际化解决方案前言：前面提供的网络解决方案也为SPRING MVC的国际化解决方案，但具有一定的局限性；接下来本文探讨一种基于Spring的i18n包实现的国际化解决方案。4.1 Spring DispatcherServlet工作原理DispatcherServlet为Spring的神经中枢，所有的请求与分发均要通过此Servlet。此Servlet会加载WEB以及applicationContext中的配置，以初始化相应的相应的参数。对于Spring应用的国际化来说，最重要的参数有三个：localeResolver、localeChangeInterceptor以及messageSource。LocaleResolver在i18n中是一个接口，具有setLocale()和resolverLocale()两个方法，setLocale()方法用于在locale发生变化的时候调用，而localeChangeInterceptor用于监听浏览器端locale的变化（第一次访问此应用时，会调用此方法来设置locale;之后，如果locale有变化，则会调用setLocale()方法），resolveLocale()方法主要用于获得当前的locale（如果为空，则返回浏览器端的locale），在多个地方均会调用此方法获得当前的locale，其中对于页面显示最重要的一处为DispatcherServlet的render()方法。这个地方获得的locale直接决定浏览器端页面显示的语言，通过resolveLocale()得到的locale即为setLocale()方法设置的值。Spring中，AcceptHeaderLocaleResolver, SessionLocaleResolver, CookieLocaleResolver分别是LocaleResolver的三种实现，这在前面的网络解决方案中已经讨论，这里不再赘述。当spring配置文件中，没有配置localeResolver时，spring会默认的使用org.springframework.web.servlet.i18n.AcceptHeaderLocaleResolver（缺省策略）。AcceptHeaderLocaleResolver表示接受浏览器端的语言设置，即根据浏览器端的语言来setLocale()。也就是说，如果不设置localeResolver，render()时调用resolverLocale()方法获得的locale始终是浏览器端的语言。在render之前通过filter,interceptors以及servlet等对locale进行修改也无济于事。因为在spring MVC中，当所有的filter,interceptors以及servlet执行完毕后，DispatcherServlet的render()方法此时会调用localeResolver的resolveLocale方法，获得当前的locale对象。然后set到response中去。因此，要想控制页面浏览器端页面的显示，必须配置localeResolver。而采用Spring自带的LocaleResolver接口的实现，无法满足上述提及的需求，且无法处理诸如图片类的资源文件。4.2 实现思路自定义类实现LocaleResolver接口的setLocale()和resolveLocale()，编写LanguageRequest抽象类（包括getLocale()方法）及其相应的实现类（LanguageRequestFromAppconfig、LanguageRequestFromHostName、LanguageRequestFromRequestHeader、LanguageRequestFromUserSelection），用于表示国际化解决方案的不同配置。编写过滤器，用于拦截请求，并对设置的资源文件进行处理。resolveLocale()直接从languageRequest中获得相应的locale。在四个实现类中，分别实现相应的locale获得机制。4.3 配置流程4.3.1 web配置目的：配置过滤器代理，使得过滤器可以通过Spring注入的方式来进行配置，方便属性的设置。WEB配置如下。filterChainProxyorg.springframework.web.filter.DelegatingFilterProxyencodingutf-8filterChainProxy/*REQUEST4.3.2 Spring配置所谓的Spring配置是指applicationContext.xml文件的配置。下面给出了此国际化解决方案的最全配置。 .jpg.gif.png.js.cssdwr/!- 覆盖默认的session存储，而使用cookie存储locale，cookie有效期为一个月-!- 覆盖默认的session存储，而使用cookie存储locale，cookie有效期为一个月-!- 覆盖默认的session存储，而使用cookie存储locale，cookie有效期为一个月-如上所述，本配置为此方案的最全配置，仅起到参考作用。实际应用过程中，可以根据需求来进行相应的删减。以下是部分配置的说明：（1）本应用安装的语言资源列表：当应用需要读取其支持的语言时，以进行进一步的配置时，可以通过得到此Bean (LocaleResource)，进而得到应用所支持的语言。比如：利用VDB Model Buider进行建模时，需要读取当前支持的语言包，并为每套语言提供一套配置界面。如无此需求，可以不进行配置；（2）系统需要处理的资源类型：locale语言本身仅能解决页面国际化显示的问题，而不能解决诸如JS、JPEG、GIF等资源文件的国际化，而这对于国际化应用来说又是必须的。比如：中文系统的某个JS提示可能为：”对不起，您不允许进行此操作“，而对应的英文系统应有对应的英文提示，可能为：“Sorry, You have no Privilege!”（建议JS文件中尽量少写中文）。此时，就需要有各个语言版本的JS、JPEG以及GIF等资源文件。不同的locale，加载不同的资源文件，分别存储在“/WEB-INF/lang/语言”目录下。其list主要用来配置需要处理的资源文件类型，filterList主要用来排除某些特定的资源文件类型，如dwr所用到的JS等。（3）国际化配置类型：本方案支持四种国际化配置类型，如有需要，还可以通过继承LanguageRequest来实现自己的国际化配置类型。四种国际化配置类型分别如下：LanguageRequestFromAppconfig：表示根据应用的配置来设置浏览器显示的语言，而不管浏览器端使用的是何种语言。有三个属性：medium：表示存储介质，可以使用session和cookie两种方式来存储；appLocale：默认显示的语言；localeParameterStatus：是否支持url中的locale参数；如果支持浏览器端参数，则当用户选定（通过URL参数来传递）某个语言版本后，在session或者cookie不失效的情况下，均为用户选择的语言。LanguageRequestFromHostName：表示根据主机名称来加载浏览器端显示的语言，而不管浏览器端使用的是何种语言。有一个属性：urlLocaleMap：用于存储主机地址与语言之间的映射关系。当使用对应的主机地址时，加载对应的语言版本；如遇不支持的语言，则显示默认值（default）。LanguageRequestFromRequestHeader：表示根据浏览器端语言来决定其显示。有两个参数：medium: 表示存储介质，可以使用session和cookie两种方式来存储；localeParameterStatus：是否支持url中的locale参数；如果支持浏览器端参数，则当用户选定（通过URL参数来传递）某个语言版本后，在session或者cookie不失效的情况下，均为用户选择的语言。LanguageRequestFromUserSelection：表示根据用户选择的语言来决定其显示。当用户不选定（不通过url传递locale参数）任何语言时，默认按照浏览器端的语言来展示。有一个参数：medium: 表示存储介质，可以使用session和cookie两种方式来存储。在具体使用时，可以根据需求选择其中的一种进行配置。（4）localeResolver：必须要配置。如果不配置localeResolver，则应用始终按照浏览器端来决定显示的语言。这在DispatcherServlet的工作原理中已经解释。localeResover有一个参数：languageRequest，用于设置用户选择的国际化配置类型。（5）internationalFilter：本解决方案所使用的过滤器，必须要配置。用于对拦截的资源类型进行处理，并跳转到相应的语言目录下，加载不同语言版本的资源文件。如果没