后台传了一份TXT通知稿，网页打开后中文全变成方块和问号，英文数字却一点没事——这是不少网站维护人员都遇到过的场景。很多人的第一反应是文件传坏了，于是反复重传，结果每次都一样。TXT看似最简单，却最容易被误判成文件损坏。实际上，文件大概率完好无损，出问题的是编码与读取之间的那层约定。
先核对文件本身的字节编码
TXT不携带字体，也不携带排版，它只存字节。同样两个字“你好”，用UTF-8保存占六个字节，用GBK保存占四个字节，两种编码互不认识。判断方法并不复杂：用系统自带的文本编辑器打开原文件，查看“另存为”时的编码选项，或借助编辑器的编码识别功能切换几种常见编码，看哪一种能让中文正常显示。如果切换后显示正常，说明文件本身没问题，故障出在后续环节；若多种编码都显示异常，才需要怀疑文件是否真的受损。
再核对网页端的读取与转码
不少上传组件默认按UTF-8读取文件内容，而部分系统里的记事本默认把文件保存为GBK。声明编码与实际编码不一致，典型表现就是中文整段变成问号或方块，英文和数字不受影响，因为它们在两种编码中的字节位置一致。维护时应确认读取文件时是否指定了编码、是否有自动探测机制、探测失败时是否有回退策略，而不是一律按默认编码硬读。
最后核对浏览器展示与字体回退
少数情况下编码已经正确，页面仍显示异常，原因可能在字体。若页面声明的字体不包含某些中文字形，浏览器会回退到其他字体，回退失败就出现方块。此时可以查看页面源码中的字符集声明是否与实际输出一致，再检查字体栈是否覆盖了常用中文字体。编码正确但显示异常，往往就是这一层的问题。
一套可执行的排查顺序
先看原文件编码，再看服务端读取时指定的编码，然后看页面输出的字符集声明，最后看字体回退。临时处理办法是保留原始文件不动，另存一份转换为UTF-8后再上传，避免直接在原文件上反复覆盖。转换前最好备份，转换后抽查几段中文和标点，确认没有新的错位。
要从根本上减少重复问题，维护流程里应加入上传规范：明确推荐编码，上传时自动检测并提示，检测不通过则拒绝入库而非静默转换。it数运在网站维护环节的做法是先固定编码约定，再让检测环节把异常拦在前面，而不是等用户看到乱码再回头找原因。乱码不可怕，可怕的是每次都从零猜起。把核对顺序固定下来，这类问题就会越来越少。
