3

我试图弄清楚如何解释PHP 的include结构，例如它是否是文本包含、何时评估等。像往常一样，文档是相当非正式和模糊的。

根据实验，它似乎是语法糖。具体来说，构造

include 'Baz.php'

是一个可以替换为的表达式

eval('?>' . file_get_contents('Baz.php',  FILE_USE_INCLUDE_PATH))

这个对吗？这种替换在一般情况下是正确的，还是仅在我的测试中是正确的？

编辑：正如 bwoebi 所指出的，这通常不是真的，因为 uatedeval代码没有相同的__DIR__和__FILE__魔法常数。如果有一些方法可以设置它们，我们也可以建模。

编辑 2：这个问题是这个问题的副本：Equivalent of include using eval。但是，那里的所有答案似乎都忽略了 bwoebi 关于文件路径上下文的观点。

4

2 回答 2

2

是的，这通常应该是正确的。

唯一的区别是：

  • 文件上下文（现在是eval()'ed code，不是该文件中的代码）
  • 相对路径：当您在其他目录中包含文件并且它们使用自己的相对路径时，它指向的文件现在可能找不到了
  • file_get_contents()不受allow_url_includeini 设置的影响（尽管allow_url_fopen两者都影响）
于 2014-05-15T14:46:43.277 回答
0

其他需要注意的是：

  • 这将破坏 PHP Opcode 缓存，因为文件内容作为文本被读入内存，然后被解析/评估，如果您不期望它会对性能产生重大影响。正如这个问题中提到的。
  • 代码中的解析错误不会对脚本的其余部分造成致命影响，这具有允许脚本继续执行的副作用，即使预期发生的逻辑可能没有发生。（这也可能适用于其他类型的错误）。
  • 错误报告不会解析到正确的文件/行，因此调试会变得困难。
  • 这将不支持该_once构造，该构造允许严格包含/要求文件一次。这意味着重复的类/函数声明将是致命的和/或行为异常。

我确信还有其他考虑因素也使这不明智。在不知道您想要的功能或您需要这样做的原因的情况下，很难给您一个有用的答案。

利用的最好的部分eval是从错误中恢复（如果你可以称之为“最好”的事情）。但是，如果这是您试图利用的好处，那么这是您唯一的选择……不幸的是……

于 2014-05-15T15:32:44.260 回答