1. Chinese garbled characters
The high version of IE (should be 9 or above, not sure), in the get mode request, Chinese is prone to garbled characters when it is transmitted to the background. The workaround is as follows:
1. The first one, change to post method
If possible, change to post method. If you use a form or ajax, you can put the data into the form field or the data of ajax, and use a post request.
Note: After testing, put the data into the form, use the serialize() method of jQuery to obtain the data to be transmitted, and there will be no garbled problem through the GET method of ajax.
2. Second, use encodeURI()
If you must use the get method to directly concatenate the parameters in the url, you can use the encodeURI() method to encode the Chinese parameters. Important: the encodeURI() method needs to be used twice.
如：action="www.baidu.com?name=encodeURI(encodeURI('小明‘))"
After getting the data in the background, it also needs to be decoded. The java code:
- String name=request.getParameter("name");
- name= URLDecoder.decode(name, "UTF-8");
In this way, it can be used normally, and of course, it is the first simple and trouble-free.
2. Special characters
There are many distributed projects now, and urls often need to be passed back and forth between different sub-projects. Sometimes there are special characters such as +, space, /, ?, %, #, &, = in the url, which are easily lost during the transmission process. The solution is to use encoding instead of
+ + sign in URL means space %2B
space Space in URL can use + sign or encoding %20
/ separate directories and subdirectories %2F
? separate actual URL and parameters %3F
% specify special characters %25
# indicate bookmarks %23
& Separator between parameters specified in
URL %26 = value of parameter specified in URL %3D
PS:
js中：encodeURI（）
var o={};
o.summaryTitle=encodeURI($("#summaryTitle").val());
$.ajax({
url:url,
date: o,
success:function({
});
});
In action:
String summaryType = request.getParameter("summaryType");
java.net.URLDecoder.decode(summaryTitle,"UTF-8")
java.net.URLDecoder.decode
I encountered a strange problem in the project, that is, I used the java.net.URLDecoder.decode(ruleName) method to decode locally. There is no problem, and the local page can be opened normally. But when I ported the code to the test environment, I couldn't open the page, and there was no error message when I checked the background log.
JDK1.6 used in the local environment, 7 used by tomcat, and the tomcat version of JDK1.6 in the test environment is not clear
I was wondering, because this method has been prompted out of date, I was thinking about whether it was caused by this problem, there should be an alternative method, and then I went to check the JDK API, as follows
Try to change the java.net.URLDecoder.decode(ruleName) in the code to java.net.URLDecoder.decode(ruleName, "UTF-8"); Then compile and replace the code of the test environment, and find that the problem is solved.
This should be because some outdated codes in the JDK may be invalid in the lower version of tomcat, so everyone must try to avoid the use of outdated methods in future programming to avoid unnecessary problems.
java.net.URLDecoder.decode
I encountered a strange problem in the project, that is, I used the java.net.URLDecoder.decode(ruleName) method to decode locally. There is no problem, and the local page can be opened normally. But when I ported the code to the test environment, I couldn't open the page, and there was no error message when I checked the background log.
JDK1.6 used in the local environment, 7 used by tomcat, and the tomcat version of JDK1.6 in the test environment is not clear
I was wondering, because this method has been prompted out of date, I was thinking about whether it was caused by this problem, there should be an alternative method, and then I went to check the JDK API, as follows
Try to change the java.net.URLDecoder.decode(ruleName) in the code to java.net.URLDecoder.decode(ruleName, "UTF-8"); Then compile and replace the code of the test environment, and find that the problem is solved.
This should be because some outdated codes in the JDK may be invalid in the lower version of tomcat, so everyone must try to avoid the use of outdated methods in future programming to avoid unnecessary problems.