Navicat 12不自动探测TXT编码，必须手动选对编码（如UTF-8无BOM选UTF-8、有BOM选UTF-8 with BOM、GBK文件选GBK），并确保目标表字符集为utf8mb4且连接启用UTF-8，三者缺一不可。
Navicat 12 不识别 TXT 真实编码，必须手动指定
navicat 12 从不自动探测 txt 文件编码，它只按你选的编码去解码字节流。选错就必然乱码——不是“可能”，是“一定”。它不会报错，只会把 gbk 的 张三 解成 ??，或把 utf-8 with bom 的首字段截掉第一个字符。
常见错误现象：
- 中文全变成
?或方块 - 第一列数据缺失（如本该是
张三，实际导入为三） -
SELECT HEX(col)返回非标准 UTF-8 字节序列（如C0A1、B9E3）
实操建议：
- 用 VS Code / Notepad++ 打开 TXT，右下角看真实编码（注意区分
UTF-8和UTF-8 with BOM） - Linux/macOS 下执行
file -i your_file.txt，别信 Windows 的chcp - Excel 另存为的 TXT：Windows 简体系统下大概率是
GBK；若含中文日期/符号，极可能是UTF-16 LE（记事本另存时会显示）
Navicat 导入向导里“UTF-8”和“UTF-8 with BOM”到底怎么选？
选项名有误导性：Navicat 实际只靠 BOM 头判断，不是靠你“感觉”。没 BOM 的纯 UTF-8 文件，必须选 UTF-8；有 BOM 的（哪怕内容全是 ASCII），必须选 UTF-8 with BOM，否则首字段丢字符或解析失败。
实操建议：
- 用十六进制编辑器（如 HxD）或命令行
xxd -l 8 your_file.txt查前 8 字节：看到ef bb bf→ 有 BOM → 选UTF-8 with BOM - 文件由记事本“另存为”生成 → 几乎必带 BOM → 优先试
UTF-8 with BOM - 文件由 Python
open(..., encoding='utf-8')写出 → 默认无 BOM → 选UTF-8 - 不想赌？用
iconv -f utf-8 -t utf-8 -o clean.txt your_file.txt去 BOM（Linux/macOS）
目标表字符集和 Navicat 连接编码不匹配，导入照样乱码
即使 TXT 编码选对了，如果数据库表字段是 latin1，或 Navicat 连接用的是 GBK，数据在传输途中仍会被二次转码损坏。这不是导入问题，是链路断裂。
实操建议：
- 确认目标表字符集：
SHOW CREATE TABLE your_table，字段应为utf8mb4（不是utf8） - 检查 Navicat 连接设置：右键连接 → “编辑连接” → “高级” → “编码” 必须设为
UTF-8（不是空着，也不是勾选“使用 MySQL 字符集”） - 临时验证连接环境：
SET NAMES 'utf8mb4'在查询窗口执行，再SHOW VARIABLES LIKE 'char%'确认character_set_client、connection、results全是utf8mb4 - 若数据库是旧系统且不能改表结构，宁可把 TXT 转成
GBK再导入，也别让 Navicat 强制转换
大文件或特殊分隔符导致字段映射错乱，别依赖自动识别
Navicat 12 对制表符以外的分隔符（如空格、中文顿号、多空格）识别极差。它会把一行切碎或合并，导致字段数错位；大文件还会因内存缓存机制卡死或静默丢数据。
实操建议：
- 导入前用文本编辑器打开 TXT，确认分隔符是否统一；含空格分隔 → 在向导中选“其他”，手动输入
\t或 - 无表头时，Navicat 默认按位置映射 → 第 2 步“字段映射”页面必须手动拖拽调整顺序，和 TXT 列严格对齐
- 超 50 万行？停手。改用
LOAD DATA INFILE（MySQL）或COPY（PostgreSQL），或 Navicat 的“数据传输”工具（走服务端批量接口） - 含换行符的字段（如备注列）？Navicat 无法处理 → 提前用正则替换掉字段内换行，或改用 CSV + 引号包裹
