宅居

时隔N久，继续生产，年底实在忙……

在上一篇发表之后，有网友指出这个沙箱过于复杂，事实上一些更简单的代码也能完成同样的效果，例如：

var proxy = {
    document: new DocumentProxy()
};
function(window) {
    // 开发者提交的代码
}.call(proxy, proxy);

通过call和函数参数来劫持this及window这两个指向全局对象的变量，以达到屏蔽全局对象的目的。

但是正如我在回复中指出的，这个方式虽然简单易懂，却有一个非常重要的环节无法照顾到，即全局环境下LexicalEnvironment和VariableEnvironment和ThisBinding均是全局对象，这一特性意味着在全局环境下执行的代码将同时满足以下4个条件：

1. 通过var x = 3;定义的变量，可以使用console.log(x);输出。
2. 通过this.x = 3;定义的属性，可以使用console.log(this.x);输出。
3. 通过this.x = 3;定义的属性，可以使用console.log(x);输出。
4. 通过var x = 3;定义的变量，可以使用console.log(this.x);输出。

其中第1点和第2点是任何环境下的代码都可以满足的，因此通过call和函数参数来支持全局对象没有问题。但是第3和第4点正是全局环境的特征，并不能简单地通过单层的函数代码来控制。而通过一个with语句则可以得到满足第3点，而第4点则需要一些tricky的手段来实现了，本文将会重点从标准出发来阐述这2点的推理过程。

问题本质

首先，抛开沙箱这一目标，从本质上来看一下，以下几个语句分别是什么作用：

1. var x = 3;
2. this.x = 3;
3. x;
4. this.x;

只要有基本的javascript基础的开发者，都会很顺利地回答出来：

1. 定义一个变量，变量名为x，其值为3。
2. 在this对象上定义一个属性，属性名为x，其值为3。
3. 获取变量名为x的变量。
4. 从this对象上获取属性名为x的属性。

因此，从这4句代码中，我们可以总结而得，第1节中提到的4个条件，其实质是处理以下几个问题：

• 变量定义。
• 变量查找。
• this对象确定。
• 属性查找。

由于事实上，我们希望定义的变量本身就在this对象上，而非其原型链上的其他对象上，因此这里不会涉及到属性查找这一环节，真正需要处理的是变量的定义和查找，以及this绑定的问题。

而接下去的章节，就将来分析一下这3个过程在标准中是如何定义的。

变量定义

继续打开ECMAScript 5的HTML版本，搜索Variable关键字，并不会有太多的结果，一一过目，最终与变量定义有关的内容会集中在Declaration Binding Instantiation一章中，这一章概述了当进入一个函数时，函数名、形参、变量是如何进行初始化绑定的，其中内容非常多，因此只抽取与变量相关的部分摘录：

Every execution context has an associated VariableEnvironment. Variables and functions declared in ECMAScript code evaluated in an execution context are added as bindings in that VariableEnvironment’s Environment Record. For function code, parameters are also added as bindings to that Environment Record.

Which Environment Record is used to bind a declaration and its kind depends upon the type of ECMAScript code executed by the execution context, but the remainder of the behaviour is generic. On entering an execution context, bindings are created in the VariableEnvironment as follows using the caller provided code and, if it is function code, argument List args:

1. Let env be the environment record component of the running execution context’s VariableEnvironment.

…其他内容

8. For each VariableDeclaration and VariableDeclarationNoIn d in code, in source text order do

1. Let dn be the Identifier in d.

2. Let varAlreadyDeclared be the result of calling env’s HasBinding concrete method passing dn as the argument.

3. If varAlreadyDeclared is false, then

   1. Call env’s CreateMutableBinding concrete method passing dn and configurableBindings as the arguments.
   2. Call env’s SetMutableBinding concrete method passing dn, undefined, and strict as the arguments.

这一段告诉我们，一个变量是绑定在VariableEnvironment上的（env对象），并且同名的变量只会绑定一次（通过HasBinding判断）。

变量查找

关于变量查找，很多开发者都明白存在一个称为“作用域链”的数据结构，变量是在作用域链上自下向上进行查找。而在ECMAScript 5中，作用域链的概念已经不复存在，相对应地引入了LexicalEnvironment这一概念，在Identifier Resolution一章中，对变量的查找过程进行了描述：

Identifier resolution is the process of determining the binding of an Identifier using the LexicalEnvironment of the running execution context.
During execution of ECMAScript code, the syntactic production PrimaryExpression : Identifier is evaluated using the following algorithm:

1. Let env be the running execution context’s LexicalEnvironment.
2. If the syntactic production that is being evaluated is contained in a strict mode code, then let strict be true, else let strict be false.
3. Return the result of calling GetIdentifierReference function passing env, Identifier, and strict as arguments.

The result of evaluating an identifier is always a value of type Reference with its referenced name component equal to the Identifier String.

这一段说明查找一个变量，是通过将LexicalEnvironment及变量名称作为参数，传递给GetIdentifierReference函数来进行的，而GetIdentifierReference函数的说明在标准中有如下描述：

