1, Page command in the pageencoding:
Sets the encoding to use when the JSP is compiled into a servlet when it is read. Typically, the strings that are defined inside the JSP (defined directly in the JSP, rather than the data submitted from the browser) are garbled, many of which are caused by the parameter setting error. Can only be used in JSPs.
In addition, when the page command contenttype and Response.setcharacterencoding methods are not set, it also specifies the encoding format for recoding the server response.
in fact, when the server is sending data, the encoding is to use response.setcharacterencoding-contenttype-pageencoding precedence.
2, Page command in the contenttype:
Specifies the encoding format to use when recoding a server response. Can only be used in JSPs.
In addition, when the Response.setcharacterencoding method is not set, it also specifies the encoding format for recoding the server response.
3, request.setcharacterencoding:
Specifies the encoding format for encoding client requests. The encoding format used to encode data that is sent from the browser end. Can be used for JSPs and servlet.
4, Response.setcharacterencoding:
Specifies the encoding format to use when recoding a server response. That is, before the server sends the data to the browser, it is encoded, and it is adopted. Can be used for JSPs and servlet.
In addition, when the browser accepts and sends the data, the encoding used is also the encoding format set in Response.setcharacterencoding. Which is called "Browser encoding."
--------------------------------------------------------------------------------------------------------------- ------------------
one, the actual interaction process, JSP made two times "code":
When the JSP is converted to a servlet, it is read by the encoding specified in Pageencoding, and then converted to the Java source in the unified UTF-8 format by the specified encoding scheme, that is, the servlet;
The servlet is actually the. java file, which is then converted to a. class file in UTF-8 encoding, the Java bytecode.
The server loads the Java bytecode, and then converts it to the client, which is what is seen in the browser, using the encoding format set in ContentType.
Second, the server in the sending data, the encoding method is to use the response.setcharacterencoding-contenttype-pageencoding priority order;
While the server in the acceptance of data, there are three kinds of situations: the browser directly with the URL submission data, table alone get or post way to submit data;
Because a variety of Web servers handle these three different ways, let's take Tomcat5.0 as an example.
Regardless of the manner in which it is submitted, if the parameter contains Chinese, the browser encodes it using the current browser encoding.
1, for the form of post method submitted data, as long as the data received in the JSP correctly request.setcharacterencoding parameters, will be the client request to encode the code set to browser encoding, you can ensure that the parameters are correctly encoded. In the default case, the browser encoding is the value you response.setcharacterencoding set in the JSP page where the request should be sounded. Therefore, for the data submitted by the Post form, in the JSP page where the data is obtained, request.setcharacterencoding is set to the same value as the response.setcharacterencoding that generated the JSP page that submitted the form.
2, for the data submitted by the URL and the form of the data submitted by get way, set the request.setcharacterencoding parameter in the JSP receiving the data is not possible, because in Tomcat5.0, by default, use iso- 8859-1 the data submitted by the URL and the data submitted by get in the form is recoding (decoded), instead of using this parameter to encode (decode) the data submitted by the URL and the data submitted by the form in a Get mode. To resolve this issue, you should set the Usebodyencodingforuri or uriencoding attribute in the Connector tab of the Tomcat configuration file, where
The Usebodyencodingforuri parameter indicates whether the data submitted by the URL and the form's Get method are encoded with the request.setcharacterencoding parameter, by default, The argument is false (this parameter defaults to true in Tomcat4.0);
The uriencoding parameter specifies a uniform recoding (decoding) encoding of all get-mode requests, including data submitted by the URL and the get-mode submissions in the form.
The difference between uriencoding and Usebodyencodingforuri is that uriencoding is a unified recoding (decoding) of the requested data for all get methods, And Usebodyencodingforuri is based on the requested page of the request.setcharacterencoding parameters of the data recoding (decoding), different pages can have different recoding (decoding) of the encoding. So for the data submitted by the URL and the data submitted by get in the form, you can modify the uriencoding parameter to encode the browser or modify Usebodyencodingforuri to true, and in the JSP page where the data is obtained The request.setcharacterencoding parameter is set to browser encoding.
The following summary, to Tomcat5.0 as a Web server, how to prevent Chinese garbled.
1, for the same application, the best unified coding, recommended for UTF-8, of course, GBK also can.
2, correctly set the JSP pageencoding parameters
3, in all Jsp/servlet set contenttype= "Text/html;charset=utf-8" or response.setcharacterencoding ("UTF-8"), This indirectly implements the settings for the browser encoding.
4. For requests, you can use filters or set request.setcharacterencoding ("UTF-8") in each jsp/servlet. Also, to modify the default configuration for Tomcat, it is recommended that you set the Usebodyencodingforuri parameter to True, or you can set the uriencoding parameter to UTF-8 (which may affect other applications, so it is not recommended).
Reprint the original text:
Http://hi.baidu.com/encodinglife/blog/item/5d1655091380c2a72fddd4dc.html
Http://www.showweb.cn/program/JSP/4450.html