Navicat导入CSV中文乱码主因是编码不匹配，需先用Notepad++等工具确认文件真实编码（如GBK或UTF-8），再在导入向导第二步手动选择对应Character Set，不可依赖Auto；同时检查字段分隔符、换行符及目标表字符集是否为utf8mb4。
Navicat导入CSV时中文变问号或方块？先看文件实际编码
乱码本质是navicat读取的编码和csv文件真实编码不匹配。别急着改navicat设置，先确认文件本身是什么编码——windows记事本保存时默认是gbk，而vs code、sublime等工具新建文件常为utf-8（无bom）。用notepad++或vs code底部状态栏看真实编码，比猜更可靠。
常见错误现象：、???、涓枃这类明显转义失败；或者部分字段正常、部分乱码（说明CSV里混了不同编码行，极少见但可能）。
- 用
file -i your_file.csv（Linux/macOS）或PowerShell中Get-Content -Path "your_file.csv" -Encoding UTF8 -ErrorAction SilentlyContinue | Select-Object -First 1粗略判断 - 如果用Excel另存为CSV，它默认输出
GBK（Windows系统下），但Navicat新建连接默认尝试UTF-8，必然失败 - 不要依赖文件扩展名或“看起来像UTF-8”，BOM存在与否（
UTF-8-BOMvsUTF-8）Navicat识别行为也不同
Navicat导入向导里选错Character Set是主因
在“导入向导”第2步（选择文件后点击“下一步”），必须手动点开Character Set下拉框，而不是留空或信默认值。这个选项控制Navicat如何解码原始字节流，和目标数据库的character_set_client无关，只管当前CSV文件。
使用场景：你确认CSV是GBK（比如从Excel导出、老系统生成），就选GBK；确认是UTF-8-BOM，选UTF-8（Navicat会自动处理BOM）；纯UTF-8（无BOM）也选UTF-8。
-
UTF-8和UTF-8-BOM在Navicat里是同一个选项，不用区分 - 选
Auto基本等于放弃治疗——它只靠前几百字节猜，对中文CSV大概率误判为Latin1 - MySQL 8.0+ 默认字符集是
utf8mb4，但这不影响CSV导入环节的解码，别混淆“导入编码”和“表字段编码”
字段分隔符和换行符不一致也会触发乱码假象
当CSV里含有换行符（比如地址字段含回车）或逗号未被双引号包裹，Navicat可能错切行，导致后续所有字段偏移，看着像乱码，其实是解析错位。这种情况在Character Set选对的前提下依然发生。
参数差异：Field Separator默认是,，Text Qualifier默认是"，Line Separator建议选Auto（Navicat能识别\n或\r\n），但如果源文件来自Mac（\n）或旧Windows（\r\n）且混合存在，可手动指定。
- 用文本编辑器打开CSV，搜索
"和换行，看是否成对出现；不成对就大概率是格式问题 - 临时把
Field Separator改成;试试，如果乱码消失，说明原CSV里有未转义的逗号 - Navicat不会自动跳过BOM之后的内容，所以BOM存在时务必选对
UTF-8，否则BOM三字节会被当普通字符吞掉，首字段直接报废
导入后数据库里还是乱码？检查目标表字段的COLLATE
即使CSV成功解码、数据正确进到MySQL，如果目标字段定义是CHAR(10) CHARSET latin1，中文照样显示为?。这是存储层的问题，和导入过程无关。
性能 / 兼容性影响：用utf8mb4_unicode_ci比utf8mb4_general_ci略慢但更准，utf8mb4_0900_as_cs（MySQL 8.0+）支持大小写敏感，但除非业务强需求，不必升级。
- 建表时显式指定：
name VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 已有表修改：
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 别只改
CHARACTER SET不改COLLATE，MySQL可能沿用旧排序规则，某些特殊字符比较异常
最麻烦的情况是CSV里夹杂了半角/全角符号、不可见控制字符（如\u200b零宽空格），这种不会报错，但会导致后续SQL处理异常，得用正则或Python脚本预清洗。不过那已经超出Navicat导入的范畴了。
