1、java
因为JDK是国际版的,在对程序进行编译的时候,若是咱们没有用-encoding参数指定咱们的Java源程序的编码格式,则javac.exe首先得到咱们操做系统默认采用的编码格式,即:在编译.java文件时,若咱们不指定源程序文件的编码格式,JDK首先得到操做系统的file.encoding参数(它保存的就是操做系统默认的编码格式,若是是WIN2k,则它的值为GBK)。而后JDK就把咱们的Java源程序从file.encoding编码格式,转化为Java内部默认的Unicode编码格式放入内存中。而后,javac.exe把转换后的Unicode编码格式的文件进行编译,使之成.class类文件,此时的.class文件是Unicode编码的,它暂放在内存中。紧接着,JDK将此以Unicode编码的编译后的.class文件保存到咱们的操做系统中,造成咱们见到的.class文件。对咱们来讲,咱们最终得到的.class文件是内容以Unicode编码格式保存的类文件,它内部包含咱们源程序中的中文字符串,只不过此时它已经由file.encoding格式转化为Unicode格式了。当咱们不加设置就对程序进行编译时,至关于使用了参数:javac -encoding gbk XX.java,固然就会出现不兼容的状况。数据库
因为JDK是国际版的,在对程序进行编译的时候,若是咱们没有用-encoding参数指定咱们的Java源程序的编码格式,则javac.exe会首先得到咱们操做系统默认采用的编码格式,也即在编译Java程序时,若咱们不指定源程序文件的编码格式,JDK首先得到操做系统的file.encoding参数(它保存的就是操做系统默认的编码格式,若是是WIN2k,则它的值为GBK),而后JDK就把咱们的Java源程序从file.encoding编码格式,转化为Java内部默认的Unicode格式放入内存中。而后,javac.exe把转换后的Unicode格式的文件进行编译,使之成.class类文件,此时的.class文件是Unicode编码的,它暂放在内存中。紧接着,JDK将此以Unicode编码的编译后的.class 文件保存到咱们的操做系统中,造成咱们见到的.class文件。对咱们来讲,咱们最终得到的.class文件是内容以Unicode编码格式保存的类文件,它内部包含咱们源程序中的中文字符串,只不过此时它己经由file.encoding格式转化为Unicode格式了。当咱们不加设置就对程序进行编译时,至关于使用了参数:数组
javac -encoding gbk XX.java,固然就会出现不兼容的状况。优化
2、编码
Java开发中,经常会遇到乱码的问题,一旦遇到这种问题,经常就很扯蛋,每一个人都不肯意认可是本身的代码有问题。其实编码问题并无那么神秘,那么不可捉摸,搞清Java的编码本质过程就真相大白了。
spa
其实,编码问题存在两个方面:JVM以内和JVM以外。
操作系统
1
、Java文件编译后造成
class
命令行
这里Java文件的编码可能有多种多样,但Java编译器会自动将这些编码按照Java文件的编码格式正确读取后产生
class
文件,这里的
class
文件编码是Unicode编码(具体说是UTF-
16
编码)。
code
所以,在Java代码中定义一个字符串:
内存
String s=
"汉字"
;
无论在编译前Java文件使用何种编码,在编译成
class
后,他们都是同样的----Unicode编码表示。
2
、JVM中的编码
JVM加载
class
文件读取时候使用Unicode编码方式正确读取
class
文件,那么原来定义的String
s=
"汉字"
;在内存中的表现形式是Unicode编码。
当调用String.getBytes()的时候,其实已经为乱码买下了祸根。由于此方法使用平台默认的字符集来获取字符串对应的字节数组。在WindowsXP中文版中,使用的默认编码是GBK,不信运行下:
public class Test { public static void main(String[] args) { System.out.println("当前JRE:"System.getProperty("java.version")); System.out.println("当前JVM的默认字符集:"Charset.defaultCharset()); } }
当前JRE:
1.6
.0_16
当前JVM的默认字符集:GBK
当不一样的系统、数据库通过屡次编码后,若是对其中的原理不理解,就容易致使乱码。所以,在一个系统中,有必要对字符串的编码作一个统一,这个统一模糊点说,就是对外统一。好比方法字符串参数,IO流,在中文系统中,能够统一使用GBK、GB13080、UTF-
8
、UTF-
16
等等均可以,只是要选择有些更大字符集,以保证任何可能用到的字符均可以正常显示,避免乱码的问题。(假设对全部的文件都用ASCII码)那么就没法实现双向转换了。
要特别注意的是,UTF-
8
并不是能容纳了全部的中文字符集编码,所以,在特殊状况下,UTF-
8
转GB18030可能会出现乱码(文末有阐述)
,然而一群傻B经常在作中文系统喜欢用UTF-
8
编码而说不出个因此然出来!最傻B的是,一个系统多我的作,源代码文件有的人用GBK编码,有人用UTF-
8
,还有人用GB18030。FK,都是中国人,也不是外包项目,用什么UTF-
8
啊,神经!源代码通通都用GBK18030就OK了,省得ANT脚本编译时候提示不可认的字符编码。
所以,对于中文系统来讲,最好选择GBK或GB18030编码(其实GBK是GB18030的子集),以便最大限度地避免乱码现象。
3
、内存中字符串的编码
内存中的字符串不只仅局限于从
class
代码中直接加载而来的字符串,还有一些字符串是从文本文件中读取的,还有的是经过数据库读取的,还有多是从字节数组构建的,然而他们基本上都不是Unicode编码的,缘由很简单,存储优化。
所以就须要处理各类各样的编码问题,在处理以前,必须明确“源”的编码,而后用指定的编码方式正确读取到内存中。若是是一个方法的参数,实际 上必须明确该字符串参数的编码,由于这个参数多是另一个日文系统传递过来的。当明确了字符串编码时候,就能够按照要求正确处理字符串,以免乱码。
在对字符串进行解码编码的时候,应该调用下面的方法:
getBytes(String charsetName) String(byte[] bytes, String charsetName)
而不要使用那些不带字符集名称的方法签名,经过上面两个方法,能够对内存中的字符进行从新编码。
UTF-
8
并不是能容纳了全部的中文字符集编码
在Windows下用editPlus编写一段Java代码,里面含有中文的文档注释。结果在编译时出现了“编码GBK的不可映射字符”。若此时保存的时候用的是UTF-8编码,在cmd命令行编译的时候写
javac
-encoding UTF8 XXX.java,可是编译仍然会报错,只是关于字符
的报错减小了,说明
。UTF-
8
并不是容纳了全部的中文字符集编码