c语言如何读取txt文件/文件乱码根源藏在打开模式里

上周实训课赶数据处理程序，满脑子都是c语言如何读取txt文件，盯着编译器报错框整整两节课都没理顺逻辑，随手新建的文本文档存了几组设备参数，编译运行后控制台只蹦出来一堆方块乱码，当时整个人都闷得慌。

代码里照搬了网课里现成的fopen写法，文件路径写的桌面完整地址，循环fgetc逐字符读取，逻辑看着完全没有纰漏，调试断点跟着走，文件指针明明正常偏移，输出界面却没有半行正常文字。反复修改文件保存编码，把txt换成ANSI格式，运行之后乱码依旧存在，当时只觉得是编译器自带编码适配出了问题，重启软件重装环境折腾了半个钟头，半点好转都没有。

后来才反应过来，打开文件的参数直接决定读取效果，当初随手敲下"r"只读模式，压根没考虑文本和二进制文件的读取区分。实训同桌写的同功能程序可以正常读出全部文字，凑过去对照代码才发现对方用的是"rt"文本模式打开文件，自己的代码全程只用基础r模式读取，底层读写规则出现偏差，读取中文内容时字节解析错乱，屏幕上自然全是无法识别的方块符号。

改动文件打开参数之后，第一次运行程序终于跳出清晰的设备数值，不用再对着满屏乱码反复排查。后续试着用fgets整行读取文档内容，不用逐字符循环占用运行资源，处理几十行的参数文本速度快了不少。当时随手测试空白txt文件，程序不会弹出崩溃报错，文件指针读到文件末尾自动跳出循环，不用额外写判断语句兜底空文件。

电脑桌面还存着那次实训写的两份代码备份，一份满是乱码报错的原始版本，一份调整过打开模式的可用版本。两份文件放在同一文件夹，读取同一个原始txt文档，运行结果天差地别。原本以为txt文件读取只需要把控文件路径和读取循环，压根没在意打开模式的细微差别，就这一个不起眼的参数，直接卡住我大半节课的调试进度。

课间趴在实训桌前翻课本，课本里简单标注了rt和rb两种打开标识，没有细说中文文本读取的适配问题，自学的时候直接跳过这一小段文字，写代码时完全没有联想到编码读取的关联。要是课前稍微扫一眼课本里的文件打开参数说明，根本不用浪费那么多时间反复调试程序，对着控制台发呆的那段时间足够写完整套完整读取逻辑。

傍晚收拾实训设备的时候，重新运行改过参数的程序，屏幕上完整打印出txt里所有设备参数，没有一处乱码。指尖敲下回车运行程序的那一刻，忽然觉得之前钻牛角尖的调试过程格外没必要，明明只需要修改一个字符的文件打开标识，却绕了一大圈排查编译器、文件编码、循环逻辑这些无关问题。