The coding problem of Java in JS

In the current Web application, JS operation of the page elements more and more, especially when the asynchronous request through JS encountered coding problems often occur. The following is a description of the coding problem in JS several cases.

1. External introduction of JS file

In a separate JS file contains string input cases, such as:

      

If you introduce a script.js script, the script has the following code:
     document.write ("This is a Chinese language");     document.getElementById (' TestID '). InnerHTML = ' This is a Chinese ';

At this time if the script is not set CharSet, the browser will be the current and the page's default character set parsing the JS file, if the external JS file encoding format and the current page encoding format, then you can not set this charset. However, if the script.js file is inconsistent with the encoding format of the current page, such as Script.js is UTF-8 encoded and the page is GBK encoded, the Chinese input in the above code will become garbled.

URL encoding for 2.JS
The URL of the asynchronous call via JS default encoding is also affected by the browser, such as using the original Ajax Http_request.open (' GET ', url,true) call, URL encoding under IE is the operating system's default encoding, In Firefox, it is UTF-8 encoded. In addition, different JS frames may not be the same for URL encoding processing. So, how to deal with JS URL coding problem?
In fact, in JS processing URL encoding function has three, as long as the master of these three functions, basically can correctly handle JS URL garbled problem.

1.escape ()
This function is to place ASCII letters, numbers, punctuation marks (* +-). Other than/@ _) is converted to Unicode encoded value, and "%u" is added before the encoded value, as shown in.

By converting special characters to Unicode encoded values, it is possible to avoid the problem of information loss due to incompatible encoding character sets, and to avoid garbled problems by decoding parameters on the service side.
Note that escape () and Unecape () have been removed from the ECMAScript v3 standard, and URL encodings can be replaced with encodeURI () and encodeURIComponent.

2.encodeURI ()
Compared to escape (), encodeURI () is the real JS used to encode the URL function, it can be the entire URL of the characters (except some special characters, such as "!" "#" "$" "&" "" "(" ")" "*" "+" "," "-" "." "/" ":" ";" "=" "?" "@" "_" "~" "0-9" "A-Z" "A-Z") is UTF-8 encoded, preceded by a "%" in each code value, as shown in.


Decode through the decodeURI function as shown in.


3.encodeURICompoent ()
encodeURIComponent () This function is more thorough than the encodeURI () code, except for "!" "," "(" ")" "*" "-" "." "_" "~" "0-9" "A-Z" "A-Z" These characters do not encode, all other characters are encoded. This function is typically used to place a URL as a parameter in another URL, as shown in.


It can put HTTP://localhost/servlet/Junshan? a=c&a=b as one parameter in another URL, if not encodeuricomponent () encoding, the following URL in the "&" will affect the integrity of the previous URL. Encode by decodeURIComponent () as shown in.


4.java and JS decoding problems
The previous three functions are JS to deal with, if JS is encoded, encoded characters to the server after the Java to decode, then how to decode Java?
We know that there are two classes in the Java-side processing URL codec, namely Java.net.URLEncoder and Java.net.URLDecoder. These two classes can decode all "%" plus UTF-8 code values with UTF-8 to get the original characters. View the source code of Urlencoder you can find that Urlencoder protected special characters less than the special characters protected in JS. Java side of the Urlencoder and Urldecoder and front-end JS corresponds to encodeURIComponent and decoderuricomponent. Note that the front end with encodeURIComponent encoding, to the service side with Urldecoder decoding may be garbled, this must be two character encoding inconsistency caused. JS encoding default is UTF-8 encoding, and the service side Chinese decoding is generally GBK or GB2312, so with encodeuricomponent code is UTF-8, and Java with GBK to decode obviously not. The solution is to use encodeuricomponent two times to encode, such as encodeURIComponent (encodeURIComponent (str)). In this way, the Java side through Request.getparamter () decoding with GBK is UTF-8 encoded string, if the Java side need to use this string, then use UTF-8 decoding once, if the result is directly through the JS output to the front end, Then this UTF-8 string can be displayed directly on the front side.

The coding problem of Java in JS