同一份CSV表格，在本地用办公软件打开时中文显示正常，上传到网页端后却变成一串问号或方块，这是网站维护中很常见的一类反馈。遇到这种情况，先不要急着怀疑文件损坏。文件能在本地正常打开，说明数据本身大概率是完整的，问题更可能出在“文件用什么编码保存”和“网页端用什么编码读取”这两件事没有对上。下面按从文件到配置的顺序，分层核对。
第一层，核对文件的编码声明。CSV本身是纯文本，中文能否正确显示，取决于保存时使用的字符编码。常见的UTF-8和GBK在字节层面并不兼容，同一段中文用GBK保存、却按UTF-8读取，就会出现乱码。核对方法是：用文本编辑器打开文件，查看保存编码；或者用编码检测工具确认实际编码，而不是只看扩展名。如果本地软件默认另存为GBK，而网页端按UTF-8解析，乱码几乎必然出现。此时用“另存为”统一转成UTF-8，再上传测试，往往能快速定位问题。
第二层，核对分隔符与引号。CSV依靠分隔符划分列，逗号、分号、制表符混用时，列会被切错位置。列错位本身不直接改变字符编码，但会让包含中文的字段被截断或拼接，看起来像乱码。核对时重点看三点：分隔符是否全表统一；含逗号的中文内容是否用引号包裹；引号内的换行是否被正确识别。若某几列整体偏移，优先怀疑分隔符，而不是编码。
第三层，核对网页端的解析配置。文件编码正确，也可能在读取环节被改坏。需要确认读取时传入的编码参数是否与文件一致；文件是否带BOM头，带BOM的UTF-8与不带BOM的处理方式不同；服务端是否存在先转码再解析的顺序问题。转码顺序错误，会让本来正确的内容二次变形。这一层通常需要开发人员查看解析日志和实际读取参数。
第四层，建立上传前自检清单。建议固定五项检查：编码是否为UTF-8；是否保留或去除BOM并有明确约定；分隔符是否统一；首行表头是否完整；特殊字符是否已转义或加引号。it数运在网站维护中处理此类问题时，通常按“先确认文件编码，再核对分隔符，最后检查解析配置”的顺序推进，避免在错误的方向上反复修改。
多数CSV中文乱码并不是浏览器的问题，而是编码声明与解析配置不一致。把上传规范固定下来，让保存编码、分隔符和读取参数形成统一约定，同类问题就会明显减少。
