PHP 中两次转义引号
我有一个复杂的表单，我首先必须采用一些 $_GET 参数，显然我必须对它们执行 mysql_real_escape_string() ，因为我在数据库中查找内容他们。
对我来说，他们的问题是在初始数据库查找之后。当用户提交表单时，我将它们作为 $_POST 请求发送，显然必须再次执行此 mysql_real_escape_string 调用，以防万一有人试图使用伪造的表单提交。
然后我遇到的问题是参数被转义了两次，我的查询开始看起来很奇怪，如下所示：
select field1 , field2 , from my_table where some_id = \'.$lookup_id.\' ...
所以系统似乎添加了 \' 这让我很困惑:) 另外，在我的其他形式中我还没有看到这样的行为。关于可能导致这种情况的原因有什么想法吗？
一件奇怪的事情是我尝试将未转义的参数发送到帖子，并且发生了同样的问题。这是一条线索，但对我来说还不够。 :(
I have a complicated form where I first have to take some $_GET parameters and obviously I have to do a mysql_real_escape_string() on them since I look stuff up in the database with them.
Them problem for me is after the initial db lookup. When the user submits a form, I send them along as a $_POST request and obviously have to do this mysql_real_escape_string call again just in case someone tries to hack my site with a faked form submission.
Then the problem I have is the arguments are escaped twice and my queries begin to look strange like this:
select field1 , field2 , from my_table where some_id = \'.$lookup_id.\' ...
So the system seems to be adding \' and it is messing me up :)
Also, in my other forms I have not seen such behavior. Any ideas on what may be causing this?
One weird thing is that I tried to send unescaped parameters to the post, and the same problem happens. That is a clue, but not a sufficient one for me. :(
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
条斜线 http://php.net/manual/en/function.stripslashes.php 函数可能有用 - 在转义之前运行它？
The stripslashes http://php.net/manual/en/function.stripslashes.php function may be of use - run that before you do your escaping?
在 php 中查看此设置：
http://www.tizag.com/phpT/ php-magic-quotes.php
See this setting in your php :
http://www.tizag.com/phpT/php-magic-quotes.php
您应该使用准备好的语句，这种语句被认为更安全，因为用户提交的字符串永远不会被解析为 SQL 语句，从而降低 SQL 注入风险。
由于不解析用户字符串，因此不需要转义特殊字符。
you should use prepared statements which are considered safer because user submitted string are never parsed as SQL statement, thus reducing the sql injection risk.
As user strings are not parsed, you don't need to escape special chars.