Solve Ajax Chinese problems thoroughly

The Chinese issue is inseparable from web programmers. The Chinese issue of JSP pages, the Chinese issue of URL passing parameters, and the Chinese issue of request value ....... Now that AJAX is becoming more and more mature, its Chinese problems are also emerging.

In fact, the Chinese problem is the encoding problem, we know all the character sets, whether in English, operators, punctuation marks, the most basic encoding method is ISO-8859-1, chinese encoding method is currently the most commonly used is GBK, gb2312, UTF-8 three, these three are inherited from the ISO-8859-1, so as long as the grasp of the underlying the most basic encoding, whether Ajax or struts, the solutions to Chinese problems are in the same line.

Well, let's take a look at a complete Ajax process and analyze its Chinese Problems and Solutions step by step.

First, the page: the encoding method of the JSP page determines the display of Chinese characters on the page, which should be clear. Chinese characters on JSP pages are not garbled

In this way, you can specify the Chinese encoding of the page as a UTF-8 (the reason for UTF-8 is because the XML encoding method is UTF-8, and Ajax is closely linked with XML, JSP page and the Ajax request parameters after the submission, Servlet write the output stream to the client is a UTF-8, Ajax processing is quite necessary ).

<% @ Page contenttype = "text/html; charset = UTF-8" %>

 

Then there is the Chinese language passed during the Ajax request. We know that although the Ajax request is asynchronous, it is also an HTTP request, so it also has HTTP header, URL and other parameters, if we need to pass Chinese parameters when sending Ajax requests, the best way is to complete the encoding of Chinese data in the HTTP request on the client, otherwise the browser sends HTTP requests by default using ISO-8859-1 encoding. The Chinese data here includes two parts:

First, the URL parameters in the HTTP header, such

The method for configuring the URI for Tomcat is as follows (tomcat5.x and above must be set, otherwise it will adopt a non-ISO-8859-1 encoding method, so that even if the server then requests. setcharaterencoding () is useless. It must be garbled !) :

<A href = "test. jsp? Param1 = Chinese parameter 1 & param2 = Chinese parameter 2>

The solution to this Chinese encoding is best for the application server, for example, the most common

<Connector Port = "8080" maxthreads = "150" minsparethreads = "25" maxsparethreads = "75" enablelookups = "false" acceptcount = "100" DEBUG = "0" connectiontimeout =" 20000 "proxyport =" 80 "disableuploadtimeout =" true "uriencoding =" UTF-8 "/>

 

The second is the Chinese characters in the body of the HTTP request. This is the data in the form. The httprequest of Ajax has special settings:

Request. setRequestHeader ('content-type', 'application/X-WWW-form-urlencoded; charset = UTF-8 ');

 

So the HTTP body part of the Chinese has been encoded as a UTF-8 .,

Well, since the client browser to send Ajax request when the content of the request has been encoded with the UTF-8, then the data uploaded to the server is already encoded after the Chinese data, the server does not need to pass the request. setcharaterencodin () is used to set the encoding format. This is the biggest difference from struts. We usually see that struts solves the encoding problem through a filter, that is, all requests sent to the backend server are implemented through this filter, set the Request Encoding Method in this filter. In fact, the two methods are the same in different ways. Ajax is encoded on the client and does not need to be set when it is sent to the server. struts does not make any settings when it submit the client, that sent to the server is certainly the data of the ISO-8859-1, so you need to specify in the filter, so that the request to find the data in the Chinese, it will be encoded.

Then the server completes the business logic and returns the result to the client. The same problem arises. Do you still remember what we set on the JSP page at the beginning of this article? It specifies the UTF-8 encoding, so we now write the output stream to the JSP page, should it also be encoded and the Chinese encoding method of the page consistent? The answer is yes. The contenttype of response should be added when Ajax returns data:

Contenttype

 

! In this way to the client to write the data in the Chinese is also UTF-8 encoding, the client JS script to get the request. responsexml or responsetext, the data inside will not be garbled.

Response. setcontenttype ("text/XML; charset = UTF-8 ");

Response. setcontenttype ("text/XML; charset = UTF-8 ");

Response. setheader ("Pragma", "No-Cache"); // HTTP 1.0

Response. setdateheader ("expires", 0); // prevents caching at the Proxy Server

Printwriter out = response. getwriter ();

Out. Write (outxml );

Out. Flush ();

Out. Close ();

OK

So far, Ajax's Chinese problems have all been solved. From the original JSP page, Chinese is a problem of encoding. The reason for garbled characters is mostly at the wrong time, wrong location encoding operations, and encoding type for a while GBK, later gb2312, later UTF-8, of course, the data will be out of order. In fact, if you are familiar with the HTTP protocol and have a clear understanding of the encoding problem, there is no problem with Chinese as described above.