The abstract operation GetIdentifierReference is called with a Lexical Environment lex, an identifier String name, and a Boolean flag strict. The value of lex may be null. When called, the following steps are performed:

1. If lex is the value null, then

   1. Return a value of type Reference whose base value is undefined, whose referenced name is name, and whose strict mode flag is strict.

2. Let envRec be lex’s environment record.

3. Let exists be the result of calling the HasBinding(N) concrete method of envRec passing name as the argument N.

4. If exists is true, then

   1. Return a value of type Reference whose base value is envRec, whose referenced name is name, and whose strict mode flag is strict.

5. Else

   1. Let outer be the value of lex’s outer environment reference.
   2. Return the result of calling GetIdentifierReference passing outer, name, and strict as arguments.

简而言之，ECMAScript 5定义了一种自内向外的变量查找过程，如果使用大家熟悉的javascript代码来描述，则可以这样表达：

function LexcicalEnvironment(outer) {
    this.outer = outer || null;
    // 存放变量名-变量关系
    this.environmentRecords = {};
}

function GetIdentifierReference(env, name) {
    while (env) {
        if (env.environmentRecords[name]) {
            return env.environmentRecords[name];
        }
        env = env.outer;
    }
}

至此，我们可以得出以下结论：

• 变量的定义是通过VariableEnvironment进行的。
• 变量的查找是通过LexicalEnvironment进行的。
• ThisBinding规则已经有非常多的文献进行了介绍，也应当作为开发者的基本认识，便不再赘述。

因此回到最初的问题，来分析一下为何通过一个with语句，可以使得this.x =3;定义的属性，能通过console.log(x);的形式访问。

LexicalEnvironment及VariableEnvironment的创建

为了解释上一节最后提出的问题，有必要再回顾一下我们上一篇得到的代码在执行过程中，LexicalEnvironment和VariableEnvironment是如何变化的：

new function() {
    with (this) {
        this.x = 3;
        console.log(x);
    }
};

在这段代码执行的过程中，我们可以很简单地看到，其中包含了一个函数的调用和一个with语句，同时肉眼不可见的自然有一个全局环境。根据上一篇中引用的标准：

1. 当进入函数代码时，会创建一个LexicalEnvironment和一个VariableEnvironment，他们指向同一个对象，由NewDeclarativeEnvironment生成。
2. 当进入with语句时，会创建一个LexicalEnvironment，该LexicalEnvironment的environmentRecords由with语句的对象提供，由NewObjectEnvironment生成。

因此，加上最外层的全局对象，我们不难得到这样的一个图：

图中自外向内依次为全局环境、new function以及with语句生成的相关环境，并根据颜色，在下文中用R、G、B给予代替：

1. 在进入全局代码时，生成了一个LexicalEnvironment和一个VariableEnvironment，均为global对象，并且this也为global对象。
2. 在进入函数代码时，生成一个LexicalEnvironment和一个VariableEnvironment，这个对象由引擎生成且不可通过编码的方式访问，这里以env为指代。同时在函数中，this指向new运算符的结果，使用obj为指代。
3. 在进入with语句时，生成一个新的LexicalEnvironment，该LexicalEnvironment使用this，即obj对象为environment records组件，在图中简单地描述该LexicalEnvironment即为obj对象。同时with语句不会改变this对象，因此this依旧指向obj对象。

这便是with语句的奇特之处，简单来说，with语句是唯一可以指定使用确定对象形成LexicalEnvironment的语句，也正因为这个特性，让我们有办法将this和LexicalEnvironment统一为一个对象。

在上图表示的结构中，根据标准定义的查找变量的方式，当执行console.log(x);的时候，会从B层的LexicalEnvironment中查找变量名为x的变量，而该LexicalEnvironment的environment records正好是obj对象，与this指向的对象相同，而obj对象上自然因为之前this.x = 3;这一语句，定义了一个名为x的属性，因此顺利地拿到了对应的值。

回到变量定义

在正确地解释了为何this.x = 3;定义属性后可以通过console.log(x);输出之后，唯一需要解决的问题就是以上过程的反向，即如果使用var x = 3;定义变量后，现在还没有办法使得console.log(this.x);可以正确地输出值。

重新审视上面这张LexicalEnvironment和VariableEnvironment的关系图，当我们进入函数时，在搜索到var x = 3;这一语句后，发生了什么：

1. 找出当前执行环境里的VariableEnvironment，由于with语句并不会改变VariableEnvironment，因此找到的VariableEnvironment是图中G部分的对象，即env对象。
2. 判断env对象的environment records中是否有名为x的绑定，由于没有在函数中定义任何变量，自然不会有。
3. 由于没有相关的绑定，则在env的environment recrods添加一个绑定，变量名为x，值为undefined。
4. 等待函数被执行并运行到var x = 3;这一句时，再对x赋值。

由此可见，非常遗憾地，x被定义到了由函数代码生成的VariableEnvironment对象，即env对象中，而env和我们希望的obj自然不是同一个对象，且没有任何编码方式可以访问到env对象，也无法通过修改引用来使得obj和env指向同一对象。

