在前面一篇中简单介绍了写一个 Markdown translator 的思路：
+-------+
| input |
+---+---+
|
|
+---v----+
| Tokens |
+---+----+
|
|
+---v----+
| Tree |
+---+----+
|
|
+---v----+
| html |
+--------+
对于 Markdown 而言，它主要包含 Block 和 Inline 两类元素。那么我的想法就是先解析出 Block 元素，然后在其 Content 中进行 Inline 的解析。
为了方便调试，我将生成的 Tree 采用 XML 来进行组织后输出，对于这样的输入：
header
====
解析后输出的 Tree 将是这样
symbol
Token(type: SpecialSymbol, value: ["="])
[Token(type: Plaintext, value: ["h", "e", "a", "d", "e", "r"])]
在解析 Block 元素的过程中，我发现 Markdown 语法的低效，平时我们在写 Markdown 的时候，都会在块元素之间加上一个或多个空格，以此来获得清晰的阅读效果，比如这样：
Paragraph
header
====
但是，Markdown 语法中，并没有明确的要求块元素之前使用多个 Newline 来分隔，那么你会好奇如果这样写会有怎样的解析结果：
Paragraph
header
====
很高兴基本上 Translator 直接都有了共识，对应的 HTML 将是这样：
Paragraph
header
但是这种兼容模式实际是给解析带来了不必要的难度，首先上面的文本会被解析成 Tokens，它们看起来像是这样：
1. Token(type: Plaintext, value: ["P", "a", "r", "a", "g", "r", "a", "p", "h"])
2. Token(type: Newline, value: ["\n"])
3. Token(type: Plaintext, value: ["h", "e", "a", "d", "e", "r"])
4. Token(type: Newline, value: ["\n"])
5. Token(type: SpecialSymbol, value: ["="])
6. Token(type: SpecialSymbol, value: ["="])
7. Token(type: SpecialSymbol, value: ["="])
8. Token(type: SpecialSymbol, value: ["="])
为了方便说明，我给它们编了号
根据 Markdown 语法，在看到 Token#1 时，我们发现接下来将有可能产生一个 Paragraph，于是我们继续往下读取，直到读到 Token#5 的时候，我们才直到，原来前面的内容可能并不全是 Paragraph，它们有可能包含 Header-Setext，于是我们开始尝试 Header-Setext 的语法，直到读到 Token#8 时，我们才确定，之前的内容原来是 Paragraph 和 Header-Setext。
那么如果语法强制要求块元素之间必须使用两个以上的 Newline 来分隔呢？那么如果你希望被解析成 Paragraph 和 Header-Setext 话，你就必须写成这样：
Paragraph
header
====
这样的话，当读取到两个以上的 Newline 我们就知道需要开始新的块元素解析了。这样做，既可以让解析更佳的高效，也会符合 Markdown 被创造时的原则 - 易读易写。
那么 Blockquote 元素是如何解析的呢，对于下面的内容：
> > nested blockquote
> H1
> ====
解析方式就是先解析出最外层的 Blockquote，然后对其内容进行处理 - 去掉 > 和紧随其后的 Space(如果有的话)。那么处理后的 Content 就会是这样：
> nested blockquote
H1
====
这就是为什么我们在 Blockquote 中如果希望使用 4 空格缩进表示代码块时需要输入 5 个空格：
> blockquote
>
> code block
未完待续