Shulou(Shulou.com)06/03 Report--

This article introduces the knowledge of "how to configure SpringMVC internationalization". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

1.SpringMVC internationalization configuration

Let's first talk about usage, and then talk about the source code, so that we are not easy to get confused. Let's first talk about how to deal with internationalization in SSM.

First of all, we may have two needs for internationalization:

Internationalize during page rendering (this is achieved with the help of Spring tags)

Get the message after internationalization matching in the interface

Roughly speaking, these are the above two scenarios. Next, Brother Song uses a simple usage to demonstrate the specific ways to play.

First, we create new language files, language_en_US.properties and language_zh-CN.properties, under the resources directory of the project, as shown below:

The contents are as follows:

Language_en_US.properties:

Login.username=Username login.password=Password

Language_zh-CN.properties:

Login.username= username login.password= user password

These two correspond to the English and Chinese environments respectively. After the configuration file is written, you also need to provide a ResourceBundleMessageSource instance in the SpringMVC container to load the two instances, as follows:

The file name language and the default encoding format are configured here.

Next, let's create a new login.jsp file, as follows:

Title

In this file, we refer to variables through the spring:message tag, which selects the appropriate language file based on the current situation.

Next, we provide a controller for login.jsp:

@ Controller public class LoginController {@ Autowired MessageSource messageSource; @ GetMapping ("/ login") public String login () {String username = messageSource.getMessage ("login.username", null, LocaleContextHolder.getLocale ()); String password = messageSource.getMessage ("login.password", null, LocaleContextHolder.getLocale ()); System.out.println ("username =" + username); System.out.println ("password =" + password) Return "login";}}

Just return to the login view directly in the controller.

In addition, I also injected the MessageSource object, mainly to show you how to get the internationalized language text in the processor.

After the configuration is complete, start the project for testing.

By default, the system judges the current locale based on the Accept-Language field in the request header, which is automatically sent by the browser. For convenience of testing, we can use POSTMAN to test, and then manually set the Accept_Language field.

First, test the Chinese environment:

Then test the English environment:

It's all right. Perfect! At the same time, observe the IDEA console, can also print out the language correctly.

The above one is based on AcceptHeaderLocaleResolver to parse the current region and language.

Sometimes we want the locale to be passed directly through the request parameters rather than through the request header, which we can achieve through either SessionLocaleResolver or CookieLocaleResolver.

Let's take a look at SessionLocaleResolver first.

First, provide an instance of SessionLocaleResolver in the SpringMVC configuration file, and configure an interceptor, as follows:

SessionLocaleResolver is responsible for region parsing, and there is nothing to say about this. Interceptor LocaleChangeInterceptor is mainly responsible for parameter parsing. When we configure the interceptor, we set the parameter locale (the default is this), that is, we can pass the current environment information through the locale parameter in the future.

After the configuration is complete, let's access the login controller as follows:

At this point, we can directly control the current locale through the locale parameter, which is automatically parsed in the previously configured LocaleChangeInterceptor interceptor.

If you don't want to configure the LocaleChangeInterceptor interceptor, you can manually parse the locale parameter and then set the locale, like the following:

@ Controller public class LoginController {@ Autowired MessageSource messageSource; @ GetMapping ("/ login") public String login (String locale,HttpSession session) {if ("zh-CN" .equals (locale)) {session.setAttribute (SessionLocaleResolver.LOCALE_SESSION_ATTRIBUTE_NAME, new Locale ("zh", "CN")) } else if ("en-US" .equals (locale)) {session.setAttribute (SessionLocaleResolver.LOCALE_SESSION_ATTRIBUTE_NAME, new Locale ("en", "US"));} String username = messageSource.getMessage ("login.username", null, LocaleContextHolder.getLocale ()); String password = messageSource.getMessage ("login.password", null, LocaleContextHolder.getLocale ()); System.out.println ("username =" + username) System.out.println ("password =" + password); return "login";}}

