Tomcat under the JSP garbled reason (bottom)

Source: Internet
Author: User


Series: The cause of JSP garbled under Tomcat


In the previous article, the main explanation of the file encoding, page encoding, how to decode, and analysis of the role of Tomcat, Poke here to learn more about the reasons for Tomcat JSP garbled (on)

Tomcat under the JSP garbled reason (below), here we are divided into the following points to explain the way to solve garbled, are combined with Tomcat.

1, Pure manual decoding

2, Setencoding

3, GET, POST method

4. By configuring Tomcat parameters

Well, let's take a closer look at the above methods

1, Pure manual decoding

This way, our previous article has done a more detailed description, the reason is put here to repeat the main is and several other ways can have a contrast. For example:
String ABC1 = new String (Abc.getbytes ("iso-8859-1"), "UTF8");  
The method is to decode the iso8859 encoded string into a UTF8-formatted string. It's called a purely manual method, because this way, you have to hand-convert this in all of your collection parameters.
String ABC1 = new String (Abc.getbytes ("iso-8859-1"), "UTF8");
It is not very troublesome to write this sentence. "Lazy" programmers are good programmers: is there any good way?


2, Setencoding

Let's review the source code for Tomcat in the previous article.

    String encoding = getcharacterencoding ();      if (encoding = = NULL)          encoding = "iso-8859-1";      try{          requestutil.parseparameters (queryparameters, queryparamstring, encoding);      } catch (Exception e) {          ;      }  

Here we first see that Tomcat defaults to setting the string to iso8859, but it is in the getcharacterencoding () to fetch the value, so we have a relatively simple way to deal with this problem

1, in string abc = Request.getparameter ("abc"), before we can write add a code to specifically set the request encoding, so Tomcat At the time of Getcharacterencoding ()

We can take the encoding we define, which is the code:

Request.setcharacterencoding ("UTF8"); String ABC = request.getparameter ("abc");

2. The ABC in the above code is directly UTF8 encoded. If we were to submit a UTF8 code, then the direct encoding is the right one. is not the first method inside, each string is to encode a lot more concise? Further, we can use a more efficient method of filter. You can define a filter specifically for this request.setcharacterencoding ("UTF8"); , and of course we're in every JSP, or servlet, or

Action, you do not have to deal with this encoding, which is more conducive to uniform processing of coding, of course, if the more flexible can be request.setcharacterencoding ("UTF8"), utf8 in the parameters, so that the more

Flexible and can be modified at any time without recompiling the program.

is not more in line with the lazy thought style, hehe, is indeed more concise than the first method a lot. But this is also a double-edged sword, concise at the same time, also hides a lot of content, many projects inside most of the people are for business, if there is no contact, then it is possible to confuse the middle also have these conversion things happen, so as a programmer should improve their quality, not just to complete the task, Well, this is out of our range. Well, after saying some nonsense, we'll go back to the subject.

The above we have from their own initiative to convert the code, to the unified code, then we can't help but think, there are other ways? The answer is yes, the great God of Tomcat has already considered these questions for us, but how much do we know about it? Let's start by doing some preparation knowledge.

3, GET, POST method

HTML get and Post methods, why do you want to list this problem here? Let's take a look at 2, or use the test.jsp and result.jsp in the previous article as an example:

First we set the method of get in test.jsp, we use HttpWatch to observe what is done by IE browser?

First of all, we set the method of post in test.jsp, we use HttpWatch to observe what is done by IE browser?

With the above 2 drawings, we can clearly see the changes in the time of submission of our test.jsp. A parameter in the head, a parameter in the body. (Note: This is also the reason that post can have longer data, and get is limited)
With this basic understanding, let's go back to the topic and see how Tomcat can help us deal with this coding problem.

4. By configuring Tomcat parameters

Tomcat handles the Get and post methods separately on this issue. We just need to modify the corresponding parameters.

The location and name of the parameter are Config/server.xml

<connector executor= "Tomcatthreadpool"               port= "8080" protocol= "http/1.1"               connectiontimeout= "               20000" redirectport= "8443"/>

Add parameters Inside:

Uriencoding= "GBK"

is to set the URL encoding for get time.

Let's show how to use the following separately:

    <connector port= "9090"                protocol= "http/1.1"               connectiontimeout= "20000"               redirectport= "       8443" uriencoding= "GBK"   />


Here we set Server.xml's urlencoding to GBK, test.jsp encoding is now GBK, and this is telling Tomcat that the URL parameter of my Get method is encoded in GBK mode. Look at the results:

When result.jsp is defined like this:

String ABC = request.getparameter ("abc"); if (ABC = = NULL) {   OUT.PRINTLN ("null value");  }  else   {      out.println ("Original code:");    OUT.PRINTLN (ABC);      Out.println (Java.util.Arrays.toString (Abc.getbytes ("iso-8859-1"));     Out.println (New String (Abc.getbytes ("iso-8859-1"));    Out.println ("</br>");    Out.println ("UTF8 Code:");    String ABC1 = new String (Abc.getbytes ("iso-8859-1"), "UTF8");      System.out.println (ABC1);       Out.println (ABC1);      Out.println ("</br>");    Out.println ("GBK Code:");    String ABC2 = new String (Abc.getbytes ("iso-8859-1"), "GBK");         Out.println (ABC2);   }     


The corresponding code and results, we can clearly see, we use the iso8859 way to decode the time, all error. But when you get the parameters directly, there is no garbled characters.

OK below we change the way of test.jsp to post, result.jsp way should not, we look at the result:


You can see that the parameter setting for this place is valid for Get mode.

Ramble and write so much, in fact, there are a lot of details there seems to be no way to suddenly involved and clear. Have a chance to say it later. Welcome to Exchange


Tomcat under the JSP garbled reason (bottom)

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.