java默認編碼

❶ java中為什麼要用ISO-8859-1編碼啊

Java使用ISO-8859-1編碼是因為這種編碼國際上是通用的，可以兼容很多國家的語言編碼。我們國家的gbk編碼格式是可以換成ISO-8859-1格式神汪的。
國際中通用的還有一種編碼格式就是UTF-8能兼容世界上幾乎所有的語言，在網路傳輸迅握為了避免出現亂碼，都採用這種編碼方游昌仔式。

❷ java中的String的默認編碼是什麼

可以通過如下代碼獲得默認編碼：

System.out.println(Charset.defaultCharset());

字元編碼（英語：Character encoding）也稱字集碼，是把字元集中的字元編碼為指定集合中某一對象（例如：比特模式、自然數序列、8位組或者電脈沖），以便文本在計算機中存儲和通過通信網路的傳遞。常見的例子包括將拉丁字母表編碼成摩斯電碼和ASCII。其中，ASCII將字母、數字和其它符號編號，並用7比特的二進制來表示這個整數。通常會額外使用一個擴充的比特，以便於以1個位元組的方式存儲。
在計算機技術發展的早期，如ASCII（1963年）和EBCDIC（1964年）這樣的字元集逐漸成為標准。但這些字元集的局限很快就變得明顯，於是人們開發了許多方法來擴展它們。對於支持包括東亞CJK字元家族在內的寫作系統的要求能支持更大量的字元，並且需要一種系統而不是臨時的方法實現這些字元的編碼。

❸ java怎麼設置為utf-8的編碼

要讓一個
Java
源文件打開時編碼格式為
UTF-8，需要做2件事情：
1）設置Java
源文件的默認編碼格式為UTF-8；
2）設置workspace的編碼格式為UTF-8。
相應設置如下：
設置
Java
源文件的默認編碼格式為
UTF-8
在
Windows->Preference
頁面中，選擇
General->Content
Types
在右邊的框中，選擇
Text->Java
Source
File，將下面的
Default
Encoding
改為
UTF-8
設置
workspace
的編碼格式為
UTF-8
在
Windows->Preference
頁面中，選擇
General->WorkSpace
選擇右側框中的
Text
File
encoding，改為
UTF-8
設置完這2處，默認打開
Java
源文件就是UTF-8編碼了。

❹ 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的默認編碼不是utf-8 而是gbk

因為系統是中文語言的，得到的是GBK編碼，所以肯定不是utf的。

工具：

win7

jdk

方法：

1. 在計算機上右鍵選擇屬性

   

❻ JAVA編碼時為什麼用的是utf-8呢

Linux好像默認是UTF-8吧。WINDOWS平台java默認編碼是GBK，你也可以自己設置編碼啊

❼ 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的 但是伺服器是否正確抓到 你好嗎 不得而知

但是如果更改為