Solution to struts and ajax garbled characters

The garbled problem seems to have a special relationship with our Chinese programmers. It has been plagued by the JSP garbled problem, STRUTS garbled problem, and now the AJAX garbled problem, no one is engaged in a lot of programmers, all day scold XXX products for Chinese support, UTF-8 can not use Chinese ah what, in fact, more than 99% of the products mentioned above provide excellent support for Chinese characters. The reason for garbled characters is that they do not know about international support, file encoding, and other information. If you want to know how popular a product is, how can you not support Chinese? Let's start to solve these problems one by one.

1. Encoding
-- If you want to solve the Chinese problem, you must not understand the encoding. encoding is the root solution to the Chinese Garbled text problem.
Commonly used encoding are: UTF-8, GBK, GB2312, ISO-8859-1, in addition to the iso-8859-1 of the other three encoding can be very good support for Chinese, but they are compatible with the ISO-8859-1 encoding (that is, no matter how the encoding changes, as long as it is a character in the ISO-8859-1, there will never be garbled ).

Among the four types of codes, GB2312 is a Chinese character encoding set specified by China, or a simplified Chinese character set encoding. GBK is an extension of GB2312, in addition to compatibility with GB2312, it can also display Traditional Chinese and Japanese Kana; while UTF-8 although also supports Chinese, but not compatible with the GB code (encoding value ). The UTF-8 uses a variable-length UNICODE encoding that may be 1-bit hexadecimal (that is, a character in the ISO-8859-1, which is also encoded in the same way) it may also be two or three hexadecimal digits. UTF-8 advantages are:

1. It is irrelevant to the CPU byte sequence and can communicate with each other on different platforms.
2. High Fault tolerance capability. If any one byte is damaged, only one encoding bit may be lost at most and no chainlock error will occur.
(For example, if the GB code is wrong, a byte will be garbled in the whole line), so in international processing, it is basically recommended to use UTF-8 as the encoding.

2. file encoding
Although you only need to set the correct encoding to display the characters correctly, if you ignore the encoding when saving the file, it will make you go into the fog.

There are two most commonly used file encoding types: ANSI and UTF-8, you can guess the name, ANSI is the default encoding we use to save the file, and UTF-8 needs to set their own. I used NOTEPAD and ECLIPSE tools for coding changes. NOTEPAD is the easiest to use. Just open the file and select the corresponding encoding in the Save As file, in addition, it supports encoding very well. In ECLIPSE, you only need to set the encoding slightly, open the preferences, and then select: regular-> content type (ContentType ), on the right side, select the file type you want to change the encoding, change its value in the default encoding below, and click UPDATE.

In other editors, the default saved content is GB2312 or GBK (corresponding to ANSI in NOTEPAD ). and according to the above mentioned UTF-8 and GBK, GB2312 and Other encoding values are different, you can know, if the file uses a UTF-8, then character encoding must use UTF-8, otherwise, different encoding values may cause garbled characters. This is why so many people use the UTF-8 encoding will also produce garbled root cause. (This is true for JS and JSP)

3. Chinese garbled solutions for JSP and STRUTS
In fact, there is only one solution:

Request. setCharacterEncoding (encoding );

There is only one method, but there are a variety of processing methods. Beginners will use it directly on JSP pages, while experienced programmers will use filters. The method to be mentioned now is also a filter. Here we use a unified use of UTF-8 as an example. There are many tutorials on the Internet. A little lazy, just copy it to TOMCAT. In the TOMCAT directory \ webapps \ jsp-examples \ WEB-INF \ classes \ filters \ find the SetCharacterEncodingFilter. java class, put it in your program and configure the ing path. After the configuration, your garbled problem is basically solved. However, you must note that you cannot use '*' in the ing path '*'

<Filter-mapping>
<Filter-name> Set Character Encoding </filter-name>
<Servlet-name> * </servlet-name>
</Filter-mapping>

