The URL is used to pass Chinese parameters. The Windows and Linux functions are inconsistent (two solutions ).
In the afternoon, I plan to complete the Upgrade within two hours. On the personal website, I will perform the upgrade for 6th times. As a result, I spent two more hours in the afternoon and two more hours in the evening,.
The last challenge in the world is to pass Chinese parameters through URLs.
The problem is roughly as follows: I added the full-text search feature for the blog review, which was implemented using lucene. Therefore, you must pass Chinese parameters.
Submit the form in the search box and pass Chinese characters. It's easy to do.
The pagination url after the search must contain the current "search term", such as "programmer", which is easy for me to do locally. This is nothing more:
Search/search.html? Keyword = $ {keyword} "keyword is a Chinese Word, such as" programmer ".
I thought it would be okay if I threw it onto the server and restarted it once. When I clicked page 2nd, I did not find any articles.
Check the log and find that the search term is garbled ".
My first response was that the passed Chinese "programmer" did not properly perform url encoding, so:
<# Setting url_escaping_charset = 'utf-8'>
<# Assign url = "$ {base}/search/search.html? Keyword =$ {keyword? Url} "/>
After the search term is encoded, It is appended with the Url,:
Windows Local Environment, OK, worked. However, the online Linux environment still does not work.
I tried multiple times on QQ, Chrome, and IE around whether the code is correct. As a result, no matter whether url encoding is performed, all local Windows browsers can pass Chinese parameters normally, and online Linux fails.
Since it is not about URL encoding, I think it should be about Chinese encoding. (In the 1st years of Java Web development, I encountered a variety of coding problems, so I am very experienced now .)
String a = "maid ";
Byte [] B = a. getBytes ("iso8859-1 ");
System. out. println (new String (B, "UTF-8 "));
The final output is "programmer", which fully demonstrates that the linux Online environment is caused by "inconsistent Chinese encoding and decoding ".
@ RequestMapping ("search ")
Public String search (String keyword ).
At the beginning, I still made a mistake, thinking that the keyword is still url encoding and still needs to be decoded.
Later, we found that SpringMVC will automatically perform url Decoding when receiving parameters. At this time, the keyword is already a "character.
My solution:
Log.info ("searchKey =" + keyword );
SearchService. search (lucendexdexdir, keyword, pageVo );
// It may be caused by garbled Parameters
If (pageVo. getTotalCount () <= 0 ){
// Although the Chinese parameters sent by the browser are url encoded, spring will automatically decode them. The reason for garbled characters is that the url encoding is different from the "character set encoding" of url Decoding.
// If this problem occurs in online linux, and then convert the iso5559-1 string to UTF-8
Log.info ("search url iso8859-1, when in is:" + keyword );
Byte [] B = keyword. getBytes ("iso8859-1 ");
Keyword = new String (B, "UTF-8 ");
SearchService. search (lucendexdexdir, keyword, pageVo );
Log.info ("search url iso8859-1, when out is:" + keyword );
}
If no results are found for the first time, it is very likely that "Chinese garbled characters" will be converted to the correct characters, and then the query will be performed again.
My approach is really not the best. However, I have not been able to try a universal one-time solution for the moment. Windows is normal, Linux is not normal, and it is difficult to do so.
Only two queries are allowed to ensure that the content is not found due to garbled characters.
-----------------------------
The above is written on the 14th.
Today I will add a "best solution ":
Modify Tomcat's URIEncoding to a UTF-8 on the server
The Processing Method for garbled Chinese parameters transmitted by URLs is special. The problem cannot be solved only by converting the Chinese string or setting the display encoding of the JSP page, you must modify the configuration file of the Tomcat server to solve the problem. Modify the server. xml configuration file in the conf directory of Tomcat. The code after modification is as follows:
Server. xml
<Connector port = "8080" protocol = "HTTP/1.1" URIEncoding = "UTF-8"
ConnectionTimeout = "20000"
RedirectPort = "8443" type = "regxph" text = "yourobjectname"/>
Add URI encoding settings URIEncoding = "UTF-8" in the original code, restart the Tomcat server to get the correct page. The principle is similar to the above situation, that is, to specify the encoding type for the program, and then the display is normal.
When reading this article, I think it should be this problem.
Http://blog.csdn.net/beijiguangyong/article/details/7414247
I generally do not like to modify Tomcat configurations, but prefer "default.