DBeaver列错位主因是分隔符或引号设置与CSV实际格式不一致。需先用编辑器确认真实分隔符、引号类型及字段内逗号；再在导入向导中准确配置delimiter、quoteChar、Header row和escapeChar；最后检查BOM、转义符、千分位、日期格式等干扰项。
预览时列就错位，八成是分隔符或引号没对上
字段错位不是数据本身有问题，而是DBeaver在“切行切列”这一步就切歪了。它完全依赖你指定的delimiter和quoteChar去解析文本，哪怕文件里实际用的是分号;，而你选了逗号,，整行就会被当成一列塞进第一列里。
别急着点完成，先做这三件事：
- 用Notepad++或VS Code打开CSV文件，看第一行真实分隔符是什么（注意：有些Excel导出的CSV会用
;，尤其欧洲区域设置） - 检查字段里是否含逗号——比如地址字段
"北京市,朝阳区"，这种必须靠引号包裹，否则DBeaver会把它切成两列；确认文件里实际用的是双引号"还是单引号' - 在DBeaver导入向导的“格式设置”页，把
delimiter和quoteChar改成和文件一致的值，再点“预览”，看列是否立刻对齐
预览看着对，导入后还是错位？检查转义字符和控制符
预览对齐只说明前几行被正确切分，不代表全量安全。Linux/MySQL环境下，反斜杠会被当作转义符处理；源数据里的 、
如果没被引号包裹，可能被跳过或截断，导致后续列整体偏移。
这类问题不会在预览里暴露，但导入后你会发现：中间某几列突然空了，或者日期跑到金额列里。解决办法很直接：
- 打开CSV文件，搜索
、\、t（中间加空格）、n - 如果文件来自Excel，优先用“另存为 → CSV UTF-8 (逗号分隔)”生成，避免ANSI+制表符混用
- DBeaver导入设置里，把
escapeChar设为（默认就是），并确保“启用转义字符”已勾选
列映射页显示“列名不匹配”，其实是首行被当成了数据
预览里第一行看起来像表头，但DBeaver没把它识别成列名，结果第二行数据顶上来当了头，后面所有列映射都错一位——这是最隐蔽的错位来源。
关键判断依据是预览窗口左上角是否显示Row #0对应的是字段名。如果不是，说明向导误判了标题行：
- 回到参数页，勾选“首行为列名”（Header row）
- 如果CSV确实没有表头，但DBeaver坚持要读，就取消勾选，并在列映射页手动把源列拖到对应目标列
- 特别注意：某些导出工具会在第一行插入BOM头（如
EF BB BF），导致首行开头多出乱码字符，这时需用编辑器删掉BOM再导入
导入后数值列全变成NULL，可能是千分位逗号干扰了类型推断
错位不一定体现在列顺序上。比如源数据里数字写成1,234.56，DBeaver在预览阶段可能把它识别为字符串；进入列映射页后，目标列是DECIMAL，但源列类型仍是TEXT，强行导入就会静默转成NULL，看起来像“数据丢失”。
这不是分隔符问题，但常被误认为错位。验证方式很简单：在预览页看那一列的值是否带高亮背景（表示被识别为字符串）。应对策略：
- 在列映射页，找到该列，点击类型下拉框，手动改为
Number或Decimal - 更稳妥的做法是提前清洗：用
sed 's/,//g'或Python脚本去掉千分位逗号 - 日期列同理——如果混着
2023/01/01和01-Jan-2023，DBeaver无法统一推断，必须手动设为String再在数据库侧用STR_TO_DATE()转换
分隔符设置只是起点，真正决定字段是否错位的，是DBeaver解析器对每一行字节流的解读逻辑。它不猜、不试、不兼容——你给什么参数，它就严格按什么切。所以与其反复重试，不如花两分钟打开文件看一眼真实结构。
