上传一份TXT文件，打开后第一行变成几个问号或方块，下面内容却正常显示，这种情形在网站维护中并不少见。有人以为是文件损坏，重新上传一遍仍然如此；也有人直接把整份文件转成另一种编码，结果乱码从首行扩散到全文。首行乱码和全文乱码指向的原因并不相同，前者往往集中在文件开头那几个字节上，后者才更可能是整体编码判断错误。把这两类现象分开看，核对范围会小很多。
先核对文件是否带BOM。BOM是部分编码方案在文件开头写入的标记字节，用来提示读取方这是什么编码。带BOM的UTF-8文件，开头会有三个特定字节；如果读取程序没有识别这个标记，而是把它当成正文内容，首行就会出现异常字符。判断方法很直接：用十六进制查看工具打开文件，看前三个字节是否为EF BB BF。如果是，而页面首行恰好从第四个字节之后才开始正常，基本可以确定问题出在BOM识别环节。反过来，文件本身没有BOM，读取方却按带BOM处理，也可能吞掉首行的头几个字符。
再核对服务端读取时使用的默认编码。很多运行环境在读取文本文件时有一个默认编码，如果代码里没有显式指定，就会按这个默认值解析。文件实际是UTF-8，默认却按其他编码读取，首行的中文或特殊符号最容易先出问题。同时要确认读取逻辑是否依赖浏览器端的编码声明。浏览器声明只能影响展示阶段，不能替代服务端的解析决定。若服务端已按错误编码读入并转成字符串，前端再声明什么编码都难以还原。
第三层是转码环节是否存在二次编码。常见情况是文件先被按A编码读入，又被按B编码写出，中间没有做正确的字符映射。核对时可以取文件首行的一小段内容做样本，分别用两种候选编码读取，比较哪一种能得到可读文本。样本要包含首行的中文、标点和数字，长度不必多，十几到几十个字符即可。对比结果记录下来，能快速排除猜测。
整理成检查清单，顺序可以是：先看文件头字节判断有无BOM，再确认服务端读取代码是否显式指定编码，然后检查是否存在读入后再次转码的步骤，最后用首行小样本做两种编码的对比验证。回退策略上，探测失败时不要静默按默认编码硬读，应记录文件标识、探测结果和实际采用编码，便于后续追溯。日志里保留原始字节片段和解析后的首行内容，比只记一句读取失败更有用。
长期看，编码问题靠临时改一处代码难以根治。更稳妥的做法是在上传环节就做编码探测，把探测结果随文件一起保存，读取时优先使用记录值，缺失时再走回退逻辑。it数运在网站维护中处理这类问题时，习惯把文件头检查、读取编码确认和转码链路核对分开记录，让每一次乱码都有据可查，而不是反复试错。
