DBeaver导出CSV中文乱码的根本原因是导出链路独立于数据库连接编码，必须手动设UTF-8并勾选Insert BOM；BOM是Windows Excel正确识别UTF-8的唯一可靠标记，缺之则解析为ANSI导致乱码。
导出 CSV 中文乱码，根本不是数据库或 JDBC 配置的问题，而是 DBeaver 导出链路独立于连接编码，必须手动指定文件编码 + BOM 才能被 Excel 正确识别。
导出向导里 encoding 必须设为 UTF-8 with BOM
DBeaver 的 CSV 导出不读取 useunicode=true&characterencoding=utf-8 这类 JDBC 参数，它走的是纯本地文件写入流程。内存中 Java String 是 UTF-16，导出时需显式转为字节流——若只选 UTF-8 而不勾选 Insert BOM，Windows Excel 会按 ANSI（如 GBK）解析，直接显示 æ人 或 ???。
- 打开导出向导 → 选择
CSV格式 → 点击Next - 在「Output encoding」下拉菜单中选
UTF-8 - 务必勾选
Insert BOM（BOM 是 Excel 唯一可靠的 UTF-8 识别标记） - 分隔符建议用
\t（Tab），避免中文字段内含逗号导致列错位
Windows 系统下别信“系统默认编码”这种说法
有人建议导出用 GBK 或 GB18030 来匹配 Windows 默认 ANSI，这看似合理，实则埋坑：
-
GBK不是标准 CSV 编码，部分工具（如 Python pandas）默认按 UTF-8 解析，一导入就报错 - 跨平台协作时，Linux/macOS 机器打开 GBK 编码的 CSV 会全乱，且无法自动检测
- 即使你本地用记事本另存为
UTF-8-BOM，Excel 双击打开仍可能失效——因为 Windows 文件关联默认忽略 BOM，必须用「数据 → 从文本/CSV」导入向导并手动选65001: Unicode (UTF-8)
导出后验证是否真生效：用命令行查编码
别只看 Excel 显示，用终端快速验证文件实际编码：
- Windows PowerShell：
Get-Content -Path export.csv -Encoding UTF8 -TotalCount 5（若报错说明不是 UTF-8） - Linux/macOS：
file -i export.csv，正确应返回charset=utf-8；若返回charset=us-ascii或charset=iso-8859-1，说明 BOM 没写入或导出设置没生效 - 更准的方法：
xxd export.csv | head -n2，开头看到00000000: efbb bf...即表示 BOM 存在
dbeaver.ini 和 JDBC 参数对导出无效，别白改
很多人花时间改 dbeaver.ini 里的 -Dfile.encoding=UTF-8，或在连接 URL 加 &characterEncoding=UTF-8，这些只影响查询结果渲染和 SQL 执行，完全不影响导出文件的字节编码。
-
-Dfile.encoding控制的是 DBeaver 自身日志、配置文件等 JVM 内部 I/O，默认 UTF-8 已足够，改了也无用 - JDBC 的
characterEncoding只管从数据库读取时的解码，导出是把内存中的 String 再 encode 成文件，路径已脱离 JDBC - 真正要调的只有导出向导里的
Output encoding和Insert BOM两个开关
BOM 是 Windows 生态下绕不开的兼容性补丁，哪怕它不符合 RFC；导出后若还要给 Excel 用户双击即开，就必须带 BOM——这点容易被忽略，但恰恰是成败关键。
