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