JavaScript

不完美沙箱 - 变量定义及查找

时隔N久,继续生产,年底实在忙…… 在上一篇发表之后,有网友指出这个沙箱过于复杂,事实上一些更简单的代码也能完成同样的效果,例如: var proxy = { document: new DocumentProxy() }; function(window) { // 开发者提交的代码 }.call(proxy, proxy); 通过call和函数参数来劫持this及window这两个指向全局对象的变量,以达到屏蔽全局对象的目的。 但是这个方式虽然简单易懂,却有一个非常重要的环节无法照顾到,即全局环境下LexicalEnvironment和VariableEnvironment和ThisBinding均是全局对象,这一特性意味着在全局环境下执行的代码将同时满足以下4个条件: 通过var x = 3;定义的变量,可以使用console.log(x);输出。 通过this.

JavaScript

不完美沙箱 - 模拟全局对象

上一章中,经过对标准的查询、翻阅、解析,终于在绕了一个大圈之后,明白了全局对象的特征,并明确了模拟一个全局对象需要的内容,还为此编写了简单的测试用例。本文将从第1个测试用例着手,放眼与全局作用域的VariableEnvironment、ThisBinding以及window别名这三者的一致性,来推导出一个沙箱的原型。 所谓纰漏 在开始这一章以前,首先不得在这里道个歉,原因很简单,我对标准进行了误读,且在没有测试的情况下就开始了这一系列的博客。事实上,以我的思路,是无法制作出一个理想中的沙箱的,虽然可以控制住第三方代码的作用区域,但是无法做到完全的透明,其主要问题出在这里: var x = 3; console.log(this.x); // 打印出3 事实上,

JavaScript

不完美沙箱 - 劫持全局对象

上一章中对需求进行了分析,并对实现方案有了一定的探讨,最终得出从劫持全局对象这一环节入手的结论,而本文将讨论如何劫持这个全局对象。 全局对象,多数会进行Javascript编程的工程师都知道,在浏览器的执行环境中,叫做window,虽然事实上window和全局对象并不严格意义上是一个东西,不过这对我们的实现并不会造成什么障碍。 剖析全局对象 既然要去做劫持全局对象这样不人道的事,自然先要知道全局对象是个什么东西,有什么样的特点,以便针对目标,一刀致命。这个时候,标准就会成为我们最好的参考,首先打开ECMAScript 5的HTML版本,此后几乎所有的标准引用都会从这里产生。 所谓擒贼先擒王,经典理论告诉我们,不可以把整个洋洋洒洒数万字的标准给全看了,必须以快、狠、准的手段找到我们需要的东西。如果是纸质的书籍,对于一个不熟悉文档结构的人而言自然是无处下手,但好在现在是数字化的时代,我们有一个名为“搜索”的强大功能。

JavaScript

不完美沙箱 - 目的、背景及分析

目的 这将是一个系列的文章,大致由4篇博文组成,内容应该会是这样的: 目的、背景及分析 劫持全局对象 劫持全局对象属性 存在的问题及漏洞 起草这一系列博文的原因有两点,第一自然是因为最近突然有这样的需求,而群里正好也在某个深夜(技术宅基本深夜活动)讨论到了一个类似的话题,给了我一些灵感,所以决定将近期“研究”的成果展示一下。 而第二个目的,也是我想将这么一个简单的东西(其中最终就10几行代码)用整整5个博文的篇幅来说的原因,是因为近期有不少朋友向我强烈地表达了标准的存在意义极其微弱,我能把代码写好就足够的想法,而且现在更是催生了一种叫做jQuery工程师的职位,大有星星之火的样子。 对于这样的态度,作为一个只会理论不懂实践的2B工程师,个人自然是坚持地抱以反击态度的,因此,这一系列的博文,将会从“构建一个沙箱”

CSS

CSS语法简单学习

有这个博文的原因是,最近想做一个CSS的工具,至于工具的作用,先暂时不公开了,有兴趣的朋友可以邮件单独和我联系讨论下。为了这个工具,首先需要有一个CSS解析器,我称之为CSSParser,同时这个解释器和普通的基于Lex的词法分解+LR1的语法分析不同,他并不按标准给定的语法进行严格的检查,而仅仅分解出CSS中的各个元素。 为此,第一步自然是对CSS的语法有一个简单的了解,无论我的解释器是否按标准的语法进行解释,至少CSS语言的组成部分是必须明确的。此文也谨作总结之用。 整体组成 在CSS中,顶层元素被称为Rule,而CSS中的Rule又分为2类:CSSStyleRule和CSSAtKeywordRule。 CSSStyleRule是最基本的,即我们最常见的,由选择器+属性+值组成的部分,以下就是一个简单的示例: #nav>li~li { float:

HTML

HTML5标准学习 – 编码

相信每一个前端工程师都或多或少遇上过“乱码”这位仁兄,无论你的基础有多么扎实,在生产的过程中都免不了偶尔和“乱码”兄弟喝上几杯茶吧。作为一个前端工程师,你是如何指定一个页面的编码的呢?你知道浏览器是怎么识别编码的吗? 首先,一个很简单的例子,用遇简的HTML页面来看看各浏览器下有什么不同: <!DOCTYPE html> 最简HTML,<head>和<body>都没有内容,服务器也不给出具体的编码声明,直接从本地打开,各个浏览器下查看页面的编码: 浏览器 显示编码 备注 IE6

HTML

HTML5标准学习 – DOCTYPE

上一篇文章主要讲述了HTML文档的构成,同时肤浅地接触了“标签省略”这一概念,本文会从概念上介绍HTML文档中第一个出现的重要元素 – DOCTYPE。 所谓DOCTYPE,最初是XML的概念,即通过一种特定的语法,作为一种元数据,来描述XML文档中允许出现的元素,以及各元素的组成、嵌套规则等。具体的概念可以在WIKI中得到一个更详细的结果。 但是在HTML中,DOCTYPE又有着一些不同的效果,其中之一就是著名的触发浏览器标准模式的功能。即如果没有DOCTYPE,浏览器会进入一种被称为Quirks模式的怪异状态,在该模式下,浏览器的盒模型、样式解析、布局等都与标准规定的存在差异。 需要注意的是,所谓的HTML标准、DOM标准等,只规定了在标准模式下的概念和行为,正如文档构成中提到的,DOCTYPE是一个HTML文档绝对不可以省略的部分,因此就根本不存在“Quirks模式”这样的概念。也正是因为标准中没有对Quirks模式做出任何的规定,

HTML

HTML5标准学习 – 文档结构

说起HTML的结构,很多人都能说得头头是道,一般来说答案可能是这样的: 一个DOCTYPE,一个<html>,里面有<head>和<body>元素。 这当然不能说是不正确的,但是如果问到一个最小的HTML源文件必须有哪一些东西的话,恐怕很少有人能正确地做出回答。 先来回答一下这个问题,一个最简的HTML5源码文件需要的内容如下: <!DOCTYPE html> 是的,就这样,一个字符不多,一个字符不少,除了大小写可任意变化外,其他的任何内容都是不能变动的。 那么究竟是怎么样的规则,

HTML

HTML5标准学习 – 简介

最近前端的群都蛮热闹的,但我发现多数讨论的是javascript和css相关的问题,仿佛大家在努力创建各种交互、样式的时候,忘却了这一切的基础 – HTML。 其实我很喜欢HTML,觉得这个语言远比XML来得有趣,其灵活、轻便远非极端规范的XML可以比拟。同时又因为HTML的作用范围极小,规定的标签有限等说不上优点还是缺点的特色,使得HTML有着自己的确定性。 本系列的前面很大一部分会以非常短小的篇幅,介绍HTML5中的一些基本概念,并且: 只关心HTML这个语言,其他的javascript或者css完全不会涉及。 只关注HTML,对XHTML会简要带过,但不会详细说明,这源于XHTML有着比HTML更严格的规范,对浏览器的解析而言,可以认为是HTML的一个子集。 主要参考了whatwg的官方文档,并对现有主流浏览器的兼容性进行了评估。 介绍的全是基本的概念,不会涉及文档解析、DOM树构建、脚本执行之类的实现细节。 在这之后,可能会提取部分与浏览器的运行相关的技术细节,如脚本的解析、