The function of SessionLocaleResolver can also be realized through CookieLocaleResolver. The difference is that the former saves the parsed area information in session, while the latter saves in Cookie. Save in session, as long as the session does not change, then you do not have to pass the regional language parameters again. Save in Cookie, as long as the Cookie is not changed, you do not have to pass the regional language parameters again.

The way to use CookieLocaleResolver is very simple. You can provide an instance of CookieLocaleResolver directly in SpringMVC, as follows:

Note that you also need to use the LocaleChangeInterceptor interceptor here. If you do not use the interceptor, you need to manually parse and configure the locale yourself, as shown below:

@ GetMapping ("/ login3") public String login3 (String locale, HttpServletRequest req, HttpServletResponse resp) {CookieLocaleResolver resolver = new CookieLocaleResolver (); if ("zh-CN" .equals (locale)) {resolver.setLocale (req, resp, new Locale ("zh", "CN"));} else if ("en-US" .equals (locale)) {resolver.setLocale (req, resp, new Locale ("en", "US")) } String username = messageSource.getMessage ("login.username", null, LocaleContextHolder.getLocale ()); String password = messageSource.getMessage ("login.password", null, LocaleContextHolder.getLocale ()); System.out.println ("username =" + username); System.out.println ("password =" + password); return "login";}

After the configuration is completed, start the project to test, this test method is the same as the SessionLocaleResolver test method, Song GE will not say any more.

In addition to the previous introduction of these LocaleResolver, there is also a FixedLocaleResolver, because it is relatively rare, Brother Song will not introduce too much here.

Basic use of 2.Spring Boot internationalization configuration 2.1

Spring Boot and Spring come down in the same line, and the support for internationalization is done by default through the AcceptHeaderLocaleResolver parser, which determines the environment to which the current request belongs by default through the Accept-Language field of the request header, and then gives an appropriate response.

So if we do internationalization in Spring Boot, we can do it directly without configuration.

First create a normal Spring Boot project and add web dependencies. After the project is successfully created, the default internationalization configuration file is placed in the resources directory, so we create four test files directly in this directory, as follows:

Our message file is created directly under the resources directory. When IDEA is displayed, there will be an extra Resource Bundle. Don't worry about this. Don't create this directory manually.

Messages.properties this is the default configuration, the other is a different language configuration, en_US is English (USA), zh_CN is simplified Chinese, zh_TW is traditional Chinese (there is a complete language abbreviation table in the appendix at the end of the article).

After the four files have been created, the first one can be left blank by default, and the other three can be filled in the following:

Messages_zh_CN.properties

User.name= a little rain in the south of the Yangtze River

Messages_zh_TW.properties

User.name= a rainy day in the south of the Yangtze River

Messages_en_US.properties

User.name=javaboy

Once the configuration is complete, we can start using it directly. Where you need to use the value, you can directly inject the MessageSource instance.

The MessageSource that needs to be configured in Spring does not need to be configured now. Spring Boot will automatically configure a MessageSource instance for us through org.springframework.boot.autoconfigure.context.MessageSourceAutoConfiguration.

Create a HelloController with the following content:

@ RestController public class HelloController {@ Autowired MessageSource messageSource; @ GetMapping ("/ hello") public String hello () {return messageSource.getMessage ("user.name", null, LocaleContextHolder.getLocale ();}}

In HelloController, we can directly inject the MessageSource instance, and then call the getMessage method in the instance to get the value of the variable. The first parameter is to get the key of the variable, the second parameter is that if there is a placeholder in the value, you can pass the parameter in here, and the third parameter passes a Locale instance, which is equivalent to the current locale.

Then we can call this interface directly.

By default, when the API is called, the Accept-Language of the request header is used to configure the current environment. Here, I test it through POSTMAN. The results are as follows:

Friends see that I set Accept-Language to zh-CN in the request header, so what I get is simplified Chinese; if I set zh-TW, I get traditional Chinese:

Is it very Easy?

2.2 Custom switching

Some partners find it inconvenient to put the switch parameters in the request header, so you can also customize the parsing method. For example, parameters can be placed on the address bar as normal parameters, and our requirements can be realized through the following configuration.

@ Configuration public class WebConfig implements WebMvcConfigurer {@ Override public void addInterceptors (InterceptorRegistry registry) {LocaleChangeInterceptor interceptor = new LocaleChangeInterceptor (); interceptor.setParamName ("lang"); registry.addInterceptor (interceptor);} @ Bean LocaleResolver localeResolver () {SessionLocaleResolver localeResolver = new SessionLocaleResolver (); localeResolver.setDefaultLocale (Locale.SIMPLIFIED_CHINESE); return localeResolver;}}

In this configuration, we first provide an instance of SessionLocaleResolver, which replaces the default AcceptHeaderLocaleResolver. Unlike AcceptHeaderLocaleResolver, which uses the request header to determine the current environment information, SessionLocaleResolver saves the client's Locale to the HttpSession object and can modify it (this means that the current environment information can be sent to the browser once by the frontend. As long as the session is valid, the browser does not have to tell the server the current environment information again).

In addition, we have configured an interceptor that intercepts the parameter in the request whose key is lang (if not configured, locale), which specifies the current environment information.

All right, after the configuration is completed, start the project and access it as follows:

We specify the current environment information by adding lang to the request. You only need to specify this once, that is, if the session is unchanged, the next request does not have to take the lang parameter, and the server already knows the current environment information.

CookieLocaleResolver is also used in a similar way, so I won't repeat it.

2.3 other customizations

By default, our configuration file is placed in the resources directory. If you want to customize it, you can also customize it, for example, in the resources/i18n directory:

But in this way, the system does not know where to load the configuration file, and additional configuration is required in application.properties (note that this is a relative path):

Spring.messages.basename=i18n/messages

In addition, there are some configuration of coding format, as follows:

Spring.messages.cache-duration=3600 spring.messages.encoding=UTF-8 spring.messages.fallback-to-system-locale=true

Spring.messages.cache-duration represents the cache expiration time of the messages file, and the cache is always valid if it is not configured.

Spring.messages.fallback-to-system-locale attribute is slightly magical, the Internet can not see a clear answer, and then turned over the source code to see the clue.

The role of this property takes effect in the org.springframework.context.support.AbstractResourceBasedMessageSource#getDefaultLocale method:

Protected Locale getDefaultLocale () {if (this.defaultLocale! = null) {return this.defaultLocale;} if (this.fallbackToSystemLocale) {return Locale.getDefault ();} return null;}

As can be seen from this code, when the resource file corresponding to the current system cannot be found, if the attribute is true, the resource file corresponding to the current system will be found by default, otherwise null will be returned. After returning null, the system default messages.properties file will eventually be called.

3.LocaleResolver

The main component involved in internationalization is LocaleResolver, which is an open interface and officially provides four implementations by default. What kind of environment should be used currently is mainly parsed through LocaleResolver.

LocaleResolver

Public interface LocaleResolver {Locale resolveLocale (HttpServletRequest request); void setLocale (HttpServletRequest request, @ Nullable HttpServletResponse response, @ Nullable Locale locale);}

Here are two ways:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

ResolveLocale: the parser sends out the Locale object based on the current request.

Sets the Locale object.

Let's take a look at LocaleResolver's inheritance relationship:

Although there are several abstract classes in the middle, in the end, only four are responsible for the implementation:

AcceptHeaderLocaleResolver: determine the current regional language based on the Accept-Language field in the request header, etc.

SessionLocaleResolver: determine the regional language according to the request parameters, which will be saved in Session. As long as the Session remains unchanged, the Locale object will always be valid.

CookieLocaleResolver: determine the regional language according to the request parameters, which will be saved in Cookie. As long as the Session remains unchanged, the Locale object will always be valid.

FixedLocaleResolver: a Locale object is provided directly during configuration and cannot be modified later.

Then we will analyze these classes one by one.

3.1 AcceptHeaderLocaleResolver

AcceptHeaderLocaleResolver directly implements the LocaleResolver interface. Let's take a look at its resolveLocale method:

@ Override public Locale resolveLocale (HttpServletRequest request) {Locale defaultLocale = getDefaultLocale (); if (defaultLocale! = null & & request.getHeader ("Accept-Language") = null) {return defaultLocale;} Locale requestLocale = request.getLocale (); List supportedLocales = getSupportedLocales (); if (supportedLocales.isEmpty () | | supportedLocales.contains (requestLocale)) {return requestLocale;} Locale supportedLocale = findSupportedLocale (request, supportedLocales); if (supportedLocale! = null) {return supportedLocale;} return (defaultLocale! = null? DefaultLocale: requestLocale);}

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

First go to get the default Locale object.

If there is a default Locale object and the Accept-Language field is not set in the request header, the default Locale is returned directly.

Extract the current Locale object from request, then query the supported supportedLocales, and return requestLocale directly if the supportedLocales or supportedLocales contains requestLocale.

If the previous match is not successful, extract the locales collection from the request, then compare it with the supported locale, and select the locale that matches and returns.

If the previous failed to return, determine whether defaultLocale is empty, if not empty, return defaultLocale, otherwise return defaultLocale.

Then look at its setLocale method, which directly throws an exception, which means that processing Locale through the request header is not allowed to be modified.

@ Override public void setLocale (HttpServletRequest request, @ Nullable HttpServletResponse response, @ Nullable Locale locale) {throw new UnsupportedOperationException ("Cannot change HTTP accept header-use a different locale resolution strategy");} 3.2 SessionLocaleResolver

The implementation of SessionLocaleResolver has added an abstract class, AbstractLocaleContextResolver,AbstractLocaleContextResolver, and added support for TimeZone. Let's take a look at AbstractLocaleContextResolver:

Public abstract class AbstractLocaleContextResolver extends AbstractLocaleResolver implements LocaleContextResolver {@ Nullable private TimeZone defaultTimeZone; public void setDefaultTimeZone (@ Nullable TimeZone defaultTimeZone) {this.defaultTimeZone = defaultTimeZone;} @ Nullable public TimeZone getDefaultTimeZone () {return this.defaultTimeZone;} @ Override public Locale resolveLocale (HttpServletRequest request) {Locale locale = resolveLocaleContext (request). GetLocale (); return (locale! = null? Locale: request.getLocale ();} @ Override public void setLocale (HttpServletRequest request, @ Nullable HttpServletResponse response, @ Nullable Locale locale) {setLocaleContext (request, response, (locale! = null?) New SimpleLocaleContext (locale): null);}}

As you can see, there is an extra TimeZone attribute. Parse the Locale from the request or call the resolveLocaleContext method, which is implemented in the subclass, and call the setLocaleContext method to set the Locale, the implementation of which is also in the subclass.

Let's take a look at its subclass SessionLocaleResolver:

@ Override public Locale resolveLocale (HttpServletRequest request) {Locale locale = (Locale) WebUtils.getSessionAttribute (request, this.localeAttributeName); if (locale = = null) {locale = determineDefaultLocale (request);} return locale;}

Get Locale directly from Session. The default attribute name is SessionLocaleResolver.class.getName () + ".locale". If the Locale information does not exist in session, call the determineDefaultLocale method to load Locale. This method will first find the defaultLocale, and return directly if the defaultLocale is not null, otherwise it will get Locale from request.

Let's take a look at the setLocaleContext method, which saves the parsed Locale.

@ Override public void setLocaleContext (HttpServletRequest request, @ Nullable HttpServletResponse response, @ Nullable LocaleContext localeContext) {Locale locale = null; TimeZone timeZone = null; if (localeContext! = null) {locale = localeContext.getLocale (); if (localeContext instanceof TimeZoneAwareLocaleContext) {timeZone = ((TimeZoneAwareLocaleContext) localeContext). GetTimeZone ();} WebUtils.setSessionAttribute (request, this.localeAttributeName, locale); WebUtils.setSessionAttribute (request, this.timeZoneAttributeName, timeZone);}

Just save it to Session. As you can see, this way of saving is basically the same as the self-saving code we demonstrated earlier, with the same goal by different paths.

3.3 FixedLocaleResolver

FixedLocaleResolver has three constructors, and no matter which one is called, the default Locale is configured:

Public FixedLocaleResolver () {setDefaultLocale (Locale.getDefault ());} public FixedLocaleResolver (Locale locale) {setDefaultLocale (locale);} public FixedLocaleResolver (Locale locale, TimeZone timeZone) {setDefaultLocale (locale); setDefaultTimeZone (timeZone);}

Either pass the Locale in yourself, or call the Locale.getDefault () method to get the default Locale.

Let's look at the resolveLocale method:

@ Override public Locale resolveLocale (HttpServletRequest request) {Locale locale = getDefaultLocale (); if (locale = = null) {locale = Locale.getDefault ();} return locale;}

There should be no need to explain this.

It is important to note that its setLocaleContext method throws an exception directly, which means that Locale cannot be modified later.

@ Override public void setLocaleContext (HttpServletRequest request, @ Nullable HttpServletResponse response, @ Nullable LocaleContext localeContext) {throw new UnsupportedOperationException ("Cannot change fixed locale-use a different locale resolution strategy");} 3.4 CookieLocaleResolver

CookieLocaleResolver and SessionLocaleResolver are similar, except that the storage media has become Cookie, and the others are almost the same. Brother Song will not repeat it.

4. Appendix

A list of language abbreviations has been searched and shared with all of you:

Language abbreviation: simplified Chinese (China) zh_CN traditional Chinese (Taiwan, China) zh_TW traditional Chinese (Hong Kong, China) zh_HK English (Hong Kong, China) en_HK English (USA) en_US English (UK) en_GB English (Global) en_WW English (Canada) en_CA English (Australia) en_AU English (Ireland) en_IE English (Finland) en_ Fifen Blue (Finland) fi_FI English (Denmark) en_ DK Danish (Denmark) da_DK English (Israel) en_IL Hebrew (Israel) he_IL English (South Africa) en_ZA English (India) en_IN English (Norway) en_NO English (Singapore) en_SG English (New Zealand) en_ID English (Philippines) en_ PHE Language (Thailand) en_TH English (Malaysia) en_MY English (Arabic) en_XA Korean (Korea) ko_KR Japanese (Japan) ja_JP Dutch (Netherlands) nl_NL Dutch (Belgium) nl_BE Portuguese (Portugal) pt_PT Portuguese (Brazil) pt_BR French (France) fr_FR French (Luxembourg) fr_LU French (Switzerland) fr_ Ch method Language (Belgium) fr_BE French (Canada) fr_CA Spanish (Latin America) es_LA Spanish (Spain) es_ES Spanish (Argentina) es_AR Spanish (USA) es_US Spanish (Mexico) es_MX Spanish (Colombia) es_CO Spanish (Puerto Rico) es_PR German (Germany) de_DE German (Austria) ) de_AT German (Switzerland) de_CH Russian (Russia) ru_RU Italian (Italy) it_IT Greek (Greece) el_GR Norwegian (Norway) no_NO Hungarian (Hungary) hu_HU Turkish (Turkey) tr_ TRCzech (Czech Republic) cs_ CZMalaysian sl_SL (Poland) pl_PL Swedish (Sweden) sv_ SE Spanish (Chile) es_CL "how to configure SpringMVC internationalization" ends here Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.