因此，从这一结论上看，希望通过改变变量定义时的行为来达到目的，似乎是不可行的，只能另寻他法。

再次将目光回到var x = 3;这一语句上，这一语句究竟代表了什么，真的是定义一个名为x的变量并赋值为3这么简单的一句话吗？

作为一个javascript的开发者，你是否听过javascript有一个被称为Hosting Behavior的机制，即所有的var定义会被提前到函数开始这一通俗的言论？而本文前半部分摘录的Declaration Binding Instantiation相关内容，也正是对这个机制地阐释。事实上，变量的定义是在进入函数时进行的，而不是函数代码执行过程中进行的，换句更通俗的话说，var x = 3;这一简单的语句，包括了好多个步骤：

1. 进入函数时，定义一个名为x的变量，值为undefined。
2. 开始按行执行代码。
3. 当执行到var x = 3;时，给x赋值，值为3。

再仔细分解，就容易得出这样一个结论：var x = 3;事实上是var x;和x = 3;的整合。

因此，既然var x;这一部分已经被变量定义的过程所限制，无从下手给予变更，那么进而着眼于x = 3;这一语句，寻求突破口便成了最自然地举动。在此分析一下，x = 3;这一语句是一个怎么样的过程：

1. 在当前的LexicalEnvironment中查找名为x的变量。
2. 如果存在，则将对应的值修改为3。
3. 如果不存在，则获取当前LexicalEnvironment的outer属性指定的外层LexicalEnvironment，回到第1步，直到不存在外层LexicalEnvironment。

亦即是说，x = 3;这一语句是由变量查找和变量值修改这两个逻辑整合而成。至此，你是否又看到了一个熟悉的词汇，并因此而倍感兴奋？是的，在绕了一圈之后，变量定义的问题又变成了变量查找，而上一节中我们已经证明了变量查找是一个可控的过程。

到这一步，问题再一次被简化，我们需要做的是，当查找x变量时，可以在this对象中获得该变量，即在图中B部分的LexicalEnvironment中得到结果，即保证在obj对象中拥有x这一属性。

至于如何让obj对象拥有x属性，那自然是需要定义一下这个属性了，这是必须的无奈之举。好在如果抱着宁可错杀一万，不可漏杀一个的心态，从开发者提交的代码中提取定义的变量名并不是一个非常困难的事，通过简单的正则表达式提取var关键字以及其后的标识符即可，例如/var\s+([^\s]+)\s/g这样的正则就已经在很大程度上可以满足要求。即便提取了本不是变量定义的部分也不要紧，多出来的这些也很少会影响到逻辑。

虽然依旧避免不了对开发者的代码进行扫描，但至少不再需要进行词法、语法的分析，也不需要创建一个javascript的虚拟机来试运行，只需一个简单的正则，让问题变得简单很多，最终的代码可能是如下形式，以供大家讨论：

// new function负责创建一个新的、独立的this对象
new function() {
    // 将用户提交的代码中的所有变量名抽取出来，形成varList数组
    // 通过在this对象中定义对应的属性，来达到更完善地模拟全局环境
    (function(o) {
        for (var i = 0; i < varList.length; i++) {
            o[varList[i]] = undefined;
        }
    }(this));

    // with负责创建一个可控的LexicalEnvironment
    // 保证变量查找和this对象下的属性查找会落在一个对象上
    with (this) {
        // 用户提交的代码
    }
};

上一章中，经过对标准的查询、翻阅、解析，终于在绕了一个大圈之后，明白了全局对象的特征，并明确了模拟一个全局对象需要的内容，还为此编写了简单的测试用例。本文将从第1个测试用例着手，放眼与全局作用域的VariableEnvironment、ThisBinding以及window别名这三者的一致性，来推导出一个沙箱的原型。

所谓纰漏

在开始这一章以前，首先不得在这里道个歉，原因很简单，我对标准进行了误读，且在没有测试的情况下就开始了这一系列的博客。事实上，以我的思路，是无法制作出一个理想中的沙箱的，虽然可以控制住第三方代码的作用区域，但是无法做到完全的透明，其主要问题出在这里：

var x = 3;
console.log(this.x); // 打印出3

事实上，仅仅依靠Javascript本身，是没有办法在非全局环境下使上面这段代码得到正确的结果的。

因此，在这里，不得不先把标准给改上一改，放弃绝对透明性这一要求，事实上也确实很少有开发者会通过var声明变量并使用this.x或window.x来访问，不得以之下只能放弃这个需求，将var声明和this.x声明隔离开来。

事实上（开始狡辩），对标准的误读也是学习标准的一种过程，不会犯错的人也很难有太大的进步。我思考良久，最终的决定是不删除这一系列的博文，而是使之继续下去，在修改测试用例的情况下，继续来制作沙箱。当然这个难度要简单不少了。

这一系列已然变成了一个“边研究边写”的“研究笔记”，随着这一系列的进行，必然会出现越来越多的问题，事实上这个沙箱也不见得有可用性。还请以“标准对研究进行指导”这样的角度来看待这个问题吧，得出一个“无角”这样的结论，姑且也算一个结论……

