java中的file.encoding属性到底由什么决定？

最新推荐文章于 2025-03-10 00:15:00 发布

置顶 _古井心

最新推荐文章于 2025-03-10 00:15:00 发布

阅读量2.8w

点赞数 22

分类专栏： java基础文章标签： java file.encoding sun.jnu.encoding

本文链接：https://blog.csdn.net/u010234516/article/details/52842170

版权

java基础专栏收录该内容

10 篇文章

订阅专栏

首先先上一段代码：

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());
		// }
	}
}

这段代码会打印出file.encoding属性和sun.jnu.encoding属性的值，注释部分会依次打印所有的属性的值。

那么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);
	}
}

这里先将String转换成bytes，再利用bytes构造一个String，如果getBytes()和new String(bytes)都不带编码肯定不会乱码，因为都会采用默认编码，方法的说明如下：

运行结果如图：中文打印正常

修改getBytes()为getBytes("utf-8")，结果中文依然正常

再次修改为：getBytes("GBK")，结果中文显示乱码：

这样看来，似乎默认的编码就是UTF-8，为了进一步证明猜想，我们来跟踪一下源码：

public byte[] getBytes() {
        return StringCoding.encode(value, 0, value.length);
    }

继续跟进encode方法：

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;
        }
    }

这里的defaultcharset应该返回了一个Charset对象，继续跟进：

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属性，并通过该属性查找到了对应的Charset对象，如果找不到该属性所对应的Charset，就默认返回utf-8（所有Charset名字的参数均大小写等价）Charset。说明在值合理的情况下，file.encoding属性确实决定了所谓的默认编码。至于sun.jnu.encoding属性的用处，由于使用较少，容我先卖个关子，下一篇介绍^_^。

知道了作用，并且作用不小，那我们来看看到底是什么决定了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的默认编码：