1. 从一个让我加班到凌晨的乱码事故说起几年前我接手过一个数据导出模块需求很简单把数据库里的用户信息导成 CSV 文件再提供一个上传入口让运营同学把处理好的文件传回来。本地开发环境跑得顺风顺水测试同学也没报问题结果上线第二天运营就炸了——上传回来的文件里用户昵称中的中文全变成了问号金额字段偶尔还会多出几个莫名其妙的字符。我盯着日志查了大半天最后发现问题根本不在业务逻辑而在于我用FileReader读文件时没指定编码而写文件时用的是默认的文本模式。这个坑让我第一次真正意识到文件流里文本模式和二进制模式的区别不是教科书上的概念题而是会直接导致线上事故的实战问题。这篇文章就围绕这个主题展开。我会把文件流中文本模式与二进制模式的底层差异讲透包括它们各自在什么场景下该用、为什么会出现乱码和文件损坏、编码在其中扮演什么角色以及结合当下常见的MultipartFile与 Base64 流互转场景给出可直接落地的代码方案。不管你是刚接触 IO 的新手还是写过不少业务代码但一直没深究过这块的老手读完应该都能对什么时候该用哪种模式有一个清晰的判断标准。关键词里提到的文件流、文本模式、二进制模式以及热搜词里的multipartfile 和 base64 流文件互转本质上都指向同一个核心问题数据在字节和字符之间如何正确转换。把这个转换过程搞明白很多看似玄学的乱码、文件损坏、图片打不开的问题都会迎刃而解。2. 文本模式与二进制模式到底差在哪一层2.1 一个生活化类比翻译官和搬运工要理解这两种模式我习惯用这样一个类比。二进制模式就像一个搬运工你给它什么字节它就原封不动地搬进去或搬出来一个字节都不改。文本模式则像一个翻译官它在搬运的过程中会理解内容按照某种规则也就是编码把字节翻译成字符或者把字符翻译成字节中间还可能做一些额外的处理比如换行符的转换。这个额外的处理是很多人忽略的关键点。在 Windows 平台上文本模式写入时会把\n自动转换成\r\n读取时又会把\r\n还原成\n。这个设计在纯文本场景下没问题但如果你用文本模式去读写一张图片或者一个压缩包这个自动转换就会破坏原始数据导致文件彻底损坏。这就是为什么处理非文本文件必须用二进制模式的根本原因。2.2 字节与字符两个世界的边界从计算机的视角看文件在磁盘上永远是一串字节没有文本文件和二进制文件的本质区别这个区分是人为的。所谓文本文件只是说这串字节恰好能按照某种字符编码规则被解释成人类可读的字符而二进制文件则是这串字节按照字符编码解释会得到乱码但它有自己的结构规范比如 PNG 有文件头、JPEG 有特定的标记段。所以文本模式和二进制模式的真正差异在于程序是否在读写过程中引入了字符编码这一层抽象。二进制模式工作在字节层面读写的最小单位是 byte文本模式工作在字符层面读写的最小单位是 char中间必须经过一次编码或解码。这个抽象层带来了便利也带来了风险——一旦编码和解码用的规则不一致就会出现乱码。2.3 编码文本模式绕不开的那道坎既然文本模式要经过编码转换那编码规则的选择就成了决定成败的关键。常见的编码有 UTF-8、GBK、ISO-8859-1、UTF-16 等。UTF-8 是目前最通用的一个中文字符通常占 3 个字节GBK 是中文环境的老牌编码一个中文字符占 2 个字节ISO-8859-1 是单字节编码只能表示 256 个字符中文根本表示不了。乱码的本质就是用 A 编码写入、用 B 编码读取。比如你用 UTF-8 写了一个中字3 个字节读取时却按 GBK 解析GBK 按 2 字节一组那这 3 个字节就会被错误地拆成 1.5 个字符结果自然是一堆问号或方块。理解了这一点你就明白为什么指定编码这件事在文本模式里如此重要。对比维度文本模式二进制模式读写单位字符char字节byte是否涉及编码是必须指定或使用默认否原样读写换行符处理平台相关可能自动转换不做任何转换适用场景纯文本、配置文件、日志图片、音视频、压缩包、序列化对象典型风险编码不一致导致乱码无编码问题但需自行处理结构3. 乱码和文件损坏是怎么一步步发生的3.1 编码不一致最常见的乱码源头我见过最多的乱码场景就是写入和读取用了不同的编码。举个具体的例子下面这段代码在 Windows 上跑读出来的中文大概率是乱码// 写入时用 UTF-8 try (Writer writer new FileWriter(data.txt)) { writer.write(你好世界); } // 读取时用默认编码Windows 上通常是 GBK try (Reader reader new FileReader(data.txt)) { int ch; while ((ch reader.read()) ! -1) { System.out.print((char) ch); } }问题出在FileWriter和FileReader这两个类上它们使用的是平台默认编码你没法直接指定。写的时候平台默认是 GBK读的时候也是 GBK看起来一致但如果你的字符串本身是 UTF-8 来源或者跨平台传输过就会出问题。正确做法是始终显式指定编码用InputStreamReader和OutputStreamWriter包一层try (Writer writer new OutputStreamWriter( new FileOutputStream(data.txt), StandardCharsets.UTF_8)) { writer.write(你好世界); } try (Reader reader new InputStreamReader( new FileInputStream(data.txt), StandardCharsets.UTF_8)) { // 读取逻辑 }3.2 换行符转换跨平台传输的隐形杀手换行符的问题更隐蔽。Linux 和 macOS 用\nLFWindows 用\r\nCRLF。文本模式在 Windows 上写入时会把\n变成\r\n读取时再变回来。这在纯文本场景下是贴心的但如果你把一个二进制文件比如一个序列化后的对象用文本模式写入里面的某个字节恰好是\n就会被悄悄改成两个字节文件结构直接被破坏。我踩过的一个真实坑是把一个 Base64 编码后的字符串用文本模式写入文件然后在另一台机器上用文本模式读取。Base64 本身是纯 ASCII理论上没问题但那个字符串里包含了换行符Base64 标准要求每 76 个字符换行结果在 Windows 上写入时换行符被转换读取回来再做 Base64 解码时就报错了。处理这类数据要么用二进制模式要么在写入前统一换行符规范。3.3 缓冲区与字节序容易被忽视的细节还有一个容易被忽视的点是字节序Endianness。UTF-16 编码有大小端之分如果写入和读取的字节序不一致同样会乱码。UTF-8 没有这个问题因为它是以字节为单位的变长编码不涉及字节序。这也是我推荐在绝大多数场景下优先用 UTF-8 的原因之一——它规避了字节序这个额外的复杂度。缓冲区的问题则体现在文本模式的 Reader/Writer 通常带有字符缓冲区如果你在写入后没有 flush 或 close数据可能还留在缓冲区里没落盘。二进制流的缓冲行为类似但因为不涉及编码转换出问题的概率相对低一些。养成用完即关的习惯try-with-resources能规避绝大多数这类问题。4. 不同语言里这两种模式的落地差异4.1 Java从 FileReader 到 Files 工具类Java 里文本模式和二进制模式的区分非常明确。字节流以InputStream/OutputStream为基类字符流以Reader/Writer为基类。新手最容易踩的坑就是混用比如用FileReader去读图片或者用FileInputStream去读文本却不处理编码。Java 7 之后引入的Files工具类让这件事简单了很多。Files.readAllBytes走的是二进制路径Files.readStringJava 11走的是文本路径且默认用 UTF-8。下面这个对比很能说明问题// 二进制读取得到原始字节 byte[] bytes Files.readAllBytes(Path.of(image.png)); // 文本读取得到字符串默认 UTF-8 String content Files.readString(Path.of(config.txt), StandardCharsets.UTF_8); // 文本写入指定编码 Files.writeString(Path.of(output.txt), 内容, StandardCharsets.UTF_8);我的经验是只要不是纯文本一律用readAllBytes或InputStream只要是纯文本优先用Files.readString并显式指定编码。这样能避开 90% 的编码坑。4.2 Pythonstr 与 bytes 的泾渭分明Python 3 在这一点上做得非常彻底str和bytes是两种完全不同的类型不能隐式转换。open()函数默认是文本模式返回str加上b参数就是二进制模式返回bytes。# 文本模式指定编码 with open(data.txt, r, encodingutf-8) as f: text f.read() # str # 二进制模式 with open(image.png, rb) as f: data f.read() # bytesPython 里最常见的错误是UnicodeDecodeError本质就是用错误的编码去解码字节。解决办法要么是显式指定正确的encoding要么在确实无法确定编码时用errorsreplace或errorsignore兜底但这会丢数据慎用。我个人的习惯是读任何文本文件都显式写encodingutf-8绝不依赖默认值因为不同操作系统的默认编码不一样依赖默认值就是在给自己埋雷。4.3 前端 JavaScriptArrayBuffer 与 TextDecoder在浏览器和 Node.js 环境里二进制数据用ArrayBuffer或BufferNode.js表示文本用字符串表示。两者之间的转换需要显式调用TextDecoder或TextEncoder。// 字节转字符串 const decoder new TextDecoder(utf-8); const text decoder.decode(arrayBuffer); // 字符串转字节 const encoder new TextEncoder(); const bytes encoder.encode(你好);前端处理文件上传时FileReader提供了readAsText和readAsArrayBuffer两种方法分别对应文本模式和二进制模式。选错了方法图片就会读成一堆乱码字符串。这个选择逻辑和后端是完全一致的。5. MultipartFile 与 Base64 互转中的模式选择5.1 为什么这两个场景特别容易出问题热搜词里提到的MultipartFile和 Base64 流文件互转是文件流模式选择问题的高发区。原因在于这两个场景都涉及字节数据和字符串表示之间的来回转换而很多开发者习惯性地用文本模式去处理结果就是文件损坏或乱码。MultipartFile是 Spring 框架里处理文件上传的接口它底层持有的是文件的字节流。Base64 则是一种把二进制数据编码成 ASCII 字符串的方案常用于在 JSON、URL 或文本协议里传输文件。这两者互转的核心就是在字节和 Base64 字符串之间做正确的编解码中间任何一步用了文本模式且编码不对都会出问题。5.2 MultipartFile 转 Base64别用 Reader先看MultipartFile转 Base64 的场景。正确做法是拿到字节数组然后做 Base64 编码public String multipartFileToBase64(MultipartFile file) throws IOException { byte[] bytes file.getBytes(); // 二进制读取得到原始字节 return Base64.getEncoder().encodeToString(bytes); }这里file.getBytes()走的就是二进制路径拿到的是文件的原始字节。如果你图省事用new InputStreamReader(file.getInputStream())去读那就掉进文本模式的坑了——Reader 会尝试用默认编码把字节解释成字符对于图片、PDF 这类非文本文件这个解释过程会丢失或篡改数据最后 Base64 编码出来的字符串再解码回去文件就打不开了。注意MultipartFile.getBytes()会把整个文件加载到内存大文件场景要改用流式处理避免内存溢出。5.3 Base64 转 MultipartFile注意解码后的字节完整性反过来的场景把 Base64 字符串还原成文件同样要小心public MultipartFile base64ToMultipartFile(String base64, String fileName) { // 去掉可能存在的 data URI 前缀 String pureBase64 base64.contains(,) ? base64.substring(base64.indexOf(,) 1) : base64; byte[] bytes Base64.getDecoder().decode(pureBase64); return new MockMultipartFile(fileName, fileName, null, bytes); }这里的关键是Base64.getDecoder().decode()返回的是字节数组直接交给MockMultipartFile即可全程不涉及字符编码转换。如果你在中间用new String(bytes)转了一道那就引入了文本模式一旦编码不匹配字节就被破坏了。5.4 一个完整的互转工具类与踩坑记录把上面的逻辑整理成一个工具类方便直接抄作业public class FileStreamUtils { // MultipartFile - Base64 public static String toBase64(MultipartFile file) throws IOException { return Base64.getEncoder().encodeToString(file.getBytes()); } // Base64 - MultipartFile public static MultipartFile toMultipartFile(String base64, String fileName) { String pure base64.contains(,) ? base64.substring(base64.indexOf(,) 1) : base64; byte[] bytes Base64.getDecoder().decode(pure); return new MockMultipartFile(fileName, fileName, null, bytes); } // 大文件流式转 Base64避免内存溢出 public static String streamToBase64(InputStream inputStream) throws IOException { ByteArrayOutputStream buffer new ByteArrayOutputStream(); byte[] chunk new byte[8192]; int len; while ((len inputStream.read(chunk)) ! -1) { buffer.write(chunk, 0, len); } return Base64.getEncoder().encodeToString(buffer.toByteArray()); } }我踩过的一个坑是前端传来的 Base64 字符串带了data:image/png;base64,这样的前缀后端直接解码就报IllegalArgumentException。所以工具类里必须先判断并去掉前缀。另一个坑是 Base64 字符串里可能包含换行符某些库编码时会插入解码前最好先replaceAll(\\s, )清理一下空白字符。6. 选型决策什么场景该用哪种模式6.1 一张判断表帮你快速决策实际开发中判断该用哪种模式我总结了一个简单的决策流程。先问自己一个问题这个文件的内容我是否需要把它当作人类可读的文字来处理如果是用文本模式并指定编码如果不是用二进制模式。场景推荐模式理由读写配置文件、日志文本模式 UTF-8内容是可读文字需要编码转换读写 CSV、JSON、XML文本模式 UTF-8同上注意换行符规范上传下载图片、视频二进制模式非文本任何编码转换都会损坏数据文件复制、压缩解压二进制模式需要保证字节完全一致Base64 编解码二进制模式中间产物是字节不涉及字符序列化对象存储二进制模式结构数据编码转换会破坏结构6.2 那些看起来是文本的陷阱有些文件看起来是文本实际上处理时要格外小心。比如 CSV 文件它本身是文本但如果里面包含用户输入的换行符、逗号、引号就需要转义处理否则解析会错位。再比如 HTML 文件它声明了charset但如果你读取时用的编码和声明的不一致同样会乱码。还有一个经典陷阱是BOM字节顺序标记。Windows 上用记事本保存的 UTF-8 文件开头会多出三个字节EF BB BF。如果你用二进制模式读取这三个字节会原样出现在内容开头如果用文本模式且编码指定为 UTF-8某些语言的实现会自动跳过 BOM某些则不会。这个差异会导致同样的文件不同程序读出来开头多个怪字符的现象。处理办法是读取后判断并去除 BOM或者统一要求文件不带 BOM。6.3 性能与内存的权衡从性能角度看二进制模式通常比文本模式快因为它少了一层编码转换。但差异在大多数业务场景下可以忽略除非你在处理超大文件。真正需要关注的是内存文本模式如果一次性read()整个文件会把所有字符加载到内存二进制模式如果一次性readAllBytes()同样会占用大量内存。对于大文件无论哪种模式都应该用流式处理分块读写。文本模式用BufferedReader按行读二进制模式用固定大小的字节数组循环读。我在处理几百 MB 的日志文件时用的就是BufferedReader逐行读内存占用稳定在几十 MB完全不会 OOM。7. 几个我反复踩过才记住的实操要点7.1 永远显式指定编码别信默认值这是我用血泪换来的第一条铁律。FileReader、new String(bytes)、getBytes()这些不带编码参数的方法用的都是平台默认编码而平台默认编码在不同操作系统、不同 JDK 版本、甚至不同启动参数下都可能不一样。你的代码在开发机上跑得好好的部署到服务器就乱码十有八九就是这个原因。正确姿势是所有涉及编码转换的地方都显式传入StandardCharsets.UTF_8。多打几个字省下的是几个小时的排查时间。7.2 二进制数据绝不经过 String第二条铁律任何二进制数据图片、音频、加密后的密文、序列化字节都不要用String中转。String是字符序列把字节数组转成String再转回来中间必然经过一次编码和解码只要编码不是无损的比如 ISO-8859-1 是单字节无损的但 UTF-8 对任意字节序列不一定无损数据就会损坏。如果确实需要在文本协议里传输二进制数据用 Base64 或 Hex 编码它们是专门为这个目的设计的能保证无损。7.3 排查乱码的通用思路遇到乱码时别急着改代码先按这个顺序排查第一确认原始数据是用什么编码写入的第二确认读取时用的是什么编码第三确认中间有没有经过文本模式转换。三步定位下来问题基本就清楚了。一个实用技巧是用十六进制工具查看文件的原始字节。比如一个中字UTF-8 下是E4 B8 ADGBK 下是D6 D0。看到字节就能反推编码比盲目试各种编码快得多。7.4 跨平台传输的统一约定团队协作时最好约定统一的编码规范所有文本文件一律 UTF-8 无 BOM换行符统一用 LF二进制文件传输前做 Base64 或走二进制协议。把这些写进项目的开发规范里能避免大量在我机器上是好的这类扯皮。我在现在的项目里就是这么做的配置文件、代码文件、文档全部 UTF-8Git 配置里设置core.autocrlf处理换行符文件上传下载接口统一走二进制流。这套约定执行下来编码相关的 bug 几乎绝迹了。8. 把这件事讲清楚之后我的一点体会回过头看文本模式和二进制模式的区别本质上是一个抽象层次的问题。二进制模式贴近硬件处理的是原始字节简单直接但需要你自己理解数据结构文本模式在字节之上加了一层字符编码的抽象用起来方便但你必须理解这层抽象的工作原理否则就会被它反噬。我现在的习惯是默认用二进制模式思考只在确认处理的是纯文本时才切换到文本模式并且一定显式指定编码。这个思维顺序的调整让我少踩了很多坑。因为二进制模式是安全的默认值它不会自作主张地改动你的数据而文本模式的便利是有代价的你得清楚这个代价是什么。最后分享一个小技巧如果你不确定一个文件该用哪种模式处理就先用二进制模式读前几十个字节看看能不能用 UTF-8 正常解码成可读文字。能就是文本文件不能就是二进制文件。这个判断方法简单粗暴但在我实际工作中屡试不爽。 文件流文本模式与二进制模式：从乱码事故到MultipartFile与Base64互转实战
1. 从一个让我加班到凌晨的乱码事故说起几年前我接手过一个数据导出模块需求很简单把数据库里的用户信息导成 CSV 文件再提供一个上传入口让运营同学把处理好的文件传回来。本地开发环境跑得顺风顺水测试同学也没报问题结果上线第二天运营就炸了——上传回来的文件里用户昵称中的中文全变成了问号金额字段偶尔还会多出几个莫名其妙的字符。我盯着日志查了大半天最后发现问题根本不在业务逻辑而在于我用FileReader读文件时没指定编码而写文件时用的是默认的文本模式。这个坑让我第一次真正意识到文件流里文本模式和二进制模式的区别不是教科书上的概念题而是会直接导致线上事故的实战问题。这篇文章就围绕这个主题展开。我会把文件流中文本模式与二进制模式的底层差异讲透包括它们各自在什么场景下该用、为什么会出现乱码和文件损坏、编码在其中扮演什么角色以及结合当下常见的MultipartFile与 Base64 流互转场景给出可直接落地的代码方案。不管你是刚接触 IO 的新手还是写过不少业务代码但一直没深究过这块的老手读完应该都能对什么时候该用哪种模式有一个清晰的判断标准。关键词里提到的文件流、文本模式、二进制模式以及热搜词里的multipartfile 和 base64 流文件互转本质上都指向同一个核心问题数据在字节和字符之间如何正确转换。把这个转换过程搞明白很多看似玄学的乱码、文件损坏、图片打不开的问题都会迎刃而解。2. 文本模式与二进制模式到底差在哪一层2.1 一个生活化类比翻译官和搬运工要理解这两种模式我习惯用这样一个类比。二进制模式就像一个搬运工你给它什么字节它就原封不动地搬进去或搬出来一个字节都不改。文本模式则像一个翻译官它在搬运的过程中会理解内容按照某种规则也就是编码把字节翻译成字符或者把字符翻译成字节中间还可能做一些额外的处理比如换行符的转换。这个额外的处理是很多人忽略的关键点。在 Windows 平台上文本模式写入时会把\n自动转换成\r\n读取时又会把\r\n还原成\n。这个设计在纯文本场景下没问题但如果你用文本模式去读写一张图片或者一个压缩包这个自动转换就会破坏原始数据导致文件彻底损坏。这就是为什么处理非文本文件必须用二进制模式的根本原因。2.2 字节与字符两个世界的边界从计算机的视角看文件在磁盘上永远是一串字节没有文本文件和二进制文件的本质区别这个区分是人为的。所谓文本文件只是说这串字节恰好能按照某种字符编码规则被解释成人类可读的字符而二进制文件则是这串字节按照字符编码解释会得到乱码但它有自己的结构规范比如 PNG 有文件头、JPEG 有特定的标记段。所以文本模式和二进制模式的真正差异在于程序是否在读写过程中引入了字符编码这一层抽象。二进制模式工作在字节层面读写的最小单位是 byte文本模式工作在字符层面读写的最小单位是 char中间必须经过一次编码或解码。这个抽象层带来了便利也带来了风险——一旦编码和解码用的规则不一致就会出现乱码。2.3 编码文本模式绕不开的那道坎既然文本模式要经过编码转换那编码规则的选择就成了决定成败的关键。常见的编码有 UTF-8、GBK、ISO-8859-1、UTF-16 等。UTF-8 是目前最通用的一个中文字符通常占 3 个字节GBK 是中文环境的老牌编码一个中文字符占 2 个字节ISO-8859-1 是单字节编码只能表示 256 个字符中文根本表示不了。乱码的本质就是用 A 编码写入、用 B 编码读取。比如你用 UTF-8 写了一个中字3 个字节读取时却按 GBK 解析GBK 按 2 字节一组那这 3 个字节就会被错误地拆成 1.5 个字符结果自然是一堆问号或方块。理解了这一点你就明白为什么指定编码这件事在文本模式里如此重要。对比维度文本模式二进制模式读写单位字符char字节byte是否涉及编码是必须指定或使用默认否原样读写换行符处理平台相关可能自动转换不做任何转换适用场景纯文本、配置文件、日志图片、音视频、压缩包、序列化对象典型风险编码不一致导致乱码无编码问题但需自行处理结构3. 乱码和文件损坏是怎么一步步发生的3.1 编码不一致最常见的乱码源头我见过最多的乱码场景就是写入和读取用了不同的编码。举个具体的例子下面这段代码在 Windows 上跑读出来的中文大概率是乱码// 写入时用 UTF-8 try (Writer writer new FileWriter(data.txt)) { writer.write(你好世界); } // 读取时用默认编码Windows 上通常是 GBK try (Reader reader new FileReader(data.txt)) { int ch; while ((ch reader.read()) ! -1) { System.out.print((char) ch); } }问题出在FileWriter和FileReader这两个类上它们使用的是平台默认编码你没法直接指定。写的时候平台默认是 GBK读的时候也是 GBK看起来一致但如果你的字符串本身是 UTF-8 来源或者跨平台传输过就会出问题。正确做法是始终显式指定编码用InputStreamReader和OutputStreamWriter包一层try (Writer writer new OutputStreamWriter( new FileOutputStream(data.txt), StandardCharsets.UTF_8)) { writer.write(你好世界); } try (Reader reader new InputStreamReader( new FileInputStream(data.txt), StandardCharsets.UTF_8)) { // 读取逻辑 }3.2 换行符转换跨平台传输的隐形杀手换行符的问题更隐蔽。Linux 和 macOS 用\nLFWindows 用\r\nCRLF。文本模式在 Windows 上写入时会把\n变成\r\n读取时再变回来。这在纯文本场景下是贴心的但如果你把一个二进制文件比如一个序列化后的对象用文本模式写入里面的某个字节恰好是\n就会被悄悄改成两个字节文件结构直接被破坏。我踩过的一个真实坑是把一个 Base64 编码后的字符串用文本模式写入文件然后在另一台机器上用文本模式读取。Base64 本身是纯 ASCII理论上没问题但那个字符串里包含了换行符Base64 标准要求每 76 个字符换行结果在 Windows 上写入时换行符被转换读取回来再做 Base64 解码时就报错了。处理这类数据要么用二进制模式要么在写入前统一换行符规范。3.3 缓冲区与字节序容易被忽视的细节还有一个容易被忽视的点是字节序Endianness。UTF-16 编码有大小端之分如果写入和读取的字节序不一致同样会乱码。UTF-8 没有这个问题因为它是以字节为单位的变长编码不涉及字节序。这也是我推荐在绝大多数场景下优先用 UTF-8 的原因之一——它规避了字节序这个额外的复杂度。缓冲区的问题则体现在文本模式的 Reader/Writer 通常带有字符缓冲区如果你在写入后没有 flush 或 close数据可能还留在缓冲区里没落盘。二进制流的缓冲行为类似但因为不涉及编码转换出问题的概率相对低一些。养成用完即关的习惯try-with-resources能规避绝大多数这类问题。4. 不同语言里这两种模式的落地差异4.1 Java从 FileReader 到 Files 工具类Java 里文本模式和二进制模式的区分非常明确。字节流以InputStream/OutputStream为基类字符流以Reader/Writer为基类。新手最容易踩的坑就是混用比如用FileReader去读图片或者用FileInputStream去读文本却不处理编码。Java 7 之后引入的Files工具类让这件事简单了很多。Files.readAllBytes走的是二进制路径Files.readStringJava 11走的是文本路径且默认用 UTF-8。下面这个对比很能说明问题// 二进制读取得到原始字节 byte[] bytes Files.readAllBytes(Path.of(image.png)); // 文本读取得到字符串默认 UTF-8 String content Files.readString(Path.of(config.txt), StandardCharsets.UTF_8); // 文本写入指定编码 Files.writeString(Path.of(output.txt), 内容, StandardCharsets.UTF_8);我的经验是只要不是纯文本一律用readAllBytes或InputStream只要是纯文本优先用Files.readString并显式指定编码。这样能避开 90% 的编码坑。4.2 Pythonstr 与 bytes 的泾渭分明Python 3 在这一点上做得非常彻底str和bytes是两种完全不同的类型不能隐式转换。open()函数默认是文本模式返回str加上b参数就是二进制模式返回bytes。# 文本模式指定编码 with open(data.txt, r, encodingutf-8) as f: text f.read() # str # 二进制模式 with open(image.png, rb) as f: data f.read() # bytesPython 里最常见的错误是UnicodeDecodeError本质就是用错误的编码去解码字节。解决办法要么是显式指定正确的encoding要么在确实无法确定编码时用errorsreplace或errorsignore兜底但这会丢数据慎用。我个人的习惯是读任何文本文件都显式写encodingutf-8绝不依赖默认值因为不同操作系统的默认编码不一样依赖默认值就是在给自己埋雷。4.3 前端 JavaScriptArrayBuffer 与 TextDecoder在浏览器和 Node.js 环境里二进制数据用ArrayBuffer或BufferNode.js表示文本用字符串表示。两者之间的转换需要显式调用TextDecoder或TextEncoder。// 字节转字符串 const decoder new TextDecoder(utf-8); const text decoder.decode(arrayBuffer); // 字符串转字节 const encoder new TextEncoder(); const bytes encoder.encode(你好);前端处理文件上传时FileReader提供了readAsText和readAsArrayBuffer两种方法分别对应文本模式和二进制模式。选错了方法图片就会读成一堆乱码字符串。这个选择逻辑和后端是完全一致的。5. MultipartFile 与 Base64 互转中的模式选择5.1 为什么这两个场景特别容易出问题热搜词里提到的MultipartFile和 Base64 流文件互转是文件流模式选择问题的高发区。原因在于这两个场景都涉及字节数据和字符串表示之间的来回转换而很多开发者习惯性地用文本模式去处理结果就是文件损坏或乱码。MultipartFile是 Spring 框架里处理文件上传的接口它底层持有的是文件的字节流。Base64 则是一种把二进制数据编码成 ASCII 字符串的方案常用于在 JSON、URL 或文本协议里传输文件。这两者互转的核心就是在字节和 Base64 字符串之间做正确的编解码中间任何一步用了文本模式且编码不对都会出问题。5.2 MultipartFile 转 Base64别用 Reader先看MultipartFile转 Base64 的场景。正确做法是拿到字节数组然后做 Base64 编码public String multipartFileToBase64(MultipartFile file) throws IOException { byte[] bytes file.getBytes(); // 二进制读取得到原始字节 return Base64.getEncoder().encodeToString(bytes); }这里file.getBytes()走的就是二进制路径拿到的是文件的原始字节。如果你图省事用new InputStreamReader(file.getInputStream())去读那就掉进文本模式的坑了——Reader 会尝试用默认编码把字节解释成字符对于图片、PDF 这类非文本文件这个解释过程会丢失或篡改数据最后 Base64 编码出来的字符串再解码回去文件就打不开了。注意MultipartFile.getBytes()会把整个文件加载到内存大文件场景要改用流式处理避免内存溢出。5.3 Base64 转 MultipartFile注意解码后的字节完整性反过来的场景把 Base64 字符串还原成文件同样要小心public MultipartFile base64ToMultipartFile(String base64, String fileName) { // 去掉可能存在的 data URI 前缀 String pureBase64 base64.contains(,) ? base64.substring(base64.indexOf(,) 1) : base64; byte[] bytes Base64.getDecoder().decode(pureBase64); return new MockMultipartFile(fileName, fileName, null, bytes); }这里的关键是Base64.getDecoder().decode()返回的是字节数组直接交给MockMultipartFile即可全程不涉及字符编码转换。如果你在中间用new String(bytes)转了一道那就引入了文本模式一旦编码不匹配字节就被破坏了。5.4 一个完整的互转工具类与踩坑记录把上面的逻辑整理成一个工具类方便直接抄作业public class FileStreamUtils { // MultipartFile - Base64 public static String toBase64(MultipartFile file) throws IOException { return Base64.getEncoder().encodeToString(file.getBytes()); } // Base64 - MultipartFile public static MultipartFile toMultipartFile(String base64, String fileName) { String pure base64.contains(,) ? base64.substring(base64.indexOf(,) 1) : base64; byte[] bytes Base64.getDecoder().decode(pure); return new MockMultipartFile(fileName, fileName, null, bytes); } // 大文件流式转 Base64避免内存溢出 public static String streamToBase64(InputStream inputStream) throws IOException { ByteArrayOutputStream buffer new ByteArrayOutputStream(); byte[] chunk new byte[8192]; int len; while ((len inputStream.read(chunk)) ! -1) { buffer.write(chunk, 0, len); } return Base64.getEncoder().encodeToString(buffer.toByteArray()); } }我踩过的一个坑是前端传来的 Base64 字符串带了data:image/png;base64,这样的前缀后端直接解码就报IllegalArgumentException。所以工具类里必须先判断并去掉前缀。另一个坑是 Base64 字符串里可能包含换行符某些库编码时会插入解码前最好先replaceAll(\\s, )清理一下空白字符。6. 选型决策什么场景该用哪种模式6.1 一张判断表帮你快速决策实际开发中判断该用哪种模式我总结了一个简单的决策流程。先问自己一个问题这个文件的内容我是否需要把它当作人类可读的文字来处理如果是用文本模式并指定编码如果不是用二进制模式。场景推荐模式理由读写配置文件、日志文本模式 UTF-8内容是可读文字需要编码转换读写 CSV、JSON、XML文本模式 UTF-8同上注意换行符规范上传下载图片、视频二进制模式非文本任何编码转换都会损坏数据文件复制、压缩解压二进制模式需要保证字节完全一致Base64 编解码二进制模式中间产物是字节不涉及字符序列化对象存储二进制模式结构数据编码转换会破坏结构6.2 那些看起来是文本的陷阱有些文件看起来是文本实际上处理时要格外小心。比如 CSV 文件它本身是文本但如果里面包含用户输入的换行符、逗号、引号就需要转义处理否则解析会错位。再比如 HTML 文件它声明了charset但如果你读取时用的编码和声明的不一致同样会乱码。还有一个经典陷阱是BOM字节顺序标记。Windows 上用记事本保存的 UTF-8 文件开头会多出三个字节EF BB BF。如果你用二进制模式读取这三个字节会原样出现在内容开头如果用文本模式且编码指定为 UTF-8某些语言的实现会自动跳过 BOM某些则不会。这个差异会导致同样的文件不同程序读出来开头多个怪字符的现象。处理办法是读取后判断并去除 BOM或者统一要求文件不带 BOM。6.3 性能与内存的权衡从性能角度看二进制模式通常比文本模式快因为它少了一层编码转换。但差异在大多数业务场景下可以忽略除非你在处理超大文件。真正需要关注的是内存文本模式如果一次性read()整个文件会把所有字符加载到内存二进制模式如果一次性readAllBytes()同样会占用大量内存。对于大文件无论哪种模式都应该用流式处理分块读写。文本模式用BufferedReader按行读二进制模式用固定大小的字节数组循环读。我在处理几百 MB 的日志文件时用的就是BufferedReader逐行读内存占用稳定在几十 MB完全不会 OOM。7. 几个我反复踩过才记住的实操要点7.1 永远显式指定编码别信默认值这是我用血泪换来的第一条铁律。FileReader、new String(bytes)、getBytes()这些不带编码参数的方法用的都是平台默认编码而平台默认编码在不同操作系统、不同 JDK 版本、甚至不同启动参数下都可能不一样。你的代码在开发机上跑得好好的部署到服务器就乱码十有八九就是这个原因。正确姿势是所有涉及编码转换的地方都显式传入StandardCharsets.UTF_8。多打几个字省下的是几个小时的排查时间。7.2 二进制数据绝不经过 String第二条铁律任何二进制数据图片、音频、加密后的密文、序列化字节都不要用String中转。String是字符序列把字节数组转成String再转回来中间必然经过一次编码和解码只要编码不是无损的比如 ISO-8859-1 是单字节无损的但 UTF-8 对任意字节序列不一定无损数据就会损坏。如果确实需要在文本协议里传输二进制数据用 Base64 或 Hex 编码它们是专门为这个目的设计的能保证无损。7.3 排查乱码的通用思路遇到乱码时别急着改代码先按这个顺序排查第一确认原始数据是用什么编码写入的第二确认读取时用的是什么编码第三确认中间有没有经过文本模式转换。三步定位下来问题基本就清楚了。一个实用技巧是用十六进制工具查看文件的原始字节。比如一个中字UTF-8 下是E4 B8 ADGBK 下是D6 D0。看到字节就能反推编码比盲目试各种编码快得多。7.4 跨平台传输的统一约定团队协作时最好约定统一的编码规范所有文本文件一律 UTF-8 无 BOM换行符统一用 LF二进制文件传输前做 Base64 或走二进制协议。把这些写进项目的开发规范里能避免大量在我机器上是好的这类扯皮。我在现在的项目里就是这么做的配置文件、代码文件、文档全部 UTF-8Git 配置里设置core.autocrlf处理换行符文件上传下载接口统一走二进制流。这套约定执行下来编码相关的 bug 几乎绝迹了。8. 把这件事讲清楚之后我的一点体会回过头看文本模式和二进制模式的区别本质上是一个抽象层次的问题。二进制模式贴近硬件处理的是原始字节简单直接但需要你自己理解数据结构文本模式在字节之上加了一层字符编码的抽象用起来方便但你必须理解这层抽象的工作原理否则就会被它反噬。我现在的习惯是默认用二进制模式思考只在确认处理的是纯文本时才切换到文本模式并且一定显式指定编码。这个思维顺序的调整让我少踩了很多坑。因为二进制模式是安全的默认值它不会自作主张地改动你的数据而文本模式的便利是有代价的你得清楚这个代价是什么。最后分享一个小技巧如果你不确定一个文件该用哪种模式处理就先用二进制模式读前几十个字节看看能不能用 UTF-8 正常解码成可读文字。能就是文本文件不能就是二进制文件。这个判断方法简单粗暴但在我实际工作中屡试不爽。