在平时的开发过程中，关于代码中存在
sql注入
的问题，想必大家都有所认识和了解，也都知道通用的解决方案。
但最近看到另外一种防止SQL注入的方式是这样的：
PHP 8.5.5
PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。
下载
即先使用PHP自带的函数
函数将输入待查询字符串处理成16进制字符串，然后再SQL执行过程中使用数据库本身的
函数将该16进制字符串反转为原先的正常字符串。
这样即便$name的值为
也会正常被当作查询字符串处理，而不存在SQL注入的问题了。
查了下相关资料，也没有弄明白这其中能够绕过SQL注入的原理，希望大家帮助解释下其中的原因。
谢谢~
回复内容：
在平时的开发过程中，关于代码中存在sql注入的问题，想必大家都有所认识和了解，也都知道通用的解决方案。
但最近看到另外一种防止SQL注入的方式是这样的：
即先使用PHP自带的函数
函数将输入待查询字符串处理成16进制字符串，然后再SQL执行过程中使用数据库本身的
函数将该16进制字符串反转为原先的正常字符串。
这样即便$name的值为
也会正常被当作查询字符串处理，而不存在SQL注入的问题了。
查了下相关资料，也没有弄明白这其中能够绕过SQL注入的原理，希望大家帮助解释下其中的原因。
谢谢~
bin2hex之后$name就全部转换成hex格式的数据了，在拼接到sql里面之后就不会产生存在漏洞的语句了。最好还是建议你让$name的值为
，然后把$sql的值echo一下就明白了。
因为unhex是
mysql
函数，在mysql里面执行自然就没问题了。
SELECT * FROM
WHERE
= unhex('6d6172617472697827206f722031203d2031');
name无论啥值，都不会拆分sql了。
$sql = sprintf("SELECT * FROM `test1` WHERE `name` = unhex('%s')", bin2hex($name));
bin2hexunhex'maratrix' or 1 = 1$sql = sprintf("SELECT * FROM `test1` WHERE `name` = unhex('%s')", bin2hex($name));
bin2hexunhex'maratrix' or 1 = 1maratrix' or 1 = 1test1name