導航:首頁 > 編程語言 > java字元串decode

java字元串decode

發布時間:2024-11-11 18:52:46

java的Base64Decode解碼5M的字元串會卡死,請問有沒有好的解決辦法

每次只讀較小容量的數據再解碼,比如讀1000個base64字元,解出750個位元組,保存
多次讀、解碼、寫。對較小容量的數據操作就不會死機。

② java中文亂碼,能說下string.getBytes()和new String()轉碼是,具體點。

1、Java中,【String.getBytes(String decode)】的方法,會根據指定的decode,編碼返回某字元串在該編碼下的byte數組表示,例如:

byte[] b_gbk = "中".getBytes("GBK");
byte[] b_utf8 = "中".getBytes("UTF-8");
byte[] b_iso88591 = "中".getBytes("ISO8859-1")

上面三行代碼表示:分別返回「中」這個漢字在GBK、UTF-8和ISO8859-1編碼下的byte數組表示,此時b_gbk的長度為2,b_utf8的長度為3,b_iso88591的長度為1。

2、而通過【new String(byte[], decode)】的方式來還原這個「中」字時,實際是使用decode指定的編碼來將byte[ ]解析成字元串,例如:

String s_gbk = new String(b_gbk,"GBK");
String s_utf8 = new String(b_utf8,"UTF-8");
String s_iso88591 = new String(b_iso88591,"ISO8859-1");

s_gbk和s_utf8都是「中」,而只有s_iso88591是一個不認識 的字元,因為ISO8859-1編碼的編碼表中,根本就沒有包含漢字字元,當然也就無法通過"中".getBytes("ISO8859-1")。

因此,通過【String.getBytes(String decode)】方法來得到byte[ ]時,要確定decode的編碼表中確實存在String表示的碼值,這樣得到的byte[ ]數組才能正確被還原。

(2)java字元串decode擴展閱讀

java中文編碼避免亂碼

1、為了讓中文字元適應某些特殊要求(如http header頭要求其內容必須為iso8859-1編碼),可能會通過將中文字元按照位元組方式來編碼的情況,比如:

String s_iso88591 = new String("中".getBytes("UTF-8"),"ISO8859-1")

2、上述例子中的s_iso8859-1字元串實際是三個在 ISO8859-1中的字元,在將這些字元傳遞到目的地後,目的地程序再通過相反的方式:

String s_utf8 = new String(s_iso88591.getBytes("ISO8859-1"),"UTF-8")

來得到正確的中文漢字。這樣就既保證了遵守協 議規定、也支持中文。

3、String.getBytes(String decode)方法會根據指定的decode編碼返回某字元串在該編碼下的byte數組表示這里是encode ,not decode,從字元串到位元組數組是編碼的過程,從位元組數組到字元串(即 new String(byte[] , charsetname))才是解碼的過程。

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

問題一:在java中讀取文件時應該採用什麼編碼?
Java讀取文件的方式總體可以分為兩類:按位元組讀取和按字元讀取。按位元組讀取就是採用InputStream.read()方法來讀取位元組,然後保存到一個byte[]數組中,最後經常用new String(byte[]);把位元組數組轉換成String。在最後一步隱藏了一個編碼的細節,new String(byte[]);會使用操作系統默認的字元集來解碼位元組數組,中文操作系統就是GBK。而我們從輸入流里讀取的位元組很可能就不是GBK編碼的,因為從輸入流里讀取的位元組編碼取決於被讀取的文件自身的編碼。舉個例子:我們在D:盤新建一個名為demo.txt的文件,寫入」我們。」,並保存。此時demo.txt編碼是ANSI,中文操作系統下就是GBK。此時我們用輸入位元組流讀取該文件所得到的位元組就是使用GBK方式編碼的位元組。那麼我們最終new String(byte[]);時採用平台默認的GBK來編碼成String也是沒有問題的(位元組編碼和默認解碼一致)。試想一下,如果在保存demo.txt文件時,我們選擇UTF-8編碼,那麼該文件的編碼就不在是ANSI了,而變成了UTF-8。仍然採用輸入位元組流來讀取,那麼此時讀取的位元組和上一次就不一樣了,這次的位元組是UTF-8編碼的位元組。兩次的位元組顯然不一樣,一個很明顯的區別就是:GBK每個漢字兩個位元組,而UTF-8每個漢字三個位元組。如何我們最後還使用new String(byte[]);來構造String對象,則會出現亂碼,原因很簡單,因為構造時採用的默認解碼GBK,而我們的位元組是UTF-8位元組。正確的辦法就是使用new String(byte[],」UTF-8」);來構造String對象。此時我們的位元組編碼和構造使用的解碼是一致的,不會出現亂碼問題了。

