【问题标题】:mysql_real_escape_string again if copying data?如果复制数据,再次mysql_real_escape_string?
【发布时间】:2011-03-29 11:32:12
【问题描述】:

在将数据放入数据库之前,我将其传递给mysql_real_escape_string

如果我想将相同的数据复制到另一个表中,是否需要在复制之前再次通过mysql_real_escape_string

我写了一个小脚本来测试这个问题,看起来答案是肯定的:

$db = new AQLDatabase();
$db->connect();

$title = "imran's color";
$title = mysql_real_escape_string($title);
$sql = "insert into tags (title, color) values  ('".$title."','@32324')";
$db->executeSQL($sql);

$sql = "select * from tags where color = '@32324' ";
$result = $db->executeSQL($sql);
while($row= mysql_fetch_array($result))
{
    $new_title =  $row['title'];
}

$new_title = mysql_real_escape_string($new_title);
$sql = "insert into tags (title, color) values  ('".$new_title."','DDDDD')";
$db->executeSQL($sql);

注意:如果我删除第二个 mysql_real_escape_string 调用,则不会进行第二次插入

【问题讨论】:

  • 复制是什么意思?从一个表中提取并通过 SQL 将其插入到另一个表中?
  • 在这种情况下,您需要再次申请mysql_real_escape_string,因为从数据库中检索到的数据将没有正确的转义序列。

标签: php mysql database escaping


【解决方案1】:

正在做这样的事情吗?

  1. 保存 mysql_real_escape_string($bla) 到数据库
  2. 从数据库中获取 $bla
  3. 再次保存 $bla(在另一个表中..)

从数据库中获取 $bla 将“取消转义”它,因此它可能再次成为有害字符串。保存时一定要再次转义。

【讨论】:

  • 好的,您的答案与其他答案完全不同。其他人则说没有必要再次逃避它。有什么资料可以支持你的答案吗?
  • @Imran 它在您自己的问题中说明。你的数据会进入数据库吗?你对进入数据库的数据做了什么?
  • 我只是将数据插入表中。然后使用php检索它并再次将其放入另一个表(复制)
  • @Imran 你从哪里得到它并不重要。您将其置于查询中-因此,正如您自己所说的那样,您必须逃避它。数据的来源并不重要。数据库或文件或外星人太空船 - 都无关紧要。听起来很明智?
【解决方案2】:

在我将数据放入数据库之前,我总是让它成为 Mysql_real_Escape_String 的东西。

你做得对。保持原样。虽然不是数据库,但查询它。

唯一的注意:只有 字符串 应该使用这个函数进行转义。它不应该与任何其他查询部分一起使用。

在复制之前我需要让它再次通过 Mysql_real_Escape_String 吗?

你不是已经回答你的问题了吗? Before I put [string-type] data into my [query] I always make it go the Mysql_real_Escape_String thing.你的数据是去SQL查询的吗?所以,这是你已经得到的答案。

【讨论】:

    【解决方案3】:

    好吧,如果您确定此数据已正确转义,则无需。

    mysql_real_escape_string 用于 1) 转义 2) 安全目的。由于它是您自己的数据库,并且只要您将数据传递到潜在黑客无法触及的另一个数据库 - 您就已经安全了

    【讨论】:

    • 2) 与这里无关。而且你不能确定数据是“你自己的”
    • @Col。当您将数据插入从用户获取的表中时,您需要对其进行转义。所有的。这可以保护您免受 SQL 注入攻击,因此是一种安全措施。如果您使用自己的数据,则可以跳过转义,除非您知道在这种特殊情况下需要它。例如,总是转义整数来自客户端,而不是来自你自己。
    • 真的吗?可能是,你能解释一下,为什么?
    • 迂腐注意:永远不要转义整数。将它们转换为正确的类型,并附加它们。转义字符串,而不是整数。最佳做法是始终逃避或绑定一切。然后你永远不会陷入糟糕的境地,因为有些事情发生了变化,你可以信任的东西在你不能再信任之前。始终将任何变量视为包含错误数据,除非您当时专门清理它...
    • @Col:这不是规则,因为您可以在不遵循它的情况下使其工作。您可以拥有一个已知的 ENUM 值,并且 100% 安全而无需转义它。最佳实践说我们应该总是逃避一切,但这不是一个硬性规则(有很多有效的情况不需要逃避)。这就是我说最佳实践的原因。
    【解决方案4】:

    它已经被转义了,直接复制它,如果你想撤销mysql_real_escape_string你可以使用stripslashes($sting)来移除它

    PD:这是错误的,现在我明白为什么了。

    【讨论】:

    • 这就是精神,我通常不回答问题,这对我继续尝试没有帮助..我认为告诉我们为什么它只是蹩脚会更有成效将其标记为la脚...
    • 数据库中的数据不会被转义。您不能使用 stripslashes() 撤消 mysql_real_escape_string() - 并非所有符号都会正确转换,例如 \r\n
    • mysql_real_escape_string 用于转义数据查询。一旦进入数据库,这些转义序列就消失了,如果您在另一个查询中使用它们,则需要再次应用它们。
    • @Col。弹片。你看,你的第二条评论对我们所有人都有帮助。首先,没有人 :) 谢谢!
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2019-05-17
    • 1970-01-01
    • 1970-01-01
    • 2012-04-13
    • 1970-01-01
    • 2014-03-23
    • 2018-01-17
    相关资源
    最近更新 更多