phpmyadmin 默认不使用十六进制导出，0x格式通常源于navicat、dbeaver等工具或自定义脚本；排查应先确认导出工具及bom/十六进制字节，再检查字符集（utf8mb4）和sql导出选项。
phpMyAdmin 默认不会把字段值转成十六进制，所以“防止十六进制转换错误”这个动作本身是多余的——除非你手动改过配置或用了非标准插件。真正出问题的，通常是 Navicat、DBeaver 或某些命令行工具导出时开了 hex 选项，而你误以为是 phpMyAdmin 干的。
为什么你看到的 SQL 里有 0x 开头的值？
phpMyAdmin 导出的 INSERT 语句默认用字符串字面量，比如 INSERT INTO t VALUES ('hello', 0x616263) 这种写法在 phpMyAdmin 原生导出中几乎不会出现。如果你在导出的 .sql 文件里看到大量 0x48656C6C6F 这类内容，基本可以确定：
- 你根本没用 phpMyAdmin 导出，而是用了 Navicat（开了「使用十六进制」）或 DBeaver（导出设置选了 Hex encoding）
- 或者你用的是某个定制版 phpMyAdmin，后端被魔改过（极少见）
- 也可能是你用 Python/PHP 脚本拼 SQL 时手动调了
bin2hex()，再喂给 phpMyAdmin 执行导出
phpMyAdmin 导出时真正要盯住的编码和格式开关
它不碰十六进制，但会因字符集和格式设置不当导致乱码、截断或导入失败。关键点如下：
- 导出页面 →「格式」选项卡 →「导出字符集」必须设为
utf8mb4（不是utf8，也不是自动） - 「格式」下拉菜单选
SQL，别选CSV或JSON后再手动改后缀——那不是 SQL 导出逻辑 - 「对象创建选项」里勾上
Add DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT，否则导入时表冲突不报错，但数据错位 - 「数据处理选项」里勾上
Complete inserts（即带字段名的 INSERT），避免字段顺序变化导致插错列
导出后发现 SQL 文件里真有 0x 字段？先确认是不是 BOM 或粘包问题
有时候你以为是十六进制，其实是 UTF-8 BOM（\xEF\xBB\xBF）被编辑器渲染异常，或者导出时混入了其他工具生成的内容。快速验证方法：
- 用
head -c 20 your_file.sql | xxd看开头几个字节：如果是ef bb bf，那是 BOM，不是十六进制 - 搜索文件里第一个
0x出现的位置：如果只在某几行（比如 BLOB 字段），且出现在INSERT值部分，那大概率是上游工具写的，不是 phpMyAdmin - 打开 phpMyAdmin 的「查询」页，直接执行
SELECT HEX(blob_col) FROM t LIMIT 1—— 如果结果是0x...，说明你查的就是十六进制值，不是导出机制的问题
真正麻烦的从来不是“怎么关十六进制开关”，而是导出前没确认工具链归属、导出后没用十六进制查看器扫一眼开头三字节、以及把 Navicat 的锅当成 phpMyAdmin 的 bug 来调——这些细节一旦漏掉，排查方向就全偏了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
