1. Interface garbled problem
First, analyze the whole process. First, the browser opens the webpage, obtains the webpage data, reads the code set in the meta tag, and parses the webpage through the specified code. If it is not set, the browser uses the default code for parsing. The default encoding is different. So it will lead to this browser not garbled that browser garbled problem.
The way to solve this problem for jsp is to add the following code
<%@ page language="java" import="java.util.*" contentType="text/html; charset=UTF-8" %>By setting the charset setting in the contentType attribute to specify the encoding, jsp will automatically parse the attribute value into the following tags when parsing
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>Therefore, after adding the page command, this meta tag does not need to be added at all and it will appear automatically.
For garbled html pages, add the above meta tag to solve the garbled problem. Note that the meta tag needs to be added to the head tag.
2. The problem of passing parameters is garbled
We continue to analyze the process. After the browser obtains the encoding of the meta tag, she will also set the encoding to form submission encoding and ajax submission encoding. At this time, if the form is submitted, (if the project is running in tomcat, then it will be submitted to tomcat first, and tomcat will pass the request to the filter, servlet, etc. through the configuration of web.xml), and tomcat will do the request here. an encoding process. That is our tomcat's context.xml configuration file
<Connector executor="tomcatThreadPool"
port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
URIEncoding="UTF-8" />This code, pay special attention: do not change the commented code, the real code has not changed (it is best to edit it with an editor that supports code highlighting). The port here is the startup port, the protocol is the HTTP protocol version, the connectionTimeout connection timeout (in milliseconds), and the URIEncoding is the URI encoding. What is the URI? URI is actually the thing behind the request url domain name, for example http://www.baidu.com/test/hello, the uri is /test/hello. That is to say, this configuration will affect all GET request encodings, and some POST request encodings. Because the parameters of the GET request are all spelled behind the url, it will directly affect it. As for post requests, form submissions are all in the request body (please see the http protocol for details), not behind the url. So it won't affect him here. But the post submission of ajax, this can be customized, if it is spliced in the parameters behind the url, it will naturally also affect. Not in the request body. Some get request garbled post is not garbled because of this reason.
Continue the analysis process, the request passes tomcat, and the next step is to enter the interceptor in web.xml. If there is no interceptor, go directly to the filter. springmvc solves the problem of garbled characters through the following code.
<filter>
<filter-name>characterEncodingFilter</filter-name>
<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<init-param>
<param-name>forceEncoding</param-name>
<param-value>true</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>characterEncodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>As you can see, this is the filter. The principle of this filter is very simple, if you have space, you can look at the source code. It is to set the encoding of the request. As for what this forceEncoding is, it is actually whether to set the encoding of the response at the same time. The default value is false, that is, not set. Then the problem comes, springmvc is also a filter. They are all filters, let's say the request comes. The request advanced the springmvc filter, and then entered the encoding filter. So this encoding filter is useless. Because the request has been processed, what is the use of setting the encoding again. So there is a problem of execution order. The execution order of filters in web.xml is actually very simple, that is, the ones written in the front are executed first, and the ones in the back are executed later. It is usually sufficient to set the encoding filter to the first filter.
3. The code is normal, the database is missing garbled characters
This problem is because the data encoding is inconsistent with the code encoding, and the database encoding is not related to the table. This table does not exist with this code and the table with this code does not exist. So if you want garbled code, all the tables are garbled. The solution is to change the encoding of the database, which sometimes doesn't work. You need to delete the database (delete the database and run away), and then recreate the database (select the encoding when creating). Be sure to remember to back up your data, don't really delete the database and run away. It can be solved, and each kind of data operates in different ways. Not much introduction here, Baidu Encyclopedia by yourself.
4. @ResponseBody garbled in the deep pit of springmvc
For example, for some asynchronous ajax requests, the ResponseBody annotation will be added directly to the controller method, and then the String or entity type can be returned directly. springmvc will automatically parse it into string or json data for me and return it to the browser. Since the magical spirngmvc is garbled here, the tomcat is also configured, the encoding filter is also configured, and the forceEncoding property is also set to true. The result is still garbled, you need to add the following code to solve
Option One
@RequestMapping(value = "test.html",produces = "application/json;charset=utf-8")It is to configure the produces attribute in the RequestMapping annotation of the controller request method to set the response encoding. The disadvantage of this solution is that it directly solves one method, and it is disgusting to add one to each method.
Option II
<mvc:annotation-driven>
<mvc:message-converters>
<bean class="org.springframework.http.converter.json.MappingJacksonHttpMessageConverter"/>
<bean class="org.springframework.http.converter.StringHttpMessageConverter">
<property name="supportedMediaTypes">
<list>
<value>text/plain;charset=utf-8</value>
<value>text/html;charset=UTF-8</value>
</list>
</property>
</bean>
</mvc:message-converters>
</mvc:annotation-driven>Configuring one of this solves it all. Let's talk about why it is garbled. Here's a brief introduction, depending on the source code of spring. When springmvc processes the method with the ResponseBody annotation on the return method, it will enter many message converters. The above configuration is to configure the encoding of the message converter. If it is an object type, it will first enter a converter that converts the object into a json string, and then pass the processing result to a string converter for processing, and then it will be processed as Byte binary data, here you need to convert it into binary data by specifying the encoding. Our configuration is to configure this thing, and there are many complicated steps in the middle. Here is a brief summary.
At this point, the garbled problem of springmvc has almost disappeared.