基礎篇：一文讓你讀懂JAVA.IO、字符編碼、URL和Spring.Resource

1 JAVA.IO字節流

inputstream.png

• LineNumberInputStream和StringBufferInputStream官方建議不再使用，推薦使用LineNumberReader和StringReader代替
• ByteArrayInputStream和ByteArrayOutputStream 字節數組處理流，在內存中建立一個緩衝區作為流使用，從緩存區讀取數據比從存儲介質(如磁碟)的速率快

//用ByteArrayOutputStream暫時緩存來自其他渠道的數據ByteArrayOutputStream data = new ByteArrayOutputStream(1024); //1024位元組大小的緩存區data.write(System.in.read()); // 暫存用戶輸入數據//將data轉為ByteArrayInputStreamByteArrayInputStream in = new ByteArrayInputStream(data.toByteArray());

• FileInputStream和FileOutputStream 訪問文件，把文件作為InputStream，實現對文件的讀寫操作
• ObjectInputStream和ObjectOutputStream 對象流，構造函數需要傳入一個流，實現對JAVA對象的讀寫功能；可用於序列化，而對象需要實現Serializable接口

//java對象的寫入FileOutputStream fileStream = new FileOutputStream(&34;);ObjectOutputStream out = new ObjectOutputStream(fileStream);Example example = new Example();out.writeObject(example);//java對象的讀取FileInputStream fileStream = new FileInputStream(&34;);ObjectInputStream in = new ObjectInputStream(fileStream);Example = (Example) in.readObject();

• PipedInputStream和PipedOutputStream 管道流，適用在兩個線程中傳輸數據，一個線程通過管道輸出流發送數據，另一個線程通過管道輸入流讀取數據，實現兩個線程間的數據通信

// 創建一個發送者對象Sender sender = new Sender(); // 創建一個接收者對象Receiver receiver = new Receiver(); // 獲取輸出管道流// 獲取輸入輸出管道流PipedOutputStream outputStream = sender.getOutputStream(); PipedInputStream inputStream = receiver.getInputStream();// 連結兩個管道，這一步很重要，把輸入流和輸出流聯通起來 outputStream.connect(inputStream);sender.start();// 啟動發送者線程receiver.start();// 啟動接收者線程

• SequenceInputStream 把多個InputStream合併為一個InputStream，允許應用程式把幾個輸入流連續地合併起來

InputStream in1 = new FileInputStream(&34;);InputStream in2 = new FileInputStream(&34;);SequenceInputStream sequenceInputStream = new SequenceInputStream(in1, in2);//數據讀取int data = sequenceInputStream.read();

• FilterInputStream和FilterOutputStream 使用了裝飾者模式來增加流的額外功能，子類構造參數需要一個InputStream/OutputStream

ByteArrayOutputStream out = new ByteArrayOutputStream(2014);//數據寫入，使用DataOutputStream裝飾一個InputStream//使用InputStream具有對基本數據的處理能力DataOutputStream dataOut = new DataOutputStream(out);dataOut.writeDouble(1.0);//數據讀取ByteArrayInputStream in = new ByteArrayInputStream(out.toByteArray());DataInputStream dataIn = new DataInputStream(in);Double data = dataIn.readDouble();

• DataInputStream和DataOutputStream (Filter流的子類) 為其他流附加處理各種基本類型數據的能力,如byte、int、String
• BufferedInputStream和BufferedOutputStream (Filter流的子類) 為其他流增加緩衝功能
• PushBackInputStream (FilterInputStream子類) 推回輸入流，可以把讀取進來的某些數據重新回退到輸入流的緩衝區之中
• PrintStream (FilterOutputStream子類) 列印流，功能類似System.out.print

2 JAVA.IO字符流

21.png

• 從字節流和字符流的導向圖來，它們之間是相互對應的，比如CharArrayReader和ByteArrayInputStream
• 字節流和字符流的轉化：InputStreamReader可以將InputStream轉為Reader,OutputStreamReader可以將OutputStream轉為Writer

//InputStream轉為ReaderInputStream inputStream = new ByteArrayInputStream(&34;.getBytes());InputStreamReader reader = new InputStreamReader(inputStream, StandardCharsets.UTF_8);//OutputStream轉為WriterOutputStream out = new FileOutputStream(&34;);OutputStreamWriter writer = new OutputStreamWriter(out);//以字符為單位讀寫writer.write(reader.read(new char[2]));

• 區別：字節流讀取單位是字節，字符流讀取單位是字符；一個字符由字節組成，如變字長編碼UTF-8是由1~4個字節表示

3 亂碼問題和字符流

