Solution to ajax page Garbled text and get post Garbled text
The various garbled codes on the ASP page were previously implemented, and the page was refreshed with garbled codes or links. Last night, I went to ask du Niang to find a solution, add <% @ CODEPAGE = "65001" LANGUAGE = "VBSCRIPT" %> <% Response. CODEPAGE = 65001%>, 65001 refers to the UTF-8 encoding format GB2312 is 936, because when you enter the UTF-8 page other programs do not declare Response. codePage is a Session. codePage is assigned immediately (65001 or 936 is assigned differently due to different versions), and the Response of the other page is displayed when you enter another page. codePage is immediately Session. codePage is assigned a value, so if the page gets @ CODEPAGE = 936, your page's Response. codePage is assigned as 65001, and garbled characters are generated. Therefore, you must write the code at the beginning of the page. Encoding.
Then last night and then encountered a problem is AJAX returned when the Chinese display garbled and the encoding of the two pages are the same UTF-8 for the hair will appear garbled check du Niang is said in AJAX processing page add <% Response. charset = "UTF-8" %> the result page does not show the content. I have studied the data encoding problem of the database tutorial, because the ACCESS data encoding is based on the encoding you write into the data when I write into the GB2312 is now using the UTF-8 format encoding decoding will certainly be garbled how to do it <% Response. charset = "GB2312" %> then AJAX Chinese returns normal. here, the Charset attribute is interpreted by W3C to append the character set name to the content-type header of the page's Response object.
Add <% Response. Charset = "GB2312" %>
Page output
<% Content-type: text/html; charset = GB2312 %>
I guess Charset changed the character set to GB2312, so it can accept GB2312 encoded data, so it won't be garbled.
Take a look at the get and post garbled ajax Solution
There are two types of data garbled characters in the program execution process. One is that the Chinese characters sent to the background program are garbled characters, because xmlHTTP follows the special webpage effect word processing mechanism, use UTF-8 encoding. However, if the background page uses GB2312 or other encoding types, the received data is garbled. There is also a garbled character when the data is received and then returned. This is also because the background page uses different encoding than Javascript encoding. The characters returned by the server script are encoded by the server by default, for example, GB2312. The garbled error occurs when the server sends back data. You only need to add a file header that defines the encoding on the page where the server sends back data.
When defining the file header information, you can use the following methods based on the script:
PHP: header ("Content-Type: text/html; charset = GB2312 ");
ASP: Response. Charset ("GB2312 ")
JSP: response. setHeader ("Charset", "GB2312 ");
(Other scripts can search for their related class libraries. Usually there are functions or methods for setting header information .)
After sending back the information, let's talk about the garbled sending information. In fact, none of the encoding, the Chinese characters we enter will be correctly sent to the server in UTF-8 format, but when the server receives not according to our expectation to decode, it uses the default character encoding method of the server, usually GB2312 to decode the information. The characters we see are naturally incorrect.
We all know that XMLHTTP has two data transmission methods: GET and POST. GET garbled code is easy to solve. You only need to add a defined encoding Header: setrequestheader ("Content-Type", "text/html; encoding = gb2312 "). In this way, the data sent by the GET method will be correctly understood by the server script as the GB2312 Method for decoding.
The hard part is that when the POST method is used to send data, the above method becomes invalid, because the Content-type Used for POST data is xmlObj. setrequestheader ("Content-Type", "application/x-www-form-urlencoded"); character encoding is not defined. I encountered a lot of difficulties in solving this problem, but now I have found two better solutions. First, encode Chinese characters before sending them to the server. That is, encodeURI () is used ().
Note that this method must be used twice. The first time is to process characters into URL encoding. The second encoding is to encode the encoded data again. This is because if the first encoding is sent, the server will automatically decode it. If so, we cannot control the desired decoding method. So encodeURL is required twice. The purpose is that the data we obtain on the server is a string after the encodeURL. Then we use the corresponding decoding function of the server script to restore the string. In this way, we get the correct string we want. The downside is that we have to multiply the volume of data sent out. You know, as the data volume increases, the chance of errors increases.
Another method is to use cookies to dump data, which does not increase data but requires browser permissions. Although it is easy to read and write cookies. However, I think this operation is not ideal. I can't say anything more without a test. In my opinion, there should be a third way to solve the Garbled text problem.
Solution to ajax post garbled characters in PHP!
Although not advanced or handsome, the problem was finally solved. The solution to the problem is officially because of the complete function library of PHP! Just an iconv () function solves the garbled problem!
On the client, no settings are required. You only need to get the normal value and Send it to the server using xmlHTTP, and then accept the value normally on the server. Use the iconv () function to re-encode the string after receiving the value!
$ R_Guest = strval (iconv ("UTF-8", "GB2312", $ _ POST ["R_Guest"]);
$ R_Content = strval (iconv ("UTF-8", "GB2312", $ _ POST ["R_Content"]);