Navicat导入Excel中文乱码因编码识别错误：Excel无显式编码，Navicat依赖文件头/BOM判断；UTF-8（尤其无BOM）易被误判为GBK，v15前版本不支持；应转存为带BOM的UTF-8 CSV并选UTF-8-BOM导入，同时确保MySQL连接与字段字符集均为utf8mb4。
Navicat导入Excel时中文变问号或方块？先看文件实际编码
excel本身不存编码信息，navicat读取时默认按系统locale（比如windows简体中文是gbk）解析。但如果你的excel是用excel for mac、wps另存为或从网页导出的，很可能底层是utf-8编码——而navicat旧版本（v15之前）压根不支持utf-8编码的excel文件。
- 用记事本打开Excel另存为的
.csv文件，右下角显示“UTF-8”就别指望直接拖进Navicat选GBK能行 - Excel原生
.xlsx文件没有显式编码字段，Navicat靠文件头和BOM判断；没BOM的UTF-8 Excel会被当成ANSI处理 - 实测：Windows上用Excel「另存为→CSV UTF-8（逗号分隔）」生成的文件，Navicat v16.0.14+才真正识别，老版本一律乱码
Navicat导入向导里选错字符集=白忙活
导入Excel时弹出的「导入向导」窗口里，关键选项在「高级」页签下的Character set下拉框——它控制的是Navicat如何解读Excel里的字节流，不是数据库表的字符集。
- 必须和Excel真实编码一致：GBK文件选
GBK，UTF-8无BOM选UTF-8，有BOM的UTF-8选UTF-8-BOM -
Automatic选项在Excel场景基本失效，尤其遇到混合中英文或含emoji的单元格，会随机截断或错位 - 如果目标表是
utf8mb4，但Excel是GBK，不能指望Navicat自动转码——它只做字节映射，不转换编码
绕过Navicat直接导入：用CSV中转最稳
与其在Navicat里反复试字符集，不如把Excel转成带BOM的UTF-8 CSV，再用Navicat导入这个CSV文件。BOM是唯一能让Navicat稳定识别UTF-8的锚点。
- Excel里「文件→另存为→CSV UTF-8（逗号分隔）（*.csv）」——注意括号里必须有「UTF-8」字样
- 保存后用VS Code或Notepad++打开，确认状态栏显示
UTF-8 with BOM - Navicat导入该CSV时，
Character set明确选UTF-8-BOM，勾选First row contains column names - 遇到日期列导入成
0000-00-00？那是Excel日期格式未转文本，提前在Excel里对列右键→设置单元格格式→文本
MySQL服务端配置不匹配，导入成功也显示乱码
即使Navicat导入过程没报错、预览也正常，最终查表还是乱码，大概率是MySQL连接层或表定义没对齐。
- 检查当前连接的
character_set_client、character_set_results是否为utf8mb4（用SHOW VARIABLES LIKE 'character_set%';） - 表字段如果是
CHAR/VARCHAR，确认定义时指定了CHARACTER SET utf8mb4，光设表默认字符集不够 - Navicat连接属性里的
Initial SQL可加一句SET NAMES utf8mb4;，避免每次手动执行
Excel乱码问题从来不是单点故障。它横跨文件生成、工具解析、传输协议、服务端存储四层，任一层编码标签缺失或错配，都会在最终结果里冒出来。最容易被跳过的，是确认Excel文件本身的编码来源——而不是一上来就调Navicat设置。
