必须在DBeaver驱动属性中显式配置characterEncoding=UTF-8、useUnicode=true、connectionCollation=utf8mb4_unicode_ci三项参数，且需同步修正数据库服务端字符集（ALTER DATABASE/ALTER TABLE）、配置文件my.cnf及工作空间编码为UTF-8，否则仍会乱码。
MySQL 连接配置里必须改的三项字符集参数
只在 DBeaver 界面里点“UTF-8”下拉菜单，大概率无效。真正起作用的是 JDBC URL 里的显式参数，尤其是 characterEncoding、useUnicode 和 connectionCollation。这三项不配齐，即使数据库表是 utf8mb4，查询结果照样乱码。
修改方式：右键连接 → 编辑连接 → 切换到 驱动属性 标签页，找到或手动添加以下键值对：
-
characterEncoding=UTF-8 -
useUnicode=true -
connectionCollation=utf8mb4_unicode_ci
注意：characterEncoding 值必须大写 UTF-8（不是 utf8 或 utf-8），否则 MySQL 驱动可能忽略；connectionCollation 必须与你建库时指定的排序规则一致，比如建库用的是 utf8mb4_general_ci，这里就不能填 unicode_ci。
建库时没设 utf8mb4？现在补救要改三处
DBeaver 本身不控制数据库服务端的字符集，它只是个客户端。如果建库时漏了 CHARACTER SET utf8mb4，只靠客户端设置无法让中文存进去不丢数据。必须从服务端层面修正，且需同步更新已有对象。
执行以下 SQL（在 DBeaver 的 SQL 编辑器中运行）：
ALTER DATABASE <your_db_name> CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;</your_db_name>
但这只改了库级默认值，已有表和列仍保持旧编码。还需逐个修复：
- 改表：
ALTER TABLECONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 改单个字段注释（如 Hive 元数据）：
ALTER TABLE COLUMNS_V2 MODIFY COLUMN COMMENT VARCHAR(256) CHARACTER SET utf8mb4; - 确认
SHOW VARIABLES LIKE 'character_set%'中character_set_server和collation_server也已是 utf8mb4 相关值，否则新表默认还会回退
为什么改了连接属性还是乱码？检查这 3 个隐性层
常见现象是：连接属性全设对了，表也转成 utf8mb4 了，但查出来的中文还是问号或方块。问题往往出在更底层的链路环节：
- MySQL 服务端配置文件（
/etc/my.cnf或C:\ProgramData\MySQL\MySQL Server X.X\my.ini）里缺[mysqld]段的character-set-server=utf8mb4和collation-server=utf8mb4_unicode_ci - 客户端初始化语句没生效：在
[mysqld]下加init_connect='SET NAMES utf8mb4'，并确保用户有EXECUTE权限（否则 init_connect 会被跳过） - DBeaver 工作空间编码仍是 ISO-8859-1：菜单 →
窗口→首选项→常规→工作空间→文本文件编码改为UTF-8—— 这影响 SQL 脚本读取、导出 CSV、甚至建表语句里的中文注释显示
PostgreSQL / Oracle 连接乱码不能照搬 MySQL 设置
不同数据库的字符集协商机制完全不同，硬套 characterEncoding=UTF-8 会直接报错或被忽略。
PostgreSQL 必须在驱动属性里设：
-
client_encoding=UTF8 - 或 JDBC URL 加
?currentSchema=public&charSet=UTF8
Oracle 则依赖 NLS_LANG 环境变量，DBeaver 无法在界面里覆盖。若看到方块或问号，优先检查系统环境变量是否设为 AMERICAN_AMERICA.AL32UTF8（Linux/macOS 在 ~/.bashrc 里加 export NLS_LANG=AMERICAN_AMERICA.AL32UTF8；Windows 在系统属性→高级→环境变量里添加）。
最易被忽略的是：Oracle 的 NLS_LANG 必须与数据库服务端的 NLS_CHARACTERSET 完全匹配，差一个字符都会导致乱码，而这个值一旦数据库创建就基本固定，改起来成本极高。
