Java Web garbled Analysis and solution (III.)--garbled response

Response garbled

The request garbled is a server decoding error when the client sends data to the server. Response garbled is the server after processing the request, the output to the browser data by the browser error decoding caused by the display garbled, this kind of garbled is the most common is the most direct. The most direct result of this kind of garbled situation is that the server set the error to the CONTENT-TYPE response message.

page encoding:

Our page in general, may be generated in the following two ways, that is often said static pages and dynamic pages:

(1) static page: We use Notepad or other IDE tools to write pages (such as. html), these pages are written in the need to specify a character encoding, for example, we are designated as ISO-8859-1, then we write Chinese, it will be garbled, because there is a problem when saving. In this case, we will generally save the file (UTF-8) in Unicode. Then set the META tag's content-type in the page to the corresponding encoding and there will be no problem.

(2) dynamic page: Program dynamic output, such as with template technology or Java JSP, servlet assembled pages, this kind of technology will generally maintain consistent coding, such as Java with Unicode, so the output of Chinese is no problem. What we need to set is the Content-type to tell the browser page the encoding type.

When using JSP template technology, there are two parameters affecting the encoding, one is pageencoding, and the other is that contenttype,pageencoding, as the name implies, specifies the page encoding, which affects the JSP files compiled into Java and class files, The encoding used by the container to read the contents of the JSP file, for example, our JSP file is saved with UTF-8, but Pageencoding uses the iso-8859-1, then the JSP is pre-compiled as a class file is garbled, JSP was first translated into Java file, Java files are unified using UTF-8, then Java is compiled into a class file, uniformly using Unicode encoding (UTF-8), and then the Web container executes the class file output HTTP package body to the client, this time using the encoding is contenttype specified encoding.

Although the relationship between Pageencoding and ContentType is a bit messy, but generally their settings are related, many web containers after setting a property, another property is automatically set to the same, their two default values are iso-8859-1. When actually developing, we will set these two property values to be consistent. And when garbled, first determine whether the browser is actually using the encoding and contenttype is consistent, if consistent, adjust the value of pageencoding can generally solve garbled.

Content-type Response Header

After the page is made up of the server, we are going to transfer it to the browser, which will first build the response header, and a lot of the response headers are handled by the container itself, such as content-language, content-length, etc. In the numerous headers there is a very famous very imporant is the Context-type header.

This header tells the client entity what the media type (MIME) is, and theWeb browser uses Content-type to determine what module is used to process the body of the response, while determining the encoding type of the file with the additional charset parameter . The browser then invokes the corresponding module and encoding scheme to decode the file of the response body.

on the server side by calling response. The setContentType method can set the properties of this header. Also note that we are talking about the HTTP protocol here, but many web containers do not only support the HTTP protocol, the HTTP protocol is just one of its cases.

setContentType, setcharsetencoding and setlocale

The response API begins with the following instructions:

The charset for the MIME body response canbe specified explicitly using the setcharacterencoding (java.lang.String) andsetc Ontenttype (java.lang.String) methods, or implicitly using Thesetlocale (Java.util.Locale) method. EXPLICIT specifications take precedenceover implicit specifications. If No CharSet is specified, iso-8859-1 'll beused. The setcharacterencoding, setContentType, or SetLocale method must becalled before Getwriter and before committing the res Ponse for the characterencoding to be used.

See the Internet RFCs such as RFC 2045 Formore information on MIME. Protocols such as SMTP and HTTP define profiles ofmime, and those standards are still evolving.

It means that there are three methods that affect the character encoding of response body, setContentType and setcharsetencoding have been setlocale. (Note the API descriptions of these three methods, which are important for the first-hand data)

by looking at the API you can see that setContentType is directly set to Content-type, you can specify charset by passing. Setcharsetencoding can not be called, after the call, quite with the set Content-type character encoding part. SetLocale not important, you can ignore it, it is set to Content-language, if set Content-type it fails. and call setContentType set to Text/html;charset=utf-8 can not call setcharsetencoding (careful framework has been modified).

garbled appearance:

According to the above, the response appears garbled, modify two places, one is to call Response.setcontenttype set MIME and character encoding, two modified page HTML tags. It's all right to stay consistent. For static pages, make sure that the encoding to save the file is consistent with the encoding specified by the HTML tag. Also remember to adjust a pageencoding for JSP files.

Tomcat's official advice:

in its official documentation, Tomcat gives advice on how to avoid chaos, as follows:

What is canyou recommend to just make everything? (How to use UTF-8 everywhere).

Using UTF-8 asyour character encoding for everything are a safe bet. This should work forpretty much every situation.

In order to Completelyswitch to using UTF-8, you need to make the following changes:

1.Set uriencoding= "UTF-8" onyour <Connector> in server.xml. References: httpconnector, ajpconnector.

2.Use a characterencoding filter withthe default encoding set to utf-

3.Change all your JSPs to include CharSet name in their contentType.