• 字符以不同的編碼表示，它的字節長度（字長）是不一樣的。如「程」的utf-8編碼格式，由[-25][-88][-117]組成。而ISO_8859_1編碼則是單個字節[63]
• 平時工作對資源的操作都是面向字節流的，然而數據資源根據不同的字節編碼轉為字節時，它們的內容是不一樣，容易造成亂碼問題
• 兩種出現亂碼場景 encode和decode使用的字符編碼不一致：資源使用UTF-8編碼，而在代碼裡卻使用GBK解碼打開使用字節流讀取字節數不符合字符規定字長：字符是由字節組成的，比如「程」的utf-8格式是三個字節；如果在InputStream裡以每兩個字節讀取流，再轉為String（java默認編碼是utf-8），此時會出現亂碼（半個中文，你猜是什麼）

ByteArrayInputStream in = new ByteArrayInputStream(&34;.getBytes());byte[] buf = new byte[2]; //讀取流的兩個字節in.read(buf); //讀取數據System.out.println(new String(buf)); //亂碼---result---- � //亂碼

• 亂碼場景1，知道資源的字符編碼，就可以使用對應的字符編碼來解碼解決
• 亂碼場景2，可以一次性讀取所有字節，再一次性編碼處理。但是對於大文件流，這是不現實的，因此有了字符流的出現
• 字節流使用InputStreamReader、OutputStreamReader轉化為字符流，其中可以指定字符編碼，再以字符為單位來處理，可解決亂碼

InputStreamReader reader = new InputStreamReader(inputStream, StandardCharsets.UTF_8);

4 字符集和字符編碼的概念區分

• 字符集和字符編碼的關係，字符集是規範，字符編碼是規範的具體實現；字符集規定了符號和二進位代碼值的唯一對應關係，但是沒有指定具體的存儲方式；
• unicode、ASCII、GB2312、GBK都是字符集；其中ASCII、GB2312、GBK既是字符集也是字符編碼；注意不混淆這兩者區別；而unicode的具體實現有UTF-8，UTF-16，UTF-32
• 最早出現的ASCII碼是使用一個字節（8bit）來規定字符和二進位映射關係，標準ASCII編碼規定了128個字符，在英文的世界，是夠用的。但是中文，日文等其他文字符號怎麼映射呢？因此其他更大的字符集出現了
• unicode（統一字符集），早期時它使用2個byte表示1個字符，整個字符集可以容納65536個字符。然而仍然不夠用，於是擴展到4個byte表示一個字符，現支持範圍是U+010000~U+10FFFF
• unicode是兩個字節的說法是錯誤的；UTF-8是變字長的，需要用1~4個字節存儲；UTF-16一般是兩個字節（U+0000~U+FFFF範圍），如果遇到兩個字節存不下，則用4個字節；而UTF-32是固定四個字節
• unicode表示的字符，會用「U+」開頭，後面跟著十六進位的數字，如「字」的編碼就是U+5B57
• UTF-8 編碼和unicode字符集

範圍 Unicode(Binary) UTF-8編碼(Binary) UTF-8編碼byte長度 U+0000~U+007F 00000000 00000000 00000000 0XXXXXXX 0XXXXXX 1 U+0080~U+07FF 00000000 00000000 00000YYY YYXXXXXX 110YYYYY 10XXXXXX 2 U+0800~U+FFFF 00000000 00000000 ZZZZYYYY YYXXXXXX 1110ZZZZ 10YYYYYY 10XXXXXX 3 U+010000~U+10FFFF 00000000 000AAAZZ ZZZZYYYY YYXXXXXX 11110AAA 10ZZZZZZ 10YYYYYY 10XXXXXX 4

• 程序是分內碼和外碼，java的默認編碼是UTF-8，其實指的是外碼；內碼傾向於使用定長碼，和內存對齊一個原理，便於處理。外碼傾向於使用變長碼，變長碼將常用字符編為短編碼，罕見字符編為長編碼，節省存儲空間與傳輸帶寬
• JDK8的字符串，是使用char[]來存儲字符的，char是兩個字節大小，其中使用的是UTF-16編碼（內碼）。而unicode規定的中文字符在U+0000~U+FFFF內，因此使用char（UTF-16編碼）存儲中文是不會出現亂碼的
• JDK9後，字符串則使用byte[]數組來存儲，因為有一些字符一個char已經存不了，如emoji表情字符，使用字節存儲字符串更容易拓展
• JDK9，如果字符串的內容都是ISO-8859-1/Latin-1字符（1個字符1位元組），則使用ISO-8859-1/Latin-1編碼存儲字符串，否則使用UTF-16編碼存儲數組（2或4個字節）

System.out.println(Charset.defaultCharset()); //輸出java默認編碼for (byte item : &34;.getBytes(StandardCharsets.UTF_16)) { System.out.print(&34; + item + &34;);}System.out.println(&34;);for (byte item : &34;.getBytes(StandardCharsets.UTF_8)) { System.out.print(&34; + item + &34;);}----result----UTF-8 //java默認編碼UTF-8[-2][-1][122][11][94][-113] //UTF_16：6個字節？[-25][-88][-117][-27][-70][-113] //UTF_8：6個字節 正常