理解VariableEnvironment和ThisBinding

依旧沿用上一章的思路，打开ECMAScript 5的HTML版本，通过CTRL+F组合键打开搜索框，查询VariableEnvironment，可以看到搜索的结果并不多，同样搜索ThisBinding，则发现多数内容与VariableBinding的搜索结果重叠，说明这两者经常放在一块描述。

首先是对VariableEnvironment一词的解释，在Execution Context一章的表格中有如下描述：

Identifies the Lexical Environment whose environment record holds bindings created by VariableStatements and FunctionDeclarations within this execution context.

对ThisBinding的描述也颇为简单：

The value associated with the this keyword within ECMAScript code associated with this execution context.

当然这并不是我们需要的内容，仅仅以此来对VariableEnvironment有一个基本的认知。VariableEnvironment是用于在文法环境中保存通过变量声明语句和函数声明创建的对象之用的，即var x和function fn() {}创建的对象会被保留在VariableEnvironment中。而ThisBinding则特指this关键字指向的对象。

而我们真正需要知道的是，在各种代码的执行环境下，VariableEnvironment和ThisBinding分别会是什么，通过在标准中的搜索，我们可以很容易地找到相关的内容，在Establishing an Execution Context一章中，分别描述了全局代码、函数代码和eval代码执行时的VariableEnvironment和ThisBinding：

Initial Global Execution Context中对全局代码执行时的描述：

1. Set the VariableEnvironment to the Global Environment.
2. Set the LexicalEnvironment to the Global Environment.
3. Set the ThisBinding to the global object.

Entering Eval Code一章中对eval代码中VariableEnvironment的描述：

1. If there is no calling context or if the eval code is not being evaluated by a direct call (15.1.2.1.1) to the eval function then,

   1. Initialize the execution context as if it was a global execution context using the eval code as C as described in 10.4.1.1.

2. Else,

   1. Set the ThisBinding to the same value as the ThisBinding of the calling execution context.
   2. Set the LexicalEnvironment to the same value as the LexicalEnvironment of the calling execution context.
   3. Set the VariableEnvironment to the same value as the VariableEnvironment of the calling execution context.

3. If the eval code is strict code, then

   1. Let strictVarEnv be the result of calling NewDeclarativeEnvironment passing the LexicalEnvironment as the argument.
   2. Set the LexicalEnvironment to strictVarEnv.
   3. Set the VariableEnvironment to strictVarEnv.

4. Perform Declaration Binding Instantiation as described in 10.5 using the eval code.

可以看到，如果使用的是indirect eval，则与全局代码相同。如果使用普通的eval，则继续使用当前所在执行环境的VariableEnvironment和ThisBinding。如果是严格模式则有更复杂的过程，好在他虽然麻烦，但我们不用他就行了嘛，破坏严格模式还是很容易的一件事，现在先不作讨论。

Entering Function Code一章中描述了函数内代码执行时VariableEnvironment的情况：

1. If the function code is strict code, set the ThisBinding to thisArg.
2. Else if thisArg is null or undefined, set the ThisBinding to the global object.
3. Else if Type(thisArg) is not Object, set the ThisBinding to ToObject(thisArg).
4. Else set the ThisBinding to thisArg.
5. Let localEnv be the result of calling NewDeclarativeEnvironment passing the value of the [[Scope]] internal property of F as the argument.
6. Set the LexicalEnvironment to localEnv.
7. Set the VariableEnvironment to localEnv.
8. Let code be the value of F’s [[Code]] internal property.
9. Perform Declaration Binding Instantiation using the function code code and argumentList as described in 10.5.

其中第1-3步说明在函数代码执行时，其ThisBinding指向一个叫thisArg的东西，而第5、第7步则说明其VariableEnvironment是一个全新创建的环境，仅与当前的作用域挂钩。

至于这个thisArg是什么，相信很多编写Javascript的代码工程师很非常了解，我在javascript中的对象查找一文中也专门抽一节讲述了this的查找规则。对于已经是现成知识的内容，也就不必再辛辛苦苦去翻阅标准了，还请时刻牢记标准是指导作用，而不是强迫查询。

进一步分析

对于标准的查阅也至此为止，既然已经知道了各种代码执行时的VariableEnvironment和ThisBinding，不如先总结一下各自的优劣：

• 全局代码：这个必然不行，因为我们就是要防止代码在全局下执行。
• eval代码：eval的效果几乎透明，要么直接把代码放在全局下执行，要么和当前环境没有区别，因此eval显然也不是什么合理的选择。
• 函数代码：VariableEnvironment是个全新创建的，而ThisBinding根据函数调用时的规则有所变化。

到此，我们已经有了控制var声明变量的作用域的方式，其实这个非常简单，只要有一个新的作用域生成就行，最方便的自然是一个自调用函数表达式：

(function() {
    // 放入开发者提交的代码
}());

但是以上代码至少有2个缺陷：

