揭开转义之谜：揭秘 MySQL 通配符
在数据库交互领域，对用户输入的细致处理对于防范至关重要潜在的漏洞。此任务通常需要转义特殊字符，否则可能会中断 SQL 查询。在 PHP 中，mysql_real_escape_string 扮演了逃脱艺术家的角色，巧妙地转换用户输入以实现 MySQL 兼容性。
但是，某些字符带来了独特的挑战。虽然 mysql_real_escape_string 巧妙地处理引号和撇号等字符，但它使 MySQL 通配符 % 和 _ 容易被误解。为了解决这个疏忽，PHP 的 addcslashes 作为一个诱人的补充出现，为这些难以捉摸的字符提供了一条逃生路线。
然而，当进行测试时，一个奇怪的结果出现了。在插入和随后从数据库中检索时，下划线（_）会以莫名其妙的前面反斜杠脱颖而出，而引号（“）和撇号（'）保持不变。这种看似不一致的行为困扰了许多程序员。
解开这个谜团的关键在于 MySQL 中通配符的性质，与通常的看法相反，% 和 _ 并没有被普遍认为是通配符。仅在 LIKE 匹配的上下文中出现。当在 LIKE 语句中使用时，这些字符充当特殊符号的角色，在字符串准备过程中需要额外注意。
在字符串文字转义领域，mysql_real_escape_string 占据主导地位。然而，当冒险进入 LIKE 匹配领域时，出现了第二层转义，该层称为 LIKE 转义，要求对 _ 和 % 进行修饰。具有转义字符，通常是 . 讽刺的是，在 MySQL 中，LIKE 转义的转义字符也是反斜杠 ()，与字符串文字转义所使用的字符相同。
因此，使用 _ 遇到的令人困惑的行为是这是双重使用反斜杠的结果。数据库正确地将前面的反斜杠解释为 LIKE 转义的指示，随后在存储和检索期间将其删除。但是，引号 (") 和撇号 (') 不受 LIKE 转义的影响，保留其原始转义字符。
要驾驭这种复杂性，需要更全面的方法。支持参数化查询通过像 PDO 这样的 PHP 扩展，通过利用用户输入的占位符，参数化查询将转义的责任委托给数据库本身，这种方法消除了手动转义的需要。所有字符的处理都是一致的。
或者，对于那些喜欢手动操作字符串的人来说，可以制作自定义转义函数来解决 LIKE 转义和字符串文字转义问题。通过将两层转义合并到一个函数中，开发人员可以确保用户输入经过精心转换，以实现无缝数据库集成。
总而言之，了解 MySQL 通配符的细微差别和 LIKE 转义的复杂性对于有效的数据处理。通过采用同时考虑 LIKE 转义和字符串文字转义的整体方法，程序员可以保护其数据库操作并防止意外行为。
以上是如何在 PHP 中正确转义 MySQL 通配符 (%) 和下划线 (_) 以避免意外行为？的详细内容。更多信息请关注PHP中文网其他相关文章！