說完位元組輸入流,再來說說位元組輸出流。
我們知道如果採用位元組輸出流把位元組輸出到某個文件,我們是無法指定生成文件的編碼的(假設文件以前不存在),那麼生成的文件是什麼編碼的呢?經過測試發現,其實這取決於寫入的位元組編碼格式。比如以下代碼:
OutputStream out = new FileOutputStream("d:\\demo.txt");
out.write("我們".getBytes());
getBytes()會採用操作系統默認的字元集來編碼位元組,這里就是GBK,所以我們寫入demo.txt文件的是GBK編碼的位元組。那麼這個文件的編碼就是GBK。如果稍微修改一下程序:out.write("我們".getBytes(「UTF-8」));此時我們寫入的位元組就是UTF-8的,那麼demo.txt文件編碼就是UTF-8。這里還有一點,如果把」我們」換成123或abc之類的ascii碼字元,那麼無論是採用getBytes()或者getBytes(「UTF-8」)那麼生成的文件都將是GBK編碼的。
這里可以總結一下,InputStream中的位元組編碼取決文件本身的編碼,而OutputStream生成文件的編碼取決於位元組的編碼。

下面說說採用字元輸入流來讀取文件。
首先,我們需要理解一下字元流。其實字元流可以看做是一種包裝流,它的底層還是採用位元組流來讀取位元組,然後它使用指定的編碼方式將讀取位元組解碼為字元。說起字元流,不得不提的就是InputStreamReader。以下是java api對它的說明: InputStreamReader是位元組流通向字元流的橋梁:它使用指定的charset 讀取位元組並將其解碼為字元。它使用的字元集可以由名稱指定或顯式給定,否則可能接受平台默認的字元集。說到這里其實很明白了,InputStreamReader在底層還是採用位元組流來讀取位元組,讀取位元組後它需要一個編碼格式來解碼讀取的位元組,如果我們在構造InputStreamReader沒有傳入編碼方式,那麼會採用操作系統默認的GBK來解碼讀取的位元組。還用上面demo.txt的例子,假設demo.txt編碼方式為GBK,我們使用如下代碼來讀取文件:
InputStreamReader in = new InputStreamReader(new FileInputStream(「demo.txt」));
那麼我們讀取不會產生亂碼,因為文件採用GBK編碼,所以讀出的位元組也是GBK編碼的,而InputStreamReader默認採用解碼也是GBK。如果把demo.txt編碼方式換成UTF-8,那麼我們採用這種方式讀取就會產生亂碼。這是因為位元組編碼(UTF-8)和我們的解碼編碼(GBK)造成的。解決辦法如下:
InputStreamReader in = new InputStreamReader(new FileInputStream(「demo.txt」),」UTF-8」);
給InputStreamReader指定解碼編碼,這樣二者統一就不會出現亂碼了。