1. this.x = 3或window.x = 3就足以声明全局变量，即使是君子也很容易以这种形式不小心污染了全局。
2. this.x = 3声明属性后，无法使用console.log(x)获得正确的输出。

为了解决这2个问题，我们需要控制住this。对于第1点，只要随便有和个this对象即可，而对于第2点，则需要让ThisBinding变得和VariableEnvironment有一定关系（变量查找会找到当前this对象中）就行了，于是我们还是回顾一下ThisBinding有哪些情况：

• 直接调用，则this为全局对象。
• 方法调用，则this为函数所属对象。
• 构造器调用，则this为构造后的实例对象。
• call/apply调用，则this任意指定。

粗略一看，似乎后两者更有实用价值，特别是call/apply调用有最大的自由度。然而这里却遇到一个棘手的问题，VariableEnvironment根本是一个不可能通过Javascript访问到的对象，因此即使使用call来指定this对象，也不可能将VariableEnvironment传递过去。

于是到这一步，似乎通过修改this为VariableEnvironment的方法并不是很现实，至少不可能主动获取VariableEnvironment并将之像普通对象一样传递。而事实也是如此，用“不可能”来形容“将this修改为VariableEnvironment”这一需求也不为过，如果哪位有什么方法，还望不吝赐教。

此路不通，在此时便只能回头。回头看看刚才摘录的标准相关内容，仔细地查找每一个陌生名词，经过无数的弯路（如果把走过的弯路都写出来，我可以写小说了，所以省略吧），我们发现在讲述VariableEnvironment的时候，总是有一个名词在附近晃悠，就像打一打就能升级但又逃得飞快的的天使波波羊一样，它就是LexicalEnvironment。

对于LexicalEnvironment，Execution Contexts一章中有非常明确的解释：

The LexicalEnvironment and VariableEnvironment components of an execution context are always Lexical Environments. When an execution context is created its LexicalEnvironment and VariableEnvironment components initially have the same value. The value of the VariableEnvironment component never changes while the value of the LexicalEnvironment component may change during execution of code within an execution context.

这段话绝对是令人振奋的，他说明VariableEnvironment没有什么特别，其实VariableEnvironment和LexicalEnvironment根本是一个东西。那么我们又可以将原先对准VariableEnvironment的矛头再一次指向LexicalEnvironment，从标准里找一找，有没有什么办法修改LexicalEnvironment，让它和this变成一样呢？

在标准中搜索LexicalEnvironment，并不会有很多的结果，经过细致的查阅和过滤，发现在2个地方有单独提到LexicalEnvironment而没有讲VariableEnvironment，这显然是突破口，因此必须牢牢抓住：

标准中The with Statement一章有如下的描述：

The production WithStatement : with ( Expression ) Statement is evaluated as follows:

1. Let val be the result of evaluating Expression.
2. Let obj be ToObject(GetValue(val)).
3. Let oldEnv be the running execution context’s LexicalEnvironment.
4. Let newEnv be the result of calling NewObjectEnvironment passing obj and oldEnv as the arguments.
5. Set the provideThis flag of newEnv to true.
6. Set the running execution context’s LexicalEnvironment to newEnv.
7. Let C be the result of evaluating Statement but if an exception is thrown during the evaluation, let C be
8. (throw, V, empty), where V is the exception. (Execution now proceeds as if no exception were thrown.)
9. Set the running execution context’s Lexical Environment to oldEnv.
10. Return C.

另外The try Statement一章中对catch块的描述：

The production Catch : catch ( Identifier ) Block is evaluated as follows:

1. Let C be the parameter that has been passed to this production.
2. Let oldEnv be the running execution context’s LexicalEnvironment.
3. Let catchEnv be the result of calling NewDeclarativeEnvironment passing oldEnv as the argument.
4. Call the CreateMutableBinding concrete method of catchEnv passing the Identifier String value as the argument.
5. Call the SetMutableBinding concrete method of catchEnv passing the Identifier, C, and false as arguments. Note that the last argument is > . immaterial in this situation.
6. Set the running execution context’s LexicalEnvironment to catchEnv.
7. Let B be the result of evaluating Block.
8. Set the running execution context’s LexicalEnvironment to oldEnv.
9. Return B.

经过不小的折腾，终于找到了2个可以额外改变LexicalEnvironment的语法，即with和catch。

再仔细看一看标准中的描述，with可以指定任何一个对象，通过这个对象创建一个叫NewObjectEnvironment的东西，并把这个东西当做LexicalEnvironment。而catch则比较悲剧，只能在原有的LexicalEnvironment基础上增加一个catch的异常对象，形成新的LexicalEnvironment。

对于我们的需求，两者的优劣显而易见，with是有望符合我们的要求的，而catch则因为机制本身受限过多，基本不用抱以希望。那么现在的问题就是如何利用with语句，来创建一个和this相同的LexicalEnvironment。

解决问题

其实再仔细研读标准中对LexicalEnvironment的描述，通过简单的总结，答案已经非常明显：

