navicat导入含emoji或中文的csv乱码，主因是文件编码、navicat导入向导所选编码、目标表字段字符集三者未统一为utf-8与utf8mb4；需用vs code另存为utf-8 without bom，向导中手动选utf-8，且表字段必须为utf8mb4字符集。
CSV含emoji或中文符号时乱码，先锁死三处编码
Navicat导入含emoji、中文、日文等特殊字符的CSV，90%的乱码问题不是配置错，而是三处编码没对齐：文件保存编码、Navicat向导里选的编码、目标表字段的字符集。只要有一处是latin1或GBK而其他两处是UTF-8，就会出现问号、方块或截断。
实操建议：
- 用记事本或VS Code打开CSV →「另存为」→ 编码选
UTF-8 without BOM（千万别选带BOM的UTF-8，Navicat检测BOM后可能误判） - 在导入向导「源定义」页勾选
检测BOM，若预览仍乱码，手动切换编码：中文优先试GB18030，再退到GBK；emoji必须用UTF-8 - 确认目标表字段是
utf8mb4字符集（不是utf8），否则emoji会被截断为?；建表语句中要显式写CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
CSV里有反斜杠或双引号"，Escaped by不是万能开关
Escaped by只在字段被双引号"包裹且启用Enclosed by "时才生效。它不处理字段外的，也不解决单个路径字符串的入库问题——反而可能因误配导致Invalid escape sequence报错。
常见错误场景与对策：
- CSV内容是
"C:path o ile.txt"→ 正确：勾选Enclosed by "，设Escaped by，Navicat会把 - CSV内容是
C:path o ile.txt（无引号）→ 错误：开启Escaped by会导致p被识别为非法转义，直接中断导入 - 只想原样存
？关闭Escaped by，改用「Replace」功能：在导入向导「高级」页勾选替换文本，查找，替换为空（即删掉），或替换为\（适配MySQL存储）
TXT无表头时字段顺序错位，拖拽映射比猜列名更可靠
Navicat默认按列位置匹配字段，不是按名称。TXT没表头时，它会把第一行当数据塞进表的第一列——哪怕那列是id INT AUTO_INCREMENT，也会硬塞一个字符串进去，立刻报错。
QuickBooks Mileage CSV
下载
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
安全做法只有两种：
- 在TXT顶部加一行占位表头（如
col1,col2,col3），然后在向导第二步勾选第一行包含字段名，再进「字段映射」页手动绑定：左侧选col2，右侧点name，点「映射」 - 完全不加表头？跳过「第一行包含字段名」，直接进「字段映射」页，用鼠标拖拽调整右侧目标字段顺序，严格对齐TXT的实际列序（例如TXT第3列是生日，就把目标表的
birthday字段拖到第3个位置） - 注意：如果TXT用空格分隔而非制表符，必须在「字段分隔符」里选「其他」并手动输入
Excel导入时间格式错乱或空值丢失，别信“自动识别”
Excel里显示为2024年3月15日的单元格，Navicat常读成文本而非日期，入库后变成0000-00-00；带公式的单元格可能导入公式字符串而非结果；空格填充的“空单元格”会被跳过。
关键设置在「高级」页和前期准备：
- 时间列必须在「字段映射」页点开对应字段 → 「数据类型转换」→ 手动选
DATE，并填格式：yyyy年MM月dd日（不是yyyy-MM-dd） - 取消勾选
跳过空行，否则 - Excel含公式？复制整列 → 右键「选择性粘贴」→ 「数值」→ 再保存为
.xlsx或.csv - 驱动不匹配报错
SQLAllocHandle on SQL_HANDLE_ENV failed？卸载32位Microsoft Access Database Engine，装64位版本（与Navicat架构一致）
真正容易被忽略的是：Navicat不是ETL工具，它对超50万行的文件做图形化导入，本质是本地内存解析。一旦卡住或报“内存不足”，别调参数，直接切到LOAD DATA INFILE或COPY命令——向导界面的“高级设置”再细，也绕不开这个物理限制。
