java字元集編碼

① java中怎樣改變本地字元集編碼

System.out.println(new String(strInfo.getBytes("ISO-8859-1"),"gb2312")); 你在輸出的時候這么轉碼，還會輸出亂碼，見鬼了

② 幾種判斷字元集編碼的方法（Java） 未完

如果是Java的String對象的話，則一定是Unicode的，這個沒有為什麼，Java就是這么定的。

我猜你的問題應該是如何判斷一段位元組流是什麼編碼類型，對嗎？比如一個文件，或是網路上面取下來的一段Byte數組，你需要用一個合適的編碼來解析成字元串。

這個讓你失望了，沒有一個文檔化的，確定的方法來判斷，只能用測試的方法，這個方法也只是猜測，不能百分百的確定，方法如下：

• 用常見的編碼方式對位元組流進行解碼，比如Unicode，UTF8， UTF8 without BOM,UTF16, ANSI等等。

• 對解析的結果進行判斷，是不是一個合理的可列印字元，可列印字元最多的解碼方式就是最可能的編碼了。

• 如何判斷可列印字元？流程如下：把解析好的字元串按照字元進行遍歷，把每一個字元轉化成Unicode編碼，看看這些編碼是不是Unicode的支持范圍極客。

• 如果發現有種編碼方式都是可列印字元，那麼再使用本步驟：對字元串進行分詞，分詞這個在此不作贅述，你自己再研究一下。分詞效果好的就是最可能的編碼了。（不過通常到第三步就能搞定了，第四部絕大部分用不著）

③ Java中的字元採用的是兩個位元組編碼的什麼字元集。

java平台採用UTF-16（Unicode）編碼，一個字元佔2個位元組（不論英文，還是中文字元）。

④ java以二進制傳輸字元集填啥

用UTF-8.
java讀寫文件的有很多種方式，基本都是採用java.io的inputStream和各種基於inputstream的封裝實現對文件的讀寫，最原始的介面提供的便是基於byte的讀寫，而String可以看做是char[]，一個char是8個byte。在最原始的ASCII編碼中，我們採用一個位元組 也就時8位來表示一個字元（圖形字元或者控制字元），而後來1個位元組不足以表示現實中的所有字元，於是出現了各種各樣的編碼格式，常見的比如UTF-8，GBK，UNICODE等。java中的string也是遵循jre中定義的默認字元集(基本為UTF-8），而在byte[]轉化成String的過程中可能會由於編碼字元集問題導致String逆向回來的byte[]與原來的數組不一致。

⑤ Java中的字元使用什麼編碼

System.out.println(Charset.defaultCharset()); 字元編碼（英語：Character encoding）也稱字集碼，是把字元集中的字元編碼為指定集合中某一對象（例如：比特模式、自然數序列、8位組或者電脈沖），以便文本在計算機中存儲和通過通信網路的傳遞...

⑥ 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很高級的嘞，可以設置成不通編碼的(其實幾乎所有的都可以)。那麼分析的方法和上面一樣，結果可能正好相反。

⑦ 如何查找默認的字元集/編碼在Java中

1, Java代碼直接設置
System.out.println(System.getProperty("file.encoding"));
或
System.out.println(Charset.defaultCharset());

2，eclipse裡面選中工程->properties->Resource:text file encoding 改成你的原文件編碼格式即可；
3，一般配置jdbc連接字元串的時候可以指定字元編碼集，指定成和資料庫的編碼一致即可，這樣用jdbc讀出來的數據就是解碼後的正常的數據。當然，不同的資料庫產品具體看怎麼辦。

⑧ Java中字元集有哪些呢

字元集(character set)是一個系統支持的所有抽象字元的集合。字元(character)就是各種文字和符號，包括國家文字、標點符號、圖形符號、數字等。

如果僅僅是抽象的字元集，其實是顧名思義的，但是我們常說的字元集，其實是指編碼字元集(coded character set)，比如: Unicode、ASCII、GB2312、GBK等等。什麼是編碼字元集呢？編碼字元集是指，這個字元集里的每一個字元，都對應到唯一的一個代碼值，這些代碼值叫做代碼點(code point)，可以看做是這個字元在編碼字元集里的序號，字元在給定的編碼方式下的二進制比特序列稱為代碼單元(code unit)。在Unicode字元集中，字母A對應的數值是十六進制下的0041，書寫時前面加U+，所以Unicode里A的代碼點是U+0041。

常見的編碼字元集有：

• Unicode：也叫統一字元集，它包含了幾乎世界上所有的已經發現且需要使用的字元（如中文、日文、英文、德文等）。

• ASCII：早期的計算機系統只能處理英文，所以ASCII也就成為了計算機的預設字元集，包含了英文所需要的所有字元。

• GB2312：中文字元集，包含ASCII字元集。ASCII部分用單位元組表示，剩餘部分用雙位元組表示。

• GBK：GB2312的擴展，完整包含了GB2312的所有內容。

• GB18030：GBK字元集的超集，常叫大漢字字元集，也叫CJK（Chinese，Japanese，Korea）字元集，包含了中、日、韓三國語言中的所有字元。

學習相關java類知識，推薦來北京尚學堂，優秀的師資和科學的授課方式，會帶給你完美的學習體驗。

⑨ java中字元集什麼意思

Java 中字元串在內核中使用 Unicode，也就是說每個字元 JVM 只記錄它的 Unicode Code Point，只有在網路傳輸或保存到磁碟上時才需要把它轉換成特定的字元集的編碼，這個字元集就是把一個 Unicode Code Point 整數翻譯成一串 byte[]，因為在網路或磁碟上，位元組是一個一個排列的，我們需要知道把高位位元組排前面還是排後面並且容易推斷出哪個哪個位元組是一個字元的邊界，這樣才能把相關的幾個位元組還原成一個字元而不是把第2個字元的後面半數位元組和第3個字元的前面半數的位元組拼在一起出一個怪異的字元，我們以前在早期的電腦游戲中不支持雙位元組漢語時我們經常碰到這個問題，那就是先輸入一個漢字，在內存中有2個位元組，然後我們按一下 backspace 軟體只刪除一個位元組，我們再輸入一個漢字之後一共有3個位元組的，這時我們用一個支持漢字的軟體來查看這個文字可能是第1個剩下的位元組和後面的字元的第1位元組拼起來剛好又是另一個漢字，而剩下的第3個位元組就不是有意義的繪圖符號。

當不需要把 JVM 內存中的字元傳輸到網路外或磁碟上或列印出來的時候，我們是不需要知道字元集的，在顯示在圖形界面上時JVM知道怎麼把它們顯示出來，現在的 Windows 操作系統同樣也是 Unicode 內核的，也就是說我們只要說明 Unicode Code Point 它應該知道是什麼字元，那麼只剩下字體這邊是否也是用 Unicode Code Point 來對應一個字元啦（這個我不確定，但估計也是），如果操作系統和字元這邊也是按 Unicode Code Point 來對應，那麼當我們不保存到磁碟或發送出網路時是完全不需要知道有字元集這回事的。

下面這個例子中處理一個 Unicode 6.0 新標准中收錄的漢字，你看到 UTF-8, UTF-16, GB18030 支持它們，但 GB2312 沒有收錄這個漢字，所以出個問號，也就是我們學說的亂碼啦。

什麼是 Unicode，下面這樣的表格就是 Unicode，而那些坐標數字就是 Code Point.

⑩ java中編碼與解碼分別指什麼

java中編碼：URLEncoder.encode(strUri,"utf-8");

java中解碼碼：URLDecoder.decode(strUri,"utf-8");