下面說說字元輸出流。
字元輸出流的原理和字元輸入流的原理一樣,也可以看做是包裝流,其底層還是採用位元組輸出流來寫文件。只是字元輸出流根據指定的編碼將字元轉換為位元組的。字元輸出流的主要類是:OutputStreamWriter。Java api解釋如下:OutputStreamWriter 是字元流通向位元組流的橋梁:使用指定的 charset 將要向其寫入的字元編碼為位元組。它使用的字元集可以由名稱指定或顯式給定,否則可能接受平台默認的字元集。說的很明白了,它需要一個編碼將寫入的字元轉換為位元組,如果沒有指定則採用GBK編碼,那麼輸出的位元組都將是GBK編碼,生成的文件也是GBK編碼的。如果採用以下方式構造OutputStreamWriter:
OutputStreamWriter out = new OutputStreamWriter(new FileOutputStream(「dd.txt」),」UTF-8」);
那麼寫入的字元將被編碼為UTF-8的位元組,生成的文件也將是UTF-8格式的。

問題二: 既然讀文件要使用和文件編碼一致的編碼,那麼javac編譯文件也需要讀取文件,它使用什麼編碼呢?
這個問題從來就沒想過,也從沒當做是什麼問題。正是因為問題一而引發的思考,其實這里還是有東西可以挖掘的。下面分三種情況來探討,這三種情況也是我們常用的編譯java源文件的方法。
1.javac在控制台編譯java類文件。
通常我們手動建立一個java文件Demo.java,並保存。此時Demo.java文件的編碼為ANSI,中文操作系統下就是GBK.然後使用javac命令來編譯該源文件。」javac Demo.java」。Javac也需要讀取java文件,那麼javac是使用什麼編碼來解碼我們讀取的位元組呢?其實javac採用了操作系統默認的GBK編碼解碼我們讀取的位元組,這個編碼正好也是Demo.java文件的編碼,二者一致,所以不會出現亂碼情況。讓我們來做點手腳,在保存Demo.java文件時,我們選擇UTF-8保存。此時Demo.java文件編碼就是UTF-8了。我們再使用」javac Demo.java」來編譯,如果Demo.java里含有中文字元,此時控制台會出現警告信息,也出現了亂碼。究其原因,就是因為javac採用了GBK編碼解碼我們讀取的位元組。因為我們的位元組是UTF-8編碼的,所以會出現亂碼。如果不信的話你可以自己試試。那麼解決辦法呢?解決辦法就是使用javac的encoding參數來制定我們的解碼編碼。如下:javac -encoding UTF-8 Demo.java。這里我們指定了使用UTF-8來解碼讀取的位元組,由於這個編碼和Demo.java文件編碼一致,所以不會出現亂碼情況了。

2.Eclipse中編譯java文件。
我習慣把Eclipse的編碼設置成UTF-8。那麼每個項目中的java源文件的編碼就是UTF-8。這樣編譯也從沒有問題,也沒有出現過亂碼。正是因為這樣才掩蓋了使用javac可能出現的亂碼。那麼Eclipse是如何正確編譯文件編碼為UTF-8的java源文件的呢?唯一的解釋就是Eclipse自動識別了我們java源文件的文件編碼,然後採取了正確的encoding參數來編譯我們的java源文件。功勞都歸功於IDE的強大了。

3.使用Ant來編譯java文件。
Ant也是我常用的編譯java文件的工具。首先,必須知道Ant在後台其實也是採用javac來編譯java源文件的,那麼可想而知,1會出現的問題在Ant中也會存在。如果我們使用Ant來編譯UTF-8編碼的java源文件,並且不指定如何編碼,那麼也會出現亂碼的情況。所以Ant的編譯命令<javac>有一個屬性」 encoding」允許我們指定編碼,如果我們要編譯源文件編碼為UTF-8的java文件,那麼我們的命令應該如下:
<javac destdir="${classes}" target="1.4" source="1.4" deprecation="off" debug="on" debuglevel="lines,vars,source" optimize="off" encoding="UTF-8">
指定了編碼也就相當於」javac –encoding」了,所以不會出現亂碼了。

