CSV文件上传后，姓名、地址、商品名全变成问号或方块，这在网站维护中并不少见。许多人的第一反应是数据库出了故障，但CSV中文乱码通常不是某一个环节单独造成的，而是从用户电脑到浏览器展示之间，某一层字符集没有对齐。
先确认用户导出时的编码格式
用户用表格软件导出CSV，常见结果有两种：UTF-8和GBK或GB18030。UTF-8保存的中文在多数现代系统中能正常读取，而GBK保存的中文一旦被当作UTF-8解析，就会显示为乱码。维护人员可以请用户重新导出一次，在导出选项中确认编码，或者用文本编辑器打开原文件，查看实际保存格式。如果用户说不清编码，最好让他提供原始文件，而不是只发截图。
再检查上传接口接收时有没有隐式转码
文件从浏览器发到服务器，请求头里的Content-Type有时会带字符集声明，有时不带。后端如果默认按ISO-8859-1读取，中文在进入系统前就已经损坏。检查时不能只看前端页面，要查看接口接收日志、临时文件内容和后端读取代码。重点确认读取流时是否指定了与文件一致的字符集，以及读取后有没有再次转码。
接着核对数据库和数据表的字符集设置
即使文件读取正确，写入数据库时如果表字符集是latin1，中文依然存不进去。需要查看数据库默认字符集、表字符集和字段字符集是否一致，排序规则是否匹配。排序规则不一致时，有时能存进去，但查询和排序会出现异常。维护中可以把待写入字段的字符集统一为utf8mb4，再观察写入结果。
最后检查页面展示时的响应头编码声明
数据在数据库里正常，页面却显示乱码，问题可能出在输出环节。检查HTTP响应头中的Content-Type是否声明了UTF-8，HTML里的meta charset是否一致，接口返回的JSON是否按UTF-8编码。如果响应头声明GBK而内容实际是UTF-8，浏览器就会按错误方式解码。
实际操作可以按数据流方向逐层验证：先看用户原始文件编码，再看上传接口读取方式，接着看数据库字符集，最后看页面响应头。每一步只改一个变量，改完立即用同一份文件复测。it数运在网站维护服务中处理这类问题时，通常先保留原始文件和日志，再按上述顺序定位，避免一上来就改数据库导致问题扩大。
CSV中文乱码排查的关键是顺着数据流走，不要跳步。把用户端、接口、数据库和展示端四层字符集逐一核对清楚，多数乱码都能找到具体原因。
