1. The Java file is compiled to form a class
The encoding of the Java file here may be diverse, but the Java compiler will automatically correct these encodings according to the encoding format of the Java file. After reading, a class file is generated. The class file encoding here is Unicode encoding (specifically, UTF-16 encoding).
Therefore, define a string in Java code:
String s="Chinese characters";
No matter what encoding the java file uses before compilation, after compilation After becoming a class, they are all the same - represented by Unicode encoding.
2. Encoding in JVM
When the JVM loads the class file and reads it, it uses Unicode encoding to read the class file correctly, then the originally defined String s="Chinese characters ";The representation in memory is Unicode encoding.
When calling String.getBytes(), the cause of garbled code has actually been bought. Because this method uses the platform's default character set to obtain the byte array corresponding to the string. In the Chinese version of Windows When different systems and databases have been encoded multiple times, if the principles are not understood, it will easily lead to garbled code. Therefore, in a system, it is necessary to unify the encoding of strings. This unification is vaguely said to be external unification. For example, method string parameters, IO streams, in Chinese systems, you can use GBK, GB13080, UTF-8, UTF-16, etc., but you need to choose some larger character sets to ensure that any characters that may be used All can be displayed normally to avoid the problem of garbled characters. (Assuming that ASCII codes are used for all files) Then bidirectional conversion is impossible.
It should be noted that UTF-8 does not accommodate all Chinese character set encodings. Therefore, under special circumstances, garbled characters may appear when converting UTF-8 to GB18030. However, a group of idiots often do this. The Chinese system likes to use UTF-8 encoding without being able to explain why! The stupidest thing is that multiple people work on a system. Some people use GBK encoding for source code files, some use UTF-8, and others use GB18030. FK, they are all Chinese, and it is not an outsourcing project. Why use UTF-8? It’s crazy! It is OK to use GBK18030 for all source codes, so as to avoid unrecognized character encoding when ANT script is compiled.
Therefore, for the Chinese system, it is best to choose GBK or GB18030 encoding (in fact, GBK is a subset of GB18030) to avoid garbled characters to the maximum extent.
3. Encoding of strings in memoryStrings in memory are not limited to strings loaded directly from class code, there are also some Strings are read from text files, some are read from the database, and some may be constructed from byte arrays. However, they are basically not Unicode encoded. The reason is simple, storage optimization.
Therefore, various encoding issues need to be dealt with. Before processing, the encoding of the "source" must be clear, and then correctly read into the memory using the specified encoding method. If it is a parameter of a method, the encoding of the string parameter must actually be clear, because this parameter may be passed from another Japanese system. When the string encoding is clear, the string can be processed correctly as required to avoid garbled characters. When decoding and encoding a string, the following method should be called:
public class Test { public static void main(String[] args) { System.out.println("当前JRE：" + System.getProperty("java.version")); System.out.println("当前JVM的默认字符集：" + Charset.defaultCharset()); } }The above is the detailed content of Java character encoding example analysis. For more information, please follow other related articles on the PHP Chinese website!