Navicat导入CSV时Character Set必须手动选UTF-8，不能留空或信Auto；Auto模式易误判为Latin1导致中文变???，关键在导入向导第二步手动选择UTF-8（兼容BOM/无BOM），但需先用Notepad++或VS Code确认CSV真实编码，若源为Excel/WPS导出则大概率是GBK，须选GBK而非UTF-8。
Navicat导入CSV时Character Set必须手动选UTF-8，不能留空或信Auto
navicat默认不自动识别utf-8，哪怕文件确实是utf-8编码，auto模式大概率误判为latin1，导致中文变成???或涓枃。关键动作在导入向导第二步——选择文件后点击“下一步”，进入字段解析设置页，此时character set下拉框必须手动点开并选utf-8。
注意：UTF-8选项在Navicat里已兼容BOM和无BOM两种格式，不用区分“UTF-8 with BOM”和“UTF-8 without BOM”；但如果你的CSV是从Excel另存而来，它大概率是GBK，此时选UTF-8反而错，得改选GBK。
- 用
Notepad++底部状态栏或VS Code右下角编码标识确认真实编码 -
file -i your.csv（Linux/macOS）或PowerShell中Get-Content -Path "your.csv" -Encoding UTF8 -ErrorAction SilentlyContinue | Select-Object -First 1可辅助验证 - 别看文件扩展名或编辑器默认新建行为——Windows记事本新建保存就是GBK，VS Code新建默认是UTF-8无BOM
导入前CSV文件本身必须是UTF-8编码，否则选对Navicat选项也没用
Navicat只是按你指定的编码去解码字节流，它不转换编码。如果原始CSV是GBK，你在Navicat里硬选UTF-8，结果就是每个汉字被拆成两个乱码字节，显示为浣犲ソ这类。
常见来源的默认编码：
- Excel另存为CSV（Windows）→ 默认
GBK - WPS另存为CSV → 可选UTF-8，但默认常为GBK
- Python
pandas.to_csv()→ 默认utf-8（无BOM） - MySQL导出（
SELECT ... INTO OUTFILE）→ 编码取决于character_set_client，通常为utf8mb4
转换方法：用Notepad++打开CSV → 菜单【编码】→ 【转为UTF-8编码】→ 【保存】；或用iconv -f GBK -t UTF-8 input.csv > output.csv命令行转换。
字段分隔符和换行符不匹配会伪装成乱码
选对Character Set后仍出现部分字段偏移、列数突增、地址字段内容跑到其他列——这不是编码问题，是CSV结构解析失败。Navicat把换行符\n或\r\n当成了记录分隔符，但实际该换行在双引号内（如地址含回车），导致整行切错。
解决方法在导入向导第四步（字段设置页）：
-
Field Separator保持,（逗号） -
Text Qualifier必须设为"（英文双引号） -
Line Separator建议先选Auto；若源文件明确来自旧Windows系统，可手动选\r\n；来自Mac则选\n - 检查CSV原始内容：用文本编辑器看
"是否成对出现，中间是否含未转义的\n或,
目标表字符集不是导入乱码的主因，但需确保能存下UTF-8字符
导入环节的Character Set只管CSV字节怎么解读，和MySQL表的CHARACTER SET无关。即使目标表是latin1，Navicat仍会把UTF-8字节原样插入——只是MySQL存不下，最终截断或报错。
所以确认表支持UTF-8：
- 建表时用
CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci（MySQL 8.0+推荐） - 已有表可执行
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4; - 别只改表，还要确认列定义没写死
CHARACTER SET latin1
真正容易被忽略的是：即使CSV、Navicat、表三者都设了UTF-8，只要CSV里混了BOM以外的不可见控制字符（比如\u200B零宽空格），Navicat解析时可能卡在某一行，后续全乱——这种问题不会报错，只能逐段截取排查。
