Java solution and experience in Chinese garbled problem (2)

Solve | The problem | chinese | Garbled five, we want to have a knowledge of Java compiler:
Javac? encoding

We often do not use encoding this parameter. In fact, encoding this parameter is very important for cross-platform operation. If encoding is not specified, it is gb2312 on the default ENCODING,GB platform on the system, iso8859_1 on the English platform. The Java compiler actually calls the Sun.tools.Javac.main class and compiles the file, which has a encoding variable in the middle of the compile function, and the-encoding parameter is actually passed directly to the encoding variable. The compiler reads the Java file based on this variable and then compiles the Utf-8 form into a class file. Example code:

String str = "You";
FileWriter writer = new FileWriter ("Text.txt");
Write.write (str);
Writer.close ();

If you compile with gb2312, you will find E4 BD A0 fields;
If compiled with 8859_1, the 00c4 00e3 binary:
0000,0000, 1100,0100, 0000,0000, 1110,0011
Because each character is greater than 7 bits, it is encoded with 11 bits:
1100,0001,1000,0100,1100,0011,1010,0011
c1--84--c3--A3
You'll find C1 C3 A3.

But we tend to ignore this argument, so there's always a cross-platform problem:

The sample code is compiled on the Chinese platform to generate Zhclass

Sample code compiled on English platform, output enclass

(1) Zhclass in the Chinese platform to execute OK, but not on the English platform

(2) Enclass in the English platform to execute OK, but not on the Chinese platform

The reason is:

(1) in the Chinese platform after compiling, in fact, str in the running state of char[] is 0x4f60, run on the Chinese platform, filewriter The default code is gb2312, So chartobyteconverter automatically converts the str into a byte input to the FileOutputStream by invoking the converter of the gb2312, so 0xc4,0xe3 puts it in the file. But if it is in the English platform, the default value of Chartobyteconverter is 8859_1, FileWriter will automatically invoke 8859_1 to convert str, but he cannot explain, so he will output "?"

(2) in the English platform after compiling, in fact, str in the running state of char[] is 0x00c4 0x00e3, run on the Chinese platform, Chinese can not recognize, so will appear?? On the English platform, 0x00c4-->0xc4,0x00e3->0xe3, so 0xc4,0xe3 was put into the file.

Vi. Other reasons:

<%@ page contenttype= "text/html; CHARSET=GBK "%>

Set the browser's display code, if the response data is UTF8 encoding, the display will be garbled, but garbled and the reason is not the same.

Where the code occurs:

1. From database to Java program byte?? 〉char

2. From Java program to database char?? 〉byte

3. From file to Java program byte?? 〉char

4. From Java program to file char?? 〉byte

5. Display char from Java program to page?? 〉byte

6. Submit data from page form to Java program byte?? 〉char

7. From stream to Java program byte?? 〉char

8. From Java program to stream char?? 〉byte

You can use the method of configuring filters to resolve Chinese garbled:


<web-app>
<filter>
<filter-name>RequestFilter</filter-name>
<filter-class>net.golden.uirs.util.RequestFilter</filter-class>
<init-param>
<param-name>charset</param-name>
<param-value>gb2312</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>RequestFilter</filter-name>
<url-pattern>*. Jsp</url-pattern>
</filter-mapping>
</web-app>


public void Dofilter (ServletRequest req, servletresponse Res,
Filterchain Fchain) throws IOException, Servletexception {
HttpServletRequest request = (httpservletrequest) req;
HttpServletResponse response = (httpservletresponse) res;
HttpSession session = Request.getsession ();
String userId = (string) session.getattribute ("UserId");
Req.setcharacterencoding (This.filterConfig.getInitParameter ("CharSet"));
Set up a character set?
Actually set the byte?? 〉char's Encoding
try {
if (userId = null | | userid.equals ("")) {
if (!request.getrequesturl (). ToString (). Matches (
". */uirs/logon/logon (Controller) {0,1}\\x2ejsp$")) {
Session.invalidate ();
Response.sendredirect (Request.getcontextpath () +
"/uirs/logon/logon. Jsp ");
}
}
else {
See if you have access to the information escalation system
if (!net.golden.uirs.util.uirschecker.check (userId, "Information escalation system"),
Net.golden.uirs.util.UirsChecker.ACTION_DO)) {
if (!request.getrequesturl (). ToString (). Matches (
". */uirs/logon/logon (Controller) {0,1}\\x2ejsp$")) {
Response.sendredirect (Request.getcontextpath () +
"/uirs/logon/logoncontroller.jsp");
}
}
}
}
catch (Exception ex) {
Response.sendredirect (Request.getcontextpath () +
"/uirs/logon/logon. Jsp ");
}
Fchain.dofilter (req, res);
}