什么时候（如果有的话） eval 不是邪恶的？

Question

我听说过很多放置 PHP 的eval 函数是 通常不是答案。根据 PHP 5.3 的 LSB 和 < a href="http://php.net/manual/en/functions.anonymous.php" rel="nofollow noreferrer">闭包 我们已经没有理由依赖 eval 或 create_function。

是否存在任何可能的情况，其中eval是 PHP 5.3 中最好（唯一？）的答案？

这个问题不是关于eval总体上是否是邪恶的，因为它显然不是。

答案摘要：

• 评估数值表达式（或 PHP 的其他“安全”子集）
• 单元测试
• 交互式 PHP “shell”
• 受信任的 var_export 反序列化
• 一些模板语言
• 为管理员和/或黑客创建后门
• 与 var_export 的兼容性PHP 5.3
• 检查语法（可能不安全）

Answer 1

如果您正在编写恶意软件，并且想让试图清理您的系统管理员的日子不好过。根据我的经验，这似乎是最常见的用例。

Answer 2

Eric Lippert 总结了三篇博客文章的评估。这是一本非常有趣的读物。

据我所知，以下是使用 eval 的一些唯一原因。

例如，当您根据用户输入构建复杂的数学表达式时，或者当您将对象状态序列化为字符串以便可以存储或传输以及稍后重构时。

Answer 3

eval 的主要问题是它成为恶意代码的网关。因此，您永远不应该在可以从外部利用它的上下文中使用它，例如用户提供的输入。

一种有效的用例是模拟框架。

来自 PHPUnit_Framework_TestCase::getMock() 的示例

// ... some code before

    $mock = PHPUnit_Framework_MockObject_Generator::generate(
      $originalClassName,
      $methods,
      $mockClassName,
      $callOriginalClone,
      $callAutoload
    );

    if (!class_exists($mock['mockClassName'], FALSE)) {
        eval($mock['code']);
    }

// ... some code after

实际上，generate 方法中发生了很多事情。通俗地说：PHPUnit 将采用 generate 的参数并从中创建一个类模板。然后它将eval该类模板以使其可用于实例化。当然，这样做的目的是让 TestDoubles 模拟 UnitTests 中的依赖关系。

Answer 4

如果您正在编写一个解释和执行 PHP 代码的网站，就像交互式 shell 一样。

...

我是一个系统人员，这就是我所拥有的一切。

Answer 5

您可以使用 eval 来创建临时类：

