【问题标题】:Why {} + {} is NaN only on the client side? Why not in Node.js?为什么 {} + {} 仅在客户端是 NaN?为什么不在 Node.js 中?
【发布时间】:2013-06-20 13:06:35
【问题描述】:

虽然[] + [] 是一个空字符串,但[] + {}"[object Object]",而{} + []0。为什么{} + {}NaN?

> {} + {}
  NaN

我的问题不是为什么({} + {}).toString()"[object Object][object Object]"NaN.toString()"NaN"this part has an answer here already

我的问题是为什么这只发生在客户端?在服务器端(Node.js{} + {}"[object Object][object Object]"

> {} + {}
'[object Object][object Object]'

总结

在客户端:

 [] + []              // Returns ""
 [] + {}              // Returns "[object Object]"
 {} + []              // Returns 0
 {} + {}              // Returns NaN

 NaN.toString()       // Returns "NaN"
 ({} + {}).toString() // Returns "[object Object][object Object]"
 var a = {} + {};     // 'a' will be "[object Object][object Object]"

在 Node.js 中:

 [] + []   // Returns "" (like on the client)
 [] + {}   // Returns "[object Object]" (like on the client)
 {} + []   // Returns "[object Object]" (not like on the client)
 {} + {}   // Returns "[object Object][object Object]" (not like on the client)

【问题讨论】:

  • 这只是浏览器控制台。尝试将 记录到 控制台,这与在 NodeJS 中的相同。 jsbin.com/oveyuj/1/edit
  • 不是真正的重复,我要求 NodeJS 回答。投票重新开放...
  • 嗯...对不起。但是,stackoverflow.com/questions/9032856/… 仍然相关并回答了前半部分
  • 不要忘记{} 可以被解释为表达式或对象原语,具体取决于上下文。也许客户端和服务器上的代码相同,但由于输入代码的上下文不同,它对{} 的解释不同。
  • 请重新打开,然后一次又一次地停止关闭这个问题,因为这个问题真的不是重复的

标签: javascript node.js eval google-chrome-devtools web-developer-toolbar


【解决方案1】:

更新说明:this has been fixed in Chrome 49

非常有趣的问题!让我们深入研究。

根本原因

区别的根源在于 Node.js 评估这些语句的方式与 Chrome 开发工具的方式。

Node.js 的作用

Node.js 为此使用 repl 模块。

来自 Node.js REPL source code

self.eval(
    '(' + evalCmd + ')',
    self.context,
    'repl',
    function (e, ret) {
        if (e && !isSyntaxError(e))
            return finish(e);
        if (typeof ret === 'function' && /^[\r\n\s]*function/.test(evalCmd) || e) {
            // Now as statement without parens.
            self.eval(evalCmd, self.context, 'repl', finish);
        }
        else {
            finish(null, ret);
        }
    }
);

这就像在 Chrome 开发者工具中运行 ({}+{}) 一样,它也会如您所期望的那样生成 "[object Object][object Object]"

chrome 开发者工具的作用

另一方面Chrome dveloper tools does the following:

try {
    if (injectCommandLineAPI && inspectedWindow.console) {
        inspectedWindow.console._commandLineAPI = new CommandLineAPI(this._commandLineAPIImpl, isEvalOnCallFrame ? object : null);
        expression = "with ((window && window.console && window.console._commandLineAPI) || {}) {\n" + expression + "\n}";
    }
    var result = evalFunction.call(object, expression);
    if (objectGroup === "console")
        this._lastResult = result;
    return result;
}
finally {
    if (injectCommandLineAPI && inspectedWindow.console)
        delete inspectedWindow.console._commandLineAPI;
}

所以基本上,它对带有表达式的对象执行call。表达式为:

with ((window && window.console && window.console._commandLineAPI) || {}) {
    {}+{};// <-- This is your code
}

因此,如您所见,表达式是直接计算的,没有括号。

为什么 Node.js 的行为不同

Node.js 的源代码证明了这一点:

// This catches '{a : 1}' properly.

节点并不总是这样。这里是the actual commit that changed it。 Ryan 对更改留下了以下评论:“改进 REPL 命令的评估方式”,并举例说明了不同之处。


犀牛

更新 - OP 对 Rhino 的行为方式很感兴趣(以及为什么它的行为方式类似于 Chrome devtools 而与 nodejs 不同)。

Rhino 使用完全不同的 JS 引擎,这与 Chrome 开发工具和 Node.js 的 REPL 都使用 V8 不同。

这是在 Rhino shell 中使用 Rhino 评估 JavaScript 命令时发生的基本管道。

基本上:

Script script = cx.compileString(scriptText, "<command>", 1, null);
if (script != null) {
    script.exec(cx, getShellScope()); // <- just an eval
}

在这三个中,Rhino 的外壳是最接近实际 eval 的外壳,没有任何包装。 Rhino 最接近实际的 eval() 语句,您可以期望它的行为与 eval 完全一样。

【讨论】:

  • (不是答案的一部分,但值得一提的是,nodejs 在使用 REPL 时默认使用 vm module 进行评估,而不仅仅是 JavaScript eval
  • 你能解释一下为什么 rhino 会在终端(不仅仅是 Chrome 控制台)中做同样的事情吗?
  • +10 如果可能的话!哇,伙计,...你真的没有生命,或者你真的比我聪明,知道这样的事情。请告诉我,您搜索了一下才找到这个答案:)
  • @Samuel 只需要阅读源代码——我发誓!在 Chrome 中,如果您输入“调试器;” , 你得到了整个管道 - 它会将你 直接 扔到 'with' 上面只有一个函数到evaluateOn。在 node 中,一切都有很好的记录——他们有一个专用的 REPL 模块,在 git 上的所有历史都很好,很舒服,以前在我自己的程序中使用过 REPL,我知道去哪里看 :) 我很高兴你喜欢它并找到它很有帮助,但我应该归功于我对这些代码库(dev-tools 和 nodejs)的熟悉,而不是我的才智。直奔源头通常总是最容易的。
  • 更新 - Chrome 中的控制台 API 已经更新了一些,所以虽然这里的总体思路是正确的,但发布的代码对于最新版本的 Chrome 并不准确。见chromium.googlesource.com/chromium/blink.git/+/master/Source/…
猜你喜欢
  • 2020-02-20
  • 1970-01-01
  • 2023-03-07
  • 1970-01-01
  • 2016-03-15
  • 1970-01-01
  • 1970-01-01
  • 2019-01-31
相关资源
最近更新 更多