問題三:tomcat中編譯jsp的情況。
這個話題也是由問題二引出的。既然javac編譯java源文件需要採用正確的編碼,那麼tomcat編譯jsp時也要讀取文件,此時tomcat採用什麼編碼來讀取文件?會出現亂碼情況嗎?下面我們來分析。
我們通常會在jsp開頭寫上如下代碼:
<%@ page language="java" contentType="text/html; charset=utf-8" pageEncoding="utf-8"%>
我常常不寫pageEncoding這個屬於,也不明白它的作用,但是不寫也沒出現過亂碼情況。其實這個屬性就是告訴tomcat採用什麼編碼來讀取jsp文件的。它應該和jsp文件本身的編碼一致。比如我們新建個jsp文件,設置文件編碼為GBK,那麼此時我們的pageEncoding應該設置為GBK,這樣我們寫入文件的字元就是GBK編碼的,tomcat讀取文件時採用也是GBK編碼,所以能保證正確的解碼讀取的位元組。不會出現亂碼。如果把pageEncoding設置為UTF-8,那麼讀取jsp文件過程中轉碼就出現了亂碼。上面說我常常不寫pageEncoding這個屬性,但是也沒出現過亂碼,這是怎麼回事呢?那是因為如果沒有pageEncoding屬性,tomcat會採用contentType中charset編碼來讀取jsp文件,我的jsp文件編碼通常設置為UTF-8,contentType的charset也設置為UTF-8,這樣tomcat使用UTF-8編碼來解碼讀取的jsp文件,二者編碼一致也不會出現亂碼。這只是contentType中charset的一個作用,它還有兩個作用,後面再說。可能有人會問:如果我既不設置pageEncoding屬性,也不設置contentType的charset屬性,那麼tomcat會採取什麼編碼來解碼讀取的jsp文件呢?答案是iso-8859-1,這是tomcat讀取文件採用的默認編碼,如果用這種編碼來讀取文件顯然會出現亂碼。

問題四:輸出。
問題二和問題三分析的過程其實就是從源文件àclass文件過程中的轉碼情況。最終的class文件都是以unicode編碼的,我們前面所做的工作就是把各種不同的編碼轉換為unicode編碼,比如從GBK轉換為unicode,從UTF-8轉換為unicode。因為只有採用正確的編碼來轉碼才能保證不出現亂碼。Jvm在運行時其內部都是採用unicode編碼的,其實在輸出時,又會做一次編碼的轉換。讓我們分兩種情況來討論。
1.java中採用Sysout.out.println輸出。
比如:Sysout.out.println(「我們」)。經過正確的解碼後」我們」是unicode保存在內存中的,但是在向標准輸出(控制台)輸出時,jvm又做了一次轉碼,它會採用操作系統默認編碼(中文操作系統是GBK),將內存中的unicode編碼轉換為GBK編碼,然後輸出到控制台。因為我們操作系統是中文系統,所以往終端顯示設備上列印字元時使用的也是GBK編碼。因為終端的編碼無法手動改變,所以這個過程對我們來說是透明的,只要編譯時能正確轉碼,最終的輸出都將是正確的,不會出現亂碼。在Eclipse中可以設置控制台的字元編碼,具體位置在Run Configuration對話框的Common標簽里,我們可以試著設置為UTF-8,此時的輸出就是亂碼了。因為輸出時是採用GBK編碼的,而顯示卻是使用UTF-8,編碼不同,所以出現亂碼。

