C语言是否应始终以二进制模式打开文件（含文本文件）？

这个问题戳中了C语言文件操作里很容易被忽略的细节——“始终用二进制模式”的核心逻辑，其实是把文件操作的控制权完全攥在自己手里，避免标准库在后台偷偷做你没预料到的转换。下面具体拆解原因：

• 文本模式的隐式转换可能暗坑不断
  不同操作系统对文本文件的换行符、EOF标记处理差异极大：

  • 在Windows下，文本模式会自动把写入的\n转换成\r\n，读取时又把\r\n转回\n。如果你的“文本文件”里藏着二进制数据（比如带BOM的UTF-8文件、混了二进制标识的日志），这种转换会直接破坏字节结构；更坑的是，文本模式会把文件中的0x1A（Ctrl-Z）当作EOF，哪怕后面还有有效内容，直接导致读取不完整。
  • 而在Linux/macOS上，文本模式和二进制模式几乎没有区别，这就导致同一份代码在不同平台上行为不一致，排查起来特别头疼。

• 二进制模式带来跨平台一致性
  用二进制模式打开文件时，系统会原封不动地读取/写入磁盘上的每一个字节，完全不做额外转换。你可以自己实现换行符的处理逻辑（比如写个小函数，把统一的\n转换成目标平台的\r\n或者保留\n），这样不管代码跑在Windows、Linux还是macOS上，行为都是可预测的，不会出现“本地正常，部署到服务器就乱码”的情况。

• 避免对“文本文件”的误判
  很多时候你以为是纯文本的文件，其实可能藏着二进制内容：比如某些编辑器保存UTF-8文件时会自动加上BOM（0xEFBBBF），或者用户误把二进制文件（比如编译后的可执行文件）当成文本文件交给程序处理。用二进制模式打开的话，你可以先读取文件头几个字节判断实际类型，再决定后续处理逻辑；如果用文本模式，这些字节可能已经被转换，导致判断出错。

当然，如果你的程序只在单一平台运行，而且明确处理的是纯文本文件，文本模式用起来也没问题。但从代码健壮性和可移植性的角度来说，二进制模式是更稳妥的选择——毕竟自己掌控所有转换逻辑，比依赖标准库的隐式行为要靠谱得多。

内容的提问来源于stack exchange，提问作者tvaz