• 「程序」的UTF-16編碼竟是輸出6個字節，多出了兩個字節，這是什麼情況？再試試一個字符的輸出

for (byte item : &34;.getBytes(StandardCharsets.UTF_16)) { System.out.print(&34; + item + &34;);}---result--[-2][-1][122][11]

• 可以看出UTF-16編碼的字節是多了[-2][-1]兩個字節，十六進位是0xFEFF。而它用來標識編碼順序是Big endian還是Little endian。以字符&39;為例，它的unicode十六進位是4E2D，存儲時4E在前，2D在後，就是Big endian；2D在前，4E在後，就是Little endian。FEFF表示存儲採用Big endian，FFFE表示使用Little endian
• 為什麼UTF-8沒有字節序的問題呢？個人看法，因為UTF-8是變長的，由第一個字節的頭部的0、110、1110、11110判斷是否需後續幾個字節組成字符，使用Big endian易讀取處理，反過來不好處理，因此強制用Big endian
• 其實感覺UTF-16可以強制規定用Big endian；但這其中歷史問題。。。

5 URI概念的簡單介紹

• 既然有了java.io來操作資源流；但是對於網絡的資源，該怎麼打開，怎麼定位呢？答URI-URL
• URI全稱是Uniform Resource Identifier 統一資源標識符
• 通俗說，就是一個類似身份證號碼的字符串，只不過它是用來標識資源(如：郵件地址，主機名，文件等)
• URI 具有特定的規則: [scheme]:[scheme-specific-part][fragment]，其中模式特定部分為authority和path、query；而authority可以看做域名，如www.baidu.com終極細分則是[scheme]:[//host:port][/path][?query][片段[protocol]:[//host:port][/path][?query][34;D:/example.txt&34;example.txt&34;test.txt&34;classpath:&34;classpath*:&34;classpath*:&34;com/smart/**/*.xml&34;file:///res.txt&34;https://my.cn/res.txt&34;res.properties&34;username&34;res.yml&34;name"); // chen//url: http://www.my.com

  11 優雅地關閉資源，try-with-resource語法和lombok@Cleanup

  • 資源的打開就需要對應的關閉，但我們常會忘記關閉資源，或在多處代碼關閉資源感到雜亂，有沒有簡潔的關閉方法呢？
  • 自動關閉資源類需實現AutoCloseable接口和配合try-with-resource語法糖使用

  public class YSOAPConnection implements AutoCloseable { private SOAPConnection connection; public static YSOAPConnection open(SOAPConnectionFactory soapConnectionFactory) throws SOAPException { YSOAPConnection ySoapConnection = new YSOAPConnection(); SOAPConnection connection = soapConnectionFactory.createConnection(); ySoapConnection.setConnection(connection); return ySoapConnection; } public SOAPMessage call(SOAPMessage request, Object to) throws SOAPException { return connection.call(request, to); } @Override public void close() throws SOAPException { if (connection != null) { connection.close(); } }}

  //自動關閉的資源類使用示例try (YSOAPConnection soapConnection=YSOAPConnection.open(soapConnectionFactory)){ SOAPMessage soapResponse = soapConnection.call(request, endpoint); ...//數據操作} catch (Exception e) { log.error(e.getMessage(), e); ...}

  • lombok註解@Cleanup，對象生命周期結束時會調用public void close();對象需實現AutoCloseable接口

  import lombok.Cleanup;@Cleanup // @Cleanup的使用YSOAPConnection soapConnection=YSOAPConnection.open(soapConnectionFactory)

  12 資源不關閉，會導致什麼最壞的結果

  • JDK的原生資源類不關閉，它也不會永遠存在。JVM會藉助finalize自動關閉它，例如FileInputStream

  //FileInputStream.java - JDK8//jdk8的FileInputStream重寫了finalize，保證對象回收前開啟的資源被關閉protected void finalize () throws IOException { if (guard != null) { guard.warnIfOpen(); } if ((fd != null) && (fd != FileDescriptor.in)) { close(); }}

  • 在JDK9後，用Cleaner機制代替了finalize機制；Cleaner機制自動回收的對象同樣需要實現AutoCloseable接口；Cleaner是基於PhantomReference實現的；對實現細節感興趣的同學，可自行查閱下相關文檔
  • 但是使用JDK的提供的資源關閉機制的，那麼資源的關閉比手動關閉時要延後很長時間的。據測試，使用try-with-resources關閉資源，並讓垃圾回收器回收它的時間在12納秒。而使用finalizer機制，時間增加到550納秒
  • 不及時關閉資源，就會佔用資源，影響其他線程的執行；比如linux的文件資源，linux進程默認能打開的最大文件數是1024（有的是2048，此數值是可配置的）；如果一個線程持有十幾個文件資源，還要等550納秒用finalizer機制釋放資源，同進程的其他線程都等到花謝了

  
  作者：clswcl
  連結：https://juejin.im/post/6856266775022174222
  來源：掘金