1. 字符與字節(jié)之間的那座橋?yàn)槭裁葱枰D(zhuǎn)換流剛?cè)胄心菚?huì)兒我對(duì)Java的IO體系是有點(diǎn)發(fā)怵的。字節(jié)流、字符流、緩沖流、轉(zhuǎn)換流名字聽著都差不多用起來卻各有各的脾氣。尤其是碰到中文亂碼的時(shí)候整個(gè)人都是懵的——明明代碼邏輯沒問題讀出來的東西卻是一堆問號(hào)或者方塊。后來踩的坑多了才慢慢明白亂碼的根源十有八九出在字符編碼的轉(zhuǎn)換環(huán)節(jié)上而OutputStreamWriter和InputStreamReader這兩個(gè)類恰恰就是處理這個(gè)環(huán)節(jié)的關(guān)鍵角色。先說清楚這兩個(gè)類到底是干什么的。Java的IO流分兩大陣營(yíng)字節(jié)流InputStream/OutputStream和字符流Reader/Writer。字節(jié)流面向的是原始的二進(jìn)制數(shù)據(jù)一個(gè)字節(jié)一個(gè)字節(jié)地讀寫它不關(guān)心這些字節(jié)代表什么含義字符流面向的是文本數(shù)據(jù)它知道一個(gè)字符可能由多個(gè)字節(jié)組成會(huì)根據(jù)指定的字符集來編碼和解碼。問題在于很多時(shí)候我們手里拿到的是字節(jié)流比如網(wǎng)絡(luò)連接、文件系統(tǒng)、控制臺(tái)輸入輸出但業(yè)務(wù)邏輯需要按字符來處理比如讀寫文本、解析JSON、處理中文。這時(shí)候就需要一座橋把字節(jié)流包裝成字符流而InputStreamReader和OutputStreamWriter就是這座橋。具體來說InputStreamReader繼承自Reader它接收一個(gè)字節(jié)輸入流按照指定的字符集把讀到的字節(jié)解碼成字符OutputStreamWriter繼承自Writer它接收一個(gè)字節(jié)輸出流按照指定的字符集把要寫的字符編碼成字節(jié)再輸出。你可以把它們理解成翻譯官——字節(jié)流說的是字節(jié)語字符流說的是字符語轉(zhuǎn)換流負(fù)責(zé)在兩者之間做同聲傳譯。翻譯得好不好取決于你告訴它用哪本字典字符集。這兩個(gè)類解決的核心問題就一個(gè)讓字節(jié)和字符之間的轉(zhuǎn)換變得可控、可指定、可預(yù)期。如果你不指定字符集它們會(huì)用平臺(tái)默認(rèn)的字符集這在跨平臺(tái)場(chǎng)景下就是個(gè)定時(shí)炸彈——開發(fā)機(jī)上是UTF-8服務(wù)器上是GBK同樣的代碼跑出來的結(jié)果天差地別。所以凡是用到轉(zhuǎn)換流的地方顯式指定字符集應(yīng)該成為肌肉記憶。這篇文章適合誰看如果你正在學(xué)Java IO被各種流繞得頭暈或者你在實(shí)際項(xiàng)目里遇到過亂碼問題想搞清楚背后的原理又或者你寫代碼時(shí)習(xí)慣性地用FileReader/FileWriter但不知道它們其實(shí)內(nèi)部就是轉(zhuǎn)換流的簡(jiǎn)化版——那這篇內(nèi)容應(yīng)該能幫你把這塊知識(shí)理順。我會(huì)從設(shè)計(jì)思路、核心原理、實(shí)操代碼、常見坑幾個(gè)維度展開盡量把每個(gè)為什么都講透。2. 轉(zhuǎn)換流的設(shè)計(jì)哲學(xué)與核心原理拆解2.1 適配器模式不只是包裝那么簡(jiǎn)單InputStreamReader和OutputStreamWriter在設(shè)計(jì)模式上屬于典型的適配器模式Adapter Pattern。適配器的核心思想是把一個(gè)類的接口轉(zhuǎn)換成客戶端期望的另一個(gè)接口讓原本因?yàn)榻涌诓患嫒荻鵁o法一起工作的類可以協(xié)同工作。在這里不兼容體現(xiàn)在字節(jié)流和字符流的抽象層級(jí)不同——字節(jié)流的最小單位是byte字符流的最小單位是char而一個(gè)char在不同編碼下對(duì)應(yīng)的字節(jié)數(shù)是不一樣的。拿UTF-8來說一個(gè)英文字符占1個(gè)字節(jié)一個(gè)中文字符通常占3個(gè)字節(jié)GBK里一個(gè)中文字符占2個(gè)字節(jié)而Java內(nèi)部用的是UTF-16一個(gè)char固定占2個(gè)字節(jié)。當(dāng)你從字節(jié)流讀數(shù)據(jù)時(shí)你拿到的是一個(gè)個(gè)孤立的字節(jié)這些字節(jié)本身沒有字符邊界的概念。InputStreamReader要做的就是根據(jù)指定的字符集判斷讀到幾個(gè)字節(jié)了夠不夠組成一個(gè)完整字符夠了就解碼輸出一個(gè)char不夠就繼續(xù)讀。這個(gè)過程叫解碼decode。反過來OutputStreamWriter拿到的是char它要根據(jù)字符集把char編碼成對(duì)應(yīng)的字節(jié)序列再寫出去。這個(gè)過程叫編碼encode。編碼相對(duì)簡(jiǎn)單因?yàn)槊總€(gè)char都是完整的直接查表轉(zhuǎn)換就行解碼就麻煩一些因?yàn)樽止?jié)流是連續(xù)的你需要處理半個(gè)字符的情況——比如一次只讀到了某個(gè)中文字符的前兩個(gè)字節(jié)第三個(gè)字節(jié)還沒到這時(shí)候不能急著解碼得緩存起來等后續(xù)字節(jié)。注意轉(zhuǎn)換流內(nèi)部維護(hù)了一個(gè)字節(jié)緩沖區(qū)StreamDecoder/StreamEncoder內(nèi)部有ByteBuffer用來處理跨讀取邊界的多字節(jié)字符。這也是為什么轉(zhuǎn)換流的read()方法可能返回0表示還沒湊夠一個(gè)完整字符而普通字節(jié)流的read()返回0只表示讀到了空數(shù)據(jù)。2.2 字符集的本質(zhì)一張映射表加一套編解碼規(guī)則要理解轉(zhuǎn)換流繞不開字符集。很多人對(duì)字符集的理解停留在UTF-8不會(huì)亂碼GBK會(huì)亂碼這種模糊認(rèn)知上其實(shí)字符集的本質(zhì)很樸素它就是一張巨大的映射表規(guī)定了每個(gè)字符對(duì)應(yīng)哪個(gè)或哪幾個(gè)數(shù)字以及這些數(shù)字怎么用字節(jié)表示。以Unicode為例它為世界上幾乎所有字符都分配了一個(gè)唯一的編號(hào)叫碼點(diǎn)Code Point。比如漢字中的碼點(diǎn)是U4E2D十六進(jìn)制的4E2D十進(jìn)制是20013。但Unicode只規(guī)定了編號(hào)沒規(guī)定怎么存儲(chǔ)。UTF-8、UTF-16、UTF-32就是不同的存儲(chǔ)方案UTF-8用1到4個(gè)字節(jié)變長(zhǎng)存儲(chǔ)UTF-16用2或4個(gè)字節(jié)存儲(chǔ)UTF-32固定用4個(gè)字節(jié)。GBK則是另一套完全獨(dú)立的體系它只覆蓋中文和部分其他字符用1到2個(gè)字節(jié)存儲(chǔ)。InputStreamReader構(gòu)造時(shí)可以傳入一個(gè)Charset對(duì)象或者字符集名稱字符串。如果不傳它就用Charset.defaultCharset()也就是平臺(tái)默認(rèn)字符集。在Windows中文版上默認(rèn)字符集通常是GBK在Linux和macOS上通常是UTF-8。這就是為什么同一段代碼在不同系統(tǒng)上跑結(jié)果可能不一樣。// 不指定字符集使用平臺(tái)默認(rèn) InputStreamReader reader new InputStreamReader(inputStream); // 顯式指定UTF-8推薦做法 InputStreamReader reader new InputStreamReader(inputStream, StandardCharsets.UTF_8); // 也可以用字符串名稱但拼寫錯(cuò)誤會(huì)在運(yùn)行時(shí)拋異常 InputStreamReader reader2 new InputStreamReader(inputStream, UTF-8);我個(gè)人的習(xí)慣是永遠(yuǎn)用StandardCharsets里的常量因?yàn)樗蔷幾g期檢查的拼錯(cuò)了編譯器直接報(bào)錯(cuò)而字符串名稱拼錯(cuò)了要到運(yùn)行時(shí)才炸。2.3 為什么FileReader和FileWriter不夠用Java提供了FileReader和FileWriter這兩個(gè)便利類它們看起來用起來更簡(jiǎn)單一行代碼就能讀文件。但它們的致命缺陷是不能指定字符集。FileReader的源碼里構(gòu)造函數(shù)最終調(diào)用的是new InputStreamReader(new FileInputStream(file))沒有傳字符集參數(shù)所以用的是平臺(tái)默認(rèn)字符集。這意味著什么你的程序在開發(fā)機(jī)上UTF-8跑得好好的部署到服務(wù)器上GBK讀同一個(gè)文件中文全變亂碼。而且這個(gè)問題很隱蔽因?yàn)殚_發(fā)階段往往發(fā)現(xiàn)不了。所以但凡涉及文本文件讀寫尤其是可能包含中文的場(chǎng)景我都建議直接用InputStreamReader/OutputStreamWriter包裝FileInputStream/FileOutputStream顯式指定UTF-8。// 不推薦無法指定字符集 FileReader fileReader new FileReader(data.txt); // 推薦顯式指定字符集 InputStreamReader reader new InputStreamReader( new FileInputStream(data.txt), StandardCharsets.UTF_8);這個(gè)替換成本極低但能避免大量跨平臺(tái)亂碼問題。我在實(shí)際項(xiàng)目里見過太多次因?yàn)橛昧薋ileReader導(dǎo)致線上亂碼的案例排查起來還挺費(fèi)勁因?yàn)楸镜貜?fù)現(xiàn)不了。3. 核心API與實(shí)操要點(diǎn)詳解3.1 InputStreamReader的構(gòu)造與讀取方法InputStreamReader的構(gòu)造函數(shù)主要有三個(gè)重載構(gòu)造函數(shù)說明適用場(chǎng)景InputStreamReader(InputStream in)使用平臺(tái)默認(rèn)字符集不推薦跨平臺(tái)有風(fēng)險(xiǎn)InputStreamReader(InputStream in, String charsetName)指定字符集名稱字符集名稱動(dòng)態(tài)傳入時(shí)使用InputStreamReader(InputStream in, Charset cs)指定Charset對(duì)象推薦編譯期檢查讀取方法繼承自Reader常用的有int read()讀一個(gè)字符返回字符的int值讀到末尾返回-1int read(char[] cbuf)讀一批字符到數(shù)組返回實(shí)際讀取的字符數(shù)int read(char[] cbuf, int off, int len)讀指定范圍的字符boolean ready()判斷是否還有可讀字符注意這個(gè)方法的語義容易誤解后面會(huì)講這里有個(gè)容易踩的坑read()返回的是字符的Unicode碼點(diǎn)準(zhǔn)確說是char的int表示不是字節(jié)。如果你讀到一個(gè)中文字符返回的可能是20013中的碼點(diǎn)而不是某個(gè)字節(jié)值。所以判斷是否讀到末尾只能跟-1比較不能跟0比較。try (InputStreamReader reader new InputStreamReader( new FileInputStream(test.txt), StandardCharsets.UTF_8)) { int ch; while ((ch reader.read()) ! -1) { System.out.print((char) ch); } }這段代碼逐字符讀取文件內(nèi)容并打印。用try-with-resources確保流被關(guān)閉這是Java 7以后的標(biāo)準(zhǔn)寫法比手動(dòng)在finally里close要安全得多。3.2 OutputStreamWriter的構(gòu)造與寫入方法OutputStreamWriter的構(gòu)造函數(shù)與InputStreamReader對(duì)稱構(gòu)造函數(shù)說明OutputStreamWriter(OutputStream out)使用平臺(tái)默認(rèn)字符集OutputStreamWriter(OutputStream out, String charsetName)指定字符集名稱OutputStreamWriter(OutputStream out, Charset cs)指定Charset對(duì)象寫入方法主要有void write(int c)寫一個(gè)字符void write(char[] cbuf)寫一個(gè)字符數(shù)組void write(char[] cbuf, int off, int len)寫數(shù)組的一部分void write(String str)寫一個(gè)字符串void write(String str, int off, int len)寫字符串的一部分void flush()刷新緩沖區(qū)把緩沖的字符編碼后寫出注意OutputStreamWriter內(nèi)部有緩沖區(qū)寫入的字符不會(huì)立即變成字節(jié)輸出到目標(biāo)流而是先攢著等緩沖區(qū)滿了或者調(diào)用flush()時(shí)才真正編碼寫出。如果你寫完不flush也不close數(shù)據(jù)可能丟失。用try-with-resources的話close()會(huì)自動(dòng)flush所以一般不用擔(dān)心。try (OutputStreamWriter writer new OutputStreamWriter( new FileOutputStream(output.txt), StandardCharsets.UTF_8)) { writer.write(你好世界\n); writer.write(這是一段中文測(cè)試); writer.flush(); // 確保數(shù)據(jù)寫出 }3.3 緩沖區(qū)包裝性能優(yōu)化的關(guān)鍵一步單獨(dú)用轉(zhuǎn)換流逐字符讀寫性能其實(shí)不怎么樣因?yàn)槊看蝦ead()/write()都可能觸發(fā)一次系統(tǒng)調(diào)用或編碼操作。標(biāo)準(zhǔn)做法是在轉(zhuǎn)換流外面再套一層BufferedReader/BufferedWritertry (BufferedReader reader new BufferedReader( new InputStreamReader( new FileInputStream(input.txt), StandardCharsets.UTF_8))) { String line; while ((line reader.readLine()) ! null) { System.out.println(line); } }這個(gè)套娃結(jié)構(gòu)是Java IO里最經(jīng)典的組合字節(jié)流 → 轉(zhuǎn)換流 → 緩沖流。每一層各司其職字節(jié)流負(fù)責(zé)跟底層打交道轉(zhuǎn)換流負(fù)責(zé)編解碼緩沖流負(fù)責(zé)減少IO次數(shù)。BufferedReader的readLine()方法特別實(shí)用能按行讀取文本省去了自己處理換行符的麻煩。為什么緩沖能提升性能因?yàn)榇疟PIO和網(wǎng)絡(luò)IO的速度遠(yuǎn)低于內(nèi)存操作。假設(shè)每次read()都要從磁盤讀一個(gè)字節(jié)讀一個(gè)1MB的文件就要調(diào)用一百萬次系統(tǒng)調(diào)用開銷巨大。加了緩沖區(qū)后一次系統(tǒng)調(diào)用讀8KB默認(rèn)緩沖區(qū)大小到內(nèi)存后續(xù)的read()直接從內(nèi)存拿系統(tǒng)調(diào)用次數(shù)降到原來的八千分之一左右。這個(gè)提升是數(shù)量級(jí)的。3.4 字符集選擇UTF-8為什么是默認(rèn)答案在實(shí)際項(xiàng)目里字符集選擇基本就一個(gè)原則能用UTF-8就用UTF-8。原因有三第一UTF-8是變長(zhǎng)編碼英文占1字節(jié)中文占3字節(jié)對(duì)英文內(nèi)容友好存儲(chǔ)效率高。第二UTF-8兼容ASCII所有ASCII字符在UTF-8里編碼不變這意味著大量現(xiàn)有協(xié)議和文件格式可以無縫遷移。第三UTF-8是互聯(lián)網(wǎng)事實(shí)標(biāo)準(zhǔn)HTML、JSON、XML、HTTP頭默認(rèn)都用它跨系統(tǒng)交互時(shí)用UTF-8能避免大量轉(zhuǎn)換麻煩。GBK雖然對(duì)純中文內(nèi)容存儲(chǔ)更省空間中文占2字節(jié)但它只覆蓋中文和少量其他字符遇到日文、韓文、emoji就歇菜了。而且GBK有多個(gè)變種GB2312、GBK、GB18030兼容性也是個(gè)問題。除非你有明確的遺留系統(tǒng)對(duì)接需求否則沒有理由選GBK。提示StandardCharsets類里預(yù)定義了常用的字符集常量包括UTF_8、UTF_16、ISO_8859_1、US_ASCII等。用這些常量比用字符串名稱更安全因?yàn)槠磳戝e(cuò)誤在編譯期就能發(fā)現(xiàn)。4. 完整實(shí)操從文件讀寫到網(wǎng)絡(luò)傳輸?shù)霓D(zhuǎn)換流應(yīng)用4.1 場(chǎng)景一帶編碼指定的文本文件讀寫先看一個(gè)最基礎(chǔ)但最完整的例子——把一個(gè)UTF-8編碼的文件讀進(jìn)來轉(zhuǎn)成GBK編碼寫到另一個(gè)文件。這個(gè)場(chǎng)景在數(shù)據(jù)遷移時(shí)很常見。public class CharsetConvertExample { public static void main(String[] args) { String sourceFile source_utf8.txt; String targetFile target_gbk.txt; try (BufferedReader reader new BufferedReader( new InputStreamReader( new FileInputStream(sourceFile), StandardCharsets.UTF_8)); BufferedWriter writer new BufferedWriter( new OutputStreamWriter( new FileOutputStream(targetFile), GBK))) { String line; int lineCount 0; while ((line reader.readLine()) ! null) { writer.write(line); writer.newLine(); lineCount; } System.out.println(轉(zhuǎn)換完成共處理 lineCount 行); } catch (IOException e) { System.err.println(文件轉(zhuǎn)換失敗 e.getMessage()); e.printStackTrace(); } } }這段代碼的關(guān)鍵點(diǎn)讀的時(shí)候用UTF-8解碼寫的時(shí)候用GBK編碼中間的String是Java內(nèi)部的UTF-16表示相當(dāng)于做了一次UTF-8 → UTF-16 → GBK的轉(zhuǎn)碼。BufferedReader和BufferedWriter負(fù)責(zé)緩沖readLine()和newLine()負(fù)責(zé)按行處理。整個(gè)流程清晰、可控。4.2 場(chǎng)景二處理控制臺(tái)輸入輸出控制臺(tái)輸入輸出是轉(zhuǎn)換流的另一個(gè)典型應(yīng)用場(chǎng)景。System.in是InputStream字節(jié)流System.out是PrintStream字節(jié)流如果你想按字符讀取用戶輸入就需要用InputStreamReader包裝System.in。public class ConsoleInputExample { public static void main(String[] args) throws IOException { // 用UTF-8包裝標(biāo)準(zhǔn)輸入 BufferedReader consoleReader new BufferedReader( new InputStreamReader(System.in, StandardCharsets.UTF_8)); System.out.println(請(qǐng)輸入內(nèi)容輸入exit退出); String input; while ((input consoleReader.readLine()) ! null) { if (exit.equalsIgnoreCase(input.trim())) { break; } System.out.println(你輸入了 input); System.out.println(字符數(shù) input.length()); } } }這里有個(gè)細(xì)節(jié)值得說System.in的字符集在Windows控制臺(tái)和Linux終端上可能不同。Windows中文控制臺(tái)默認(rèn)是GBKLinux通常是UTF-8。如果你用UTF-8包裝System.in但在Windows控制臺(tái)輸入中文可能會(huì)亂碼。解決辦法是在啟動(dòng)JVM時(shí)加參數(shù)-Dfile.encodingUTF-8或者用chcp 65001把Windows控制臺(tái)切到UTF-8模式。這個(gè)問題在IDE里通常不明顯因?yàn)镮DE會(huì)做處理但打包成jar在命令行跑就容易暴露。4.3 場(chǎng)景三網(wǎng)絡(luò)通信中的字符流轉(zhuǎn)換網(wǎng)絡(luò)編程里Socket的getInputStream()和getOutputStream()返回的都是字節(jié)流。如果要傳輸文本協(xié)議比如簡(jiǎn)單的聊天程序就需要用轉(zhuǎn)換流包裝。public class SocketTextExample { public static void main(String[] args) throws IOException { // 假設(shè)已經(jīng)建立了Socket連接 Socket socket new Socket(localhost, 8888); // 發(fā)送端字符 → 字節(jié) BufferedWriter writer new BufferedWriter( new OutputStreamWriter(socket.getOutputStream(), StandardCharsets.UTF_8)); writer.write(你好服務(wù)器\n); writer.flush(); // 接收端字節(jié) → 字符 BufferedReader reader new BufferedReader( new InputStreamReader(socket.getInputStream(), StandardCharsets.UTF_8)); String response reader.readLine(); System.out.println(服務(wù)器回復(fù) response); socket.close(); } }網(wǎng)絡(luò)傳輸里字符集不一致是重災(zāi)區(qū)?？蛻舳擞肬TF-8發(fā)服務(wù)端用GBK收中文必亂。所以通信雙方必須約定好字符集通常寫在協(xié)議文檔里。我參與過的項(xiàng)目里協(xié)議頭一般會(huì)帶一個(gè)charset字段或者干脆硬性規(guī)定全用UTF-8。4.4 場(chǎng)景四大文件分塊讀取與編碼轉(zhuǎn)換處理大文件時(shí)一次性讀入內(nèi)存會(huì)OOM需要分塊讀取。轉(zhuǎn)換流配合字符數(shù)組可以實(shí)現(xiàn)按塊處理。public class LargeFileProcess { public static void main(String[] args) throws IOException { char[] buffer new char[8192]; // 8K字符緩沖區(qū) try (InputStreamReader reader new InputStreamReader( new FileInputStream(large_file.txt), StandardCharsets.UTF_8); OutputStreamWriter writer new OutputStreamWriter( new FileOutputStream(large_file_out.txt), StandardCharsets.UTF_8)) { int charsRead; long totalChars 0; while ((charsRead reader.read(buffer)) ! -1) { // 這里可以對(duì)buffer里的內(nèi)容做處理 writer.write(buffer, 0, charsRead); totalChars charsRead; } System.out.println(共處理 totalChars 個(gè)字符); } } }注意read(char[])返回的是實(shí)際讀取的字符數(shù)可能小于數(shù)組長(zhǎng)度尤其是接近文件末尾時(shí)所以寫的時(shí)候要用write(buffer, 0, charsRead)而不是write(buffer)否則會(huì)把數(shù)組里沒讀到的部分也寫出去。5. 常見問題與排查技巧實(shí)錄5.1 亂碼問題排查速查表亂碼是轉(zhuǎn)換流相關(guān)問題的絕對(duì)大頭。下面這張表整理了常見亂碼現(xiàn)象和對(duì)應(yīng)的排查方向現(xiàn)象可能原因排查方法中文變問號(hào)???編碼時(shí)目標(biāo)字符集不支持該字符檢查輸出端字符集換成UTF-8中文變方塊□□□解碼時(shí)字符集不匹配檢查讀取端字符集是否與文件實(shí)際編碼一致中文變亂碼錕斤拷UTF-8字節(jié)被GBK解碼統(tǒng)一用UTF-8或確認(rèn)文件真實(shí)編碼部分中文正常部分亂碼文件混合了多種編碼用工具檢測(cè)文件編碼或分段處理英文正常中文亂碼讀取端用了ISO-8859-1換成UTF-8或GBK換行符異常不同系統(tǒng)換行符不同用BufferedReader.readLine()自動(dòng)處理排查亂碼的核心思路是先確認(rèn)原始數(shù)據(jù)的真實(shí)編碼再確認(rèn)讀取時(shí)用的編碼兩者必須一致。如果原始數(shù)據(jù)是UTF-8你用GBK讀必亂反之亦然。確認(rèn)文件編碼可以用文本編輯器的另存為看默認(rèn)編碼或者用file -i命令Linux/macOS檢測(cè)。5.2 ready()方法的陷阱InputStreamReader.ready()這個(gè)方法很容易被誤用。它的語義是是否還有字符可以立即讀取而不阻塞而不是是否還有字符可讀。在網(wǎng)絡(luò)流場(chǎng)景下數(shù)據(jù)可能還沒到達(dá)ready()返回false但這不代表流結(jié)束了。如果你用while (reader.ready())來循環(huán)讀取可能會(huì)提前退出漏掉后面的數(shù)據(jù)。正確的做法是用read()返回-1來判斷流結(jié)束// 錯(cuò)誤用法可能漏讀數(shù)據(jù) while (reader.ready()) { int ch reader.read(); // ... } // 正確用法read()返回-1表示流結(jié)束 int ch; while ((ch reader.read()) ! -1) { // ... }5.3 忘記flush導(dǎo)致數(shù)據(jù)丟失OutputStreamWriter有內(nèi)部緩沖區(qū)寫入的字符不會(huì)立即輸出。如果程序在close之前異常退出或者你忘了flush緩沖區(qū)里的數(shù)據(jù)就丟了。用try-with-resources可以避免這個(gè)問題因?yàn)閏lose()會(huì)自動(dòng)flush。但如果你的流不是用try-with-resources管理的就要養(yǎng)成寫完手動(dòng)flush的習(xí)慣。OutputStreamWriter writer new OutputStreamWriter( new FileOutputStream(test.txt), StandardCharsets.UTF_8); writer.write(重要數(shù)據(jù)); // 如果這里拋異常下面的close不會(huì)執(zhí)行數(shù)據(jù)丟失 writer.close();5.4 字符集名稱拼寫錯(cuò)誤用字符串指定字符集時(shí)拼寫錯(cuò)誤會(huì)在運(yùn)行時(shí)拋UnsupportedEncodingException。比如把UTF-8寫成UTF8雖然有些實(shí)現(xiàn)能識(shí)別但不保證或者把GBK寫成GB2312兩者不完全等價(jià)。用StandardCharsets常量可以完全避免這個(gè)問題。5.5 嵌套流的關(guān)閉順序多層嵌套的流關(guān)閉時(shí)只需要關(guān)閉最外層。因?yàn)殛P(guān)閉外層流時(shí)會(huì)級(jí)聯(lián)關(guān)閉內(nèi)層流。比如BufferedReader包裝InputStreamReader包裝FileInputStream只需要close最外層的BufferedReader它會(huì)依次關(guān)閉內(nèi)層。手動(dòng)關(guān)閉多層反而可能出問題。// 正確只關(guān)最外層 try (BufferedReader reader new BufferedReader( new InputStreamReader( new FileInputStream(test.txt), StandardCharsets.UTF_8))) { // ... } // 錯(cuò)誤手動(dòng)關(guān)閉多層可能重復(fù)關(guān)閉或順序錯(cuò)誤 FileInputStream fis new FileInputStream(test.txt); InputStreamReader isr new InputStreamReader(fis, StandardCharsets.UTF_8); BufferedReader br new BufferedReader(isr); // ... 手動(dòng)close三個(gè)容易出錯(cuò)5.6 性能問題什么時(shí)候該加緩沖如果你發(fā)現(xiàn)IO操作很慢第一反應(yīng)應(yīng)該是檢查有沒有加緩沖。逐字符讀寫不加緩沖性能會(huì)差幾十倍甚至上百倍。判斷標(biāo)準(zhǔn)很簡(jiǎn)單只要讀寫的數(shù)據(jù)量超過幾KB就應(yīng)該加BufferedReader/BufferedWriter。對(duì)于小數(shù)據(jù)量比如讀一個(gè)配置文件加不加差別不大但加了也沒壞處。另外緩沖區(qū)大小可以調(diào)整。默認(rèn)是8192字符對(duì)于特別大的文件可以適當(dāng)調(diào)大比如16384或32768。但也不是越大越好太大會(huì)占用過多內(nèi)存而且收益遞減。// 自定義緩沖區(qū)大小 BufferedReader reader new BufferedReader( new InputStreamReader( new FileInputStream(big.txt), StandardCharsets.UTF_8), 32768);6. 進(jìn)階話題轉(zhuǎn)換流在NIO和現(xiàn)代框架中的影子6.1 NIO的CharsetDecoder與CharsetEncoderJava NIO提供了更底層的編解碼APICharsetDecoder和CharsetEncoder。它們比轉(zhuǎn)換流更靈活支持更精細(xì)的控制比如設(shè)置解碼錯(cuò)誤時(shí)的處理策略CodingErrorAction.REPLACE、REPORT、IGNORE。Charset charset StandardCharsets.UTF_8; CharsetDecoder decoder charset.newDecoder() .onMalformedInput(CodingErrorAction.REPLACE) .onUnmappableCharacter(CodingErrorAction.REPLACE); ByteBuffer byteBuffer ByteBuffer.wrap(你好.getBytes(StandardCharsets.UTF_8)); CharBuffer charBuffer decoder.decode(byteBuffer); System.out.println(charBuffer.toString());轉(zhuǎn)換流內(nèi)部其實(shí)也是用這套API實(shí)現(xiàn)的只是封裝得更簡(jiǎn)單易用。如果你需要處理編碼錯(cuò)誤比如遇到非法字節(jié)序列時(shí)不想拋異常而是替換成特定字符就需要用NIO的這套API。6.2 現(xiàn)代框架中的字符集處理Spring框架的CharacterEncodingFilter、Netty的StringDecoder/StringEncoder、Jackson的JsonEncoding底層都涉及字符集轉(zhuǎn)換。理解轉(zhuǎn)換流的原理有助于排查這些框架里的編碼問題。比如Spring Boot默認(rèn)用UTF-8但如果你在application.properties里改了server.servlet.encoding.charset就可能影響請(qǐng)求參數(shù)的解析。6.3 一個(gè)容易被忽略的細(xì)節(jié)BOM頭UTF-8文件有時(shí)會(huì)帶一個(gè)BOMByte Order Mark即文件開頭的三個(gè)字節(jié)EF BB BF。這個(gè)BOM在Windows記事本保存UTF-8文件時(shí)會(huì)自動(dòng)加上。用InputStreamReader讀取時(shí)BOM會(huì)被當(dāng)作一個(gè)特殊字符UFEFF讀進(jìn)來導(dǎo)致第一個(gè)字符異常。解決辦法是讀取后檢查并跳過BOM或者用BOMInputStreamApache Commons IO提供來包裝。// 手動(dòng)跳過UTF-8 BOM PushbackInputStream pushback new PushbackInputStream( new FileInputStream(with_bom.txt), 3); byte[] bom new byte[3]; int n pushback.read(bom); if (n 3 bom[0] (byte)0xEF bom[1] (byte)0xBB bom[2] (byte)0xBF) { // 是BOM跳過 } else { // 不是BOM推回去 pushback.unread(bom, 0, n); } InputStreamReader reader new InputStreamReader(pushback, StandardCharsets.UTF_8);這個(gè)問題在處理用戶上傳的文件時(shí)特別常見因?yàn)橛脩艨赡苡酶鞣N編輯器保存文件有的帶BOM有的不帶。7. 我踩過的坑與實(shí)操心得說幾個(gè)我在實(shí)際項(xiàng)目里踩過的坑都是文檔里不會(huì)寫的。第一個(gè)坑是測(cè)試環(huán)境和生產(chǎn)環(huán)境字符集不一致。有一次寫了個(gè)導(dǎo)出CSV的功能本地測(cè)試沒問題上線后用戶反饋中文全是亂碼。排查發(fā)現(xiàn)本地JVM默認(rèn)字符集是UTF-8生產(chǎn)服務(wù)器是GBK而代碼里用了FileWriter沒指定字符集。后來改成OutputStreamWriter顯式指定UTF-8就好了。從那以后我寫任何涉及文本IO的代碼都強(qiáng)制指定字符集絕不依賴默認(rèn)值。第二個(gè)坑是忘記flush導(dǎo)致日志丟失。有次寫了個(gè)日志工具類用OutputStreamWriter寫日志文件程序正常退出時(shí)日志是全的但程序被kill時(shí)最后幾條日志就丟了。原因是緩沖區(qū)沒flush。后來改成每條日志寫完就flush雖然性能略有下降但日志完整性更重要?；蛘哂肂ufferedWriter配合定時(shí)flush。第三個(gè)坑是readLine()處理超長(zhǎng)行。BufferedReader.readLine()在遇到?jīng)]有換行符的超長(zhǎng)行時(shí)會(huì)一直讀到內(nèi)存里可能導(dǎo)致OOM。處理用戶上傳的文本文件時(shí)要注意最好限制單行最大長(zhǎng)度或者用read(char[])分塊讀。第四個(gè)坑是字符集名稱大小寫。雖然大多數(shù)實(shí)現(xiàn)不區(qū)分大小寫但規(guī)范上字符集名稱是大小寫不敏感的。不過為了可讀性還是統(tǒng)一用大寫比如UTF-8而不是utf-8。第五個(gè)坑是多線程共享轉(zhuǎn)換流。InputStreamReader和OutputStreamWriter都不是線程安全的多個(gè)線程同時(shí)讀寫同一個(gè)流會(huì)導(dǎo)致數(shù)據(jù)錯(cuò)亂。如果需要在多線程環(huán)境使用要么加鎖要么每個(gè)線程用自己的流。最后分享一個(gè)實(shí)用技巧如果你不確定一個(gè)文件的真實(shí)編碼可以用juniversalchardet或cpdetector這類庫來檢測(cè)。它們通過分析字節(jié)序列的統(tǒng)計(jì)特征來猜測(cè)編碼準(zhǔn)確率還不錯(cuò)。對(duì)于用戶上傳的文件先檢測(cè)編碼再用對(duì)應(yīng)的InputStreamReader讀取能避免大部分亂碼問題。// 用juniversalchardet檢測(cè)編碼需引入依賴 UniversalDetector detector new UniversalDetector(null); byte[] buf new byte[4096]; int nread; while ((nread inputStream.read(buf)) 0 !detector.isDone()) { detector.handleData(buf, 0, nread); } detector.dataEnd(); String encoding detector.getDetectedCharset();這套組合拳打下來基本上能覆蓋日常開發(fā)中90%以上的字符編碼場(chǎng)景。轉(zhuǎn)換流這個(gè)知識(shí)點(diǎn)看起來簡(jiǎn)單但細(xì)節(jié)很多真正吃透需要在項(xiàng)目里多實(shí)踐、多踩坑。希望這篇內(nèi)容能幫你少走些彎路。