首先先上一段代码：
public class PropertiesTest {
public static void main(String[] args) {
System.out.println("file.encoding:"+System.getProperty("file.encoding"));
System.out.println("sun.jnu.encoding:"+System.getProperty("sun.jnu.encoding"));
// Properties pro = System.getProperties();
// Set<Entry<Object,Object>> entrySet = pro.entrySet();
// for(Entry<Object,Object> entry :entrySet){
// System.out.println(entry.getKey()+":"+entry.getValue());
// }
}
}那么java中的file.encoding属性和sun.jnu.encoding属性到底是什么？从哪里来？干什么用？网上查了查，其中大多语焉不详，不清不楚，于是决定自己动手，来一探究竟。
咱们首先来看这两个属性干什么用。毕竟先知道它们有什么用才有必要关心它们从哪里来。
来看看我在eclipse中运行上面代码的结果：
再来看一段代码：
import java.io.UnsupportedEncodingException;
public class PropertiesTest {
public static void main(String[] args) throws UnsupportedEncodingException {
System.out.println("file.encoding:" + System.getProperty("file.encoding"));
System.out.println("sun.jnu.encoding:" + System.getProperty("sun.jnu.encoding"));
encodingTest();
}
private static void encodingTest() throws UnsupportedEncodingException {
String s = "我们是中国人";
//如果使用不带参数的getBytes()肯定不会乱码的
byte[] bytes = s.getBytes("utf-8");
String s2 = new String(bytes);
System.out.println(s2);
}
}运行结果如图：中文打印正常
修改getBytes()为getBytes("utf-8")，结果中文依然正常
再次修改为：getBytes("GBK")，结果中文显示乱码：
这样看来，似乎默认的编码就是UTF-8，为了进一步证明猜想，我们来跟踪一下源码：
public byte[] getBytes() {
return StringCoding.encode(value, 0, value.length);
}static byte[] encode(char[] ca, int off, int len) {
String csn = Charset.defaultCharset().name();
try {
// use charset name encode() variant which provides caching.
return encode(csn, ca, off, len);
} catch (UnsupportedEncodingException x) {
warnUnsupportedCharset(csn);
}
try {
return encode("ISO-8859-1", ca, off, len);
} catch (UnsupportedEncodingException x) {
// If this code is hit during VM initialization, MessageUtils is
// the only way we will be able to get any kind of error message.
MessageUtils.err("ISO-8859-1 charset not available: "
+ x.toString());
// If we can not find ISO-8859-1 (a required encoding) then things
// are seriously wrong with the installation.
System.exit(1);
return null;
}
}public static Charset defaultCharset() {
if (defaultCharset == null) {
synchronized (Charset.class) {
String csn = AccessController.doPrivileged(
new GetPropertyAction("file.encoding"));
Charset cs = lookup(csn);
if (cs != null)
defaultCharset = cs;
else
defaultCharset = forName("UTF-8");
}
}
return defaultCharset;
}知道了作用，并且作用不小，那我们来看看到底是什么决定了file.encoding属性。
（PS：通常情况下为了保证程序run everywhere并且保持运行结果一致，不建议在程序中使用默认编码，应该直接指定编码）。
网上很多人给出的答案是：main方法所在类文件的编码决定了file.encoding属性。
我们来验证一下：
选中Explorer区域的类文件或将光标置于类文件编辑页，alt+enter打开类文件的属性页，可以看到我的设置
确实是utf-8，所以之前我的file.encoding属性就是utf-8了，现在修改该属性，
修改完成后，毫无疑问，中文都乱码了，运行程序，看看运行结果：
果然，file.encoding属性变成“ISO-8859-1”了。
再修改设置，改成US-ASCII，执行后果然file.encoding属性的值就变成了”US-ASCII“。
那么结论就是：file.encoding的属性值就是main方法所在类文件的编码。网友们果然机智。
但是，这样就可以下结论了吗？
我们现在是通过eclipse执行，就像隔靴搔痒，总感觉差点意思。要真正李菊福，还是要到控制台去。
将文件改回utf-8编码，消除文件中的中文乱码，getBytes和new String(bytes)依然使用不带编码的默认编码形式，接着我们直接在控制台编译并执行代码：
奇怪的现象出现了，和第一次在eclipse中执行的是一样的代码，但是运行结果居然变了，file.encoding的值变成了”GBK“，可是main方法所在类的编码明明是“UTF-8”。还有中文乱码了。这都是什么情况？？
乱码一会儿再说，先看file.encoding的变化，file.encoding变成”GBK“了，而文件的编码是utf-8才对，这样看来，之前所谓的结论似乎并不靠谱。
我们继续尝试在运行时直接指定file.encoding的属性，加上运行时参数”-Dfile.encoding=utf-8“:
这次file.encoding的值变了，变成了utf-8，说明file.encoding确实可以被设置，我们在设置一个不存在编码名试试看：
好吧，这都行，并且乱码始终没有变化。到这里我们可以看出：file.encoding可以设置为任意值。并且这次乱码问题不是出在file.encoding属性上。
到这里，我们就可以猜测，在eclipse中，之所以file.encoding属性和main方法所在类的编码一致，是因为在启动java虚拟机时,eclipse自动将文件属性中的编码设置为运行时参数。
我们知道一个文件是以二进制形式存储在硬盘中的，我们先以utf-8编码存储了java文件，然后手动javac，因为我们并没有指定编码，这时系统是不知道用什么编码来解析文件的，所以只能采用系统默认编码（这个是windows系统的默认编码，和之前提到的JVM默认编码不是一回事），我们查看windows的默认编码：
这里936表示默认编码为GBK。
那么显然问题就出在这里，文件以utf-8编码保存，如果以GBk解析，不乱码才怪呢。于是增加编译参数”-encoding utf-8“，重新编译运行：
可以看到，运行时file.encoding值依然为GBK，但是不乱码了，说明乱码确实是编译过程中引入的，运行过程没有问题。
我们可以通过以下方式再次验证，回到eclipse，我们试着修改一下代码，并重新运行：
可以看到此时的乱码和上面的一样。证明”鎴戜滑鏄腑鍥戒汉“确实是由于”我们是中国人“以utf-8格式保存，以GBK读取所致。
只不过在之前这个错误发生在编译过程中，编译完成后字符串就已经变成”鎴戜滑鏄腑鍥戒汉“。运行过程中没有问题。
而这一次，eclipse的编译没问题。不过在程序中将”我们是中国人“先以utf-8转成字节，再以GBk转换成字符串，同样产生了乱码。
由此，我们可以猜测，eclipse在编译和运行的过程中都会默认地帮我们添加上相应的编码参数，这个参数和main方法所在类的编码一致。
