換流深度解析：InputStreamReader與OutputStreamWriter原理及亂碼解決)
1. 字符與字節(jié)之間的那座橋?yàn)槭裁葱枰D(zhuǎn)換流剛?cè)胄心菚?huì)兒我對(duì)Java的IO體系是有點(diǎn)發(fā)怵的。字節(jié)流、字符流、緩沖流、轉(zhuǎn)換流名字聽(tīng)著都差不多用起來(lái)卻各有各的脾氣。尤其是碰到中文亂碼的時(shí)候整個(gè)人都是懵的——明明代碼邏輯沒(méi)問(wèn)題讀出來(lái)的東西卻是一堆問(wèn)號(hào)或者方塊。后來(lái)踩的坑多了才慢慢明白亂碼的根源十有八九出在字符編碼的轉(zhuǎn)換環(huán)節(jié)上而OutputStreamWriter和InputStreamReader這兩個(gè)類恰恰就是處理這個(gè)環(huán)節(jié)的關(guān)鍵角色。先說(shuō)清楚這兩個(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ù)指定的字符集來(lái)編碼和解碼。問(wèn)題在于很多時(shí)候我們手里拿到的是字節(jié)流比如網(wǎng)絡(luò)連接、文件系統(tǒng)、控制臺(tái)輸入輸出但業(yè)務(wù)邏輯需要按字符來(lái)處理比如讀寫文本、解析JSON、處理中文。這時(shí)候就需要一座橋把字節(jié)流包裝成字符流而InputStreamReader和OutputStreamWriter就是這座橋。具體來(lái)說(shuō)InputStreamReader繼承自Reader它接收一個(gè)字節(jié)輸入流按照指定的字符集把讀到的字節(jié)解碼成字符OutputStreamWriter繼承自Writer它接收一個(gè)字節(jié)輸出流按照指定的字符集把要寫的字符編碼成字節(jié)再輸出。你可以把它們理解成翻譯官——字節(jié)流說(shuō)的是字節(jié)語(yǔ)字符流說(shuō)的是字符語(yǔ)轉(zhuǎn)換流負(fù)責(zé)在兩者之間做同聲傳譯。翻譯得好不好取決于你告訴它用哪本字典字符集。這兩個(gè)類解決的核心問(wèn)題就一個(gè)讓字節(jié)和字符之間的轉(zhuǎn)換變得可控、可指定、可預(yù)期。如果你不指定字符集它們會(huì)用平臺(tái)默認(rèn)的字符集這在跨平臺(tái)場(chǎng)景下就是個(gè)定時(shí)炸彈——開(kāi)發(fā)機(jī)上是UTF-8服務(wù)器上是GBK同樣的代碼跑出來(lái)的結(jié)果天差地別。所以凡是用到轉(zhuǎn)換流的地方顯式指定字符集應(yīng)該成為肌肉記憶。這篇文章適合誰(shuí)看如果你正在學(xué)Java IO被各種流繞得頭暈或者你在實(shí)際項(xiàng)目里遇到過(guò)亂碼問(wèn)題想搞清楚背后的原理又或者你寫代碼時(shí)習(xí)慣性地用FileReader/FileWriter但不知道它們其實(shí)內(nèi)部就是轉(zhuǎn)換流的簡(jiǎn)化版——那這篇內(nèi)容應(yīng)該能幫你把這塊知識(shí)理順。我會(huì)從設(shè)計(jì)思路、核心原理、實(shí)操代碼、常見(jiàn)坑幾個(gè)維度展開(kāi)盡量把每個(gè)為什么都講透。2. 轉(zhuǎn)換流的設(shè)計(jì)哲學(xué)與核心原理拆解2.1 適配器模式不只是包裝那么簡(jiǎn)單InputStreamReader和OutputStreamWriter在設(shè)計(jì)模式上屬于典型的適配器模式Adapter Pattern。適配器的核心思想是把一個(gè)類的接口轉(zhuǎn)換成客戶端期望的另一個(gè)接口讓原本因?yàn)榻涌诓患嫒荻鵁o(wú)法一起工作的類可以協(xié)同工作。在這里不兼容體現(xiàn)在字節(jié)流和字符流的抽象層級(jí)不同——字節(jié)流的最小單位是byte字符流的最小單位是char而一個(gè)char在不同編碼下對(duì)應(yīng)的字節(jié)數(shù)是不一樣的。拿UTF-8來(lái)說(shuō)一個(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é)本身沒(méi)有字符邊界的概念。InputStreamReader要做的就是根據(jù)指定的字符集判斷讀到幾個(gè)字節(jié)了夠不夠組成一個(gè)完整字符夠了就解碼輸出一個(gè)char不夠就繼續(xù)讀。這個(gè)過(guò)程叫解碼decode。反過(guò)來(lái)OutputStreamWriter拿到的是char它要根據(jù)字符集把char編碼成對(duì)應(yīng)的字節(jié)序列再寫出去。這個(gè)過(guò)程叫編碼encode。編碼相對(duì)簡(jiǎn)單因?yàn)槊總€(gè)char都是完整的直接查表轉(zhuǎn)換就行解碼就麻煩一些因?yàn)樽止?jié)流是連續(xù)的你需要處理半個(gè)字符的情況——比如一次只讀到了某個(gè)中文字符的前兩個(gè)字節(jié)第三個(gè)字節(jié)還沒(méi)到這時(shí)候不能急著解碼得緩存起來(lái)等后續(xù)字節(jié)。注意轉(zhuǎn)換流內(nèi)部維護(hù)了一個(gè)字節(jié)緩沖區(qū)StreamDecoder/StreamEncoder內(nèi)部有ByteBuffer用來(lái)處理跨讀取邊界的多字節(jié)字符。這也是為什么轉(zhuǎn)換流的read()方法可能返回0表示還沒(méi)湊夠一個(gè)完整字符而普通字節(jié)流的read()返回0只表示讀到了空數(shù)據(jù)。2.2 字符集的本質(zhì)一張映射表加一套編解碼規(guī)則要理解轉(zhuǎn)換流繞不開(kāi)字符集。很多人對(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)沒(méi)規(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è)便利類它們看起來(lái)用起來(lái)更簡(jiǎn)單一行代碼就能讀文件。但它們的致命缺陷是不能指定字符集。FileReader的源碼里構(gòu)造函數(shù)最終調(diào)用的是new InputStreamReader(new FileInputStream(file))沒(méi)有傳字符集參數(shù)所以用的是平臺(tái)默認(rèn)字符集。這意味著什么你的程序在開(kāi)發(fā)機(jī)上UTF-8跑得好好的部署到服務(wù)器上GBK讀同一個(gè)文件中文全變亂碼。而且這個(gè)問(wèn)題很隱蔽因?yàn)殚_(kāi)發(fā)階段往往發(fā)現(xiàn)不了。所以但凡涉及文本文件讀寫尤其是可能包含中文的場(chǎng)景我都建議直接用InputStreamReader/OutputStreamWriter包裝FileInputStream/FileOutputStream顯式指定UTF-8。// 不推薦無(wú)法指定字符集 FileReader fileReader new FileReader(data.txt); // 推薦顯式指定字符集 InputStreamReader reader new InputStreamReader( new FileInputStream(data.txt), StandardCharsets.UTF_8);這個(gè)替換成本極低但能避免大量跨平臺(tái)亂碼問(wèn)題。我在實(shí)際項(xiàng)目里見(jiàn)過(guò)太多次因?yàn)橛昧薋ileReader導(dǎo)致線上亂碼的案例排查起來(lái)還挺費(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ù)說(shuō)明適用場(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è)方法的語(yǔ)義容易誤解后面會(huì)講這里有個(gè)容易踩的坑read()返回的是字符的Unicode碼點(diǎn)準(zhǔn)確說(shuō)是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ù)說(shuō)明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è)Q行符的麻煩。為什么緩沖能提升性能因?yàn)榇疟PIO和網(wǎng)絡(luò)IO的速度遠(yuǎn)低于內(nèi)存操作。假設(shè)每次read()都要從磁盤讀一個(gè)字節(jié)讀一個(gè)1MB的文件就要調(diào)用一百萬(wàn)次系統(tǒng)調(diào)用開(kāi)銷巨大。加了緩沖區(qū)后一次系統(tǒng)調(diào)用讀8KB默認(rèn)緩沖區(qū)大小到內(nèi)存后續(xù)的read()直接從內(nèi)存拿系統(tǒng)調(diào)用次數(shù)降到原來(lái)的八千分之一左右。這個(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é)議和文件格式可以無(wú)縫遷移。第三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è)問(wèn)題。除非你有明確的遺留系統(tǒng)對(duì)接需求否則沒(méi)有理由選GBK。提示StandardCharsets類里預(yù)定義了常用的字符集常量包括UTF_8、UTF_16、ISO_8859_1、US_ASCII等。用這些常量比用字符串名稱更安全因?yàn)槠磳戝e(cuò)誤在編譯期就能發(fā)現(xiàn)。4. 完整實(shí)操?gòu)奈募x寫到網(wǎng)絡(luò)傳輸?shù)霓D(zhuǎn)換流應(yīng)用4.1 場(chǎng)景一帶編碼指定的文本文件讀寫先看一個(gè)最基礎(chǔ)但最完整的例子——把一個(gè)UTF-8編碼的文件讀進(jìn)來(lái)轉(zhuǎn)成GBK編碼寫到另一個(gè)文件。這個(gè)場(chǎng)景在數(shù)據(jù)遷移時(shí)很常見(jiàn)。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é)值得說(shuō)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è)問(wèn)題在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é)議文檔里。我參與過(guò)的項(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ù)組里沒(méi)讀到的部分也寫出去。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 亂碼問(wèn)題排查速查表亂碼是轉(zhuǎn)換流相關(guān)問(wèn)題的絕對(duì)大頭。下面這張表整理了常見(jiàn)亂碼現(xiàn)象和對(duì)應(yīng)的排查方向現(xiàn)象可能原因排查方法中文變問(wè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è)方法很容易被誤用。它的語(yǔ)義是是否還有字符可以立即讀取而不阻塞而不是是否還有字符可讀。在網(wǎng)絡(luò)流場(chǎng)景下數(shù)據(jù)可能還沒(méi)到達(dá)ready()返回false但這不代表流結(jié)束了。如果你用while (reader.ready())來(lái)循環(huán)讀取可能會(huì)提前退出漏掉后面的數(shù)據(jù)。正確的做法是用read()返回-1來(lái)判斷流結(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è)問(wèn)題因?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è)問(wèn)題。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)閉多層反而可能出問(wè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 性能問(wèn)題什么時(shí)候該加緩沖如果你發(fā)現(xiàn)IO操作很慢第一反應(yīng)應(yīng)該是檢查有沒(méi)有加緩沖。逐字符讀寫不加緩沖性能會(huì)差幾十倍甚至上百倍。判斷標(biāo)準(zhǔn)很簡(jiǎn)單只要讀寫的數(shù)據(jù)量超過(guò)幾KB就應(yīng)該加BufferedReader/BufferedWriter。對(duì)于小數(shù)據(jù)量比如讀一個(gè)配置文件加不加差別不大但加了也沒(méi)壞處。另外緩沖區(qū)大小可以調(diào)整。默認(rèn)是8192字符對(duì)于特別大的文件可以適當(dāng)調(diào)大比如16384或32768。但也不是越大越好太大會(huì)占用過(guò)多內(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)換流的原理有助于排查這些框架里的編碼問(wè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即文件開(kāi)頭的三個(gè)字節(jié)EF BB BF。這個(gè)BOM在Windows記事本保存UTF-8文件時(shí)會(huì)自動(dòng)加上。用InputStreamReader讀取時(shí)BOM會(huì)被當(dāng)作一個(gè)特殊字符UFEFF讀進(jìn)來(lái)導(dǎo)致第一個(gè)字符異常。解決辦法是讀取后檢查并跳過(guò)BOM或者用BOMInputStreamApache Commons IO提供來(lái)包裝。// 手動(dòng)跳過(guò)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跳過(guò) } else { // 不是BOM推回去 pushback.unread(bom, 0, n); } InputStreamReader reader new InputStreamReader(pushback, StandardCharsets.UTF_8);這個(gè)問(wèn)題在處理用戶上傳的文件時(shí)特別常見(jiàn)因?yàn)橛脩艨赡苡酶鞣N編輯器保存文件有的帶BOM有的不帶。7. 我踩過(guò)的坑與實(shí)操心得說(shuō)幾個(gè)我在實(shí)際項(xiàng)目里踩過(guò)的坑都是文檔里不會(huì)寫的。第一個(gè)坑是測(cè)試環(huán)境和生產(chǎn)環(huán)境字符集不一致。有一次寫了個(gè)導(dǎo)出CSV的功能本地測(cè)試沒(méi)問(wèn)題上線后用戶反饋中文全是亂碼。排查發(fā)現(xiàn)本地JVM默認(rèn)字符集是UTF-8生產(chǎn)服務(wù)器是GBK而代碼里用了FileWriter沒(méi)指定字符集。后來(lái)改成OutputStreamWriter顯式指定UTF-8就好了。從那以后我寫任何涉及文本IO的代碼都強(qiáng)制指定字符集絕不依賴默認(rèn)值。第二個(gè)坑是忘記flush導(dǎo)致日志丟失。有次寫了個(gè)日志工具類用OutputStreamWriter寫日志文件程序正常退出時(shí)日志是全的但程序被kill時(shí)最后幾條日志就丟了。原因是緩沖區(qū)沒(méi)flush。后來(lái)改成每條日志寫完就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ī)范上字符集名稱是大小寫不敏感的。不過(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這類庫(kù)來(lái)檢測(cè)。它們通過(guò)分析字節(jié)序列的統(tǒng)計(jì)特征來(lái)猜測(cè)編碼準(zhǔn)確率還不錯(cuò)。對(duì)于用戶上傳的文件先檢測(cè)編碼再用對(duì)應(yīng)的InputStreamReader讀取能避免大部分亂碼問(wèn)題。// 用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();這套組合拳打下來(lái)基本上能覆蓋日常開(kāi)發(fā)中90%以上的字符編碼場(chǎng)景。轉(zhuǎn)換流這個(gè)知識(shí)點(diǎn)看起來(lái)簡(jiǎn)單但細(xì)節(jié)很多真正吃透需要在項(xiàng)目里多實(shí)踐、多踩坑。希望這篇內(nèi)容能幫你少走些彎路。 Java轉(zhuǎn)換流深度解析：InputStreamReader與OutputStreamWriter原理及亂碼解決
1. 字符與字節(jié)之間的那座橋?yàn)槭裁葱枰D(zhuǎn)換流剛?cè)胄心菚?huì)兒我對(duì)Java的IO體系是有點(diǎn)發(fā)怵的。字節(jié)流、字符流、緩沖流、轉(zhuǎn)換流名字聽(tīng)著都差不多用起來(lái)卻各有各的脾氣。尤其是碰到中文亂碼的時(shí)候整個(gè)人都是懵的——明明代碼邏輯沒(méi)問(wèn)題讀出來(lái)的東西卻是一堆問(wèn)號(hào)或者方塊。后來(lái)踩的坑多了才慢慢明白亂碼的根源十有八九出在字符編碼的轉(zhuǎn)換環(huán)節(jié)上而OutputStreamWriter和InputStreamReader這兩個(gè)類恰恰就是處理這個(gè)環(huán)節(jié)的關(guān)鍵角色。先說(shuō)清楚這兩個(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ù)指定的字符集來(lái)編碼和解碼。問(wèn)題在于很多時(shí)候我們手里拿到的是字節(jié)流比如網(wǎng)絡(luò)連接、文件系統(tǒng)、控制臺(tái)輸入輸出但業(yè)務(wù)邏輯需要按字符來(lái)處理比如讀寫文本、解析JSON、處理中文。這時(shí)候就需要一座橋把字節(jié)流包裝成字符流而InputStreamReader和OutputStreamWriter就是這座橋。具體來(lái)說(shuō)InputStreamReader繼承自Reader它接收一個(gè)字節(jié)輸入流按照指定的字符集把讀到的字節(jié)解碼成字符OutputStreamWriter繼承自Writer它接收一個(gè)字節(jié)輸出流按照指定的字符集把要寫的字符編碼成字節(jié)再輸出。你可以把它們理解成翻譯官——字節(jié)流說(shuō)的是字節(jié)語(yǔ)字符流說(shuō)的是字符語(yǔ)轉(zhuǎn)換流負(fù)責(zé)在兩者之間做同聲傳譯。翻譯得好不好取決于你告訴它用哪本字典字符集。這兩個(gè)類解決的核心問(wèn)題就一個(gè)讓字節(jié)和字符之間的轉(zhuǎn)換變得可控、可指定、可預(yù)期。如果你不指定字符集它們會(huì)用平臺(tái)默認(rèn)的字符集這在跨平臺(tái)場(chǎng)景下就是個(gè)定時(shí)炸彈——開(kāi)發(fā)機(jī)上是UTF-8服務(wù)器上是GBK同樣的代碼跑出來(lái)的結(jié)果天差地別。所以凡是用到轉(zhuǎn)換流的地方顯式指定字符集應(yīng)該成為肌肉記憶。這篇文章適合誰(shuí)看如果你正在學(xué)Java IO被各種流繞得頭暈或者你在實(shí)際項(xiàng)目里遇到過(guò)亂碼問(wèn)題想搞清楚背后的原理又或者你寫代碼時(shí)習(xí)慣性地用FileReader/FileWriter但不知道它們其實(shí)內(nèi)部就是轉(zhuǎn)換流的簡(jiǎn)化版——那這篇內(nèi)容應(yīng)該能幫你把這塊知識(shí)理順。我會(huì)從設(shè)計(jì)思路、核心原理、實(shí)操代碼、常見(jiàn)坑幾個(gè)維度展開(kāi)盡量把每個(gè)為什么都講透。2. 轉(zhuǎn)換流的設(shè)計(jì)哲學(xué)與核心原理拆解2.1 適配器模式不只是包裝那么簡(jiǎn)單InputStreamReader和OutputStreamWriter在設(shè)計(jì)模式上屬于典型的適配器模式Adapter Pattern。適配器的核心思想是把一個(gè)類的接口轉(zhuǎn)換成客戶端期望的另一個(gè)接口讓原本因?yàn)榻涌诓患嫒荻鵁o(wú)法一起工作的類可以協(xié)同工作。在這里不兼容體現(xiàn)在字節(jié)流和字符流的抽象層級(jí)不同——字節(jié)流的最小單位是byte字符流的最小單位是char而一個(gè)char在不同編碼下對(duì)應(yīng)的字節(jié)數(shù)是不一樣的。拿UTF-8來(lái)說(shuō)一個(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é)本身沒(méi)有字符邊界的概念。InputStreamReader要做的就是根據(jù)指定的字符集判斷讀到幾個(gè)字節(jié)了夠不夠組成一個(gè)完整字符夠了就解碼輸出一個(gè)char不夠就繼續(xù)讀。這個(gè)過(guò)程叫解碼decode。反過(guò)來(lái)OutputStreamWriter拿到的是char它要根據(jù)字符集把char編碼成對(duì)應(yīng)的字節(jié)序列再寫出去。這個(gè)過(guò)程叫編碼encode。編碼相對(duì)簡(jiǎn)單因?yàn)槊總€(gè)char都是完整的直接查表轉(zhuǎn)換就行解碼就麻煩一些因?yàn)樽止?jié)流是連續(xù)的你需要處理半個(gè)字符的情況——比如一次只讀到了某個(gè)中文字符的前兩個(gè)字節(jié)第三個(gè)字節(jié)還沒(méi)到這時(shí)候不能急著解碼得緩存起來(lái)等后續(xù)字節(jié)。注意轉(zhuǎn)換流內(nèi)部維護(hù)了一個(gè)字節(jié)緩沖區(qū)StreamDecoder/StreamEncoder內(nèi)部有ByteBuffer用來(lái)處理跨讀取邊界的多字節(jié)字符。這也是為什么轉(zhuǎn)換流的read()方法可能返回0表示還沒(méi)湊夠一個(gè)完整字符而普通字節(jié)流的read()返回0只表示讀到了空數(shù)據(jù)。2.2 字符集的本質(zhì)一張映射表加一套編解碼規(guī)則要理解轉(zhuǎn)換流繞不開(kāi)字符集。很多人對(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)沒(méi)規(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è)便利類它們看起來(lái)用起來(lái)更簡(jiǎn)單一行代碼就能讀文件。但它們的致命缺陷是不能指定字符集。FileReader的源碼里構(gòu)造函數(shù)最終調(diào)用的是new InputStreamReader(new FileInputStream(file))沒(méi)有傳字符集參數(shù)所以用的是平臺(tái)默認(rèn)字符集。這意味著什么你的程序在開(kāi)發(fā)機(jī)上UTF-8跑得好好的部署到服務(wù)器上GBK讀同一個(gè)文件中文全變亂碼。而且這個(gè)問(wèn)題很隱蔽因?yàn)殚_(kāi)發(fā)階段往往發(fā)現(xiàn)不了。所以但凡涉及文本文件讀寫尤其是可能包含中文的場(chǎng)景我都建議直接用InputStreamReader/OutputStreamWriter包裝FileInputStream/FileOutputStream顯式指定UTF-8。// 不推薦無(wú)法指定字符集 FileReader fileReader new FileReader(data.txt); // 推薦顯式指定字符集 InputStreamReader reader new InputStreamReader( new FileInputStream(data.txt), StandardCharsets.UTF_8);這個(gè)替換成本極低但能避免大量跨平臺(tái)亂碼問(wèn)題。我在實(shí)際項(xiàng)目里見(jiàn)過(guò)太多次因?yàn)橛昧薋ileReader導(dǎo)致線上亂碼的案例排查起來(lái)還挺費(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ù)說(shuō)明適用場(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è)方法的語(yǔ)義容易誤解后面會(huì)講這里有個(gè)容易踩的坑read()返回的是字符的Unicode碼點(diǎn)準(zhǔn)確說(shuō)是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ù)說(shuō)明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è)Q行符的麻煩。為什么緩沖能提升性能因?yàn)榇疟PIO和網(wǎng)絡(luò)IO的速度遠(yuǎn)低于內(nèi)存操作。假設(shè)每次read()都要從磁盤讀一個(gè)字節(jié)讀一個(gè)1MB的文件就要調(diào)用一百萬(wàn)次系統(tǒng)調(diào)用開(kāi)銷巨大。加了緩沖區(qū)后一次系統(tǒng)調(diào)用讀8KB默認(rèn)緩沖區(qū)大小到內(nèi)存后續(xù)的read()直接從內(nèi)存拿系統(tǒng)調(diào)用次數(shù)降到原來(lái)的八千分之一左右。這個(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é)議和文件格式可以無(wú)縫遷移。第三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è)問(wèn)題。除非你有明確的遺留系統(tǒng)對(duì)接需求否則沒(méi)有理由選GBK。提示StandardCharsets類里預(yù)定義了常用的字符集常量包括UTF_8、UTF_16、ISO_8859_1、US_ASCII等。用這些常量比用字符串名稱更安全因?yàn)槠磳戝e(cuò)誤在編譯期就能發(fā)現(xiàn)。4. 完整實(shí)操?gòu)奈募x寫到網(wǎng)絡(luò)傳輸?shù)霓D(zhuǎn)換流應(yīng)用4.1 場(chǎng)景一帶編碼指定的文本文件讀寫先看一個(gè)最基礎(chǔ)但最完整的例子——把一個(gè)UTF-8編碼的文件讀進(jìn)來(lái)轉(zhuǎn)成GBK編碼寫到另一個(gè)文件。這個(gè)場(chǎng)景在數(shù)據(jù)遷移時(shí)很常見(jiàn)。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é)值得說(shuō)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è)問(wèn)題在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é)議文檔里。我參與過(guò)的項(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ù)組里沒(méi)讀到的部分也寫出去。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 亂碼問(wèn)題排查速查表亂碼是轉(zhuǎn)換流相關(guān)問(wèn)題的絕對(duì)大頭。下面這張表整理了常見(jiàn)亂碼現(xiàn)象和對(duì)應(yīng)的排查方向現(xiàn)象可能原因排查方法中文變問(wè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è)方法很容易被誤用。它的語(yǔ)義是是否還有字符可以立即讀取而不阻塞而不是是否還有字符可讀。在網(wǎng)絡(luò)流場(chǎng)景下數(shù)據(jù)可能還沒(méi)到達(dá)ready()返回false但這不代表流結(jié)束了。如果你用while (reader.ready())來(lái)循環(huán)讀取可能會(huì)提前退出漏掉后面的數(shù)據(jù)。正確的做法是用read()返回-1來(lái)判斷流結(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è)問(wèn)題因?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è)問(wèn)題。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)閉多層反而可能出問(wè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 性能問(wèn)題什么時(shí)候該加緩沖如果你發(fā)現(xiàn)IO操作很慢第一反應(yīng)應(yīng)該是檢查有沒(méi)有加緩沖。逐字符讀寫不加緩沖性能會(huì)差幾十倍甚至上百倍。判斷標(biāo)準(zhǔn)很簡(jiǎn)單只要讀寫的數(shù)據(jù)量超過(guò)幾KB就應(yīng)該加BufferedReader/BufferedWriter。對(duì)于小數(shù)據(jù)量比如讀一個(gè)配置文件加不加差別不大但加了也沒(méi)壞處。另外緩沖區(qū)大小可以調(diào)整。默認(rèn)是8192字符對(duì)于特別大的文件可以適當(dāng)調(diào)大比如16384或32768。但也不是越大越好太大會(huì)占用過(guò)多內(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)換流的原理有助于排查這些框架里的編碼問(wè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即文件開(kāi)頭的三個(gè)字節(jié)EF BB BF。這個(gè)BOM在Windows記事本保存UTF-8文件時(shí)會(huì)自動(dòng)加上。用InputStreamReader讀取時(shí)BOM會(huì)被當(dāng)作一個(gè)特殊字符UFEFF讀進(jìn)來(lái)導(dǎo)致第一個(gè)字符異常。解決辦法是讀取后檢查并跳過(guò)BOM或者用BOMInputStreamApache Commons IO提供來(lái)包裝。// 手動(dòng)跳過(guò)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跳過(guò) } else { // 不是BOM推回去 pushback.unread(bom, 0, n); } InputStreamReader reader new InputStreamReader(pushback, StandardCharsets.UTF_8);這個(gè)問(wèn)題在處理用戶上傳的文件時(shí)特別常見(jiàn)因?yàn)橛脩艨赡苡酶鞣N編輯器保存文件有的帶BOM有的不帶。7. 我踩過(guò)的坑與實(shí)操心得說(shuō)幾個(gè)我在實(shí)際項(xiàng)目里踩過(guò)的坑都是文檔里不會(huì)寫的。第一個(gè)坑是測(cè)試環(huán)境和生產(chǎn)環(huán)境字符集不一致。有一次寫了個(gè)導(dǎo)出CSV的功能本地測(cè)試沒(méi)問(wèn)題上線后用戶反饋中文全是亂碼。排查發(fā)現(xiàn)本地JVM默認(rèn)字符集是UTF-8生產(chǎn)服務(wù)器是GBK而代碼里用了FileWriter沒(méi)指定字符集。后來(lái)改成OutputStreamWriter顯式指定UTF-8就好了。從那以后我寫任何涉及文本IO的代碼都強(qiáng)制指定字符集絕不依賴默認(rèn)值。第二個(gè)坑是忘記flush導(dǎo)致日志丟失。有次寫了個(gè)日志工具類用OutputStreamWriter寫日志文件程序正常退出時(shí)日志是全的但程序被kill時(shí)最后幾條日志就丟了。原因是緩沖區(qū)沒(méi)flush。后來(lái)改成每條日志寫完就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ī)范上字符集名稱是大小寫不敏感的。不過(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這類庫(kù)來(lái)檢測(cè)。它們通過(guò)分析字節(jié)序列的統(tǒng)計(jì)特征來(lái)猜測(cè)編碼準(zhǔn)確率還不錯(cuò)。對(duì)于用戶上傳的文件先檢測(cè)編碼再用對(duì)應(yīng)的InputStreamReader讀取能避免大部分亂碼問(wèn)題。// 用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();這套組合拳打下來(lái)基本上能覆蓋日常開(kāi)發(fā)中90%以上的字符編碼場(chǎng)景。轉(zhuǎn)換流這個(gè)知識(shí)點(diǎn)看起來(lái)簡(jiǎn)單但細(xì)節(jié)很多真正吃透需要在項(xiàng)目里多實(shí)踐、多踩坑。希望這篇內(nèi)容能幫你少走些彎路。