• LexicalEnvironment和VariableEnvironment其实是一个东西，变量会存在里面。
• 不严格地说，with可以指定任何对象使之变成LexicalEnvironment。
• this是一个对象。

于是不难看出，只要通过with指定this作为LexicalEnvironment，问题也就迎刃而解了。加之前文对this的理解，我们很容易就得到3种方法来创建一个干净、全新的this：

1. 将一个函数附着在空对象上，使用方法调用的形式来生成。
2. 使用new方式，形成一个空的实例。
3. 使用call或apply，主动传递一个干净的对象作为this。

每个方法都不难，个人还是选择了第2种方法，没什么原因，写着方便而已，所以有了最后的代码：

new function() {
    with(this) {
        // 嵌入开发者提交的代码
    }
};

最后再把上一章中的测试代码拿过来执行一下：

测试代码已经经过了修改，由于其中第1部分是无法做到的（参见本文第一段的声明），因此只测试this和window和读取变量的相通性，再次致以歉意！

// 测试var, this, window三者是否相通
function equals(x, y) {
    console.log(x === y);
}

new function() {
    // 动持window，无需多言
    this.window = this;

    with (this) {
        this.x = 4;
        equals(x, 4);
        equals(window.x, 4);

        window.y = 5;
        equals(y, 5);
        equals(this.y, 5);
    }
};
console.log(window.x);
console.log(window.y);

在浏览器中运行，可以在console中得到4个true的结果，这个简单的沙箱还是能起到一定的作用的。

事实上，这里本身就是一个问题，如果将测试用例封装为函数，再直接调用函数，则this已经指向了window，这是标准所规定的ThisBinding方式，根本无从拦截，除非使用类似虚拟机的工具来完成。但是个人认为，能做到这一步已经不错，进一步只能给予开发者一定的限制，比如不得直接调用函数，必须以this.fn()的形式调用。虽然会麻烦（其实这个沙箱已经是越做洞越多了），却也是无奈之举。

上一章中对需求进行了分析，并对实现方案有了一定的探讨，最终得出从劫持全局对象这一环节入手的结论，而本文将讨论如何劫持这个全局对象。

全局对象，多数会进行Javascript编程的工程师都知道，在浏览器的执行环境中，叫做window，虽然事实上window和全局对象并不严格意义上是一个东西，不过这对我们的实现并不会造成什么障碍。

剖析全局对象

既然要去做劫持全局对象这样不人道的事，自然先要知道全局对象是个什么东西，有什么样的特点，以便针对目标，一刀致命。这个时候，标准就会成为我们最好的参考，首先打开ECMAScript 5的HTML版本，此后几乎所有的标准引用都会从这里产生。

所谓擒贼先擒王，经典理论告诉我们，不可以把整个洋洋洒洒数万字的标准给全看了，必须以快、狠、准的手段找到我们需要的东西。如果是纸质的书籍，对于一个不熟悉文档结构的人而言自然是无处下手，但好在现在是数字化的时代，我们有一个名为“搜索”的强大功能。

在浏览器中按下CTRL+F的组合键，随后输入Global，看看一共有多少内容。从目录来看，一共有7处内容，确实不多：

1. 10.2.3 The Global Environment
2. 10.4. Entering Global Code
3. 15.1 The Global Object
4. 15.1.1 Value Properties of the Global Object
5. 15.1.2 Function Properties of the Global Object
6. 15.1.4 Constructor Properties of the Global Object
7. 15.1.5 Other Properties of the Global Object

而这8处内容又可以分为2部分，其中1-3分别介绍了全局对象本身的特点，而4-7则专注于介绍全局对象上的内置属性（即本地对象）的相关内容。仅仅以劫持全局对象为目的的我们，自然可以先不管全局对象上的其它属性，只针对全局对象自身入手，因此将目光放置在前3者之上。

首先是来自于The Global Environment一节对全局对象概念上的介绍：

The global environment is a unique Lexical Environment which is created before any ECMAScript code is executed. The global environment’s Environment Record is an object environment record whose binding object is the global object (15.1). The global environment’s outer environment reference is null.

As ECMAScript code is executed, additional properties may be added to the global object and the initial properties may be modified.

这一段并没有带来太多的信息，仅仅说明了“全局对象是什么”这一理论，但是其中的第二段却给我们一点有利地信息：在代码执行过程中，全局对象上可能会增加额外的属性，当前的属性也可能被修改。这就告诉我们，需要模拟全局对象的时候，可以在上面添加自己的内容，也可以让原有的原生对象变化甚至消失，这些都不会违反标准，因此在全局对象上添加诸如container或者user之类的业务相关信息也合情合理，而去除eval之类的函数也合乎逻辑，使得API的设计更加容易。

随后，将重点放在Entering Global Code一章中：

The following steps are performed when control enters the execution context for global code:

1. Initialize the execution context using the global code as described in 10.4.1.1.
2. Perform Declaration Binding Instantiation as described in 10.5 using the global code.

