navicat导入excel中文乱码主因是三处编码未对齐：excel源文件真实编码、navicat导入时声明的字符集、mysql表/列character set；需用notepad++确认csv实际编码，导入时选对应选项（如utf-8-bom），并确保连接层与表结构均为utf8mb4。
navicat 导入 excel 出现中文乱码，90% 以上不是 excel 文件本身的问题，而是 navicat 在读取时用了错误的字符集去解码字节流 —— 改成 utf-8-bom 或 gbk 只是表象，关键得让这三处编码对齐：excel 文件实际编码、navicat 导入时声明的编码、mysql 表/列的 character set。
为什么直接在 Navicat 里选 UTF-8 还是乱码？
因为 Excel（.xlsx）本质是 ZIP 容器，不带明确编码标识；Navicat 的「Excel 导入」模块会尝试自动推断文本内容编码，但经常误判为 GBK 或 ISO-8859-1，尤其当单元格含空格、数字混排时。它根本没读你 Excel 里“真正存的是什么编码”。
- 用 Excel 自带「另存为 → CSV UTF-8（逗号分隔）」生成的文件，其实带 BOM（
EF BB BF），这是唯一能稳定触发 Navicat 正确识别 UTF-8 的锚点 - 如果 Excel 原始文件是 Windows 系统下用 WPS 或旧版 Excel 保存的，很可能实际是
GBK编码，此时硬选UTF-8必然乱码 - Navicat 导入向导里选的「编码」只影响它怎么读 Excel 内部 XML 解析出的字符串，不影响后续写入数据库时的连接层编码
导入前必须确认的三个编码位置
漏掉任意一个，改再多遍导入设置都没用：
- Excel 源文件真实编码：用
Notepad++或VS Code打开该 Excel 导出的 CSV，看右下角状态栏显示的是UTF-8-BOM还是GBK；如果是.xlsx，先另存为 CSV 再查 - Navicat 导入向导中「字符集」下拉框：必须和上一步完全一致 —— 是
UTF-8-BOM就选它，不是UTF-8；是GBK就选GBK，别碰自动 - 目标表字段的
CHARACTER SET：运行SHOW CREATE TABLE `your_table`;，确认字段定义里有CHARACTER SET utf8mb4或CHARACTER SET gbk；若为空，说明继承库级设置，得先查SHOW CREATE DATABASE your_db;
导入后查表还是乱码？重点检查 connection 层
即使导入过程没报错、预览也正常，最终 SELECT * FROM table 显示问号或方块，大概率是连接初始化没生效：
- 右键连接 →「编辑连接」→「高级」→ 在「MySQL 字符集」里强制选
utf8mb4（不是utf8） - 勾选「使用 MySQL 字符集」，并确保「初始化命令」里有
SET NAMES utf8mb4; - 导入完成后，不要立刻查表 —— 先断开重连，再执行
SELECT @@character_set_client, @@character_set_connection, @@character_set_results;，三个值必须全为utf8mb4 - 如果用的是 SSH 隧道，还要在「SSH」页勾选「启用终端」，终端类型设为
xterm-256color，否则字符集会被隧道底层覆盖
实在搞不定就绕过 Excel 导入模块
Navicat 对 .xlsx 的解析逻辑封闭且不可调，不如彻底放弃它：
- 在 Excel 中把数据粘贴到新工作表 → 全选 → 复制 → 打开 Navicat 查询窗口 → 粘贴成 INSERT 语句（需提前写好模板），用
F9执行；这样走的是 SQL 协议，编码由连接层统一控制 - 用 Python 脚本读
pandas.read_excel()+to_sql(..., if_exists='append')，显式指定encoding='utf-8'或encoding='gbk'，避开 Navicat 渲染层所有坑 - 导出为 CSV 后，用命令行工具
mysql -u user -p --default-character-set=utf8mb4 db_name 直接灌库，跳过 GUI 层全部中介
最常被忽略的一点：Navicat 的「导入向导」和「查询编辑器」用的是两套独立的编码缓存机制。你在导入时选了 UTF-8-BOM，不代表查询窗口里写的 INSERT 也是这个编码 —— 右下角编辑器状态栏的编码标识必须手动点成一致，否则粘贴进去的中文当场就损坏。
