編碼java
Ⅰ java使用unicode為默認編碼是什麼意思
java初學者都會接觸到一個概念，既java的默認編碼是uincode，但書上也就出現這句話而已，究竟是什麼意思就沒再說。其實對於一個程序員來說，一個平台的編碼方式是不用了解的，因為這是他內部處理字元的方式，和我們頂層設計程序是沒有多大關系（如果真要說有關系的話，一個就是你對這個平台的熟悉程度，另一個就只能是你要處理的字元奇葩到要考慮編譯器有沒有包括這個字元）。但這並不是指我們在編程的時候完全不用考慮編碼問題，恰恰相反，編碼問題是跨系統交流的基本。
那java哪裡會用到編碼問題呢？最常見的是流，下面有兩個例子。1.在linux下用java創建了一個文件（這里默認代碼里沒有指定編碼），裡麵包括英文和中文，然後在windows下同樣用java讀取這個文件，並輸出，結果中文出現了亂碼；2.android手機和電腦的兩個java程序進行類似qq的信息交流，中文都是亂碼。疑惑來了，java不是跨平台嗎，而且默認編碼就是unicode，為什麼會有編碼？ 正如上面所說，java的系統編碼是管理內部變數等信息的，是統一不能變的，但上面兩個例子出現亂碼的原因在於這些字元信息是從外界讀取的，編碼方式直接影響到字元的顯示，比如gbk一個字元是1或2個位元組，中文是2個，而utf8是1到4個位元組不定，中文是3個，utf16是2個位元組固定不變，所以很明顯了，同樣位元組數的源信息可以每2個或者每3個位元組表達一個中文，不同編碼當然不同了，而且即使gbk和utf16都是兩個位元組表示一個中文，同樣的二進制也對應不同的字元。所以從外部讀取到這些byte信息後，就要指定編碼，比如new
String(byte[],charset),當然，也可以在構建流的時候就指定，像new
InputStreamReader(InputStream,charset)等，但像BufferedReader等沒有相應的構造函數，就只能把上面的InputStreamReader作為參數了。
總結：
1.String和流（包括控制台的輸出輸入）的默認編碼是根據系統而定，即jvm假設這些信息是當前系統創建的，windows默認中文是gbk，linux和mac是utf8（這里又來了，utf8和unicode是什麼意思，簡單地說，unicode是把每個字元和一個唯一的二進制碼對應的標准，而utf是unicode
transformation
format,即如何表示每個唯一的二進制碼，utf8，utf16和utf32是不同的編碼方式）；
2.IDE設置的編碼方式用於存取java源文件，對於在不同系統平台上共享代碼很重要；
3.java編譯器採用utf8，即class文件的存儲是用utf8，因為相對於utf16，utf8在處理英文佔用內存小，而程序大部分都是英文；
4.jvm運行時的編碼方式是utf16，即jvm用utf8從class文件讀取程序後再轉化為utf16編碼的字元串，因為utf16是2個位元組，統一的長度更方便jvm申請數組等操作；
5.網頁大部分是用utf8編碼的，在html頭幾行有charset的信息，在對下載下來的網頁進行解析時，要注意編碼，谷歌網路在對搜索結果的解析時也是用utf8的，所以在涉及到網路時編碼問題非常重要，本人曾經栽得很慘，當然了，誰叫windows的編碼不是utf8；
6.不知大家有沒有經歷過，如果編碼弄錯了，一般只有中文會出現亂碼，而中文後面的英文是正確的，不合理啊，這不是類似多骨諾米牌嗎，一個錯了，後面不是全倒嗎。所以別小看那些制定編碼的專家，像utf8每個位元組的前幾位都用來表示一些信息，不同位元組還不一樣，而utf16也有，所以弄出了utf16le和utf16be
Ⅱ java中編碼與解碼分別指什麼
java中編碼：URLEncoder.encode(strUri,"utf-8");
java中解碼碼：URLDecoder.decode(strUri,"utf-8");
Ⅲ 編寫JAVA程序輸出中文字的unicode編碼
我寫的，你試試，你可以把它改寫成循環的，可以一直把字元的Unicode輸出，完善後發給我哈：
import java.io.*;
public class FindUnicode {
public static void main(String[] args) throws IOException{
InputStreamReader read = new InputStreamReader (System.in);
int ch = read.read();
System.out.print("\\u"+Integer.toHexString(ch));
read.close();
}
}
Ⅳ JAVA 編碼 這是什麼編碼
編碼就是對已有的數據進行安全重編譯，比如說對於一個String字元串應用MD5加密 就會出現這種情況，比如字元串123456應用MD5加密編碼就會變成gdyb21LQTcIANtvYMT7QVQ== 還有時候是為了程序前端和後端保持一致的對字元串的處理方式，因為同一個字元串，一旦前、後端處理編碼不一致就會出現亂碼，就會把漢子變成亂碼輸出。像你想把手機號編碼成這種亂碼 ，最好就是應用MD5加密
Ⅳ 各個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 的執行速度有了大幅提升。
Ⅵ Java幾種常見的編碼格式
ASCII 碼
學過計算機的人都知道 ASCII 碼，總共有 128 個，用一個位元組的低 7 位表示，0~31 是控制字元如換行回車刪除等；32~126 是列印字元，可以通過鍵盤輸入並且能夠顯示出來。
ISO-8859-1
128 個字元顯然是不夠用的，於是 ISO 組織在 ASCII 碼基礎上又制定了一些列標准用來擴展 ASCII 編碼，它們是 ISO-8859-1~ISO-8859-15，其中 ISO-8859-1 涵蓋了大多數西歐語言字元，所有應用的最廣泛。ISO-8859-1 仍然是單位元組編碼，它總共能表示 256 個字元。
GB2312
它的全稱是《信息交換用漢字編碼字元集 基本集》，它是雙位元組編碼，總的編碼范圍是 A1-F7，其中從 A1-A9 是符號區，總共包含 682 個符號，從 B0-F7 是漢字區，包含 6763 個漢字。
GBK
全稱叫《漢字內碼擴展規范》，是國家技術監督局為 windows95 所制定的新的漢字內碼規范，它的出現是為了擴展 GB2312，加入更多的漢字，它的編碼范圍是 8140~FEFE（去掉 XX7F）總共有 23940 個碼位，它能表示 21003 個漢字，它的編碼是和 GB2312 兼容的，也就是說用 GB2312 編碼的漢字可以用 GBK 來解碼，並且不會有亂碼。
GB18030
全稱是《信息交換用漢字編碼字元集》，是我國的強制標准，它可能是單位元組、雙位元組或者四位元組編碼，它的編碼與 GB2312 編碼兼容，這個雖然是國家標准，但是實際應用系統中使用的並不廣泛。
UTF-16
說到 UTF 必須要提到 Unicode（Universal Code 統一碼），ISO 試圖想創建一個全新的超語言字典，世界上所有的語言都可以通過這本字典來相互翻譯。可想而知這個字典是多麼的復雜，關於 Unicode 的詳細規范可以參考相應文檔。Unicode 是 Java 和 XML 的基礎，下面詳細介紹 Unicode 在計算機中的存儲形式。
UTF-16 具體定義了 Unicode 字元在計算機中存取方法。UTF-16 用兩個位元組來表示 Unicode 轉化格式，這個是定長的表示方法，不論什麼字元都可以用兩個位元組表示，兩個位元組是 16 個 bit，所以叫 UTF-16。UTF-16 表示字元非常方便，每兩個位元組表示一個字元，這個在字元串操作時就大大簡化了操作，這也是 Java 以 UTF-16 作為內存的字元存儲格式的一個很重要的原因。
UTF-8
UTF-16 統一採用兩個位元組表示一個字元，雖然在表示上非常簡單方便，但是也有其缺點，有很大一部分字元用一個位元組就可以表示的現在要兩個位元組表示，存儲空間放大了一倍，在現在的網路帶寬還非常有限的今天，這樣會增大網路傳輸的流量，而且也沒必要。而 UTF-8 採用了一種變長技術，每個編碼區域有不同的字碼長度。不同類型的字元可以是由 1~6 個位元組組成。
UTF-8 有以下編碼規則：
如果一個位元組，最高位（第 8 位）為 0，表示這是一個 ASCII 字元（00 - 7F）。可見，所有 ASCII 編碼已經是 UTF-8 了。
如果一個位元組，以 11 開頭，連續的 1 的個數暗示這個字元的位元組數，例如：110xxxxx 代表它是雙位元組 UTF-8 字元的首位元組。
如果一個位元組，以 10 開始，表示它不是首位元組，需要向前查找才能得到當前字元的首位元組
Java 中需要編碼的場景
前面描述了常見的幾種編碼格式，下面將介紹 Java 中如何處理對編碼的支持，什麼場合中需要編碼。
I/O 操作中存在的編碼
我們知道涉及到編碼的地方一般都在字元到位元組或者位元組到字元的轉換上，而需要這種轉換的場景主要是在 I/O 的時候，這個 I/O 包括磁碟 I/O 和網路 I/O，關於網路 I/O 部分在後面將主要以 Web 應用為例介紹。
Ⅶ Java幾種常見的編碼方式
一般都用utf-8萬國碼
Ⅷ Java中如何設置編碼格式
打開Eclipse，選擇Window--〉Preferences--〉General---〉Workspace，然後在右邊的界面就可以看見Other選項，選擇即可設置編碼格式。
Ⅸ 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很高級的嘞，可以設置成不通編碼的(其實幾乎所有的都可以)。那麼分析的方法和上面一樣，結果可能正好相反。