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

Most people do not understand the knowledge points of this article "how to solve the problem of tomcat GET request parameter garbled", so the editor summarizes the following content, detailed content, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this "how to solve the problem of tomcat GET request parameter garbled" article.

In the Connector configuration of Tomcat, in addition to URIEncoding, there is also a parameter useBodyEncodingForURI that affects coding. The official document describes this parameter as follows:

This specifies if the encoding specified in contentType should be used for URI query parameters, instead of using the URIEncoding. This

Setting is present for compatibility with Tomcat 4.1.x, where the encoding

Specified in the contentType, or explicitly set using Request.setCharacterEncoding method was also used for the parameters from the URL. The default value is false.

Notes: 1) This setting is applied only to the query string of a request. Unlike URIEncoding it does not affect the path portion of a request URI. 2) If request character encoding is not known (is not provided by a browser and is not set bySetCharacterEncodingFilter or a similar filter using Request.setCharacterEncoding method), the default encoding is always "ISO-8859-1". The URIEncoding setting has no effect on this default.

Its purpose is roughly summarized as to whether the encoding specified in contentType replaces the value that URIEncoding has already set. Or use the encoding of Body for parameter parsing of URI, and the encoding of this Body comes from two sources:

Request.setCharacterEncoding ()

The encoding contained in the contentType set in request header

If the charset information can be obtained from the above two places, and the useBodyEncodingForURI parameter is also set to true, the same charset is also used for parameter parsing of the GET request.

If the charset is not available in either place, the Body encoding will use the default value ISO-8859-1, which is generally noted. But when this parameter is set to true, there is an implicit condition that the encoding of the GET request will also use the default encoding ISO-8859-1, regardless of what your previous URIEncoding set.

In this case, although the code set by URIEncoding can handle Chinese normally, if this opening and merging is configured, it is not set in accordance with its regulations, which will lead to garbled codes again. Tomcat8 has set URIEncoding to UTF-8 by default. If useBodyEncodingForURI is specified in the configuration, garbled code will appear.

For this configuration, the default is false.

/ * *

* URI encoding as body.

, /

Protected boolean useBodyEncodingForURI = false

Use whether this configuration works or not, here

/ / getCharacterEncoding () may have been overridden to search for

/ / hidden form field containing request encoding

String enc = getCharacterEncoding ()

Boolean useBodyEncodingForURI = connector.getUseBodyEncodingForURI ()

If (enc! = null) {

Parameters.setEncoding (enc)

If (useBodyEncodingForURI) {

Parameters.setQueryStringEncoding (enc)

}

} else {

Parameters.setEncoding

(org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING)

If (useBodyEncodingForURI) {/ / the configuration here is easy to ignore.

Parameters.setQueryStringEncoding

(org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);}

}

Let's take a look at the acquisition of enc variables

Request class in the coyote package: / * *

* Get the character encoding used for this request.

, /

Public String getCharacterEncoding () {

If (charEncoding! = null) {/ / the value here is set through request.setCharacterEncoding

Return charEncoding

}

CharEncoding = getCharsetFromContentType (getContentType ())

Return charEncoding

}

The code for getting charSet from ContentType is no longer listed here.

A brief summary is as follows:

The common factors that affect the parsing coding of URI parameters (GET request) are: 1. URIEncoding configuration of Connector

2. UseBodyEncodingForURI configuration of Connector. If this configuration is true, the charset of ContentType or the encoding specified by request.setCharacterEncoding will be used directly.

Note that the request setting will be used first. 3. Pay special attention to, when setting useBodyEncodingForURI to true, if getCharacterEncoding is empty, that is, request is not encoded, and ContentType is not configured with charset, then queryString will be set to ISO-8859-1 or above, which is the content of this article on "how to solve the garbled code problem of tomcat GET request". I believe we all have some understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about the relevant knowledge, please 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.