If you configure it like the above (it may also be the practice of most tutorials on the internet, and I think it would have hurt me too), you may only have to solve JSP garbled code. To solve STRUTS garbled code, you need to map *. do or servletActionName. Set the encoding value in the initialization parameter.

<Init-param>
<Param-name> encoding </param-name>
<Param-value> UTF-8 </param-value>
</Init-param>

Of course, the most important thing is to remember to change the encoding of the file saved in the editor according to the method mentioned above to be consistent with the character encoding used.
In JSP content, we still use the technology mentioned in the online tutorial to add the following to the top of all pages:

<% @ Page language = "java" contentType = "text/html; charset = UTF-8" pageEncoding = "UTF-8" %>

So far, I believe that JSP and ACTION are unlikely to be garbled.

4. Resource file garbled Solution
Resource files all know that they are an indispensable part of international support. If all the resource files are garbled, it will be okay? In fact, the resource file garbled code is a good solution, the reason is also because the use of the UTF-8 as JSP encoding, there is no corresponding change to the resource file encoding caused, so as long as the encoding of the resource file is corrected, the garbled problem will be solved. Of course, you must use the native2ascii command to convert Chinese characters correctly.

5. The JS content is garbled during JS calls.
In fact, JS garbled characters are related to file encoding. If JavaScript contains Chinese characters, the encoding stored in the JS file must be the same as the page encoding used to call this JS file. Otherwise, all your documents must be transmitted from the JSP page to JS to be displayed normally. It can be seen that the garbled code for calling JS is the easiest solution (it is also based on the previous hard work ).

6. AJAX solution for submitting garbled data and returning garbled data
With the popularity of AJAX, The Garbled text problem also began to plague many programmers who started to use it. Fortunately, I have studied JSP Garbled text before. After encountering AJAX, it has not brought me much trouble. Here I will share some of my experiences with you.

The problem of AJAX garbled characters is naturally related to encoding. In fact, many people think of setting file encoding like me, and set requet encoding when receiving data, when the returned data is encoded with response, everything is thought to be smooth, but this is all futile, and the nasty garbled code appears again in front of you. After you try N methods, including JS's own escape and unescape methods, you find garbled characters still appearing on the screen.

In fact, after trying these N methods, many people have not found that the solution is actually very simple, and the answer lies in the JSP garbled code we have previously processed. Let's take a look at the typical AJAX request code.

Xmlhttp. open ("post", url, async );
Xmlhttp. setRequestHeader ("Content-Type", "text/html ");
Xmlhttp. send (params );

According to the previous instructions, I don't know if you can see it now. I don't know whether it is affected by the online tutorials or other aspects. The setRequestHeader remains unchanged for years, and no one wants to change it. The problem lies exactly in this place. Recall the encoding settings of the content of a JSP page, which includes the following section:

ContentType = "text/html; charsets = UTF-8"

Now you know the problem, so we should change the second code to: xmlhttp. setRequestHeader ("Content-Type", "text/html; charset = UTF-8 ");

Finally, do not forget to set it when returning data:

Response. setContentType ("text/xml ");
Response. setCharacterEncoding ("UTF-8 ");

Isn't it easy?

To ask why, we can regard xmlhttp as a temporary page, which is dynamically generated by the browser, the main function is to obtain the requested data in the background (it can be considered as an advanced iframe ). Therefore, you must also set the encoding for common pages. Why do you set contentType and encoding for the returned data in servlet. As we all know, the final form of jsp is servlet, And the content set in the jsp header is actually to generate the following two sentences in the generated servlet: response. setContentType ("text/html ");
Response. setCharacterEncoding ("UTF-8 ");

PageEncoding demonstrates the encoding used for saving the content of the page with jvm (this is related to the generated CLASS ). Therefore, the response encoding in servlet is also taken for granted.

I wrote out the garbled Problem and Solution I encountered in the past year, hoping to help you.