运维人员把一份TXT日志上传到网页端查看，打开后中文全变成方块和问号，英文数字却显示正常。遇到这种情况，先不必怀疑文件损坏。多数时候文件本身是完好的，问题出在编码识别链条的某一环：文件用什么编码保存、传输过程有没有被改动、服务端按什么编码读取、网页端又按什么字符集渲染。这四层里任何一处对不上，中文就会乱码。下面按顺序拆开核对。
第一层，先确认文件本身的真实编码。TXT文件没有强制的编码标识，同一段中文用ANSI、GBK、UTF-8或UTF-8带BOM保存，字节序列完全不同。判断方法很直接：用本地编辑器打开文件，查看状态栏或另存为对话框里显示的编码名称，再尝试切换编码重新读取，看中文是否恢复正常。如果切换后正常，说明文件编码与当前读取方式不一致，记下正确编码即可。注意UTF-8带BOM和不带BOM是两种状态，部分系统会把BOM当成正文内容处理，导致开头出现多余字符。
第二层，核对上传与传输环节。检查上传接口是否按二进制方式传输，有些表单上传会把文件当文本处理，中途按默认编码重新编码，中文就在这一步被破坏。对比上传前后的文件大小和首字节是简单有效的办法：大小不一致，说明内容被改动；首字节出现异常，可能是BOM被增删。流式上传通常更安全，但仍要确认中间层没有做文本转换。
第三层，核对服务端与网页端解析。服务端读取文件时是否显式指定了编码，网页端渲染时是否声明了字符集，这两处要一致。常见声明位置包括响应头的字符集字段、页面内的字符集标签，以及接口返回数据的编码说明。多处声明互相冲突时，浏览器往往按优先级取其一，表现就是部分页面正常、部分乱码。
第四层，区分编码错和字体缺字。编码错表现为整段中文变成规律性乱码，字体缺字则是个别生僻字显示为方块，其余中文正常。用开发者工具查看响应头里的实际字符集，能快速缩小范围。若字符集正确但仍有方块，问题多半在字体覆盖范围。
可执行的排查顺序是：先看文件编码，再看传输是否改动，再看服务端读取编码，最后看前端声明与字体。每步记录结论，形成简短排查笔记。it数运在网站维护中处理此类问题时，也遵循这条由文件到显示的核对路径，避免在错误环节反复尝试。需要提醒的是，日志内容常含业务数据，排查时注意脱敏，不要把真实日志原文贴进公开渠道求助。
