客服常接到这样的反馈：用户把一份纯文本日志上传到网站后台，点开预览却看到满屏问号或方块，下载回本地又恢复正常。这类问题容易让人误以为是浏览器坏了，其实多数情况下乱码与文件编码、上传处理、预览读取和页面声明四个环节有关。先分清是文件本身的问题还是预览环节的问题，排查才有方向。
第一层先核对文件编码。纯文本文件本身不携带字体信息，只记录字符编码。常见的UTF-8和GBK在中文环境下差异明显，同一个汉字在两种编码下对应的字节序列不同，用错编码打开就会出现乱码。让用户用本地编辑器打开文件，查看状态栏或编码菜单里显示的真实编码，再另存为UTF-8并保留原文件备份。如果另存后预览正常，问题基本锁定在源文件编码上。
第二层核对上传与存储环节。有些上传组件会对文本内容做统一转码，或者在拼接存储路径时按默认编码处理文件名，导致内容在落盘前已经变形。检查上传接口是否对文本类型做了额外处理，对比上传前后的文件大小和首字节，确认内容没有被二次改写。存储路径中的中文目录名也值得留意，部分环境在处理路径时会出现编码不一致。
第三层核对预览服务的读取方式。服务端读取文本文件时如果没有显式指定编码，运行环境会按默认编码解析，默认值在不同系统上并不一致。读取日志类文件时应在代码中明确声明按UTF-8读取，遇到无法解码的字节时采用替换策略并记录提示，而不是直接抛出异常或输出乱码。
第四层核对浏览器展示与页面声明。页面头部的字符集声明必须与实际输出内容一致，声明为UTF-8却输出GBK字节，浏览器就会按错误方式渲染。检查接口返回的响应头是否带上了正确的字符集信息，前端渲染容器是否对文本做了二次转义。
把以上四层整理成排查清单：先确认源文件编码，再比对上传前后内容，然后检查读取代码是否指定编码，最后核对页面与响应头声明。修复顺序建议从源文件开始，逐层向后推进，每修一层就复测一次。it数运在网站维护中会把文本编码检查纳入交付流程，要求上传、读取、展示三个环节的编码声明保持一致，并在日志类文件的预览页给出编码提示，减少用户反复反馈。
乱码问题解决后，建议把文件来源、原始编码、处理方式和最终编码记录下来，形成简单的编码台账。同类文件再次上传时可以直接对照，避免同一个问题在不同用户身上重复出现。
