$. Chinese garbled characters passed in by Ajax in Google browsers

Some operation personnel reported that a Chinese display name edited in the background had garbled characters on the foreground ~~

First lookCodeWhether the GET request is not transcoded:

 
$. Ajax ({type: 'post', URL: '/admin/updatedisplayname}', data: {displayname: displayname}, success: function (RES) {alert (1) ;}, error: function () {alert (2) ;}, datatype: 'json '})
 

No matter what you think of this Code, there is no problem. If the POST request is in the past, there should be no garbled code. I tested it myself and modified it back. No garbled code (Firefox)

Strange ~

Ask, the other party uses Google. check whether there are any special settings in the browser encoding. No, everything works.

Wondering, when I came back and tested it in Google, I was dizzy, and it turned out to be a re-occurrence and garbled. Haha, that's easy to handle ~

Check the request header information and find that there is a problem with the value when using the $. Ajax request.

Chrome: contenttype: 'application/X-WWW-form-urlencoded'

FF: contenttype: 'application/X-WWW-form-urlencoded; charset = UTF-8 ',

Is this the reason ~

$. Ajax ({type: 'post', URL: '/admin/updatedisplayname}', data: {displayname: displayname}, contenttype: 'application/X-WWW-form-urlencoded; charset = UTF-8 ', success: function (RES) {alert (1) ;}, error: function () {alert (2) ;}, datatype: 'json '})
 

In addition to the parameter test, there is no garbled code in Google and the problem is solved.

Check the jquery manual.

Contenttype String

(Default: "application/X-WWW-form-urlencoded") Content Encoding type when sending information to the server. The default value is applicable in most cases. If you explicitly pass a Content-Type to $. Ajax (), it will certainly be sent to the server (even if there is no data to be sent)

For Mao I do not input this value, Firefox will add charset = UTF-8?

Look at jquery source code:

Ajaxsettings: {URL: location. href, Global: True, type: "Get", contenttype: "application/X-WWW-form-urlencoded", processdata: True, async: True,/* Timeout: 0, data: NULL, Username: NULL, password: NULL, traditional: false, * // create the request object; microsoft failed to properly // implement the XMLHttpRequest in IE7 (can't request local files), // so we use the activexobject when it is available // This func Tion can be overriden by calling jquery. ajaxsetupxhr: window. XMLHttpRequest & (window. Location. protocol! = "File:" |! Window. activexobject )? Function () {return new window. XMLHttpRequest () ;}: function () {try {return new window. activexobject ("Microsoft. XMLHTTP ") ;}catch (e) {}}, accepts: {XML:" application/XML, text/XML ", HTML:" text/html ", script: "text/JavaScript, application/JavaScript", JSON: "application/JSON, text/JavaScript", text: "text/plain", _ default: "*/*"}},
 

It seems that the problem has been found. Notify the team members to carefully check whether the $. Ajax method of all projects has passed the Chinese parameters. If yes, add:

 
Contenttype: 'application/X-WWW-form-urlencoded; charset = UTF-8 ',
 

I found several hidden bugs, but I used $ directly like this. ajax is generally used only by the background system, and our background system is not compatible with Google, so it may not be tested at that time.

However, there is another problem. Some students did not add it, but the test was OK. Google was not garbled and various types were not calm ....

Check again ~

First, check the jquery version. Sure enough, this guy uses jquery1.7.2, and I use 1.4.2. Check the source code of 1.7.2:

Ajaxsettings: {URL: ajaxlocation, islocal: rlocalprotocol. test (ajaxlocparts [1]), Global: True, type: "Get", contenttype: "application/X-WWW-form-urlencoded; charset = UTF-8", processdata: True, async: True,/* Timeout: 0, data: NULL, datatype: NULL, Username: NULL, password: NULL, cache: NULL, traditional: false, headers :{}, */accepts: {XML: "application/XML, text/XML", HTML: "text/html", text: "text/plain", JSON: "application/JSON, text/JavaScript "," * ": alltypes}, contents: {XML:/XML/, HTML:/html/, JSON:/JSON/}, responsefields: {XML: "responsexml", text: "responsetext"}, // list of data converters // 1) Key format is "source_type destination_type" (a single space in-between) // 2) the catchall symbol "*" can be used for source_typeconverters: {// convert anything to text "* Text": window. string, // text to HTML (true = no transformation) "text html": True, // evaluate text as a JSON expression "text JSON": jquery. parsejson, // parse text as XML "text XML": jquery. parsexml}, // For options that shouldn't be deep extended: // you can add your own custom options here if // and when you create one that shouldn't be // deep extended (see ajaxextend) flatoptions: {context: True, URL: true }},

Dizzy, in 1.7.2 actually added charset = UTF-8,

Various ~~~~, Further Exploration ~ 1.7 source code does not exist either.

Okay, there is no such problem in 1.7.2.

Conclusion:

1. If you use a version earlier than 1.7.2, you must set the contenttype when using $. Ajax. Otherwise, Google will garbled.

2. It has something to do with browsers. Firefox can automatically add UTF-8, but Google won't. The jquery team also found this problem, so the problem was corrected in the latest version.

Test and generation environment:

1. In the Java environment, package GBK, encode GBK on the page, and configure UTF-8 for uriencoding in Tomcat, which may also be related to these server configurations.

Guess: Generally, the request data encoding for post form requests is based on the encoding format specified by Meta In the page. Our page is GBK, therefore, when Google does not specify the Ajax contenttype parameter, it uses the default page encoding method GBK encoding and then sends it to the server. The uriencoding in Tomcat is UTF-8, so the encoding on both sides is different and garbled. it is OK to explicitly specify it. However, it seems that AJAX is encoded in UTF-8 format. If it is not specified, it will not be a problem. It is not Google ....