根本原因是编码不匹配：Navicat不自动探测TXT编码，需手动选对（如UTF-8无BOM选UTF-8、有BOM选UTF-8 with BOM、GBK文件选GBK），否则解码失败致乱码；还需确保目标表字符集为utf8mb4且Navicat连接启用UTF-8。
Navicat导入TXT时中文变问号或方块，根本原因是编码不匹配
navicat本身不自动探测txt文件编码，它按你指定的编码去读字节。如果选错（比如文件是utf-8 with bom却选了utf-8，或文件是gbk却选了utf-8），就会解码失败，显示乱码。
别猜，先确认真实编码：
- 用VS Code、Notepad++或Sublime Text打开TXT，看右下角状态栏显示的编码（注意区分
UTF-8和UTF-8 with BOM） - Linux/macOS下可用
file -i your_file.txt；Windows命令行无法可靠识别，别依赖chcp - 若文件由Excel另存为TXT生成，大概率是
GBK（Windows简体中文系统默认）或UTF-16 LE（带BOM）
Navicat导入向导里该选哪个编码选项
选项名容易误导：Navicat把UTF-8和UTF-8 with BOM分开列，但实际只认BOM头。没BOM的UTF-8文件选UTF-8；有BOM的必须选UTF-8 with BOM，否则首字段可能丢字符或报错。
- 文件确认为纯
UTF-8（无BOM）→ 选UTF-8 - 文件是Excel保存的TXT或记事本“另存为”→ 极大概率要选
UTF-8 with BOM或GBK - 数据库表字符集是
utf8mb4，但导入时选GBK也能成功——Navicat会做转换，只要源编码选对就行 - 如果选错编码，导入后查
SELECT HEX(col) FROM table，能看到异常十六进制值（如C0A1这种非标准UTF-8序列）
跳过BOM或预处理TXT避免手动选错
BOM是隐藏字节，肉眼不可见，但会让导入不稳定。与其每次赌选项，不如提前清理。
- 用
sed -i '1s/^\xEF\xBB\xBF//' file.txt（Linux/macOS）直接删BOM - Windows下用PowerShell：
(Get-Content file.txt -Raw) -replace "\xEF\xBB\xBF", "" | Set-Content file.txt -Encoding UTF8 - 用Python一行转码：
python -c "open('out.txt','wb').write(open('in.txt','rb').read().decode('gbk').encode('utf-8'))"（按原编码替换gbk） - Navicat不支持跳过BOM的选项，也没“自动检测”开关——这个功能它确实没有
导入后数据库里还是乱码？检查三个地方
导入界面选对了，不代表万事大吉。乱码可能发生在链路下游。
- 目标表的
CHARACTER SET不是utf8mb4（比如还是latin1）→ 执行ALTER TABLE tbl CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - Navicat连接参数没设UTF-8：右键连接 → “编辑连接” → “高级”页 → 勾选
Use Unicode UTF-8 for databases - MySQL服务端配置
character_set_server是latin1？查SHOW VARIABLES LIKE 'character_set%'，重点看character_set_client、character_set_connection、character_set_results是否全为utf8mb4
真正卡住人的，往往是表结构编码和服务端连接参数这两层，不是导入那一步。
