CSV文件真实编码常为GBK而非UTF-8，需用记事本或VS Code验证；DBeaver导入时encoding必须手动设为GBK，且MySQL目标字段collation须匹配为gbk_chinese_ci，否则必乱码。
导入前必须确认 CSV 文件真实编码是 GBK
很多人以为 Excel「另存为 CSV」就一定是 GBK，其实不一定。Windows 默认保存的 CSV 编码取决于系统区域设置和 Excel 版本，有些新版 Excel 会默认存成 UTF-8（带 BOM），导致你填了 GBK 却还是乱码。验证方法：用记事本打开 CSV 文件 →「另存为」→ 看右下角显示的编码；或用 VS Code 打开，右下角明确显示 GBK / GB2312 / UTF-8 with BOM。
导入向导里 Encoding 必须设为 GBK（不是 UTF-8）
DBeaver 导入 CSV 时，Encoding 字段控制它「怎么读这个文件」，不是「想存成什么编码」。如果文件是 GBK，这里填 UTF-8，DBeaver 就会把每个 GBK 字节当 UTF-8 解码，结果必然乱码。
- 路径：右键表 → 导入数据 → 选择 CSV 文件 → 下一步 → 在「处理器属性」面板中找到
encoding - 值填
GBK（GB2312也可，但GBK兼容性更好，尤其含生僻汉字时） - 别信「自动检测」——DBeaver 的自动编码识别对 GBK 支持不稳定，手动指定最可靠
目标表字段字符集也得是 GBK（MySQL 场景）
即使文件读对了、映射也对了，如果 MySQL 表字段用的是 utf8mb4，而你往里塞 GBK 编码的字节，MySQL 服务端会校验失败，报错 Incorrect string value: '\xE5\x85\xB3...' for column 'name' at row 1。
- 解决方法：右键已建好的表 → 查看表 → 属性 → 找到中文字段（如
name）→ 双击编辑 → 把Collation改成gbk_chinese_ci（MySQL 5.7+ 支持）或gb2312_chinese_ci - 注意：整个表的默认字符集（
CREATE TABLE ... DEFAULT CHARSET=gbk）也建议同步设为gbk，避免新字段继承错的 collation - PostgreSQL / Oracle 不走这套逻辑，它们靠数据库级 encoding 控制，字段本身不存 collation，所以这步只对 MySQL 有效
Excel 直接另存为 CSV 的两个大坑
你从 Excel 出来的 CSV，表面是文本，实际埋了两颗雷：
-
前导零丢失：Excel 把
00123当数值处理，存 CSV 时直接变成123，DBeaver 导入时已经没得救。预防方法：在 Excel 里选中该列 → 右键「设置单元格格式」→ 「文本」→ 再输入或粘贴带前导零的内容 -
日期格式错乱：Excel 的日期在 CSV 里可能导出成
44562（序列号）或2022/1/1（本地格式），DBeaver 默认按字符串导入。务必在导入向导「列设置」页，为日期字段手动指定date format，比如yyyy-MM-dd或yyyy/M/d
真正麻烦的不是设置哪几个选项，而是 GBK 这个编码本身没有标准 BOM 标记，DBeaver 和 MySQL 都没法靠字节头自动识别——所有环节都得人工对齐，漏一环就全崩。
