java编译编码
下载JDK
首先我们需要下载java开发工具包JDK
下载后JDK的安装根据提示进行，还有安装JDK的时候也会安装JRE，一并安装就可以了。
安装JDK，安装过程中可以自定义安装目录等信息，例如我们选择安装目录为 C:\Program Files (x86)\Java\jdk1.8.0_91。
配置环境变量
1.安装完成后，右击"我的电脑"，点击"属性"，选择"高级系统设置"；
2.选择"高级"选项卡，点击"环境变量"；
在"系统变量"中设置3项属性，JAVA_HOME,PATH,CLASSPATH(大小写无所谓),若已存在则点击"编辑"，不存在则点击"新建"。
变量设置参数如下：
变量名：JAVA_HOME
变量值：C:\Program Files (x86)\Java\jdk1.8.0_91 // 要根据自己的实际路径配置
变量名：CLASSPATH
变量值：.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar; //记得前面有个"."
变量名：Path
变量值：%JAVA_HOME%\bin;%JAVA_HOME%\jre\bin;
JAVA_HOME 设置
这是 Java 的环境配置，配置完成后，你可以启动 Eclipse 来编写代码，它会自动完成java环境的配置。
注意：如果使用1.5以上版本的JDK，不用设置CLASSPATH环境变量，也可以正常编译和运行Java程序。
测试JDK是否安装成功
1、"开始"->"运行"，键入"cmd"；
2、键入命令: java -version、java、javac 几个命令，出现以下信息，说明环境变量配置成功；
2. 各个JAVA编码的区别
Java的class文件采用utf8的编码方式，JVM运行时采用utf16。
Java的字符串是unicode编码的。
总之，Java采用了unicode字符集，使之易于国际化。
java对不同编码的处理：一个字节存8位，每位都有两中可能(0,1)共可以组合成表示2的8次方 256种可能，0~127存储空格、标点符号、数字、大小写字母，127~255存储其他国家语言的一些特殊字符还加入了很多画表格时需要用下到的横线、竖线、交叉等形状，一直把序号编到了最后一个状态255。
Java是一种可以撰写跨平台应用程序的面向对象的程序设计语言。Java技术具有卓越的通用性、高效性、平台移植性和安全性，广泛应用于PC、数据中心、游戏控制台、科学超级计算机、移动电话和互联网，同时拥有全球最大的开发者专业社群。
Java 编程语言的风格十分接近C、C++语言。Java是一个纯的面向对象的程序设计语言，它继承了 C++ 语言面向对象技术的核心，Java舍弃了C ++语言中容易引起错误的指针（以引用取代）、运算符重载（operator overloading）、多重继承（以接口取代）等特性，增加了垃圾回收器功能用于回收不再被引用的对象所占据的内存空间，使得程序员不用再为内存管理而担忧。在 Java SE 1.5 版本中，Java 又引入了泛型编程（Generic Programming）、类型安全的枚举、不定长参数和自动装/拆箱等语言特性。
Java 不同于一般的编译执行计算机语言和解释执行计算机语言。它首先将源代码编译成二进制字节码(bytecode)，然后依赖各种不同平台上的虚拟机来解释执行字节码，从而实现了“一次编译、到处执行”的跨平台特性。不过，每次的编译执行需要消耗一定的时间，这同时也在一定程度上降低了 Java 程序的运行效率。但在J2SE1.4.2 发布后，Java 的执行速度有了大幅提升。
3. 对utf-8编码下的java文件如何编译
其实我也遇到你说的问题，但是很遗憾，除了借助Notepad++打开，然后在菜单“格式”中选择“以UTF-8 无BOM格式编码”，然后保存，这时候就可以指定编码了，更干脆的做法是直接在eclipse里面编辑，编辑之前，先设置工作空间为UTF-8，这样，后续创建的文件就会以UTF-8编码编译。
4. java中编码与解码分别指什么
java中编码：URLEncoder.encode(strUri,"utf-8");
java中解码码：URLDecoder.decode(strUri,"utf-8");
5. java编译出错
由于JDK是国际版的，在编译的时候，如果我们没有用-encoding参数指定我们的JAVA源程序的编码格式，则javac.exe首先获得我们操作系统默认采用的编码格式。
在编译java程序时，若我们不指定源程序文件的编码格式
JDK首先获得操作系统的file.encoding参数(它保存的就是操作系统默认的编码格式，如WIN2k，它的值为GBK)
然后JDK就把我们的java源程序从file.encoding编码格式转化为JAVA内部默认的UNICODE格式放入内存中。
然后，javac把转换后的unicode格式的文件进行编译成.class类文件，此时.class文件是UNICODE编码的，它暂放在内存中
对我们来说，我们最终获得的.class文件是内容以UNICODE编码格式保存的类文件，它内部包含我们源程序中的中文字符串，只不过此时它己经由file.encoding格式转化为UNICODE格式了。当我们不加设置就编译时，相当于使用了参数：javac -encoding gbk xx.java，当然就会出现不兼容的情况。
解决方法
1.使用-encoding 指定字符集
javac -encoding utf-8 xx.java
2.把源文件编码修改成ASCII
6. JAVA字符串编码问题！
这种编码问题真是很tricky的问题。说它tricky是因为这至少涉及到以下4种编码选取的排列组合(有时甚至更多)，更有时乃至会发生错进错出，负负得正，中间过程错了但反而到不是乱码的情况。
(1)源代码的编码
(2)编译时告诉java编译器的源代码编码
(3)运行时jvm参数file.encoding
(4)输出终端对输出字节流的解码所采用的码组
在这简单情况下(1)和(2)一致，(3)和(4)一致就不会因为编解码映射错误(当然字符向终端字体映射的错误是另一回事，如字体缺失之类)。而(1)(2)和(3)(4)不必一致，这样就使得不必强求开发编译环境和运行应用环境的编码必须一致。
源代码的录入与编译若在在一个平台上时，大多数情况没有问题(反而用聪明的Idea IDE设置错误时会乱套，越是简陋的开发环境越不太会错)。但是如果你在中文GBK编码平台上的源代码在别人的unicode编码平台上编译，就有问题了。所以和别人，特别是和不同母语的人合作编程时，建议要么约定一律用unicode作为源文件编码；要么只用ASCII字符，反正其他编码一般都和ASCII兼容的，对于非ASCII字符，用Java的/uxxxx表示机制，比如"中国"就表示为"\u4e2d\u56fd"。4e2d和56fd分别是中国二字的unicode十六进制编码。
但我认为楼主在这里其实主要关心的是运行时的编码一致问题，即(3)和(4)。所以言归正传，让我们来检查它们是否一致。
由于正如上述，iso8859-1编码集其实是被其他所有公认的编码集所兼容的，也就是说它是所有公认编码集的公共子集。所以以iso8859-1为基础可以外延到任何一个公认编码集。事实上大多数情况也是这样做的。比如java System property里设定了encoding为iso8859-1，事实上不仅仅是一个Latin字母的映射，在非Latin区域按JVM宿主操作系统的编码扩展。即选iso8859-1其实是选择了宿主操作系统的默认编码。
假设楼主的操作系统编码是GBK,那么file.encoding=iso8859-1相当于选择了file.encoding=GBK。那么System.out.println(...)这个核心类方法会将china字符转换为file.encoding指定的编码(GBK)字节由out流输出给最终out所绑定的终端。比如console一般采用系统默认编码也是GBK的话，那就和file.encoding一致，能正常解码，不会乱码。
至于System.out.write()直接写字节流。由于该字节流是由china.getBytes()得到的，在不指定编码的时候使用file.encoding指定的默认值的(即GBK)，因此Str->Byte的编码方法GBK和console采用的解码方法GBK又是一致的，所以也不是乱码。
但是这时候用toHexString打印出的两个字节串是不一样的。先直接把china逐字强行转换为int的情况，不涉及输出编码，总是unicode的。(JVM规范规定class里字串必须unicode编码)只要上述(1) (2)匹配，java编译器会自动从各种编码的源文件正确转成class文件里统一unicode编码的字串。相反，作为一个题外话提一下，当(1)(2)不匹配时会在特定的一种配合(1)(2)的(3)(4)也不匹配的情况下会负负得正输出正常，但这是绝对错误的做法，因为任何要求(1)(2)和(3)(4)有匹配关系的要求都是在应用中可能无法满足的。java编译器对这种情况也会报告warning，但不fail。
综上，一旦file.encoding设成宿主操作系统默认而系统consle也采用操作系统默认编解码的话，(3)(4)总是一致的，无论系统选择的是GBK还是utf-8等等。
那么如果file.encoding不选系统默认呢？比如utf-8。那就很可能出现乱码了。但是，慢着，试验的结果还是没有乱码。那是因为file.encoding是静态的JVM系统参数，在程序里像楼主那样设定是不起作用的(我不知道有没有办法发一个什么通知让这种程序改变生效的)。必须作为JVM参数直接传给java程序让它构造虚拟机的时候就得到这个参数，否则JVM会去拿宿主系统的默认值，就相当于又回到设file.encoding=iso8859-1了。
java -Dfile.encoding=utf-8 A
这下终于乱码了，而且两个都乱了。打印出的字节串一个还是unicode，另一个从GBK变到utf-8了。
如果你发现试验的现象和我上面说的正好相反，请注意检查console的编码设置，我们上面假设它也采用了宿主系统默认编码，但有些console很高级的嘞，可以设置成不通编码的(其实几乎所有的都可以)。那么分析的方法和上面一样，结果可能正好相反。
7. java编码理解
<%@ page contentType= text/ charset=utf pageEncoding= GBK %>
jsp页面（pageEncoding）——根据pageEncoding的设定读取jsp——>翻译成统一的UTF JAVA源码（即 java）——由JAVAC的JAVA源码至java byteCode的编译——>
编译成UTF encoding的二进制码（即 class）——Tomcat（或其的application container）载入和执行阶段二的来的JAVA二进制码——>输出contentType编码给浏览器
页面输入的参数用pageEncoding来编码
页面的默认编码是什么？
ntentType的默认编码是什么？
编码和解码过程各种文件时什么编码
response setContentType（ text/ charset=gb ） 是在页面显示时设置的字符格式request setCharacterEncoding（ gb ） 是servlet接受请求后对请求中的字符进行设置字符格式 因为默认通过网络传输的内容都被进行了iso 编码 如果想在后处理的时候不让中文成乱码 那就得对得到的内容进行gb 编码
JSP pageEncoding和contentType属性
JSP要经过两次的 编码 第一阶段会用pageEncoding 第二阶段会用utf 至utf 第三阶段就是由Tomcat出来的网页 用的是contentType
关于JSP页面中的pageEncoding和contentType两种属性的区别
pageEncoding是jsp文件本身的编码
contentType的charset是指服务器发送给客户端时的内容编码
JSP要经过两次的 编码 第一阶段会用pageEncoding 第二阶段会用utf 至utf 第三阶段就是由Tomcat出来的网页 用的是contentType
第一阶段是jsp编译成 java 它会根据pageEncoding的设定读取jsp 结果是由指定的编码方案翻译成统一的UTF JAVA源码（即 java） 如果pageEncoding设定错了 或没有设定 出来的就是中文乱码
第二阶段是由JAVAC的JAVA源码至java byteCode的编译 不论JSP编写时候用的是什么编码方案 经过这个阶段的敏埋结果全部是UTF 的encoding的java源码
JAVAC用UTF 的encoding读取java源码 编译成UTF encoding的二进制码（即 class） 这是JVM对常数字串在二进制码（java encoding）内表达的规范
第三阶段是Tomcat（或其的application container）载入和执行阶段二的来的JAVA二进制码 输出的结果 也就是在客户端见到的 这时隐藏在阶段一和阶段二的参数contentType就发挥了功效
contentType的设定
pageEncoding 和contentType的预设都是 ISO 而随便设定了其中一个 另一个就跟着一样了（TOMCAT 是如此） 但这不是绝对的 这要看各自JSPC的处理方式 而pageEncoding不等于contentType 更有利亚洲区的文字 CJKV系JSP网页的开发和展示 （例pageEncoding=GB 不等于 contentType=utf ）
jsp文件不像 java java在被编译器读入的时候默认采用的是操作系统所设定的locale所对应的编码 一般我们不管是在段侍记事本还是在ue中写代码 如果没有经过特别转码的话 写出来的都是本地编码格式的内容 所以编译器采用的方法刚好可以让虚拟机得到正确的资料
但是jsp文件不是这样 它没有这个默认转码过程 但是指定了pageEncoding就可以实现正确转码了
举个例子
<%@ page contentType= text/ charset=utf %>大都会打印出乱码 因为我输桥燃蚂入的 你好吗 是gbk的 但是服务器是否正确抓到 你好吗 不得而知
但是如果更改为
lishixin/Article/program/Java/hx/201311/26477