Eval

title: 安全风险.
content: 当使用 codice_1 而数据来自不可信任的来源时,一定要特别的注意。比如说,假设 codice_5 函数从 Internet 获取数据,这个 Python 代码就是不安全的:  一个攻击者可以让字符串 codice_6 作为数据提供给这个程序,它将会更新 codice_7 字典以设定一个通过身份验证的键为 True。为了补救这一点,所有将会被 codice_1 使用的数据必须被转义,或者必须运行于无法访问可能有害的函数的环境下。
title: 使用.
content: 对 codice_1 的调用有时被没经验的程序员在所有种类的事物上使用。在绝大多数情况下,有更加灵活而不会造成解析代码时速度损失的可替代的方法。  比如说,codice_1 有时被用于一个简单的邮件合并设施上,就像如下 PHP 代码所示:  尽管这确实有用,它可能导致一些安全问题 (见安全风险),而且比其它的解决方案慢很多。一个更快和更安全的解决方案可以是改变最后一行为 codice_11 和移除前一行的单引号,或者使用 codice_12。  codice_1 有时也被用于需要对数学表达式求值的应用中,如电子试算表。这比写一个表达式解析器简单多了,但是发现或者写出一个表达式解析器通常是一个更好的选择。除了可修复的安全风险,使用这种语言的求值特性通常很有可能更慢,也没有那么高的可定制性。  也许 codice_1 的最佳使用是在 bootstrapping 一个新的语言的过程中 (就像 Lisp 那样),以及作为语言的允许用户在受控制的环境下运行他们自己的程序的指导程序。  出于表达式求值的目的,eval 相比表达式解析器的主要优势在于,在 codice_1 受支持的绝大多数编程环境下,这个表达式可能是任意的复杂,而且可能包括对使用者所写的不可能被解析器的创造者所预先知道的函数的调用。这个能力允许你用一个你可以按需要增强的函数库有效的增加 eval() 引擎,而不必持续的维持一个表达式解析器。然而,如果你不需要这么终极的灵活性,表达式解析器远远更加有效和轻量。
title: 实施.
content: 在直译语言中,codice_1 几乎总是被和正常的代码使用一样的解析器实现。在编译语言中,用于编译程序的编译器可能被嵌入在使用 codice_1 的程序中; 分开来的解释器有时也被使用,尽管这可能会导致重复代码。
title: 程序语言.
title: JavaScript.
content: 在 JavaScript 中,codice_1 是某种介于表达式求值器和语句执行器的混合体。它返回最后一个被求值的表达式的值 (在 JavaScript 中,所有语句都是表达式),也允许最后一个分号省略。  如下示例是一个表达式求值器: 如下示例则是一个语句执行器。  JavaScript 的 codice_1 的一个应用是解析 JSON 文本,也许是作为 Ajax 框架中的一部分。然而,现代的浏览器提供 codice_20 作为这个任务的一个更加安全的替代品。
title: ActionScript.
content: 在 ActionScript (Flash 的编程语言) 中,codice_1 不能用于计算任意的表达式。根据 Flash 8 文档,它的使用仅限于代表“变量名,属性,对象或者要检索的影片剪辑。这个参数可以是一个字符串或者对对象实例的一个直接引用”的表达式。  ActionScript 3 不支持 eval。  ActionScript 3 Eval Library 和 D.eval API 是进行中的用以在 ActionScript 3 中创建 codice_1 的等价物的开发项目。
title: Lisp.
content: Lisp 是首先使用 codice_1 函数的语言。事实上,对 codice_1 函数的定义导致了该语言解释器的最初的实施。在 codice_1 函数被定义之前,Lisp 函数只是手动被编译成汇编语言语句。然而,一旦 codice_1 函数被手动编译,它随后就被用于组成第一个 Lisp 解释器的基础的Read–eval–print循环的一部分。  Lisp codice_1 函数的后来版本也被作为编译器实施。  Lisp 中的 codice_1 函数期望一个形式作为一个参数被求值和执行。给定形式的返回值将会是对 codice_1 的调用的返回值。  这是一个示例 Lisp 代码:  Lisp 众所周知的非常灵活,codice_1 函数也是。例如,为了对字符串的内容求值,这个字符串首先必须使用 codice_31 函数转化为 Lisp 格式,随后这个结果的格式将会被传给 codice_1:  主要造成混淆的一点是这个问题,即在哪个上下文中这个形式中的符号会被求值。在上述示例中,codice_33 包含符号 +。对该符号的求值必然会产生一个用于加法的函数以使得该示例像预期那样工作。因而 Lisp 的某些方言允许为 codice_1 传入一个额外的参数以指定求值的上下文 (类似于 Python 的 codice_1 函数的可选参数 - 如下所示)。一个用 Lisp 的 Scheme 方言 (RRS 和以后版本) 写出的示例:
title: Perl.
content: 在 Perl 中,codice_1 函数是某种介于表达式求值器和语句执行器的混合体。它返回最后一个被求值的表达式的结果 (在 Perl 编程中,所有的语句都是表达式),且允许最后一个分号省略。  一个表达式求值器的示例:  一个语句执行器的示例:  Perl 也有 codice_1 "块",作为它的异常处理机制。这与上述对 codice_1 传入字符串的用法不同,在于 codice_1 内的代码在编译时而不是运行时解释,所以它不是本文中使用的 codice_1 的含义。
title: PHP.
content: 在 PHP 中,codice_1 执行在一个字符串中的代码几乎就像它被放进了文件中,而不是对 codice_44 的调用一样。唯一的区别是错误被报道为来自对 codice_44 的一个调用,而返回语句则成为函数的结果。

Summary: 在一些程序语言中,eval 是一个把字符串当作表达式执行而返回一个结果的函数;在另一些之中,它执行多行的代码就好像它们被包括在其中,而不是包括 codice_1 的这一行。codice_1 的输入不一定是字符串;在支持句法抽象的语言(如 Lisp)中,codice_1 的输入将会由抽象句法形式组成。

Eval: In some programming languages, codice_1 is a function which evaluates a string as though it were an expression and returns a result; in others, it executes multiple lines of code as though they had been included instead of the line including the codice_1. The input to codice_1 is not necessarily a string; it may be structured representation of code, such as an abstract syntax tree (like Lisp forms), or of special type such as codice_4 (as in Python). The analog for a statement is codice_5, which executes a string (or code in other format) as if it were a statement; in some languages, such as Python, both are present, while in other languages only one of either codice_1 or codice_5 is.