function myAutoLoad($sClassName){

   # classic part
   if (file_exists($sClassName.'.php'){

      require $sClassName.'.php';

    } else {

      eval("
            class $sClassName{
                public function __call($sMethod,$aArgs){
                     return 'No such class: ' . $sClassName;
                 }
                }");

    }

} 

当然，尽管使用非常有限（一些 API 或可能是 DI 容器、测试框架、必须处理具有动态结构的数据库的 ORM、代码游乐场）

Answer 6

eval 是一个可用于检查语法错误的构造。

假设您有以下两个 PHP 脚本：

script1.php

<?php
// This is a valid syntax
$a = 1;

script2.php

<?php
// This is an invalid syntax
$a = abcdef

您可以使用 eval 检查语法错误：

$code1 = 'return true; ?>'.file_get_contents('script1.php');
$code2 = 'return true; ?>'.file_get_contents('script2.php');

echo eval($code1) ? 'script1 has valid syntax' : 'script1 has syntax errors';
echo eval($code2) ? 'script2 has valid syntax' : 'script2 has syntax errors';

与 php_check_syntax （无论如何已弃用并删除），代码将不会被执行。

编辑：

另一个（首选）替代方案是 php -l 。如果您无权访问 system() 或 shell 执行命令，则可以使用上述解决方案。

此方法可以在代码中注入类/函数。执行此操作之前，请务必强制执行 preg_replace 调用或 namespace，以防止它们在后续调用中执行。

至于OP主题：什么时候（如果有的话）eval不是邪恶的？ eval根本就不是邪恶的。程序员无缘无故地使用eval是邪恶的。 eval 可以缩短您的代码（例如数学表达式评估）。

Answer 7

我发现有时一种语言的大多数功能都是有用的。毕竟，即使 GOTO 有其支持者。 Eval 在许多框架中都有使用，并且使用得很好。例如，CodeIgniter 使用 eval 来区分 PHP 4 和 PHP 5 实现的类层次结构。允许执行 PHP 代码的博客插件肯定需要它（这是 Expression Engine、Wordpress 等中可用的功能）。我还将它用于一个网站，其中一系列视图几乎相同，但每个视图都需要自定义代码，并且创建某种疯狂的规则引擎要复杂得多且速度慢得多。

虽然我知道这不是 PHP，但我发现 Python 的 eval 使基本计算器的实现变得更加简单。

基本上，问题是：

1. eval 是否使它更容易阅读？我们的主要目标之一是与其他程序员交流我们编写本文时的想法。在 CodeIgniter 示例中，他们想要实现的目标非常清楚。
2. 还有别的办法吗？如果您使用 eval（或变量，或任何其他形式的字符串查找或反射语法），很可能还有另一种方法可以实现。您是否已用尽其他选择？您的输入集是否受到合理限制？可以使用switch语句吗？

其他考虑因素：

1. 它可以安全吗？有没有办法让一段杂散的代码进入 eval 语句？
2. 可以使其一致吗？在给定输入的情况下，您能否始终一致地产生相同的输出？

Answer 8

合适的场合（考虑到缺乏简单的替代方案）是使用 var_export 序列化可信数据并且有必要对其进行反序列化。当然，它不应该以这种方式序列化，但有时错误已经完成。

Answer 9

我想，应该在代码实际需要编译的地方使用 eval。我的意思是这样的情况，比如模板文件编译（为了性能而将模板语言编译成 PHP）、插件钩子编译、出于性能原因的编译等。

Answer 10

您可以使用 eval 创建一个设置，以便在安装系统后添加代码。通常，如果您想更改服务器上的代码，则必须添加/更改现有的 PHP 文件。另一种方法是将代码存储在数据库中并使用 eval 来执行它。不过，您必须确保添加的代码是安全的。

将其视为一个插件，只是一个可以做任何事情的插件...

您可以想到一个网站，该网站允许人们贡献代码片段，然后用户可以将这些代码片段动态添加到他们的网页中 - 而无需他们实际将代码保留在网站上。网络服务器文件系统。不过，您需要的是批准流程......

Answer 11

这个 eval 争论实际上是对 php 的一个很大的误解。人们被洗脑认为 eval 是邪恶的，但通常他们使用 include 没有问题，尽管 include 本质上是同一件事。 Include foo 与 eval file_get_contents foo 相同，因此每次包含某些内容时，您都会犯下 eval 的大罪。

Answer 12

兼容性。提供 PHP4 后备方案是很常见的。但同样，也可能希望在 5.3 中模拟 PHP5.4 功能，例如 SplString。虽然简单地提供两个包含变体（include.php4 与 include.php5）很常见，但有时使用 eval() 会更有效或更具可读性：

 $IMPL_AA = PHP_VERSION >= 5 ? "implements ArrayAccess" : "";
 eval(<<<END
     class BaseFeature $IMPL_AA {

在这种情况下，代码可以在 PHP4 上工作，但仅在 PHP5 上公开更好的 API/语法。请注意，该示例是虚构的。

Answer 13

当我有一个 php 引擎的机器人与我通信时，我使用了 eval，我可以告诉它通过 EVAL：此处的 php 命令执行命令。仍然是邪恶的，但如果您的代码不知道会发生什么（如果您从数据库中提取一段 PHP 代码），那么 eval 是唯一的解决方案。

Answer 14

因此，这对于所有带有 eval 的语言都适用：

基本上，除了少数例外，如果您正在构建传递给 eval 的值或从非可信源获取它你做错了什么。如果您在静态字符串上调用 eval，同样如此。

除了在运行时初始化解析器的性能问题和安全问题之外，您通常还会弄乱类型系统。

更严重的是，事实证明，在绝大多数情况下，有更优雅的解决方案。然而，与其完全禁止该构造，不如将其视为人们可能goto的做法。两者都有合法的用途，但这是一个很好的危险信号，应该让您思考是否以正确的方式解决问题。

根据我的经验，我只发现属于插件和特权用户（例如网站管理员，而不是此类用户）扩展类别的合法用途。基本上，充当来自可信来源的代码的东西。

Answer 15

不是直接使用，而是 preg_replace 的 /e 修饰符利用 eval 并且非常方便。请参阅 http://php.net/preg_replace 上的示例 #4。

它是否是邪恶/坏是主观的，完全取决于你在特定背景下认为“好”的东西。当处理不受信任的输入时，它通常被认为是不好的。但是，在其他情况下它可能很有用。想象一下在极端的截止日期压力下编写一次性数据转换脚本。在这种情况下，如果 eval 起作用并且使事情变得更容易，我就很难称其为邪恶。