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 用\n（LF），Windows 用\r\n（CRLF）。文本模式在 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.readString（Java 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 Python：str 与 bytes 的泾渭分明
Python 3 在这一点上做得非常彻底，str和bytes是两种完全不同的类型，不能隐式转换。open()函数默认是文本模式，返回str；加上'b'参数就是二进制模式，返回bytes。
# 文本模式，指定编码 with open('data.txt', 'r', encoding='utf-8') as f: text = f.read() # str # 二进制模式 with open('image.png', 'rb') as f: data = f.read() # bytesPython 里最常见的错误是UnicodeDecodeError，本质就是用错误的编码去解码字节。解决办法要么是显式指定正确的encoding，要么在确实无法确定编码时用errors='replace'或errors='ignore'兜底（但这会丢数据，慎用）。我个人的习惯是：读任何文本文件都显式写encoding='utf-8'，绝不依赖默认值，因为不同操作系统的默认编码不一样，依赖默认值就是在给自己埋雷。
4.3 前端 JavaScript：ArrayBuffer 与 TextDecoder
在浏览器和 Node.js 环境里，二进制数据用ArrayBuffer或Buffer（Node.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 AD，GBK 下是D6 D0。看到字节就能反推编码，比盲目试各种编码快得多。
7.4 跨平台传输的统一约定
团队协作时，最好约定统一的编码规范：所有文本文件一律 UTF-8 无 BOM，换行符统一用 LF，二进制文件传输前做 Base64 或走二进制协议。把这些写进项目的开发规范里，能避免大量"在我机器上是好的"这类扯皮。
我在现在的项目里就是这么做的，配置文件、代码文件、文档全部 UTF-8，Git 配置里设置core.autocrlf处理换行符，文件上传下载接口统一走二进制流。这套约定执行下来，编码相关的 bug 几乎绝迹了。
8. 把这件事讲清楚之后我的一点体会
回过头看，文本模式和二进制模式的区别，本质上是一个"抽象层次"的问题。二进制模式贴近硬件，处理的是原始字节，简单直接但需要你自己理解数据结构；文本模式在字节之上加了一层字符编码的抽象，用起来方便，但你必须理解这层抽象的工作原理，否则就会被它反噬。
我现在的习惯是：默认用二进制模式思考，只在确认处理的是纯文本时才切换到文本模式，并且一定显式指定编码。这个思维顺序的调整，让我少踩了很多坑。因为二进制模式是"安全"的默认值，它不会自作主张地改动你的数据；而文本模式的便利是有代价的，你得清楚这个代价是什么。
最后分享一个小技巧：如果你不确定一个文件该用哪种模式处理，就先用二进制模式读前几十个字节，看看能不能用 UTF-8 正常解码成可读文字。能，就是文本文件；不能，就是二进制文件。这个判断方法简单粗暴，但在我实际工作中屡试不爽。
