navicat 16 不支持为 binary/varbinary/blob 字段设置全局十六进制显示格式，需在 select 中用 hex() 或 concat('0x', hex(col)) 转换，插入时用 x'' 或 unhex()，字段属性中的 binary 仅影响排序行为，与显示无关。
navicat 16 本身不提供“为字段设置二进制显示格式”的全局配置项——它不会自动把 binary、varbinary 或 blob 字段的内容默认渲染成十六进制字符串。你看到的乱码或不可读字节，是 navicat 按原始字节展示的结果；想让它以 0x1a3f... 形式显示，得靠查询时显式转换。
在 SELECT 查询中用 HEX() 函数转成十六进制字符串
这是最常用、也最可控的方式：不改表结构，只改查法。
-
HEX()函数会把二进制值（如BINARY(16)或BLOB）转成大写十六进制字符串，比如0x48656C6C6F→'48656C6C6F' - 若要带
0x前缀，可用CONCAT('0x', HEX(col)) - 注意：
HEX(NULL)返回NULL，不是空字符串；如果字段允许 NULL，建议加IFNULL()处理 - 示例语句：
SELECT id, CONCAT('0x', HEX(data)) AS hex_data FROM my_table;
插入或更新时用 X'' 或 UNHEX() 写入十六进制字面量
你不能在 Navicat 的网格视图里直接输入 0x1a3f 并期望它被存成二进制——必须用 SQL 显式解析。
- 写入固定长度二进制数据（如 UUID）：用
X'1a3f7e'字面量，MySQL 自动转为BINARY值 - 写入变长或需兼容性更强的数据：用
UNHEX('1A3F7E')，大小写不敏感，且可处理奇数长度（自动补 0） - Navicat 的“编辑数据”网格不支持直接识别十六进制输入，强行粘贴
0x...会被当普通字符串存入（可能触发字符集转换错误） - 正确做法：右键表 → “打开表” → 点击工具栏“SQL”按钮 → 手写
INSERT INTO t (bin_col) VALUES (X'1a3f');
为什么勾选字段属性里的 Binary 不等于显示十六进制
这是最容易混淆的一点：Binary 在 Navicat 表设计里的复选框，只影响 VARCHAR/TEXT 类型的**比较行为**，和显示格式完全无关。
- 它等价于在 DDL 中加
VARCHAR(50) BINARY，让排序/索引按字节而非字符进行（区分大小写、不忽略尾部空格） - 该字段仍存 UTF-8 文本，
SELECT出来还是原文，不是十六进制 - 如果你真要存二进制并希望显示为十六进制，请确认字段类型是
BINARY、VARBINARY或BLOB，而不是勾选VARCHAR的 Binary 复选框 - Navicat 对
BLOB/VARBINARY字段，在数据网格里默认显示为「[BLOB]」，双击才弹出二进制查看器——那里也**不自动转 HEX**，只是提供十六进制/ASCII 双栏预览
用 Navicat 的二进制查看器手动看字节，但别依赖它做展示
当你双击一个 BLOB 或 VARBINARY 字段，会弹出“查看/编辑二进制数据”对话框——这是唯一内置的二进制可视化入口。
- 左侧是十六进制字节（每行 16 字节），右侧是对应 ASCII 显示（不可见字符显示为
.） - 你可以复制某段十六进制内容（如
1a 3f 7e），但无法一键导出为0x1a3f7e格式字符串 - 它不支持搜索、高亮或批量导出，仅适合临时调试小数据
- 对超过几 MB 的 BLOB，加载会卡顿，且不显示完整长度——此时必须用
HEX(col)+SUBSTRING()在 SQL 中分段查
真正需要“字段值恒定以十六进制形式呈现”的场景，本质是业务逻辑需求，不是 Navicat 能配置出来的。要么在应用层统一处理，要么在 SQL 查询层强制套 HEX() —— 别在 Navicat 界面找那个不存在的“二进制显示开关”。
