navicat 16导入excel中文乱码主因是三处编码未对齐：excel导出的csv真实编码、navicat导入时声明的字符集（如utf-8-bom或gbk）、mysql表/列及连接层的character set必须均为utf8mb4，缺一不可。
navicat 16导入excel中文乱码，90% 是三处编码没对齐：excel源文件真实编码、navicat导入时声明的字符集、mysql表/列的 character set。改一个地方不管用，必须同步校准。
确认Excel导出的CSV实际编码（不是.xlsx本身）
Navicat 对 .xlsx 文件不读编码元数据，它会把 Excel 解析成 XML 后再提取文本——这个过程依赖文件头或 BOM 判断编码，极易误判。所以别直接导入 .xlsx，先另存为 CSV：
- 在 Excel 中打开原文件 →「文件」→「另存为」→ 选择「CSV UTF-8（逗号分隔）(*.csv)」
- 用
Notepad++或VS Code打开该 CSV → 看右下角状态栏：必须显示UTF-8-BOM（不是 “UTF-8”） - 如果显示的是
GBK或ANSI，说明原始 Excel 是 Windows 下用旧版 Excel/WPS 保存的，此时应选GBK编码导入，硬选 UTF-8 必然乱码
Navicat 导入向导里 Character set 必须严格匹配
这个下拉框控制 Navicat 怎么解码你提供的字节流，不是“推荐用哪个”，而是“你给的是什么就选什么”：
- CSV 显示
UTF-8-BOM→ 导入向导「高级」页签中Character set必须选UTF-8-BOM（注意：不是UTF-8） - CSV 显示
GBK→ 这里必须选GBK，Automatic在混合中英文场景大概率错判 - 勾选
First row contains column names，避免首行被当数据解析 - 不要点「预览」就以为没问题——预览只反映 Navicat 当前解码结果，不验证写入数据库后的表现
检查 MySQL 表字段和连接层是否都用了 utf8mb4
即使导入过程顺利、预览正常，查表仍是问号或方块，问题一定出在连接或表结构上：
- 运行
SHOW CREATE TABLE `your_table`;→ 确认字段定义含CHARACTER SET utf8mb4；若无，说明继承库级设置 - 运行
SHOW CREATE DATABASE `your_db`;→ 确保库默认字符集是utf8mb4 - 右键 Navicat 连接 →「编辑连接」→「高级」→ 勾选
Use MySQL character set，MySQL character set下拉框选utf8mb4 - 务必在「初始化命令」里填：
SET NAMES utf8mb4;（不是utf8） - 改完必须断开重连，再执行
SELECT @@character_set_client, @@character_set_connection, @@character_set_results;，三个值都应为utf8mb4
绕过 Excel 导入模块：用 CSV 中转最稳
Navicat 的 Excel 模块对编码推断不可信，尤其 v16.0.14 之前版本对无 BOM UTF-8 支持差。直接放弃导入 .xlsx：
- Excel 另存为「CSV UTF-8（逗号分隔）」→ 用 Notepad++ 确认是
UTF-8-BOM→ Navicat 导入该 CSV，Character set选UTF-8-BOM - 日期列异常（如变成
0000-00-00）？在 Excel 中提前将该列「设置单元格格式」→「文本」，再另存为 CSV - 数字列被识别为科学计数法或截断？同样设为「文本」格式，或在 Excel 中加单引号前缀（
'123456789012345）
最容易被忽略的是连接层初始化：就算表和导入都对了，只要 @@character_set_client 不是 utf8mb4，SELECT 出来的永远是问号。别跳过断开重连这一步。
