java编译编码问题

最近由一个编码问题。让我对另一个编码问题产生了疑惑。
即我们在写java源文件的时候一般使用的是utf-8编码,但是tomcat控制台(直接在bin里面启动的那个黑窗口)编码是gbk.为什么tomcat控制没有乱码问题？

最开始我想的是既然我的java源文件是按照utf-8编码,那么最后必须按照utf-8解码才不会有问题啊。为什么tomcat用gbk解码没有乱码问题？

然后查了下javac编译过程：
   当javac编译的时候会根据-Dfile.encoding参数来进行编译,-Dfile.encoding,一般为系统默认字符,windows下为gbk。当我们在ecplise下编写文件的时候,一般我们会设置编码为utf-8,所以编译的时候会以utf-8编译。

   重点来了：java编译采用的编码是unicode编码,所以这里面有一个转码的过程。java源文件的编码转码为unicode。这里我做了一个实验：
  

    public static void main(String[] args) {
	System.out.println((int)'我');
}

    分别修改java源文件的编码为gbk,和utf-8运行上面的代码会发现打印出来的unicode编码都是25105。可见java都是使用unicode编码来对源文件的编码。相当于unicode是一座桥梁。

    然后就是打印输出到控制台。
    当我们执行下面这段代码的时候到底是什么意思?
  
   

     String a = "您好";
	byte[] bytes = a.getBytes("utf-8");

     这句代码的意思是将unicode编码转化为utf-8编码。然后交由控制台去显示。
     
     现在回到最开始的问题：为什么tomcat控制台没有乱码问题？

因为1、在编译源文件的时候,java会根据根据源文件的编码来用unicode编码。放在内存中。不管gbk还是utf-8.都会查找码表生成统一的unicode编码。
2、在控制台输出的时候,java会根据当前-Dfile.encoding参数进行转化,在windows上该编码为gbk,所以java会将unicode编码转化为gbk,然后tomcat控制台用的gbk解码。所以没有乱码问题。

换言之：对java来说,我们不用考虑那么多,只要保证调用String.getBytes("编码")这句代码使用的编码和最终用来解码的编码一致即可。