eval(parse(...)) 的具体危险是什么? [英] What specifically are the dangers of eval(parse(...))?

问题描述

关于如何避免使用eval(parse(...))

• r-evalparse-is-often-suboptimal
• avoiding-the-inavour-evalparse-construct

引发问题的原因:

• 为什么要特别避免eval(parse())?
• 最重要的是，有哪些危险?
  • 如果代码不在生产环境中使用，会有什么危险吗?(我在想，返回意外结果的任何危险.显然，如果您不小心解析的内容，就会遇到问题.但是，这是否比使用 get()?)

  推荐答案

  大多数反对 eval(parse(...)) 的论据出现不是是因为安全毕竟，并没有声称 R 是一个安全的接口，可以公开到 Internet，而是因为这样的代码通常在做一些可以使用不那么晦涩的方法来完成的事情，即更快且更人性化的方法——有能力的.R 语言应该是高级语言，所以行家(我不认为自己属于那个群体)的偏好是看到既紧凑又富有表现力的代码.

  Most of the arguments against eval(parse(...)) arise not because of security concerns, after all, no claims are made about R being a safe interface to expose to the Internet, but rather because such code is generally doing things that can be accomplished using less obscure methods, i.e. methods that are both quicker and more human parse-able. The R language is supposed to be high-level, so the preference of the cognoscenti (and I do not consider myself in that group) is to see code that is both compact and expressive.

  所以危险在于 eval(parse(..)) 是一种绕过缺乏知识的后门方法，提高这一障碍的希望是人们将改进他们对 R 的使用语.门仍然敞开着，但希望能更富有表现力地使用其他功能.Carl Witthoft 今天早些时候提出的问题 说明不知道 get函数可用，并且他链接的问题暴露了对如何[[ 函数的行为(以及 $ 如何比 [[] 更受限制).在这两种情况下，都可以构建 eval(parse(..)) 解决方案，但它比替代方案更笨拙且不够清晰.

  So the danger is that eval(parse(..)) is a backdoor method of getting around lack of knowledge and the hope in raising that barrier is that people will improve their use of the R language. The door remains open but the hope is for more expressive use of other features. Carl Witthoft's question earlier today illustrated not knowing that the get function was available, and the question he linked to exposed a lack of understanding of how the [[ function behaved (and how $ was more limited than [[). In both cases an eval(parse(..)) solution could be constructed, but it was clunkier and less clear than the alternative.

  这篇关于eval(parse(...)) 的具体危险是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！