在php中Eval什么时候是evil?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (17)

在我开发php的这么多年来,我一直听说使用eval()是evil。

考虑到下面的代码,使用第二个(更优雅的)选项不是很有意义吗?如果没有,为什么?

// $type is the result of an SQL statement
// e.g. SHOW COLUMNS FROM a_table LIKE 'a_column';
// hence you can be pretty sure about the consistency
// of your string
$type = "enum('a','b','c')";

// possibility one
$type_1 = preg_replace('#^enum\s*\(\s*\'|\'\s*\)\s*$#', '', $type);
$result = preg_split('#\'\s*,\s*\'#', $type_1);

// possibility two
eval('$result = '.preg_replace('#^enum#','array', $type).';');
提问于
用户回答回答于

我会谨慎地称呼eval()是pure evil。动态评估是一个强大的工具,有时可以成为救命稻草。使用eval()可以解决PHP的缺点(见下文)。

eval()的主要问题是:

1. 潜在的不安全输入。传递不可信的参数是失败的一种方式。确保某个参数(或其中的一部分)完全可信是很重要的任务。

2. 技巧。使用eval()使代码更加灵活,因此更难以遵循。 调试的难度是编写代码的两倍,因此,如果n你尽可能巧妙地编写代码,则根据定义,你的调试不够巧妙 。

实际使用eval()的主要问题只有一个:

没有经验的开发者在没有足够的考虑的情况下使用它。

作为一个经验法则,我倾向于遵循这一点:

有时候eval()是唯一/正确的解决方案。

对于大多数情况下,人们应该尝试别的。

如果不确定,转到2。

否则,要非常小心。

用户回答回答于

Eval是evil,当用户输入被包含在计算字符串中的可能性很小的时候。当你在没有来自用户的内容的情况下执行val时,你应该是安全的。

然而,在使用val之前,你至少要考虑两次,它看起来非常简单,但是考虑到错误处理(请参阅VBAssassins的注释)、调试性等等,它不再是那么简单了。

因此,作为一个经验法则:忘记它。

扫码关注云+社区