浏览器工作原理 - 推酷
浏览器工作原理
这只是一个学习摘要！这只是一个学习摘要！这只是一个学习摘要！重要的事情说三遍，以下内容均来自网络，如有雷同，算我抄你的 :）“学习浏览器的内部工作原理将有助于您作出更明智的决策，并理解那些最佳开发实践的个中缘由。” ---Paul Irish
一、浏览器的主要功能
浏览器的主要功能就是向服务器发出请求，在浏览器窗口中展示您选择的网络资源。这里所说的资源一般是指 HTML 文档，也可以是 PDF、图片或其他的类型。资源的位置由用户使用 URI（统一资源标示符）指定。
浏览器解释并显示 HTML 文件的方式是在 HTML 和 CSS 规范中指定的。这些规范由网络标准化组织 W3C（万维网联盟）进行维护。
多年以来，各浏览器都没有完全遵从这些规范，同时还在开发自己独有的扩展程序，这给网络开发人员带来了严重的兼容性问题。如今，大多数的浏览器都是或多或少地遵从规范。
浏览器的用户界面有很多彼此相同的元素，其中包括：
用来输入URL的地址栏；
前进和后退按钮；
书签设置选项；
用于刷新和停止加载当前文档的刷新和停止按钮；
用于返回主页的主页按钮。
奇怪的是，浏览器的用户界面并没有任何正式的规范，这是多年来的最佳实践自然发展以及彼此之间相互模仿的结果。HTML5 也没有定义浏览器必须具有的用户界面元素，但列出了一些通用的元素，例如地址栏、状态栏和工具栏等。当然，各浏览器也可以有自己独特的功能，比如 Firefox 的下载管理器。
二、浏览器的高层结构
浏览器的主要组件为：
1、 用户界面 - 包括地址栏、前进/后退按钮、书签菜单等。除了浏览器主窗口显示的您请求的页面外，其他显示的各个部分都属于用户界面。
2、 浏览器引擎 - 在用户界面和呈现引擎之间传送指令。
3、 呈现引擎 - 负责显示请求的内容。如果请求的内容是HTML，它就负责解析 HTML 和 CSS 内容，并将解析后的内容显示在屏幕上。
4、 网络 - 用于网络调用，比如 HTTP 请求。其接口与平台无关，并为所有平台提供底层实现。
5、 用户界面后端 - 用于绘制基本的窗口小部件，比如组合框和窗口。其公开了与平台无关的通用接口，而在底层使用操作系统的用户界面方法
6、 JavaScript 解释器 -用于解析和执行 JavaScript 代码。
7、 数据存储 -这是持久层。浏览器需要在硬盘上保存各种数据，例如 Cookie。新的 HTML 规范 (HTML5) 定义了“网络数据库”，这是一个完整（但是轻便）的浏览器内数据库。
图：浏览器的主要组件
值得注意的是，和大多数浏览器不同，Chrome 浏览器的每个标签页都分别对应一个呈现引擎实例。每个标签页都是一个独立的进程。
呈现引擎的作用：在浏览器的屏幕上显示请求的内容
默认情况下，呈现引擎可显示 HTML 和 XML 文档与图片。通过插件（或浏览器扩展程序），还可以显示其他类型的内容；例如，使用 PDF 查看器插件就能显示 PDF 文档。但是在本章中，我们将集中介绍其主要用途：显示使用 CSS 格式化的 HTM L 内容和图片。
一、呈现引擎类型
本文所讨论的浏览器（Firefox、Chrome 浏览器和 Safari）是基于两种呈现引擎构建的。Firefox 使用的是 Gecko，这是 Mozilla 公司“自制”的呈现引擎。而 Safari 和 Chrome 浏览器使用的都是 WebKit。WebKit 是一种开放源代码呈现引擎，起初用于 Linux 平台，随后由 Apple 公司进行修改，从而支持苹果机和 Windows。
二、主流程
呈现引擎一开始会从网络层获取请求文档的内容，内容的大小一般限制在 8000 个块以内。
然后进行如下的基本流程：
图：呈现引擎的基本流程
呈现引擎将开始解析 HTML 文档，并将各标记逐个转化成“内容树”上的 DOM 节点。同时也会解析外部 CSS 文件以及样式元素中的样式数据。HTML 中这些带有视觉指令的样式信息将用于创建另一个树结构：呈现树。
呈现树包含多个带有视觉属性（如颜色和尺寸）的矩形。这些矩形的排列顺序就是它们将在屏幕上显示的顺序。
呈现树构建完毕之后，进入“布局”处理阶段，也就是为每个节点分配一个应出现在屏幕上的确切坐标。下一个阶段是绘制 - 呈现引擎会遍历呈现树，由用户界面后端层将每个节点绘制出来。
需要着重指出的是，这是一个渐进的过程。为达到更好的用户体验，呈现引擎会力求尽快将内容显示在屏幕上。它不必等到整个 HTML 文档解析完毕之后，就会开始构建呈现树和设置布局。在不断接收和处理来自网络的其余内容的同时，呈现引擎会将部分内容解析并显示出来。
三、主流程示例
图：webkit主流程
图：Mozilla的呈现引擎Gecko主流程
从上图中可以看出，虽然 WebKit 和 Gecko 使用的术语略有不同，但整体流程是基本相同的。Gecko 将视觉格式化元素组成的树称为“框架树”。每个元素都是一个框架。WebKit 使用的术语是“呈现树”，它由“呈现对象”组成。对于元素的放置，WebKit 使用的术语是“布局”，而 Gecko 称之为“重排”。对于连接 DOM 节点和可视化信息从而创建呈现树的过程，WebKit 使用的术语是“附加”。有一个细微的非语义差别，就是 Gecko 在 HTML 与 DOM 树之间还有一个称为“内容槽”的层，用于生成 DOM 元素。我们会逐一论述流程中的每一部分：
一、解析综述
解析式呈现引擎中非常重要的一个环节。解析文档是指将文档转化成为有意义的结构，也就是可让代码理解和使用的结构。解析得到的结果通常是代表了文档结构的节点树，它称作解析树或者语法树。
解析是以文档所遵循的语法规则（编写文档所用的语言或格式）为基础的。所有可以解析的格式都必须对应确定的语法（由词汇和语法规则构成）。这称为与上下文无关的语法。
解析器和词法分析器
解析的过程可以分成两个子过程：词法分析和语法分析。
词法分析是将输入内容分割成大量标记的过程。标记是语言中的词汇，即构成内容的单位。
语法分析是应用语言的语法规则的过程。
解析器通常将解析工作分给以下两个组件来处理：词法分析器（有时也称为标记生成器），负责将输入内容分解成一个个有效标记；而解析器负责根据语言的语法规则分析文档的结构，从而构建解析树。词法分析器知道如何将无关的字符（比如空格和换行符）分离出来。
解析是一个迭代的过程。通常，解析器会向词法分析器请求一个新标记，并尝试将其与某条语法规则进行匹配。如果发现了匹配规则，解析器会将一个对应于该标记的节点添加到解析树中，然后继续请求下一个标记。
如果没有规则可以匹配，解析器就会将标记存储到内部，并继续请求标记，直至找到可与所有内部存储的标记匹配的规则。如果找不到任何匹配规则，解析器就会引发一个异常。这意味着文档无效，包含语法错误。
很多时候，解析树还不是最终产品。解析通常是在翻译过程中使用的，而翻译是指将输入文档转换成另一种格式。编译就是这样一个例子。编译器可将源代码编译成机器代码，具体过程是首先将源代码解析成解析树，然后将解析树翻译成机器代码文档。
解析器类型
有两种基本类型的解析器：自上而下解析器和自下而上解析器。直观地来说，自上而下的解析器从语法的高层结构出发，尝试从中找到匹配的结构。而自下而上的解析器从低层规则出发，将输入内容逐步转化为语法规则，直至满足高层规则。
（未完待续。。。）
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致打开万维网 - CNET科技资讯网
中关村，被称为中国的硅谷，这里除了熙攘的电子卖场，...
剥皮寮是这此次「推荐Google街景三轮车拍摄景点」票选...
话说，某日，祝英台与梁山伯去逛街……
6月22日上午，在大连世界博览广场举办的第八届中国国际...
大部分公司在走向死亡。本文分析了微软之所以处于危险...
苹果发布的最新产品似乎并没有给苹果联合创始人之一的...
打开万维网
10年前的今天，在斯坦福大学的线性加速中心，粒子物理学家Paul Kunz编写了美国历史上第一个网页。在研究亚原子微粒的工作之余，他在西欧建立了全世界第一个万维网服务器，为人们获取科技文献提供了一条更容易的途径。
长期以来，科学家们一直为进入远程计算机协议和界面的繁琐而困扰，万维网确实为人们提供了便捷的登陆方式。发明万维网的人不是Kunz，而是Tim Berners-Lee。Tim是在日内瓦的CERN实验室工作的一名英国研究人员，现在是W3C协会的主席。通过对万维网有力的实证，Kunz把万维网发展成一个人们获取信息来源的主要工具，无论是对于学术研究，还是人们日常生活所需，万维网都越来越成为不可缺少的工具。
在SLAC的办公室里，Kunz向CNET讲述了美国万维网的发展情况。
问：象你这样的原子物理学家是如何建立美国第一个网页的？
答：我曾经参观过在瑞士日内瓦的CERN实验室，这是由欧洲国家建立的一个大型国际实验室。当时，Tim Berners-Lee邀请我参观他的万维网的使用情况，这是在NeXT计算机上编写的一个应用程序。那是日，他给我演示了在NeXT上编写的网络浏览器，我对此非常感兴趣。
问：是什么让你感到兴趣？
答：这不仅仅是一个浏览器，它可以在一个远程计算机上进行文件搜索，当然这也是万维网的关键之处。他在一个IBM主机上进行搜索，向系统提供信息，并告知它什么地方可以找到所需要的文件。这给了我一个想法：如果他可以进行搜索，那我也可以。在SLAC我有一个名为SPIRES的在线数据库，它的确需要一个友好的界面来把它连接到网络上。
当我目睹Tim Berners-Lee所做的一切时，我说：“这个很好，但是它可以在网络上工作吗？”Tim说：“当然，这个浏览器就是为网络设计的。”我说：“给我演示一下。”但是他说，他现在做不到。现在唯一的问题就是网络上所有的网络服务器不是统一的结构。
所以，我们就决定把这个浏览器上载到我在SLAC的计算机里，然后运行浏览器，把所有的视窗都传输到在CERN的计算机里。NeXT可以在一个计算机上运行这个应用软件，把视窗传输到另一个计算机上。这是我们测试万维网在网络上运行是快，还是慢的方法，我们只能通过远程控制运行网络浏览器，没有别的更好的办法。
问：万维网能运行的第一个证明是什么？
答：我们所做的就是在SLAC 和CERN之间来回传输信息。我相信这是Tim Berners-Lee第一次看见万维网在网络上的运行情况。我告诉他，我一回去，就在SLAC建立一个网络服务器，因为在SLAC我们有一个数据库，当时里面有200,000篇高能物理学的参考文献。每一篇都包含了作者，文章的标题和关键词，40个不同国家的成千上万的人在使用这个数据库。
问：所以它在计算机网络上已经可以使用了？
答：是的，但是人们必须登录到另外一个计算机上，而且数据库的命令不是很友好，所以应用起来很困难。我要做的就是把万维网作为一个更加友好的界面，这样世界各地的人都可以进行搜索了。当我回到美国时，我把这个工作交给了别人，两个月什么事情都没有发生。两个月后，Tim提醒我该开始进行演示了，而他要参加一个超文本的会议。所以直到12月12日我才结束了我的工作，开始进行网页设计的原因。
问：第一个网页的内容是什么？
答：第一个主页能做两件事情。一是通过BINLIST连接可以让人们在SLAC的在线电话薄上进行搜索，这样就可以得到电话号码和电子邮件地址；第二个连接就是HEP。
问：那时你用浏览器来做什么？
答：当时能够使用的浏览器是在NeXT机器上的，那些没有NeXT机器的人就只能看文本文件。我给Tim Berners-Lee发了一封电子邮件，说：“我们这里的服务器已经建立起来，并且在运行了，让我们来试一下吧。”这可能是在12月13日，Tim回信说：“太好了，恭喜恭喜，但是你的网页看起来不是很漂亮。”
问：那接下来发生了什么？
答：一个月后，也就是在日，另一个最重要的事情发生了。在法国的La Londe有一个为高能和原子物理提供先进计算技术的工厂，在那里Tim Berners-Lee进行了第一次万维网的运行试验。来自世界各地的约200名物理学家参加了这次演示。这次演示最成功地方就是Tim Berners-Lee用他的浏览器连接到了SLAC的数据库，这大开了这些物理学家的眼界。来自世界各地的约100个不同机构的200名物理学家聚在一起，你可以想象当他们回到自己的实验室后，向同事讲述他们所看见的一切，是一件多么令人激动的事情。
问：那以后，你是怎样安排你的时间的？
答：从那次会议结束后，一切都开始了。人们开始四处寻找可以找到浏览器的地方。CERN有自己的数据库，但是没有过多久更多的CERN物理学家都在使用6,000英里以外的SLAC数据库，因为万维网的使用界面更加友好。
问：所以万维网成功的关键之处就是界面友好？
答：我想是这样的。早期在万维网上的信息可以通过其他的方式来获得，但是一般的人不懂得如何来操作。人们经常发现自己登录在外国的一个计算机上，不知道命令，而且还有不熟悉的语法。
问：当你发明的网页开始发展时，浏览器发生了什么？是谁发明了第一个浏览器，或者说是谁发明了第一个图形界面的浏览器？
答：当时，第一个图形浏览器是在NeXT机器上使用的，而NeXT机器并不多，我想全世界大概只有100,000台。其他的人使用的都是线性模式的浏览器。Tim Berners-Lee和Robert Cailliau都忙于推广万维网，没有时间给Unix编写图形浏览器，他们希望万维网的思想能够广泛传播，并希望别的人能开始做这件事情。
问：你会继续做你的一流万维网设计师吗？
答：不，我还有其他的项目要做。我已经把这件事情交给了一名首席管理员，告知她去寻找别人的帮助，我不想在这上面花费太多的时间。帮助她的那些人被称为Web Wizards，Tony Johnson就是其中的一位，他开始从事万维网的开发，并发明了第一个动态网页，他也对图形感兴趣，希望有一个能在X-Windows下运行的浏览器。
问：Marc Andreessen的贡献是什么？
答：Marc开启了这一行动并参加了试验。有一天Tony给我们看了来自Marc的电子邮件：“恭喜，这太好了。”然后他给了Tony一个有关程序中的10个缺口的列表。几天后，Tony又从Marc那里得到了关于缺口的信息。从这时起，Tony感觉自己不想把全部时间花费在浏览器上，就让Marc来接手了。
问：高能物理学就是意味着粉碎原子吗？
答：我们不再研究原子了，它们太大了，我们粉碎离子。在SLAC我们研究电子，在Fermilab他们研究质子。
问：第一个图形浏览器是怎样开始发展的？
答：在我们的万维网发展的同时，在Los Alamos也在进行试验。我们有一个出版前的文献服务器，但是如果你要把文献全部放在万维网上，那么文献里的数据就要通过图表来显示，于是有一个能进行图表处理的浏览器就成为当时的需要了。
问：从结构来看，万维网发展最不好的地方在哪里？
答：我不想回答这个问题，因为万维网几乎没有什么缺点。整个网络是由在256台计算机前面的一群人设计的，最初的ARPAnet协议只能支持256台计算机。我们在成万上亿的计算机上进行测试，都没有发现什么缺点。当设计一个系统时，很难把它设计成可升级的。Tim Berners-Lee也不会认为每个学校，新闻社和航空公司都应该有一个万维网服务器，而这个基本上没有改变的万维网就有了很大的发展。
问：很难想象在过去的10年里没有什么缺口被发现。
答：当然是这样，在这段时间里，经常有一些电脑黑客为了娱乐而添加一些缺口，但是对于万维网最开始的预期情况来讲，这是微不足道的。
问：什么时候万维网将会成为科学家门日常生活和工作的一个部分？什么时候它会遍布于整个科学界？
答：当然万维网首先是在学术界发展，对于人们来讲，这是一个更好的方式。因为我们正在解决你还不知道的问题，所以我想必须有一个资金充足的科学团体。
详情请查看
（编辑：秦晶）
独家 | 原创
11/18/2004
06/15/2004
04/16/2004
11/13/2003
01/25/2002
09/13/2000
10/14/2013
10/12/2013
10/11/2013
10/10/2013
10/10/2013
10/10/2013
10/09/2013
10/09/2013
09/12/2012
09/04/2012
08/02/2012
07/24/2012
07/17/2012
07/04/2012
05/25/2012
05/09/2012浏览器是如何工作的？（工作原理）(一) - 测试天堂 - 51Testing软件测试网 51Testing软件测试网-中国软件测试人的精神家园
浏览器是如何工作的？（工作原理）(一)
& 17:24:50
/ 个人分类：
简介浏览器可以被认为是使用最广泛的软件，本文将介绍浏览器的工 作原理，我们将看到，从你在地址栏输入到你看到google主页过程中都发生了什么。将讨论的浏览器今天，有五种主流浏览器——IE、Firefox、Safari、Chrome及Opera。本文将基于一些开源浏览器的例子——Firefox、 Chrome及Safari，Safari是部分开源的。根据W3C（World Wide
Consortium 万维网联盟）的浏览器统计数据，当前（2011年9月），Firefox、Safari及Chrome的市场占有率综合已快接近50％。（原文为2009年10月，数据没有太大变化）因此，可以说开源浏览器将近占据了浏览器市场的半壁江山。浏览器的主要功能浏览器的主要功能是将用户选择得web资源呈现出来，它需要从服务器请求资源，并将其显示在浏览器窗口中，资源的格式通常是HTML，也包括PDF、image及格式。用户用URI（Uniform. Resource Identifier 统一资源标识符）来指定所请求资源的位置，在网络一章有更多讨论。HTML和CSS规范中规定了浏览器解释html文档的方式，由 W3C组织对这些规范进行维护，W3C是负责制定web标准的组织。HTML规范的最新版本是HTML4(http://www.w3.org/TR/html401/)，HTML5还在制定中（译注：两年前），最新的CSS规范版本是2（http://www.w3.org/TR/CSS2），CSS3也还正在制定中（译注：同样两年前）。这些年来，浏览器厂商纷纷开发自己的扩展，对规范的遵循并不完善，这为web开发者带来了严重的兼容性问题。但是，浏览器的用户界面则差不多，常见的用户界面元素包括：用来输入URI的地址栏前进、后退按钮书签选项用于刷新及暂停当前加载文档的刷新、暂停按钮用于到达主页的主页按钮奇怪的是，并没有哪个正式公布的规范对用户界面做出规定，这些是多年来各浏览器厂商之间相互模仿和不断改进得结果。HTML5并没有规定浏览器必须具有的UI元素，但列出了一些常用元素，包括地址栏、状态栏及工具栏。还有一些浏览器有自己专有得功能，比如Firefox得下载管理。更多相关内容将在后面讨论用户界面时介绍。浏览器的主要构成High Level Structure浏览器的主要组件包括：用户界面－ 包括地址栏、后退/前进按钮、书签目录等，也就是你所看到的除了用来显示你所请求页面的主窗口之外的其他部分浏览器引擎－ 用来查询及操作渲染引擎的接口渲染引擎－ 用来显示请求的内容，例如，如果请求内容为html，它负责解析html及css，并将解析后的结果显示出来网络－ 用来完成网络调用，例如http请求，它具有平台无关的接口，可以在不同平台上UI 后端－ 用来绘制类似组合选择框及对话框等基本组件，具有不特定于某个平台的通用接口，底层使用的用户接口JS解释器－ 用来解释执行JS代码数据存储－ 属于持久层，浏览器需要在硬盘中保存类似cookie的各种数据，HTML5定义了web database技术，这是一种轻量级完整的客户端存储技术图1：浏览器主要组件需要注意的是，不同于大部分浏览器，Chrome为每个Tab分配了各自的渲染引擎实例，每个Tab就是一个独立的进程。对于构成浏览器的这些组件，后面会逐一详细讨论。组件间的通信 Communication between the componentsFirefox和Chrome都开发了一个特殊的通信结构，后面将有专门的一章进行讨论。渲染引擎 The rendering engine渲染引擎的职责就是渲染，即在浏览器窗口中显示所请求的内容。默认情况下，渲染引擎可以显示html、xml文档及图片，它也可以借助插件（一种浏览器扩展）显示其他类型数据，例如使用PDF阅读器插件，可以显示PDF格式，将由专门一章讲解插件及扩展，这里只讨论渲染引擎最主要的用途——显示应用了CSS之后的html及图片。渲染引擎 Rendering engines本文所讨论得浏览器——Firefox、Chrome和Safari是基于两种渲染引擎构建的，Firefox使用Geoko——Mozilla自主研发的渲染引擎，Safari和Chrome都使用webkit。Webkit是一款开源渲染引擎，它本来是为linux平台研发的，后来由Apple移植到Mac及上，相关内容请参考http：//webkit.org。主流程 The main flow渲染引擎首先通过网络获得所请求文档的内容，通常以8K分块的方式完成。下面是渲染引擎在取得内容之后的基本流程：解析html以构建dom树-&构建render树-&布局render树-&绘制render树图2：渲染引擎基本流程渲染引擎开始解析html，并将标签转化为内容树中的dom节点。接着，它解析外部CSS文件及style标签中的样式信息。这些样式信息以及html中的可见性指令将被用来构建另一棵树——render树。Render树由一些包含有颜色和大小等属性的矩形组成，它们将被按照正确的顺序显示到屏幕上。Render树构建好了之后，将会执行布局过程，它将确定每个节点在屏幕上的确切坐标。再下一步就是绘制，即遍历render树，并使用UI后端层绘制每个节点。值得注意的是，这个过程是逐步完成的，为了更好的用户体验，渲染引擎将会尽可能早的将内容呈现到屏幕上，并不会等到所有的html都解析完成之后再去构建和布局render树。它是解析完一部分内容就显示一部分内容，同时，可能还在通过网络下载其余内容。图3：webkit主流程图4：Mozilla的Geoko 渲染引擎主流程从图3和4中可以看出，尽管webkit和Gecko使用的术语稍有不同，他们的主要流程基本相同。Gecko称可见的格式化元素组成的树为frame树，每个元素都是一个frame，webkit则使用render树这个名词来命名由渲染对象组成的树。Webkit中元素的定位称为布局，而Gecko中称为回流。Webkit称利用dom节点及样式信息去构建render树的过程为attachment，Gecko在html和dom树之间附加了一层，这层称为内容接收器，相当制造dom元素的工厂。下面将讨论流程中的各个阶段。解析 Parsing－general既然解析是渲染引擎中一个非常重要的过程，我们将稍微深入的研究它。首先简要介绍一下解析。解析一个文档即将其转换为具有一定意义的结构——编码可以理解和使用的东西。解析的结果通常是表达文档结构的节点树，称为解析树或语法树。例如，解析“2＋3－1”这个表达式，可能返回这样一棵树。图5：数学表达式树节点文法 Grammars解析基于文档依据的语法规则——文档的语言或格式。每种可被解析的格式必须具有由词汇及语法规则组成的特定的文法，称为上下文无关文法。人类语言不具有这一特性，因此不能被一般的解析技术所解析。解析器－词法分析器 Parser－Lexer combination解析可以分为两个子过程——语法分析及词法分析词法分析就是将输入分解为符号，符号是语言的词汇表——基本有效单元的集合。对于人类语言来说，它相当于我们字典中出现的所有单词。语法分析指对语言应用语法规则。解析器一般将工作分配给两个组件——词法分析器（有时也叫分词器）负责将输入分解为合法的符号，解析器则根据语言的语法规则分析文档结构，从而构建解析树，词法分析器知道怎么跳过空白和换行之类的无关字符。图6：从源文档到解析树解析过程是迭代的，解析器从词法分析器处取道一个新的符号，并试着用这个符号匹配一条语法规则， 如果匹配了一条规则，这个符号对应的节点将被添加到解析树上，然后解析器请求另一个符号。如果没有匹配到规则，解析器将在内部保存该符号，并从词法分析器 取下一个符号，直到所有内部保存的符号能够匹配一项语法规则。如果最终没有找到匹配的规则，解析器将抛出一个异常，这意味着文档无效或是包含语法错误。转换 Translation很多时候，解析树并不是最终结果。解析一般在转换中使用——将输入文档转换为另一种格式。编译就是个例子，编译器在将一段源码编译为机器码的时候，先将源码解析为解析树，然后将该树转换为一个机器码文档。图7：编译流程解析实例 Parsing example图5中，我们从一个数学表达式构建了一个解析树，这里定义一个简单的数学语言来看下解析过程。词汇表：我们的语言包括整数、加号及减号。语法：1. 该语言的语法基本单元包括表达式、term及操作符2. 该语言可以包括多个表达式3. 一个表达式定义为两个term通过一个操作符连接4. 操作符可以是加号或减号5. term可以是一个整数或一个表达式现在来分析一下“2＋3－1”这个输入第一个匹配规则的子字符串是“2”，根据规则5，它是一个term，第二个匹配的是“2＋3”，它符合第2条规则——一个操作符连接两个term，下一次匹配发生在输入的结束处。“2＋3－1”是一个表达式，因为我们已经知道“2＋3”是一个term，所以我们有了一个term紧跟着一个操作符及另一个term。“2＋＋”将不会匹配任何规则，因此是一个无效输入。词汇表及语法的定义词汇表通常利用正则表达式来定义。例如上面的语言可以定义为：INTEGER：0｜［1－9］［0－9］＊PLUS：＋MINUS：－正如看到的，这里用正则表达式定义整数。语法通常用BNF格式定义，我们的语言可以定义为：expression :＝ term operation termoperation := PLUS | MINUSterm := INTEGER | expression如果一个语言的文法是上下文无关的，则它可以用正则解析器来解析。对上下文无关文法的一个直观的定义是，该文法可以用BNF来完整的表达。可查看http：//en.wikipedia.org/wiki/Context-free_grammar。解析器类型 Types of parsers有两种基本的解析器——自顶向下解析及自底向上解析。比较直观的解释是，自顶向下解析，查看语法的最高层结构并试着匹配其中一个；自底向上解析则从输入开始，逐步将其转换为语法规则，从底层规则开始直到匹配高层规则。来看一下这两种解析器如何解析上面的例子：自顶向下解析器从最高层规则开始——它先识别出“2＋3“，将其视为一个表达式，然后识别出”2＋3－1“为一个表达式（识别表达式的过程中匹配了其他规则，但出发点是最高层规则）。自底向上解析会扫描输入直到匹配了一条规则，然后用该规则取代匹配的输入，直到解析完所有输入。部分匹配的表达式被放置在解析堆栈中。StackInput2 + 3 – 1term+ 3 – 1term operation3 – 1expression- 1expression operation1expression自底向上解析器称为shift reduce 解析器，因为输入向右移动（想象一个指针首先指向输入开始处，并向右移动），并逐渐简化为语法规则。自动化解析 Generating parse解析器生成器这个工具可以自动生成解析器，只需要指定语言的文法——词汇表及语法规则，它就可以生成一个解析器。创建一个解析器需要对解析有深入的理解，而且手动的创建一个由较好性能的解析器并不容易，所以解析生成器很有用。Webkit使用两个知名的解析生成器——用于创建语法分析器的Flex及创建解析器的Bison（你可能接触过Lex和Yacc）。Flex的输入是一个包含了符号定义的正则表达式，Bison的输入是用BNF格式表示的语法规则。rs automaticallyHTML解析器 HTML ParserHTML解析器的工作是将html标识解析为解析树。HTML文法定义 The HTML grammar definitionW3C组织制定规范定义了HTML的词汇表和语法。非上下文无关文法 Not a context free grammar正如在解析简介中提到的，上下文无关文法的语法可以用类似BNF的格式来定义。不幸的是，所有的传统解析方式都不适用于html（当然我提出它们并不只是因为好玩，它们将用来解析css和js），html不能简单的用解析所需的上下文无关文法来定义。Html 有一个正式的格式定义——DTD（Document Type Definition 文档类型定义）——但它并不是上下文无关文法，html更接近于xml，现在有很多可用的xml解析器，html有个xml的变体——xhtml，它们间的不同在于，html更宽容，它允许忽略一些特定标签，有时可以省略开始或结束标签。总的来说，它是一种soft语法，不像xml呆板、固执。显然，这个看起来很小的差异却带来了很大的不同。一方面，这是html流行的原因——它的宽容使web开发人员的工作更加轻松，但另一方面，这也使很难去写一个格式化的文法。所以，html的解析并不简单，它既不能用传统的解析器解析，也不能用xml解析器解析。HTML DTDHtml适用DTD格式进行定义，这一格式是用于定义SGML家族的语言，包括了对所有允许元素及它们的属性和层次关系的定义。正如前面提到的，html DTD并没有生成一种上下文无关文法。DTD有一些变种，标准模式只遵守规范，而其他模式则包含了对浏览器过去所使用标签的支持，这么做是为了兼容以前内容。最新的标准DTD在http：//www.w3.org/TR/html4/strict.dtdDOM输出的树，也就是解析树，是由DOM元素及属性节点组成的。DOM是文档对象模型的缩写，它是html文档的对象表示，作为html元素的外部接口供js等调用。树的根是“document”对象。DOM和标签基本是一一对应的关系，例如，如下的标签：&html&&body&&p&Hello DOM&/p&&div&&img src=”example.png” /&&/div&&/body&&/html&将会被转换为下面的DOM树：图8：示例标签对应的DOM树和html一样，DOM的规范也是由W3C组织制定的。访问http：//www.w3.org/DOM/DOMTR，这是使用文档的一般规范。一个模型描述一种特定的html元素，可以在http：//www.w3.org/TR/2003/REC-DOM-Level-2-HTML-/idl-definitions.htm&查看html定义。这里所谓的树包含了DOM节点是说树是由实现了DOM接口的元素构建而成的，浏览器使用已被浏览器内部使用的其他属性的具体实现。解析算法 The parsing algorithm正如前面章节中讨论的，hmtl不能被一般的自顶向下或自底向上的解析器所解析。原因是：1. 这门语言本身的宽容特性2. 浏览器对一些常见的非法html有容错机制3. 解析过程是往复的，通常源码不会在解析过程中发生改变，但在html中，脚本标签包含的“document.write ”可能添加标签，这说明在解析过程中实际上修改了输入不能使用正则解析技术，浏览器为html定制了专属的解析器。Html5规范中描述了这个解析算法，算法包括两个阶段——符号化及构建树。符号化是词法分析的过程，将输入解析为符号，html的符号包括开始标签、结束标签、属性名及属性值。符号识别器识别出符号后，将其传递给树构建器，并读取下一个字符，以识别下一个符号，这样直到处理完所有输入。图9：HTML解析流程符号识别算法 The tokenization algorithm算法输出html符号，该算法用状态机表示。每次读取输入流中的一个或多个字符，并根据这些字符转移到下一个状态，当前的符号状态及构建树状态共同影响结果，这意味着，读取同样的字符，可能因为当前状态的不同，得到不同的结果以进入下一个正确的状态。这个算法很复杂，这里用一个简单的例子来解释这个原理。基本示例——符号化下面的html：&html&&body&Hello world&/body&&/html&初始状态为“Data State”，当遇到“&”字符，状态变为“Tag open state”，读取一个a－z的字符将产生一个开始标签符号，状态相应变为“Tag name state”，一直保持这个状态直到读取到“&”，每个字符都附加到这个符号名上，例子中创建的是一个html符号。当读取到“&”，当前的符号就完成了，此时，状态回到“Data state”，“&body&”重复这一处理过程。到这里，html和body标签都识别出来了。现在，回到“Data state”，读取“Hello world”中的字符“H”将创建并识别出一个字符符号，这里会为“Hello world”中的每个字符生成一个字符符号。这样直到遇到“&/body&”中的“&”。现在，又回到了“Tag open state”，读取下一个字符“/”将创建一个闭合标签符号，并且状态转移到“Tag name state”，还是保持这一状态，直到遇到“&”。然后，产生一个新的标签符号并回到“Data state”。后面的“&/html&”将和“&/body&”一样处理。图10：符号化示例输入树的构建算法 Tree construction algorithm在树的构建阶段，将修改以Document为根的DOM树，将元素附加到树上。每个由符号识别器识别生成的节点将会被树构造器进行处理，规范中定义了每个符号相对应的Dom元素，对应的Dom元素将会被创建。这些元素除了会被添加到Dom树上，还将被添加到开放元素堆栈中。这个堆栈用来纠正嵌套的未匹配和未闭合标签，这个算法也是用状态机来描述，所有的状态采用插入模式。来看一下示例中树的创建过程：&html&&body&Hello world&/body&&/html&构建树这一阶段的输入是符号识别阶段生成的符号序列。首先是“initial mode”，接收到html符号后将转换为“before html”模式，在这个模式中对这个符号进行再处理。此时，创建了一个HTMLHtmlElement元素，并将其附加到根Document对象上。状态此时变为“before head”，接收到body符号时，即使这里没有head符号，也将自动创建一个HTMLHeadElement元素并附加到树上。现在，转到“in head”模式，然后是“after head”。到这里，body符号会被再次处理，将创建一个HTMLBodyElement并插入到树中，同时，转移到“in body”模式。然后，接收到字符串“Hello world”的字符符号，第一个字符将导致创建并插入一个text节点，其他字符将附加到该节点。接收到body结束符号时，转移到“after body”模式，接着接收到html结束符号，这个符号意味着转移到了“after after body”模式，当接收到文件结束符时，整个解析过程结束。图11：示例html树的构建过程解析结束时的处理 Action when the parsing is finished在这个阶段，浏览器将文档标记为可交互的，并开始解析处于延时模式中的脚本——这些脚本在文档解析后执行。文档状态将被设置为完成，同时触发一个load事件。Html5规范中有符号化及构建树的完整算法(http://www.w3.org/TR/html5/syntax.html#html-parser)。浏览器容错 Browsers error tolerance----&见下文}