phpmyadmin导出blob为0x...由导出页“使用十六进制表示二进制数据”选项及$cfg['protectbinary']配置共同控制；取消该选项并设$cfg['protectbinary']=false才能生成可兼容导入的转义字符串。
phpmyadmin 默认把 blob 字段当成二进制内容处理，导出时若启用十六进制选项，就会生成 0x... 格式；这不是 bug，而是它为“安全显示”做的默认选择——但这个选择常导致导入失败或数据截断。
导出 SQL 时 BLOB 变成 0x... 是谁控制的？
由 phpMyAdmin 导出页的「格式特定选项」中「使用十六进制表示二进制数据」勾选状态决定。该选项一开，所有 BLOB、TINYBLOB、MEDIUMBLOB、LONGBLOB 字段都会被转成 0xFFD8FFE0... 形式写入 INSERT 语句。
- 这个行为受配置项
$cfg['ProtectBinary']影响：设为true（默认）时，即使你没勾选，某些版本也会强制走十六进制路径 -
$cfg['TruncateAtLimit'] = true（默认）会进一步截断长 BLOB，导出内容只有一小段，后面是省略号 - 真正生效的是导出动作那一刻的页面选项，不是服务器配置——所以改
config.inc.php后仍需在导出页手动取消勾选
为什么 0x... 导入会失败或变 NULL？
因为 0x... 语法依赖 MySQL 服务端支持，且对 SQL mode 敏感。旧版 MySQL（如 5.6）、或启用了 STRICT_TRANS_TABLES / NO_BACKSLASH_ESCAPES 的实例，会直接拒绝解析或静默转为空值。
- 错误示例：
Incorrect integer value: '0xFFD8FFE0' for column 'image_data' - 更隐蔽的问题：没报错，但插入后
SELECT HEX(image_data)发现只有前几个字节，其余为00——这是因导入中途被截断 - 兼容性更好的方式是让 phpMyAdmin 用转义字符串导出：
'\xFF\xD8\xFF\xE0'，它靠单引号包裹 + 反斜杠转义，MySQL 所有版本都认
怎么让导出的 BLOB 是可读字符串而不是 0x...？
关键就两步：关掉十六进制开关 + 确保 PHP 配置不截断。
- 导出页 → 展开「格式特定选项」→ 取消勾选「使用十六进制表示二进制数据」
- 确认
$cfg['ProtectBinary'] = false和$cfg['TruncateAtLimit'] = false已写入config.inc.php（否则页面选项可能被覆盖） - 如果 BLOB 很大（>10MB），还得调高 PHP 限制：
memory_limit至少512M，max_execution_time设为0，并取消导出页的「压缩」勾选 - 实在导不出？别硬扛——换
mysqldump --hex-blob或--skip-extended-insert命令行，它不拼整条 SQL，不爆内存
导出 CSV 里含 0x... 十六进制，能直接导入回 BLOB 字段吗？
不能。phpMyAdmin 的 CSV 导入器完全忽略 0x 前缀，会把整个字符串当普通文本塞进字段，结果存的是 ASCII 字符 0xFF…，不是原始二进制。
- 必须用
LOAD DATA INFILE+UNHEX()：先上传 CSV 到服务器，再执行LOAD DATA INFILE '/path/file.csv' INTO TABLE t1 (id, @hex_data) SET image_data = UNHEX(@hex_data); - CSV 中该列必须严格为
0xFFD8FFE0...格式（无引号、无空格、偶数位） - 目标字段类型必须是
BLOB系列，不能是TEXT或VARCHAR，否则UNHEX()返回NULL
最易被忽略的一点：你以为在导出页取消了十六进制选项就万事大吉，但若 $cfg['ProtectBinary'] 在配置文件里仍是 true，phpMyAdmin 会无视你的勾选，照旧输出 0x...。动手前先查 config.inc.php。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
