纯文本文件常被当成最省事的格式，没有复杂排版，也没有嵌入对象。可偏偏是这种看起来最简单的文件，上传到网页端打开后，中文变成了方块、问号或者一串看不懂的符号。遇到这种情况，先别急着改文件内容，乱码往往不是文字本身出了问题，而是编码在某个环节没有对上。按顺序分层核对，比反复重新上传更有效。
第一层，核对文件自身的字符编码。TXT文件只存文字，不存字体和样式，真正决定中文能否正确显示的是保存时使用的编码方式。常见的有UTF-8和GBK，两者对同一个汉字的字节表示并不相同。判断方法很直接：用支持查看编码的文本编辑器打开原文件，看状态栏或保存选项里标注的是哪一种。如果原文件是GBK，而后续环节按UTF-8去读，中文就会变成乱码。需要注意的是，有些编辑器会自动识别编码，识别结果不一定准确，最好以保存时的设置为准。
第二层，核对网页端的读取与解码方式。网页端展示TXT内容时，通常需要先读取文件再按某种编码解码。如果程序里写死了按UTF-8解码，而文件实际是GBK，乱码就会稳定出现。反过来，如果程序依赖自动探测，短文件、中英混排或只有少量中文的内容，探测结果容易偏差。这一层的排查重点是看解码声明和文件实际编码是否一致，而不是只看页面显示结果。可以先用一个已知编码的小文件做对照测试，确认读取环节的行为。
第三层，核对浏览器显示环节。编码正确解码之后，文字还要经过字体渲染。如果页面使用的字体缺少某些中文字形，可能显示为方块，但这与编码乱码的表现不同：编码问题通常是大面积符号错乱，字体问题多集中在个别生僻字或特定字符。另外，浏览器缓存也可能让人误判，改动后仍看到旧结果，清理缓存或换一个浏览器复核能排除干扰。
实际处理时，可以按这个顺序走：先备份原文件，确认原始编码；再用编辑器另存为UTF-8副本，上传测试；如果仍然异常，检查网页端解码逻辑；最后排查字体与缓存。任何时候都不要直接在原文件上反复转换，避免编码被二次破坏。
日常维护中，把文件类型和编码核对纳入上传前的常规检查，能省下大量排查时间。it数运在网站维护中处理用户上传文件时，也会把纯文本的编码确认作为固定环节，先看清文件本身，再谈页面显示，问题往往在第一步就能定位。
