Java coding, garbled problem

I. Common coding formats1.ASCII

Basic coding, English and Western European characters.

With a low of 7 bits of one byte, altogether 128.

0~13 is a control character such as line break, carriage return, delete, etc., 32~126 is the print character, keyboard input.

2.ios-8859-1

An extension of ASCII.

Represented by a byte, altogether 256.

3.gb2312

Chinese coded character set.

denoted by two bytes, a1~a9 is the symbol area, altogether 682, B0~f7 is the Chinese character area, altogether 6,763.

Coding needs to query the corresponding code table, the efficiency is slightly lower.

4.GBK

GB2312 extension, compatible with GB2312.

In two bytes, there are 23,940 code bits representing 21,003 kanji.

Coding needs to query the corresponding code table, the efficiency is slightly lower.

5.utf-16

UTF-16 specifically defines how Unicode characters are accessed on the computer.

Represents the conversion format for Unicode in two bytes.

A fixed-length display method that represents one character per two bytes, high conversion efficiency, memory and hard disk use this encoding (Java Memory storage format UTF-16).

Sequential encoding can not be used to verify the encoding of a single character, if damaged, the subsequent code value will be affected.

6.utf-8

UTF-8 specifically defines how Unicode characters are accessed on the computer.

A character is made up of 1-6 bytes, and Chinese characters are represented by three bytes.

The display method of the variable length, each coding area has the different loadline length.

A large portion of the characters in the network transmission can be shown with one byte, and all UTF-16 normalization is converted to two bytes, and only one byte is required for these characters UTF-8.

UTF-8 if a code value in the middle is damaged, the subsequent code value is not affected.

Compared to Utf-16,utf-8 has the advantage of small resources in transmission, more secure data, more suitable for network transmission, but UTF-16 coding rules are relatively simple, coding efficiency is higher, suitable for local memory and disk.

Second, common Java coding api1.i/o

New InputStreamReader (InputStream, "Utf-8"new outputstreamwriter (OutputStream, "Utf-8"); Charset Streamencoder

2. Memory operation

Conversion of characters to bytes:

String
String s = "Chinese characters"; byte [] B = s.getbytes ("UTF-8"new String (b, "UTF-8");

Charset
Charset Charset = Charset.forname ("UTF-8");
Bytebuffer Bytebuffer = Charset.encode (string);
Charbuffer Charbuffer = Charset.decode (Bytebuffer);

The soft conversion of char and Byte splits a 16bit char into two 8bit bytes to display, and the actual value is not converted.
Bytebuffer Heapbytebuffer = bytebuffer.allocate (1024);
Bytebuffer Bytebuffer = Heapbytebuffer.putchar (c);

Third, the Java web involved in the codec 1.URL codec

PathInfo Chinese Questions:

Configure Server.xml for Tomcat:

<uriencoding= "UTF-8"/>

QueryString Chinese Questions:

QueryString is passed through the header in HTTP to the background, his decoding character set by default is Iso-8859-1,

It can also be defined by CharSet in the contenttype of the header.

How to determine the back end of the ContentType character set in the configuration, need to be configured in Server.xml (this configuration is only valid for QueryString):

<usebodyencodingforuri= "true"/>

2.HTTP Header encoding and decoding

For other parameters in the header, such as Cookie,redirectpath.

Try not to pass non-ASCII characters, and if necessary, encode and re-pass with the following API before delivery:

Org.apache.catalina.util.URLEncoder

3.POST encoding and decoding of forms

The client obtains the argument to be garbled after the solution idea:

1. Change post to get to see if there is a problem on the browser side.

2. Backend Request.gecharacterencdoing Returns whether the result is an expected encoding.

// Use Request.setcharacterencoding (CharSet) before using Request.getparameter for the first time ;

4.HTTP body encoding and decoding

Mainly elaborated from backstage to the foreground codec:

// to encode the data returned to the foreground, the foreground will first decode Response.setcharacterencoding (CharSet) based on this value ;

<!---<http-equiv= "Content-type"  Content= "Text/html;charset=utf-8"/>

<!---url= "Jdbc:mysql://localhost:3306/db?useunicode=true& Characterencoding=utf-8 "

Four, JS coding problem 1. External introduction of JS file

<!---<src= "De/mo/demo.js"  CharSet= "GBK"></script>

URL encoding for 2.js

Encode and decode URLs according to UTF-8, except for some special characters "!" " # "$" "&" "" "" (")" "*" "+" "," "-" "." " /"":"";"" =""?"" @ "_" "~" "0-9" "A-Z" "A-Z"

encoding results with a "%" in front of each code value

encodeURI ("http://localhost:8080/examples/servlets/servlet/come to Quentin, grandson Inviter= Geralt");
decodeURI ("* * encoded content * *");

The URL is encoded and decoded according to UTF-8, which is more thorough than the encodeURI. The special characters excluded are "!" "" "" ("")""*""-""."" _ "" ~ "" 0-9 "" A-Z "" A-Z "

Encoding results with a "%" in front of each code value

It excludes fewer words transmitting encodeURI, which is commonly used to encode URLs as parameters, such as example if you do not encode & in the parameter URL affects the integrity of the entire URL

"Http://localhost/servlet?ref=" + encodeuricomponent ("http://localhost:8080/examples/servlets/servlet/come to Quentin, grandson?" inviter= Geralt &inviter= Yenai Law ");

decodeuricomponent ("* * encoded content * *");

3. Decoding at Backend reception

The back-end processing URL codec relies on the two classes of Java.net.URLEncoder and Java.net.URLDecoder.

The URL encoding of the back-end pair also has special characters that are excluded, as opposed to the encodeuricomponent of the front end.

Back-end direct access to the URL parameters will be automatically decoded
If the request.setcharacterencoding () is not set in advance, it is very easy to encode a different code and cause garbled
Request.getparameter ();

Another way is through the front-end JS URL encoding two times, the background regardless of what through the first decoding, can get the correct UTF-8 encoding, foreground code is as follows
encodeURIComponent (encodeuricomponent (URL));
The percent of the first encoded result (for example:%e2%a7) will be converted to%25 after the second encoding (for example:%25E2%25A7)
The background is automatically decoded when the Request.getparameter () is executed, regardless of the current container's encoding, and the correct UTF-8 encoding is obtained (for example:%E2%A7)

V. Other places to encode 1.xml

<?xml version= "1.0" encoding= "UTF-8"?>

2.Velocity

Services. Velocityservice.input.encoding=utf-8

3.JSP

<% @page contenttype= "Text/html;charset=utf-8"%>

Note: This article is a summary of the relevant contents of the book "Xilingpo in-depth analysis of Java Web Technology Insider"

Java coding, garbled problem