navicat导入csv乱码主因是编码未对齐，需在导入向导中严格匹配文件真实编码（如gbk/cp936或utf-8无bom），并确认文本限定符、首行字段名选项，同时确保目标表字符集为utf8mb4。
navicat导入csv乱码，90%是因为编码没对齐，不是软件问题，也不是数据库字符集错了——而是你没在导入向导里把utf-8设对、设稳、设到底。
为什么“导入向导里选UTF-8”还不够？
Navicat不会自动探测CSV文件编码，它只认你手动选的那一个。但很多人点开向导后只扫了一眼下拉框，默认值是UTF-8就直接点下一步，结果失败。失败原因往往有三个：
- 文件实际是
GBK（比如Excel另存为CSV时选了“Windows默认编码”），却硬选UTF-8； - 文件是
UTF-8 with BOM，而Navicat某些版本（尤其v15及更早）会把BOM当乱码解析，导致首列错位或报错Invalid UTF-8 sequence； - 你改了导入向导里的编码，但目标表的
CHARACTER SET仍是latin1或gbk，数据存进去就变形，预览看着对，查库就乱。
如何确认CSV真实编码？别靠猜
打开文件前先验证，省去反复重试。推荐用命令行快速判断（Windows可用Git Bash / WSL，macOS/Linux直接终端）：
file -i your_data.csv
或用iconv试探转换：
iconv -f GBK -t UTF-8 your_data.csv | head -n 5
如果输出中文正常，说明原文件是GBK；如果报错Invalid argument，再试UTF-8或GB2312。记事本右下角显示的“ANSI”≈GBK（Windows简体中文系统下），不是标准编码名，不能直接填进Navicat。
导入向导中必须手动核对的三项编码设置
进入Navicat“导入向导”后，在“选择文件”页面之后的“文件格式选项”页，这三个地方必须显式确认：
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
-
字符集：严格匹配文件真实编码，不是“看着像就选UTF-8”。若文件是GBK，这里必须选GBK（Navicat列表里叫CP936或GBK）； -
文本限定符：中文CSV常含逗号（如“上海市,浦东新区”），若未用双引号包裹，必须勾选使用文本限定符并填"，否则字段直接劈开； -
第一行作为字段名：必须勾选——否则标题行被当数据插入，所有后续行整体下移，看起来像“字段错位”，实则是元数据断点。
导入后仍乱码？检查表级字符集是否兜底
即使向导设置全对，如果目标表用的是latin1或utf8（注意不是utf8mb4），中文照样变???或æ些。执行这条SQL确认：
SHOW CREATE TABLE your_table;
重点看DEFAULT CHARSET=和各VARCHAR字段的COLLATE。正确应为：
DEFAULT CHARSET=utf8mb4COLUMN name VARCHAR(100) COLLATE utf8mb4_unicode_ci
如果不对，建表前先改库默认字符集，或建表时显式声明：CREATE TABLE ... DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci。已有表可改：ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci。
跨平台最险的点在于：macOS Numbers导出CSV默认用UTF-8 + 分号，Windows版Navicat若没手动切分隔符，整行就塌成一列；而Windows Excel导出的“CSV UTF-8”实际带BOM，Navicat解析时首字段名前多出。这些细节不肉眼核对，光靠“统一选UTF-8”只会让问题更隐蔽。
