DBeaver CSV导入问题主因是格式不规范或配置错误：双引号/换行符需严格遵循RFC 4180包裹规则；反斜杠默认不转义，应改用引号包裹；编码必须手动指定而非依赖自动检测；空值映射需在选项中明确设置。
CSV导入时双引号和换行符被截断或报错
DBeaver默认用双引号"包裹含逗号、换行符或双引号本身的字段，这是CSV RFC 4180标准行为。但如果你看到字段被截断、换行后数据错位，或报错Malformed CSV line，大概率是源文件里存在未正确包裹的换行符或嵌套引号。
实操建议：
- 用文本编辑器（如VS Code）打开CSV，搜索
"包围的字段中 - 在DBeaver导入向导的「选项」页，确认「引用字符」设为
"，且「转义字符」保持为空（DBeaver默认不启用反斜杠转义，依赖引号包裹） - 若原始数据确实含未包裹的换行符，优先在Excel中另存为CSV前，用
=SUBSTITUTE(A1,CHAR(10)," ")清理单元格内换行；或用Python脚本预处理：import csv with open('in.csv', newline='', encoding='utf-8') as f: reader = csv.reader(f, quoting=csv.QUOTE_MINIMAL) # 再写入标准化CSV
反斜杠
DBeaver的CSV导入器（DataImporterCSV.java）默认不把当作转义字符——它只认引号包裹逻辑。所以当你看到路径C:Users
ame变成C:Usersname，或正则表达式\d+变成d+，不是DBeaver“吃掉”了反斜杠，而是CSV解析阶段根本没把它当转义符处理。
实操建议：
- 不要依赖
做转义；改用双引号包裹整个字段，例如"C:Users ame"，这样DBeaver能原样保留 - 如果必须用反斜杠（如某些旧系统导出格式），在导入向导「选项」页勾选「使用转义字符」，并手动填入
——但注意这会全局生效，可能误伤其他字段 - 更稳妥的方式：先导出为SQL插入语句（DBeaver支持「导出为SQL」），再执行；SQL里的
\会被MySQL/PostgreSQL正确识别
中文括号、全角符号或emoji导致乱码或截断
这类问题几乎全是编码不匹配。DBeaver界面默认UTF-8，但CSV文件可能是GBK、Big5或带BOM的UTF-8。一旦编码识别错，（可能变成「，emoji直接变??，甚至触发字段错位。
实操建议：
- 在DBeaver导入向导「选项」页，务必手动指定「字符编码」——别信「自动检测」；常见场景：Windows记事本保存的CSV选
GBK，Mac Numbers导出选UTF-8 - 用
file -i your_file.csv（Linux/macOS）或Notepad++的「编码」菜单确认真实编码 - 如果文件有BOM，DBeaver有时会多读3个字节导致首列异常；用
sed -i '1s/^//' file.csv去掉BOM（Linux/macOS）
导入后数据库里显示NULL或空字符串，但源CSV明明有值
这不是DBeaver“丢数据”，而是它把某些字符串当成了空值占位符。默认配置下，NULL、nil、空字符串""都可能被映射为SQL NULL，尤其当目标列为NOT NULL时，就会静默失败或填充默认值。
实操建议：
- 在导入向导「选项」页，找到「空值表示」设置项，清空它，或明确填入你CSV里真正代表空的标记（比如
[NULL]） - 检查目标表字段是否定义了
DEFAULT，比如status VARCHAR(20) DEFAULT 'pending'——即使CSV该列为空，也会被填成'pending'，看起来像“数据没进来” - 导入前用DBeaver「预览」功能看解析结果，确认每一列的值是否符合预期；预览里显示
<null></null>就说明DBeaver已按空值处理
DBeaver对特殊字符的处理逻辑很务实：它不试图智能猜意图，而是严格遵循CSV规范 + 显式配置优先。最容易被忽略的，是「预览」按钮右侧那个小小的「编码」下拉框——90%的乱码问题，点开它改对就解决了。