For example, use <% @page contenttype= "text/html; charset=utf-8"%> forthe usual JSP pages and <jsp:d Irective.page contenttype= "text/html; Charset=utf-8 "/> forthe pages in XML syntax (aka JSP Documents).

4.Change all your servlets to set the content type for responses and to include charset name in the content type to be UTF -8.

Use response.setcontenttype ("text/html; Charset=utf-8 ") or response.setcharacterencoding (" UTF-8 ").

5.Change any content-generation libraries your use (Velocity, freemarker, etc) to use UTF-8 and to specify UTF-8 in the CO Ntent type of the responses that they generate.

6.Disable any valves or filtersthat may read request parameters before your character encoding filter or Jsppage ha S a chance to set the encoding to UTF-8. for more information see http://www.mail-archive.com/[email protected]/msg21117.html.

This means: In the Rectification project using UTF-8 as a character set, it can work perfectly in all situation, in order to fully use the UTF-8, you need to do the following settings:

(1) Setting uriencoding= "UTF-8" in the connector of Server.xml;

(2) using Tomcat-provided charsetencodingfilter (similar to spring MVC);

(3) Set the content-type= "Text/html;charset=utf-8" in the page directive of JSP pages; or Jsp:directive.page contenttype= "text/html; Charset=utf-8 "

(4) Call setContentType "Text/html;charset=utf-8" in all Servlets Or the Setcharsetencoding method sets the Content-type encoding to UTF-8,

(5) Setting all template techniques (such as freemarker, velocity, etc.) using UTF-8, or explicitly specifying the content-type of the response head as UTF-8;

(6) Do not allow any other filter to read the request parameters until your character encoding filter is working.

Summary:

The problem with garbled pages is that the browser does not use the specified character set for parsing the page, this can be done by the right-click menu to see what type of character set the browser uses for the current page, and then to compare whether the Content-type setting is incorrect, if yes, Determine if the HTML tag settings are not a problem, if both are OK, it is necessary to determine whether the file is not used to save the specified character set.

Note--response's API Response.setcontettype

Sets the content type of the response beingsent to the client, if the response have not been committed yet. The givencontent type may include a character encoding specification, for example, Text/html;charset=utf-8. The response ' s character encoding are only set from the given content type Ifthis method is called before getwriter are call Ed.

This method is called repeatedly tochange content type and character encoding. This method has a effect if calledafter the response has been committed. It does not set the response ' s characterencoding if it's called after getwriter have been called or after theresponse have been committed.

Containers must communicate the content Typeand the character encoding used for the servlet response's writer to the Clien TIF the protocol provides a-on-doing so. In the case of HTTP, the Content-type Headeris used.

If response has not yet occurred, set the content type of response before sending response to the client, and the content type set can contain character encodings such as: Text/html;charset =utf-8. If this method is called before Getwriter is called, then the response encoding will be set according to the given content type.

This method can be called repeatedly to change the content type and character encoding. If called after response commits, this method is not valid. If this method is called after Getwriter is called or after response commits, the response character encoding setting will not work.

If the protocol provides a way to communicate the content type to the client, the container will use response's wirter to send information about the content type and character encoding to the container. The Content-type header is used under the HTTP protocol.

setcharsetencoding

Sets the character encoding (MIME charset) of the response being sent to the client, for example, to UTF-8. If Thecharacter encoding have already been set bysetContentType (java.lang.String) or SetLocale ( Java.util.Locale), this method overrides it. Calling setContentType (java.lang.String) withthe string of text/html and calling this method with the String of U TF-8 isequivalent with calling setContentType with the String of Text/html;charset=utf-8.

This method can be called repeatedly tochange the character encoding. This method has no effect if it's called after Getwriter Hasbeen called or after the response have been committed.

Containers must communicate the characterencoding used for the servlet response's writer to the client if the Protocolprov Ides A-on-doing so. In the case of HTTP, the character encoding iscommunicated as part of the Content-type header for text media types. Note that the character encoding cannot is communicated via HTTP headers if Theservlet does not specify a content type; However, it is still used to encodetext written via the servlet response ' s writer.

before response is sent to the client, set the character encoding type (MIME characters), for example, using "UTF-8" encoding. If the character encoding has been set by setContentType or setlocale, this method will overwrite them. The following calls are equal, call setContentType to set the content type to text/html, call Setcharsetencoding to set the character encoding to UTF-8, Equivalent to calling setContentType to set the content type to Text/html;charset=utf-8

This method can be called repeatedly, but must precede getwriter or before response is committed.

The container will tell the client the character encoding if the protocol provides the appropriate means of communication. Under the HTTP protocol, the character encoding is provided to the client as part of the Content–type header. It is important to note that if the servlet does not specify a content type, the character encoding will not be sent to the client via the HTTP protocol, but the text sent to the client will still be encoded with the given character set.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Java Web garbled Analysis and solution (III.)--garbled response