Example code of coding and garbled code when java servlet uses printwriter

In the coding and garbled code series in the previous web pages, the dynamic response stream constructed by servlet has been mentioned many times, but the byte stream is directly used there. However, the more common way is to use character stream. Earlier, I talked about the topic of Java byte stream and character stream.

With the previous foundation, now let's talk about the coding and garbled code when using character stream in java servlet, that is, printwriter.

Review the byte stream

To recall, in the previous byte stream response, we used string GetBytes method, and then always explicitly pass in the encoded parameter to make it consistent with the declaration in meta or header. For example:

Or this:

As long as the consistency is maintained, there is no need to worry about the problem of garbled code.

Use printwriter character stream, default encoding

Now what if you use printwriter as a response? For example:

The code does not explicitly pass in any encoded parameters, unlike string GetBytes. On the other hand, we know that the character stream will eventually be converted into a byte stream, but what encoding does it use? Isn't it charset What about the value in defaultcharset?

Take the above code as an example. If you view it in the browser, you will find that the result is as follows:

It can be seen that defaultcharset defaults to UTF-8. As mentioned earlier, this actually comes from the parameter cdfile passed in when starting Tomcat server encoding：

However, Chinese characters are not output correctly. It can be seen that printwriter does not adopt this default value. To view the response in the header:

There is no indication of any coding.

Although the declaration in meta is UTF-8 and the value of the output default character set is UTF-8, it is not difficult to see from the final result that printwriter did not adopt this value to convert the byte stream. (in fact, it won't try to understand this at all).

Take a look at its document description and you will find that the situation is a little different:

When it is not specified, printwriter does not use charset Instead of the value in defaultcharset, use response If the value returned in the getcharacterencoding method is not specified, the method actually returns a default value: iso-8859-1.

Take another look at the getcharacterencoding method:

You can see that its value comes from the explicit response SetCharacterEncoding or response Setcontenttype method, or implicit setlocale method. (explicitly with higher priority) if not, use the default iso-8859-1.

It also refers to the RFC 2047 standard. Open it to see about the mime (Multipurpose Internet mail extensions) part three: message header extensions for non ASCII text. It is mentioned in this article that if the character set code is missing, iso8859 series is recommended:

That's all for the coding and garbled code when using printwriter in java servlet. See servlet printwriter for the sample code in this article_ jb51. rar