2.jsp中使用out.println()輸出到客戶端瀏覽器。
Jsp編譯成class後,如果輸出到客戶端,也有個轉碼的過程。Java會採用操作系統默認的編碼來轉碼,那麼tomcat採用什麼編碼來轉碼呢?其實tomcat是根據<%@ page language="java" contentType="text/html; charset=utf-8" pageEncoding="utf-8"%>中contentType的charset參數來轉碼的,contentType用來設置tomcat往瀏覽器發送HTML內容所使用的編碼。Tomcat根據這個編碼來轉碼內存中的unicode。經過轉碼後tomcat輸出到客戶端的字元編碼就是utf-8了。那麼瀏覽器怎麼知道採取什麼編碼格式來顯示接收到的內容呢?這就是contentType的charset屬性的第三個作用了:這個編碼會在HTTP響應頭中指定以通知瀏覽器。瀏覽器使用http響應頭的contentType的charset屬性來顯示接收到的內容。
總結一下contentType charset的三個作用:
1).在沒有pageEncoding屬性時,tomcat使用它來解碼讀取的jsp文件。
2).tomcat向客戶端輸出時,使用它來編碼發送的內容。
3).通知瀏覽器,應該以什麼編碼來顯示接收到的內容。
為了能更好的理解上面所說的解碼和轉碼過程,我們舉一個例子。
新建一個index.jsp文件,該文件編碼為GBK,在jsp開頭我們寫上如下代碼:
<%@ page language="java" contentType="text/html; charset=utf-8" pageEncoding="GBK"%>
這里的charset和pageEncoding不同,但是也不會出現亂碼,我來解釋一下。首先tomcat讀取jsp內容,並根據pageEncoding指定的GBK編碼將讀取的GBK位元組解碼並轉換為unicode位元組碼保存在class文件中。然後tomcat在輸出時(out.println())使用charset屬性將內存中的unicode轉換為utf-8編碼,並在響應頭中通知瀏覽器,瀏覽器以utf-8顯示接收到的內容。整個過程沒有一次轉碼錯誤,所以就不會出現亂碼情況。

問題五:Properties和ResourceBundle使用的解碼編碼。

以上兩個是我們常用的類,他們在讀取文件過程中並不允許我們指定解碼編碼,那麼它們採取什麼解碼方式呢?查看源碼後發現都是採用iso-8859-1編碼來解碼
的。這樣的話我們也不難理解我們寫的properties文件為什麼都是iso-8859-1 的了。因為採取任何一個別的編碼都將產生亂碼。因為iso-8859-1編碼是沒
有中文的,所以我們輸入的中文要轉換為unicode,通常我們使用插件來完成,也可以使用jdk自帶的native2ascii工具。

④ java中 Integer的decode(),parseInt(),valueOf()有什麼區別

【轉】Integer.decode()和Intger.valueof()
今天沒事看看API
decode合適用來分析數字
可以分析
8進:010=>分析後回為 8
10進:10=>分析後為 10
16進:#10|0X10|0x10=>分析後是答 16
而valueof 只能分析純數字的String
像 010 這樣的8進制 他會解析成 =>10
//////////////////////////////////////////////////////2010.01.22補充///////////////////////////////////////////////
public static int parseInt( s,
int radix)
throws
也可以用來分析各種輸入,以radix為基數. 范圍是 大於等於2,小於等於36
可以直接返回int.
decode 返回Integer
想要獲得Integer:
String 為十進制. 採用valueof(String)合適. 非十進制,採用decode(String)
想要獲得int
String 為十進制. 採用parseInt(String )合適. 非十進制,採用parseInt(String ,int)

閱讀全文

與java字元串decode相關的資料

熱點內容
pr工程文件打開找不到打開方式 瀏覽:673
win10不自動降頻 瀏覽:531
sat文件是什麼文件 瀏覽:494
appletv如何連接無線網 瀏覽:93
win10怎麼添加搜狗輸入法嗎 瀏覽:391
awk取文件名 瀏覽:692
uc記錄在哪個文件夾 瀏覽:339
網路專家教你如何認證 瀏覽:688
dnf85泰拉石武器升級 瀏覽:11
網路詞眼是什麼意思 瀏覽:953
信達證券網路學院 瀏覽:11
微信發文件復印件 瀏覽:548
列印模板在哪個文件夾 瀏覽:978
linux命令界面 瀏覽:859
編程買什麼工作站好 瀏覽:131
mac虛擬機鏡像文件 瀏覽:853
c生成的文件夾哪些可以刪除 瀏覽:213
衡量網路有效帶寬的性能指標是 瀏覽:712
一加app在哪個文件夾 瀏覽:334
蘋果6home鍵漏電 瀏覽:941

友情鏈接