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