先说几个核心判断：当你在 RDM 中双击某个 Key，看到的却是一堆十六进制字符、问号、方框，甚至一片空白——那通常不是 Redis 存错了。

而是 RDM 这边“看错了”——它用的解码格式和你实际存储的字节对不上。

要验证这一点，方法很简单：直接在 RDM 界面上选中那个有问题的 Key，右键 → “View in Console”，然后执行一条 GET key_name。

如果控制台里能正常返回中文，但主界面显示的却是 test 或 xe4xb8xadxe6x96x87 这样的乱码——那就可以下定论：100% 是 RDM 本地解码的问题，跟 Redis 存储本身无关。

反过来，如果控制台里也是乱码，你才需要去排查 Redis 服务端是不是用了非 UTF-8 的方式写入数据（比如 Java 应用忘了给 StringRedisTemplate 指定编码）。

这一步千万别跳过。很多人花上几个小时去改 Redis 的配置文件，最后发现，其实只要在 RDM 里点三下鼠标就能解决。

确认乱码表现并定位问题根源

实际操作中，先在 RDM 里挑一个中文或特殊字符明显的 Key，用上面说的 Console 方式确认一次。

这一步的核心价值在于：它能帮你快速把问题锁定在“客户端显示”还是“服务端存储”上。

方向一旦搞错，后面的所有操作都是在做无用功。

立即生效的编码设置法（推荐）

确认是 RDM 解码问题后，处理方法有两种，都很直接。

方法一：全局强制 UTF-8 解码

这个设置会作用于所有数据库。操作路径：顶部菜单栏 Edit → Preferences → Encoding，把 Text Encoding 下拉框改成 UTF-8，然后点 OK。

方法二：按数据库单独指定

如果你在同一个 RDM 里连接了多套业务的数据，且它们的编码方式不同，这个方法更灵活。在左侧数据库列表上右键目标库（比如 “db 1”），选择 Change Encoding…，弹窗里选 UTF-8，确认即可。这个设置只对该库生效。

改完之后，必须断开连接再重新连一次，或者直接重启 RDM。不重连的话，新编码不会生效——这是最容易被忽略的细节，很多人改完发现没变化，就是因为漏了这一步。

高级排查：当 UTF-8 仍无效时

有些场景下，即便你已经把编码切到了 UTF-8，问题可能依然没解决。这时需要再往下走几步。

第一步：检查 RDM 当前对这个 Key 实际用的什么解码

双击打开 Key 的详情页，在右侧面板底部会有一个 “Encoding:” 字段。它会明确告诉你当前在用什么格式解析，比如 Latin1、System Default 之类的。如果这里写的是 Latin1，而你确定数据就是用 UTF-8 存的，那说明你刚才那两步设置没生效——大概率是没重连。

第二步：用命令行验证原始字节

绕过界面显示，直接在 RDM 的内置 Console 里执行 DEBUG OBJECT key_name，看输出中的 encoding 字段值，比如 encoding:raw。

然后再执行 GET key_name | xxd -g1（需要 RDM v2024.1 以上版本支持），看看返回的十六进制字节是不是符合 UTF-8 的编码规则。

比如中文通常以 e4 到 ef 开头。如果是其他模式，那数据本身的编码可能就和你想的不一样。

第三步：强制以 UTF-8 重载当前 Key

如果不想全局改配置，只是临时看一眼某个 Key，还有一个更快的方法：在 Key 详情页的右上角，找到 Reload as UTF-8 那个按钮（图标是一个带 UTF-8 标识的循环箭头），点一下就能即时刷新显示，不需要断连。

《夸克》非常好用的免费AI浏览器

下载APP查看