这一段没有什么有效的信息，不过告诉我们10.4.1.1节会有相关的内容（当然10.5节也有内容，但这一节并不专为全局环境服务，因此不再赘述，有兴趣的可以自行翻阅）：

The following steps are performed to initialize a global execution context for ECMAScript code C:

1. Set the VariableEnvironment to the Global Environment.
2. Set the LexicalEnvironment to the Global Environment.
3. Set the ThisBinding to the global object.

这一段的信息就非常重要了，他告诉我们2个事实：

• 全局环境下的VariableEnvironment是全局对象本身，即所有通过var声明的变量都会成为全局对象的属性。
• 全局环境下的ThisBinding是全局对象本身，即this对象为全局对象。

这也是全局对象最大的特征，那通过var声明和通过this.x声明会有几乎相同的效果。

最后再看看15.1节带给我们的信息（摘录部分）：

Unless otherwise specified, the standard built-in properties of the global object have attributes {[[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true}.

The global object does not have a [[Construct]] internal property; it is not possible to use the global object as a constructor with the new operator.

The global object does not have a [[Call]] internal property; it is not possible to invoke the global object as a function.

The values of the [[Prototype]] and [[Class]] internal properties of the global object are implementation-dependent.

这一段告诉我们以下事实：

• 所有全局对象上的内置属性都是可写、不可遍历且不可删除的。
• 全局对象本身不是一个构造器，且不能被调用。亦即全局对象是个普通对象，并非函数。
• 全局对象的[[Prototype]]和[[Class]]是什么与标准没关系，因此模拟的时候不需要考虑这个环节。

到这里，相关的标准也基本翻阅完毕，从标准中我们可以总结，如果需要模拟出一个全局对象，则需要满足以下条件：

1. 开发者提交的代码中使用var定义的变量和this.x或window.x定义的属性均会出现在这个对象上。
2. 全局对象上需要一些本地对象，如Object、Array等，且这些对象可以被修改，但无法通过for..in遍历出来，且不可被delete运算符删除。

测试先行

本着满足上节中提到的2个要求的目的，为了可以验证最终实现的沙箱的可用性，我们必须有一些测试的代码，来检验成果。

根据2个要求，在此先设计2个测试用例：

// 测试var, this, window三者是否相通
function testBinding() {
    var x = 3;
    equals(this.x, 3);
    equals(window.x, 3);

    this.y = 4;
    equals(y, 4);
    equals(window.y, 4);

    window.z = 5;
    equals(z, 5);
    equals(this.z, 5);
}

// 测试是否存在内置对象，且不可被遍历及删除
function testNative() {
    var natives = ['Object', 'String', 'Number', 'RegExp', 'Array', 'Date'];
    var keys = {};
    for (var name in window) {
        keys[name] = true;
    }

    for (var i = 0; i < natives.length; i++) {
        var key = natives[i];
        if (keys[key]) {
            fail();
        }
        var value = window[key];
        delete window[key];
        if (window[key] !== value) {
            fail();
        }
    }
}

至此，开工的先决条件已经具备，而未来的2个篇章，将着重从这2个测试用例下手，以一章一个问题的速度给予解决。而解决过程中自然少不了对标准的查阅、引用，毕竟这一系列的目的就是展示标准如何引导问题的解决。

在此之前，如果有兴趣的，可以尝试着来制作一个沙箱，沙箱的目标是在用户提交的脚本前后插入一些代码，让用户的代码只能在我们模拟的全局对象中运行，不可越级访问到真实的全局对象。只要符合以上2点的沙箱就是好沙箱哦~

PS：一开始从脑子里挖标准的时候，觉得对全局对象的形容也就是最后2句话而已，所以本想这一章可以将第一个测试用例搞定。但没想真正从标准是引用内容的时候，竟然有如此大的篇幅，导致本章还没有空余来真正着手解决问题，这也从另一方面展现了标准的严谨性和权威性。由于下面要处理的变量及对象绑定问题也会有大量的标准引用来支撑，因此本系列会多出一个章节，单独来处理这个问题，望见谅！

目的

这将是一个系列的文章，大致由4篇博文组成，内容应该会是这样的：

1. 目的、背景及分析
2. 劫持全局对象
3. 劫持全局对象属性
4. 存在的问题及漏洞

起草这一系列博文的原因有2，第一自然是因为最近突然有这样的需求，而群里正好也在某个深夜（技术宅基本深夜活动）讨论到了一个类似的话题，给了我一些灵感，所以决定将近期“研究”的成果展示一下。

而第二个目的，也是我想将这么一个简单的东西（其中最终就10几行代码）用整整5个博文的篇幅来说的原因，是因为近期有不少朋友向我强烈地表达了标准的存在意义极其微弱，我能把代码写好就足够的想法，而且现在更是催生了一种叫做jQuery工程师的职位，大有星星之火的样子。

对于这样的态度，作为一个只会理论不懂实践的2B工程师，个人自然是坚持地抱以反击态度的，因此，这一系列的博文，将会从“构建一个沙箱”这样的场景出发，将对于这一话题的研究过程展现于众，期间将频繁涉及到对标准的参阅，以展现标准如何引导问题的解决这一事实。

在阅读这一系列的博文前，还请确认几件事：

• 你懂英文，因为我不是翻译专家，没能力也没篇幅将标准相关的内容都翻译一下。对于标准，我会将相关的原文引用于此，但肯定是英文的。
• 你得抱着标准无用论来看待问题，如果你也觉得标准很好用，那还是看最后的成品代码吧，因为其中的过程于你已经失去了大部分的意义。

最后，还是先声明一件事，其实我研究这个问题并没有这么麻烦，因为本系列博文中引用标准的内容几乎全在我的脑子里。我只是将这个思考、查找、得出结论的过程放大、放慢，进行分解，一点一点地通过文字表达出来而已。至于类似“根本不知道标准又怎么会往这方面想”的问题如果出现在你的大脑中，那么恭喜你似乎已经意识到了标准学习的些许价值。

背景

如果你有一个小小的项目，想提供一个开放地平台，供第三方的开发者提交一些小程序（Widget）并嵌入到页面中使用。这有点类似与人人网。

对于此类的系统，一个比较合理的设计，自然是让开发者提交一个HTML片段，并配以相应的CSS和Javascript，随后在页面中提供一个容器，引入该HTML片段，并且通过一定的手段引入CSS和Javascript，并保证CSS和Javascript只影响到该容器内的所有DOM元素。

于是，这样的设计就引入了一个问题。正如上文所说，我们必须保证开发者提供的CSS及Javascript仅作用在容器及其子元素之上。对于CSS，可以使用style元素的scoped属性，虽然这个属性的定义一直处于讨论之中，但这并不妨碍它可以基本满足我们的需求。但是对于Javascript，却并没有这么简单。事实上，至今为止并没有任何的HTML属性或者Javascript函数，可以让一段Javascript在指定的作用域内执行，达到不污染全局、不影响外围DOM元素等目标。

基于此，我们必须人为地创造出一个环境，在这个环境中所执行的代码要求能满足以下几点：

• 无法在全局对象下建议任何属性。
• 所有选择DOM的方法返回的NodeList仅包含容器及其子元素。
• 不得使用一些高危险性的函数，如eval和document.write。
• 尽可能对开发者透明，即开发者提交正常执行环境下可用的Javascript片段，则在系统中也同样可用。

根据专业术语，我们将这个人为创造的环境，称为沙箱（sandbox），以下是Wikipedia上对sandbox一词的解释:

In computer security, a sandbox is a security mechanism for separating running programs. It is often used to execute untested code, or untrusted programs from unverified third-parties, suppliers, untrusted users and untrusted websites.

在追求Javascript的安全执行上，很多团队都有着丰富的积累和成果，其中以Facebook的FBML、微软的Web Sandbox和Google的caja最为典型，百度泛用户体验上也有一篇文章对几个较为成熟的技术方案进行了介绍。

但是这几个方案，对于一个小小的项目来说，无疑都太过沉重，不是引入一个新的语法，就是带上后端的虚拟机，同时又需要约束开发者的提交的代码，使得其对第三方小程序开发者无法透明，更加大了系统的推广成本。因此，我们试图以防君子不防小人为目标，去创造一个轻量级的沙箱环境，在保证Javascript代码基本受限地执行，又无需引入太多外部的环境依赖。

分析

重新回顾一下我们对沙箱的要求：

• 保护全局环境不受污染。
• DOM的获取在可控范围内。
• 提供有限的API。
• 对开发者透明。

反过来想，正常的开发者是怎么写代码的呢？先随便来一段：

var time = new Date;
document.getElementById('time').innerHTML = formatDate(time, 'yyyy-MM-dd HH:mm:ss');
document.getElementById('hello').innerHTML = 'Hello ' + username;

对于一个认为自己是在纯净的环境中开发的开发者而言，使用document.getElementById来获取DOM元素，使用var来定义变量，随后对DOM进行操作，是再正常不过的事。但是在一个拥有容器的环境中，以上代码却适时地暴露出了几个问题：

• var定义的变量会污染全局。
• document.getElementById会获取到不应该能够获取的DOM元素。

此两者是一个正常的开发者（非存心搞破坏的那类）最容易在不经意之间遭遇的问题，这不是他们蓄意的破坏，只是他们认为自己的Javascript片段的执行环境是纯净、隔离、独立的。因此抱着防君子之心，对此做出限制是合理且必要的。

纵观这些问题，经过一段时间的思考（思考过程过于繁琐就不说了），可以发现，其实问题集中在一点上，即拦截全局对象。由于在Javascript中，本地对象和宿主对象以及DOM对象都是和全局对象挂钩的，且全局对象是唯一的入口，因此只要将入口劫持，所有的东西都可以得到合理地控制。如以上的问题，如果能够对全局对象进行劫持，随后提供刻意“伪造”的document对象，则问题迎刃而解。

因此，从下一节开始，将从全局对象的概念开始，讲述如何支持全局对象。并在此之后，讲述如何在劫持后伪造出相关的本地和宿主对象。