Shulou(Shulou.com)06/02 Report--

This article mainly introduces JSP and Servlet coding what is used, the text is very detailed, has a certain reference value, interested friends must read!

First, let's talk about the role of several codes in JSP and Servlet.

In JSP and Servlet, there are several places where encoding can be set, pageEncoding="UTF-8", contentType="text/html; characset = UTF-8", request. setCharacteristEncoding ("UTF- 8") and response. setCharacteristEncoding ("UTF-8"), of which the first two can only be used in JSP, and the latter two can be used in JSP and Servlet.

1. pageEncoding="UTF-8" is used to set the encoding used when compiling JSP into Servlet.

As we all know, JSP on the server is to be compiled into Servlet. pageEncoding="UTF-8" tells the JSP compiler what encoding to use when compiling JSP files into servlets. Often, when garbled characters appear in strings defined internally in JSP (defined directly in JSP, not data submitted from browser), many of them are caused by incorrect setting of this parameter. For example, if you specify pageEncoding="UTF-8" in your JSP file, which is encoded in GBK, it will cause the string defined inside JSP to be garbled.

In addition, this parameter has the ability to specify the encoding to re-encode the server response when the contentType parameter is not specified in the JSP and the response. setCharacteristEncoding method is not used.

ContentType="text/html;charset= UTF-8" specifies the encoding to re-encode the server response. Use this parameter to specify the encoding to re-encode the server response when the response. setCharacteristEncoding method is not used.

request. setCharacteristEncoding ("UTF-8") sets the encoding used to re-encode client requests. This method is used to specify the encoding to use when re-encoding (or decoding) data sent by the browser.

Response. setCharacteristEncoding ("UTF-8") specifies the encoding to re-encode the server response. This encoding is used by the server when it re-encodes the data before sending it to the browser.

Second, talk about how browsers encode data they receive and send.

response. setCharacteristEncoding ("UTF-8") specifies the encoding to re-encode the server response. At the same time, the browser also re-encodes (or decodes) the data it receives according to this parameter. So whether you set response. setCharacteristEncoding ("UTF-8") or response. setCharacteristEncoding ("GBK") in JSP, the browser will display Chinese correctly (provided that the data encoding you send to the browser is correct, such as setting the pageEncoding parameter correctly). Readers can do an experiment, set response. setCharacteristEncoding ("UTF- 8") in JSP, when displaying the page in IE, select "View (V)"à"Encoding (D)" in IE menu to see " Unicode (UTF-8)," and set response. setCharacteristEncoding ("GBK") in JSP, when displaying the page in IE, select "View (V)"à"Encoding (D)" in IE menu to see "Simplified Chinese (GB2312)."

When the browser sends data, it will encode URL and parameters. For Chinese in parameters, the browser also uses response. setCharacteristEncoding parameter to encode URL. Take Baidu and Google for example. If you search for "Chinese characters" in Baidu, Baidu will encode them as "%BA%BA%D7%D6." Search for "Chinese character" in Google, Google will encode it as "%E6%B1%89%E5%AD%97", this is because Baidu's response. setCharacteristEncoding parameter is GBK, and Google's response. setCharacteristEncoding parameter is UTF-8.

The encoding used by the browser when receiving data from the server and sending data to the server is the same. By default, it is the response. setCharacteristEncoding parameter (or contentType and pageEncoding parameters) of the JSP page, which we call browser encoding. Of course, the browser code can be modified in IE (in IE's menu, select "View (V)"à"Code (D)"), but usually, modifying this parameter will cause garbled characters to appear on the otherwise correct page. An interesting example is that when browsing Google's homepage in IE, the browser code is modified to "Simplified Chinese (GB2312)." At this time, the Chinese on the page will become garbled, ignore it, enter "Chinese characters" in the text box, submit, and Google will encode it as "%BA%BA%D7%D6." It can be seen that the browser uses the browser code when encoding the URL of Chinese.

Now that we know how browsers encode data when they receive and send it, let's look at how servers encode data when they receive and send it.

For sending data, the server encodes the data to be sent in priority order of response. setCharacteristEncoding-contentType-pageEncoding.

For receiving data, there are three situations. One is data submitted directly by the browser using URL, and the other two are data submitted using GET and POST methods of the form.

Because various WEB servers handle these three ways differently, we take Tomcat 5.0 as an example.

Either way, if the parameter contains Chinese, the browser will URL encode it using the current browser encoding.

For data submitted in POST mode in the form, as long as the request. setCharacteristEncoding parameter is correctly set in the JSP receiving the data, i.e., the encoding for re-encoding the client request is set to the browser encoding, the obtained parameter encoding can be guaranteed to be correct. Some readers may ask, how do I get the browser code? As mentioned above, by default, the browser encoding is the value you set for response. setCharacteristEncoding in the JSP page that responds to the request. So for the data submitted by the POST form, request. setCharacteristEncoding in the JSP page that gets the data should be set to the same value as response. setCharacteristEncoding in the JSP page that generated the submitted form.

For data submitted by URL and data submitted by GET in form, it is not possible to set the request. setCharacteristEncoding parameter in the JSP receiving the data, because in Tomcat 5.0, ISO-8859-1 is used by default to re-encode (decode) the data submitted by URL and data submitted by GET in form, instead of using this parameter to re-encode (decode) the data submitted by URL and data submitted by GET in form. To resolve this issue, you should set the useBodyEncodingForURI or URIEncoding attribute in the Connector tag of Tomcat's configuration file, where the useBodyEncodingForURI parameter indicates whether to reencode the data submitted by URL and GET in the form with the request. setCharacteristEncoding parameter, which is false by default (This parameter defaults to true in Tomcat 4.0); the URIEncoding parameter specifies the encoding to uniformly re-encode (decode) all GET mode requests, including data submitted by URLs and GET mode data submitted in forms. The difference between URIEncoding and useBodyEncodingForURI is that URIEncoding uniformly re-encodes (decodes) all data requested in GET mode, while useBodyEncodingForURI re-encodes (decodes) the data according to the request. setCharacteristEncoding parameter of the page corresponding to the request. Different pages can have different re-encoding (decoding) encodings. Therefore, for the data submitted by URL and the data submitted by GET mode in the form, you can modify the URIEncoding parameter to browser encoding or modify the useBodyEncodingForURI to true, and set the request. setCharacteristEncoding parameter to browser encoding in the JSP page for obtaining data.

Below is a summary of how to prevent Chinese garbled code when Tomcat5.0 is the WEB server.

1, for the same application, *** unified coding, recommended for UTF-8, of course GBK can also be.

2. Set the pageEncoding parameter of JSP correctly

3. Set contentType="text/html;charset= UTF-8" or response. setCharacteristEncoding ("UTF-8") in all JSP and Servlets, thus indirectly realizing the setting of browser encoding.

For requests, you can use filters or set request. setCharacteristEncoding ("UTF-8") in each JSP and Servlet. Also, to modify Tomcat's default configuration, it is recommended to set the useBodyEncodingForURI parameter to true, or set the URIEncoding parameter to UTF-8 (it may affect other applications, so it is not recommended).

The above is "JSP and Servlet coding what to use" all the content of this article, thank you for reading! Hope to share the content to help everyone, more relevant knowledge, welcome to pay attention to the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.