javascript - JavaScript的eval（）什么时候不邪恶？(When is JavaScript's eval() not evil?)

Question

I'm writing some JavaScript code to parse user-entered functions (for spreadsheet-like functionality).

(我正在编写一些JavaScript代码来解析用户输入的功能（用于类似于电子表格的功能）。)

Having parsed the formula I could convert it into JavaScript and run eval() on it to yield the result.

(解析了公式之后，我可以将其转换为JavaScript并对其运行eval()以产生结果。)

However, I've always shied away from using eval() if I can avoid it because it's evil (and, rightly or wrongly, I've always thought it is even more evil in JavaScript, because the code to be evaluated might be changed by the user).

(但是，如果可以避免使用eval() ，我总是避免使用它，因为它是邪恶的（并且，无论正确与否，我一直认为它在JavaScript中更加邪恶，因为要评估的代码可能会更改由用户）。)

So, when it is OK to use it?

(那么，何时可以使用它呢？)

  ask by Richard Turner translate from so

Answer 1

I'd like to take a moment to address the premise of your question - that eval() is " evil ".

(我想花一点时间来解决您的问题的前提-eval（）是“ 邪恶的 ”。)

The word " evil ", as used by programming language people, usually means "dangerous", or more precisely "able to cause lots of harm with a simple-looking command".

(编程语言人员所用的“ 邪恶 ”一词通常表示“危险”，或更确切地说，“能够通过简单的命令造成大量伤害”。)

So, when is it OK to use something dangerous?

(那么，什么时候可以使用危险的东西呢？)

When you know what the danger is, and when you're taking the appropriate precautions.

(当您知道危险所在以及采取适当的预防措施时。)

To the point, let's look at the dangers in the use of eval().

(到目前为止，让我们看一下使用eval（）的危险。)

There are probably many small hidden dangers just like everything else, but the two big risks - the reason why eval() is considered evil - are performance and code injection.

(就像其他所有事物一样，可能存在许多小的潜在隐患，但是性能和代码注入是两个大隐患-eval（）被认为是邪恶的原因。)

• Performance - eval() runs the interpreter/compiler.

  (性能-eval（）运行解释器/编译器。)

  If your code is compiled, then this is a big hit, because you need to call a possibly-heavy compiler in the middle of run-time.

  (如果您的代码已编译，那么这将是一个很大的成功，因为您需要在运行时中途调用可能很重的编译器。)

  However, JavaScript is still mostly an interpreted language, which means that calling eval() is not a big performance hit in the general case (but see my specific remarks below).

  (但是，JavaScript仍主要是一种解释型语言，这意味着在一般情况下调用eval（）不会对性能造成很大的影响（但请参阅下面的我的特别评论）。)

• Code injection - eval() potentially runs a string of code under elevated privileges.

  (代码注入-eval（）可能以提升的特权运行一串代码。)

  For example, a program running as administrator/root would never want to eval() user input, because that input could potentially be "rm -rf /etc/important-file" or worse.

  (例如，以管理员/超级用户身份运行的程序永远不会希望eval（）用户输入，因为该输入可能是“ rm -rf / etc / important-file”或更糟的。)

  Again, JavaScript in a browser doesn't have that problem, because the program is running in the user's own account anyway.

  (同样，浏览器中的JavaScript也不存在此问题，因为该程序无论如何都以用户自己的帐户运行。)

  Server-side JavaScript could have that problem.

  (服务器端JavaScript可能有此问题。)

On to your specific case.

(根据您的具体情况。)

From what I understand, you're generating the strings yourself, so assuming you're careful not to allow a string like "rm -rf something-important" to be generated, there's no code injection risk (but please remember, it's very very hard to ensure this in the general case).

(据我了解，您是在自行生成字符串，因此，假设您谨慎地不允许生成“ rm -rf something-important”之类的字符串，就不会有代码注入的风险（但是请记住，这非常非常在一般情况下很难确保这一点）。)

Also, if you're running in the browser then code injection is a pretty minor risk, I believe.

(另外，我相信，如果您正在浏览器中运行，则代码注入的风险很小。)

As for performance, you'll have to weight that against ease of coding.

(至于性能，您必须权衡其易编码性。)

It is my opinion that if you're parsing the formula, you might as well compute the result during the parse rather than run another parser (the one inside eval()).

(我认为，如果要解析公式，则最好在解析过程中计算结果，而不是运行另一个解析器（eval（）内部的那个）。)

But it may be easier to code using eval(), and the performance hit will probably be unnoticeable.

(但是使用eval（）进行编码可能会更容易，并且性能下降可能不会引起注意。)

It looks like eval() in this case is no more evil than any other function that could possibly save you some time.

(在这种情况下，eval（）看起来比其他任何可以节省您时间的函数都更加邪恶。)