chore: 修改笔误

docs/art/100vue-html-parser.md

@@ -1,6 +1,6 @@
 # Vue 中的 html-parser
 
-<p class="tip">本节中大量出现 `parse` 以及 `parser` 这两个单词，不要混淆这两个单词，`parse` 是动词，代表“解析”的过程，`parser` 是名词，代表“解析器”。</p>
+本节中大量出现 `parse` 以及 `parser` 这两个单词，不要混淆这两个单词，`parse` 是动词，代表“解析”的过程，`parser` 是名词，代表“解析器”。
 
 打开 `src/compiler/parser/html-parser.js` 文件，该文件的开头是一段注释：
 
@@ -46,7 +46,7 @@ const conditionalComment = /^<!\[/
 
 ### attribute
 
-这与上之前我们讲解的小例子中所定义的正则的作用基本是一致的，只不过 `Vue` 所定义的正则更加严谨和完善，我们一起看一下这些正则的作用。首先是 `attribute` 常量：
+这与之前我们讲解的小例子中所定义的正则的作用基本是一致的，只不过 `Vue` 所定义的正则更加严谨和完善，我们一起看一下这些正则的作用。首先是 `attribute` 常量：
 
 ```js
 // Regular Expressions for parsing tags and attributes
@@ -61,7 +61,7 @@ const attribute = /^\s*([^\s"'<>\/=]+)(?:\s*(=)\s*(?:"([^"]*)"+|'([^']*)'+|([^\s
 
 * 1、使用双引号把值引起来：`class="some-class"`
 * 2、使用单引号把值引起来：`class='some-class'`
-* 3、不适用引号：`class=some-class`
+* 3、不使用引号：`class=some-class`
 
 正因如此，需要三个正则分组分别匹配三种情况，我们可以对这个正则做一个测试，如下：
 
@@ -172,7 +172,7 @@ const startTagOpen = new RegExp(`^<${qnameCapture}`)
 const startTagClose = /^\s*(\/?)>/
 ```
 
-`startTagOpen` 用来匹配开始标签的 `<` 以及标签的名字，但是并不包过开始标签的闭合部分，即：`>` 或者 `/>`，由于标签可能是一元标签，所以开始标签的闭合部分有可能是 `/>`，比如：`<br />`，如果不是一元标签，此时就应该是：`>`
+`startTagOpen` 用来匹配开始标签的 `<` 以及标签的名字，但是并不包括开始标签的闭合部分，即：`>` 或者 `/>`，由于标签可能是一元标签，所以开始标签的闭合部分有可能是 `/>`，比如：`<br />`，如果不是一元标签，此时就应该是：`>`
 
 观察 `startTagClose` 可知，这个正则拥有一个捕获分组，用来捕获开始标签结束部分的斜杠：`/`。
 
@@ -199,7 +199,7 @@ const doctype = /^<!DOCTYPE [^>]+>/i
 const comment = /^<!\--/
 ```
 
-这个正则用来匹配注释节点，没有捕获组。大家注意这句代码上方的注释，所以是：`#7298`。有兴趣的同学可以去 `Vue` 的 `issue` 中搜索一下相关问题。在这之前实际上 `comment` 常量的值是 `<!--` 而并不是 `<!\--`，之所以改成 `<!\--` 是为了允许把 `Vue` 代码内联到 `html` 中，否则 `<!--` 会被认为是注释节点。
+这个正则用来匹配注释节点，没有捕获组。大家注意这句代码上方的注释，索引是：`#7298`。有兴趣的同学可以去 `Vue` 的 `issue` 中搜索一下相关问题。在这之前实际上 `comment` 常量的值是 `<!--` 而并不是 `<!\--`，之所以改成 `<!\--` 是为了允许把 `Vue` 代码内联到 `html` 中，否则 `<!--` 会被认为是注释节点。
 
 ### conditionalComment
 
@@ -209,7 +209,7 @@ const conditionalComment = /^<!\[/
 
 这个正则用来匹配条件注释节点，没有捕获组。
 
-最后很重要的地点是，大家主要，这些正则表达式有一个共同的特点，即：*他们都是从一个字符串的开头位置开始匹配的，因为有 `^` 的存在*。
+最后很重要的一点是，大家注意，这些正则表达式有一个共同的特点，即：*他们都是从一个字符串的开头位置开始匹配的，因为有 `^` 的存在*。
 
 在这些正则常量的下面，有着这样一段代码：
 
@@ -249,7 +249,7 @@ const encodedAttrWithNewLines = /&(?:lt|gt|quot|amp|#10|#9);/g
 
 然后定义了 `reCache` 常量，它被初始化为一个空的 `JSON` 对象字面量。
 
-再往下定义了 `decodingMap` 常量，它也是一个 `JOSN` 对象字面量，其中 `key` 是一些特殊的 `html` 实体，值则是这些实体对应的字符。在 `decodingMap` 常量下面的是两个正则常量：`encodedAttr` 和 `encodedAttrWithNewLines`。可以发现正则 `encodedAttrWithNewLines` 会比 `encodedAttr` 多匹配两个 `html` 实体字符，分别是 `&#10;` 和 `&#9;`。对于 `decodingMap` 以及下面两个正则的作用不知道大家能不能猜得到，其实我们 [创建编译器](http://localhost:8080/#/note/7Vue%E7%9A%84%E7%BC%96%E8%AF%91%E5%99%A8%E5%88%9D%E6%8E%A2) 一节中有讲到 `shouldDecodeNewlines` 和 `shouldDecodeNewlinesForHref` 这两个编译器选项，当时我们就有针对这两个选项作用的讲解，可以再附录 [platforms/web/util 目录下的工具方法全解](http://localhost:8080/#/note/%E9%99%84%E5%BD%95/web-util?id=compat-js-%E6%96%87%E4%BB%B6) 中查看。
+再往下定义了 `decodingMap` 常量，它也是一个 `JOSN` 对象字面量，其中 `key` 是一些特殊的 `html` 实体，值则是这些实体对应的字符。在 `decodingMap` 常量下面的是两个正则常量：`encodedAttr` 和 `encodedAttrWithNewLines`。可以发现正则 `encodedAttrWithNewLines` 会比 `encodedAttr` 多匹配两个 `html` 实体字符，分别是 `&#10;` 和 `&#9;`。对于 `decodingMap` 以及下面两个正则的作用不知道大家能不能猜得到，其实我们 [创建编译器](http://localhost:8080/#/note/7Vue%E7%9A%84%E7%BC%96%E8%AF%91%E5%99%A8%E5%88%9D%E6%8E%A2) 一节中有讲到 `shouldDecodeNewlines` 和 `shouldDecodeNewlinesForHref` 这两个编译器选项，当时我们就有针对这两个选项的作用做讲解，可以在附录 [platforms/web/util 目录下的工具方法全解](http://localhost:8080/#/note/%E9%99%84%E5%BD%95/web-util?id=compat-js-%E6%96%87%E4%BB%B6) 中查看。
 
 所以这里的常量 `decodingMap` 以及两个正则 `encodedAttr` 和 `encodedAttrWithNewLines` 的作用就是用来完成对 `html` 实体进行解码的。
 
@@ -484,7 +484,7 @@ if (textEnd < 0) {
 }
 ```
 
-当 `textEnd === 0` 时，说明 `html` 字符串的第一个字符就是左尖括号，比如 `html` 字符串为：`<div>asdf</div>`，那么这个字符串的第一个字符就是左尖括号(`<`)。现在我们采用深度优先的方式去分析，所以我们暂时不关系 `textEnd >= 0` 以及 `textEnd < 0` 的情况，我们查看一下当 `textEnd === 0` 时的 `if` 语句块内的代码，如下：
+当 `textEnd === 0` 时，说明 `html` 字符串的第一个字符就是左尖括号，比如 `html` 字符串为：`<div>asdf</div>`，那么这个字符串的第一个字符就是左尖括号(`<`)。现在我们采用深度优先的方式去分析，所以我们暂时不关心 `textEnd >= 0` 以及 `textEnd < 0` 的情况，我们查看一下当 `textEnd === 0` 时的 `if` 语句块内的代码，如下：
 
 ```js
 if (textEnd === 0) {
@@ -528,7 +528,7 @@ if (textEnd === 0) {
 
 ### parse 注释节点
 
-针对以上六中情况我们逐个来看，首先判断是否是注释节点：
+针对以上六种情况我们逐个来看，首先判断是否是注释节点：
 
 ```js
 // Comment:
@@ -571,7 +571,7 @@ continue
 html.substring(4, commentEnd)
 ```
 
-通过调用字符串的 `substring` 方法截取注释内容，其中其实位置是 `4`，结束位置是 `commentEnd` 的值，用一张图表示将会更加清晰：
+通过调用字符串的 `substring` 方法截取注释内容，其中起始位置是 `4`，结束位置是 `commentEnd` 的值，用一张图表示将会更加清晰：
 
 ![](http://ovjvjtt4l.bkt.clouddn.com/2017-12-26-115232.jpg)
 
@@ -698,7 +698,7 @@ function parseStartTag () {
 }
 ```
 
-`parseStartTag` 函数首先会调用 `html` 字符串的 `match` 函数匹配 `startTagOpen` 正则，前面我们讲到过 `startTagOpen` 正则用来匹配开始标签的一部分，这部分包括：`<` 以及后面的 `标签名称`，并且拥有一个不获取，即捕获标签的名称。然后将匹配的结果赋值给 `start` 常量，如果 `start` 常量为 `null` 则说明匹配失败，则 `parseStartTag` 函数执行完毕，其返回值为 `undefined`。
+`parseStartTag` 函数首先会调用 `html` 字符串的 `match` 函数匹配 `startTagOpen` 正则，前面我们讲到过 `startTagOpen` 正则用来匹配开始标签的一部分，这部分包括：`<` 以及后面的 `标签名称`，并且拥有一个捕获组，即捕获标签的名称。然后将匹配的结果赋值给 `start` 常量，如果 `start` 常量为 `null` 则说明匹配失败，则 `parseStartTag` 函数执行完毕，其返回值为 `undefined`。
 
 如果匹配成功，那么 `start` 常量将是一个包含两个元素的数组：第一个元素是标签的开始部分(包含 `<` 和 `标签名称`)；第二个元素是捕获组捕获到的标签名称。比如有如下 `html`：
 
@@ -822,7 +822,7 @@ end = ['/>', '/']
 end = ['>', undefined]
 ```
 
-所以，如果 `end[1]` 不为 `undefined`，那么说明该标签是一个一元标签。那么现在再看 `if` 语句块内的代码，将很容以理解，首先在 `match` 对象上添加 `unarySlash` 属性，其值为 `end[1]`：
+所以，如果 `end[1]` 不为 `undefined`，那么说明该标签是一个一元标签。那么现在再看 `if` 语句块内的代码，将很容易理解，首先在 `match` 对象上添加 `unarySlash` 属性，其值为 `end[1]`：
 
 ```js
 match.unarySlash = end[1]

docs/art/80vue-compiler-start.md

@@ -130,7 +130,7 @@ return {
 而这里的 `compileToFunctions` 属性就是 `platforms/web/compiler/index.js` 文件中解构出来的 `compileToFunctions`：
 
 ```js
-// 这里通过 createCompiler 函数的返回值结构出 compileToFunctions
+// 这里通过 createCompiler 函数的返回值解构出 compileToFunctions
 const { compile, compileToFunctions } = createCompiler(baseOptions)
 ```
 
@@ -205,7 +205,7 @@ const { render, staticRenderFns } = compileToFunctions(template, {
 
 其中 `shouldDecodeNewlines` 和 `shouldDecodeNewlinesForHref` 这两个变量来自于 `platforms/web/util.js` 文件，大家可以在附录 [platforms/web/util 目录下的工具方法全解](/note/附录/web-util) 中查看这两个变量的作用，其目的是对浏览器的怪癖做兼容，具体在附录中都有讲到，并且这两个变量的类型都是布尔值。
 
-对于 `options.delimiters` 和 `options.comments`，其中 `options` 就是当前 `Vue` 实例的 `$options` 属性，并且 `delimiters` 和 `comments` 都是 `Vue` 提供的选项。所以这两只是简单的将这两个选项透传了过去。
+对于 `options.delimiters` 和 `options.comments`，其中 `options` 就是当前 `Vue` 实例的 `$options` 属性，并且 `delimiters` 和 `comments` 都是 `Vue` 提供的选项。所以这里只是简单的将这两个选项透传了过去。
 
 另外 `delimiters` 和 `comments` 这两个选项大家在 `Vue` 的官方文档都能够找到讲解。而这里我要强调的是在 `Vue` 官方文档中有特殊说明，即这两个选项只在完整版的 `Vue` 中可用。这是为什么呢？可能有的同学已经知道了，其原因是这两个选项只有在创建完整版 `Vue` 的时候才会用到，大家不要忘了 `entry-runtime-with-compiler.js` 这个文件是完整版 `Vue` 的入口，也就是说运行时版的 `Vue` 压根不存在这些内容所以自然不会起作用。
 
@@ -629,7 +629,7 @@ export default function text (el: ASTElement, dir: ASTDirective) {
 
 `baseOptions` 的第四个属性是 `isPreTag`，它是一个函数，可以在附录 [platforms/web/util 目录下的工具方法全解](/note/附录/web-util) 中查看其实现讲解，其作用是通过给定的标签名字检查标签是否是 `'pre'` 标签。
 
-`baseOptions` 的第五个属性是 `isUnaryTag`，它来自于与 `options.js` 文件同级目录下的 `util.js` 文件，即 `src/platforms/web/compiler/util.js` 文件，带看这个文件，找到 `isUnaryTag` 如下：
+`baseOptions` 的第五个属性是 `isUnaryTag`，它来自于与 `options.js` 文件同级目录下的 `util.js` 文件，即 `src/platforms/web/compiler/util.js` 文件，再看这个文件，找到 `isUnaryTag` 如下：
 
 ```js
 export const isUnaryTag = makeMap(
@@ -732,7 +732,7 @@ if (options.directives) {
 
 由于 `directives` 是对象而不是数组，所以不能采用与 `modules` 相同的处理方式，对于 `directives` 采用原型链的原理实现对扩展属性与基本属性。首先通过 `Object.create(baseOptions.directives || null)` 创建一个以 `baseOptions.directives` 对象为原型的新对象，然后使用 `extend` 方法将 `options.directives` 的属性混合到新创建出来的对象中，并将该对象作为 `finalOptions.directives` 的值。
 
-最后对于 `options` 中既不是 `modules` 又不是 `directives` 其他属性，采用直接复制过去的方式进行处理：
+最后对于 `options` 中既不是 `modules` 又不是 `directives` 的其他属性，采用直接复制过去的方式进行处理：
 
 ```js
 // copy other options
@@ -749,7 +749,7 @@ for (const key in options) {
 const compiled = baseCompile(template, finalOptions)
 ```
 
-上面的代码调用了 `baseCompile` 函数，并分别将字符串模板(`template`)，以及最终的编译器选项(`finalOptions`)传递了过去。这说明什么？这说明 `compile` 函数对模板的编译是通过委托 `baseCompile` 完成的。`baseCompile` 函数是 `createCompilerCreator` 函数的形参，是在 `src/compiler/index.js` 文件中调用 `createCompilerCreator` 创建 `'编译器创建者' 的创建者时` 传递过来的：
+上面的代码调用了 `baseCompile` 函数，并分别将字符串模板(`template`)，以及最终的编译器选项(`finalOptions`)传递了过去。这说明什么？这说明 `compile` 函数对模板的编译是通过委托给 `baseCompile` 完成的。`baseCompile` 函数是 `createCompilerCreator` 函数的形参，是在 `src/compiler/index.js` 文件中调用 `createCompilerCreator` 创建 `'编译器创建者' 的创建者时` 传递过来的：
 
 ```js
 export const createCompiler = createCompilerCreator(function baseCompile (

docs/art/90parser-intro.md

@@ -2,7 +2,7 @@
 
 在 [Vue的编译器初探](/note/7Vue的编译器初探) 这一章节中，我们对 `Vue` 如何创建编译器，以及在这个过程中经历过的几个重要的函数做了分析，比如 `compileToFunctions` 函数以及 `compile` 函数，并且我们知道真正对模板进行编译工作的实际是 `baseCompile` 函数，而接下来我们任务就是搞清楚 `baseCompile` 函数的内容。
 
-`baseCompile` 函数是在 `src/compiler/index.js` 中作为 `createCompilerCreator` 函数参数使用的，代码如下：
+`baseCompile` 函数是在 `src/compiler/index.js` 中作为 `createCompilerCreator` 函数的参数使用的，代码如下：
 
 ```js
 // `createCompilerCreator` allows creating compilers that use alternative
@@ -62,9 +62,9 @@ const ast = parse(template.trim(), options)
 
 > 它主要的目的是将便于人编写、阅读、维护的高级计算机语言所写作的 `源代码` 程序，翻译为计算机能解读、运行的低阶机器语言的程序。`源代码` 一般为高阶语言（High-level language），如Pascal、C、C++、C# 、Java等，而目标语言则是汇编语言或目标机器的目标代码（Object code）。
 
-编译器所包含的概念很多，比如 词法分析，语义分析，类型检查/推导，代码优化，代码生成...等等，且大学中已有专门的课程，而我们这里要将的 `parser` 就是编译器中的一部分，准确的说，`parser` 是编译器对源代码处理的第一步。
+编译器所包含的概念很多，比如 词法分析，语义分析，类型检查/推导，代码优化，代码生成...等等，且大学中已有专门的课程，而我们这里要讲的 `parser` 就是编译器中的一部分，准确的说，`parser` 是编译器对源代码处理的第一步。
 
-说点题外话，看到这里的同学，如果你不是科班出身，请不要对自己产生怀疑，一个对你最简单有效鼓励方式是：这套系列文章的作者，也就是我本人也不是科班出身的。如果这对你的鼓励不够，那我再换一种方式：`Vue` 的作者也不是科班出身的，这次够了吗？知识是死的但人是活的，知识就摆在那里，你学了多了就会了多少。
+说点题外话，看到这里的同学，如果你不是科班出身，请不要对自己产生怀疑，一个对你最简单有效鼓励方式是：这套系列文章的作者，也就是我本人也不是科班出身的。如果这对你的鼓励不够，那我再换一种方式：`Vue` 的作者也不是科班出身的，这次够了吗？知识是死的但人是活的，知识就摆在那里，你学了多少就会了多少。
 
 回到正题，我们说 `parser` 是编译器处理源代码的第一步，原因是什么呢？接下来我们讲一讲什么是 `parser`。