每天开心一点

markdown操作入门

2018-01-24 15:27:00    六月    1402    来源: http://wowubuntu.com/markdown/basic.html

基本 Markdown 语法


第一类:对文字样式的编辑

编辑器最基本的功能,就是对文字本身加以处理。

Markdown 支持两种标题的语法, Setextatx 形式。Setext 形式是用底线的形式,利用=(最高阶标题)和-(第二阶标题),Atx 形式在行首插入 1 到 6 个#,对应到标题 1 到 6 阶。区块引用则使用 email 形式的 '>' 角括号。

例如对文字加粗,settext方式可以在Markdown 中通过

123
= 
    


来实现 对文字加粗

例如对文字加粗,在Markdown 中通过** **来实现。其实在 Word 中就对应工具栏中的「字体」选项,同类的标记字符还有* *来实现斜体。如果你在编辑器中写成


例 3:

  **演示粗体** 
  *演示斜体*

最终会显示为:

  
  演示 
  
  演示斜体

可以看出来,通过这些字符就改变了文字本身的属性。

第二类:对段落的编辑

相较于对「字」的编辑,更高一层的就是对「段落」的编辑,对应在 Word 中其实也是工具栏的「段落」选项。和第一类字符稍有不同,这些字符会把一些段落变成特殊格式的段落。例如+实现列表,#实现标题效果,>将一段文字变为引用,或者简单不加任何字符,但是在段落前缩进,就会显示出代码块。

注意:这些标记字符和文字之间有一个空格,且都为英语的符号。

例 4:

  + 演示列表 
   + 列表还可以有层级 
    
  > 这是引用文字的效果

最终会显示为:

  • 演示列表
    • 列表还可以有层级

这是引用文字的效果

第三类:插入文章其他元素

正如 Word 中的「插入」选项一样,Markdown 也不仅仅只编辑文字,而是可以将不同的元素放入文档中。最常见的就是通过[]()来插入链接和![]()来插入图片(可以是本地图片也可以是网络图片)

例 5:

[
少数派](
https://sspai.com)

![](https://cdn.sspai.com/attachment/thumbnail/2016/11/04/264631b984633898c415a818b181e5205653e
_mw_640.jpg)

注意:插入网络链接和图片的书写方式不止上面演示的一种,更全面的介绍可以查看  完整文档

Markdown 全部的标记字符基本就可以被分为这三类,如果你一时间无法记住,完全没有必要担心,需要时去翻看文档,尝试用 Markdown 语法写一两次文章,你就会发现,这个数量级的标记字符很快就可以记住了。

Markdown 语法的演进

如果你是第一次接触 Markdown,可能会觉得之前提及的 Markdown 拥有的编辑功能稍显羸弱;而如果你之前接触过 Markdown,就会发现一个奇怪的现象:在一些 Markdown 文档中出现的标记字符,居然不在这份 John Gruber 写的官方文档里。这就自然联系到下一个话题——Markdown 语法的增强和不同语法之间的异同。

正如任何一门自然语言都会存在方言的现象一样,随着 Markdown 的发展和普及,越来越多人不满足于 John Gruber 定义的那些 功能有限的标记字符,开始以他的语法为基础,拓展出各种各样的「Markdown 方言」。这些改进主要体现在两个方面:

  1. 增加新的标记字符,带来了新的编辑功能,例如表格、脚注和目录等。
  2. 修改了现有的标记字符,这主要出现在一些编辑器中,例如 Ulysses。

对基本语法的拓展

提到在编辑功能上对原生 Markdown 的拓展,最好的例子当属 Github Flavored Markdown。这是一套由 Github 网站为了帮助他们的主体用户群——程序员——更好的书写项目文档而推出的 Markdown 版本。由于其网站本身的影响力,以及他们的用户和 Markdown 用户高度重合,所以这套语法在互联网中得到了广泛推广。

原有的 Markdown 语法的功能稍显不足,Github Flavored Markdown 在前面所说的语法的三个方面都做出了相应的增强。同样的,你可以通过  官方文档 来查看全部的语法。相较原生语法,Github Flavored Markdown 主要做了以下改进:

  • 在对文字处理方面,它可以直接将网址高亮出来 (原生语法需要加相应的标记字符)
  • 在对段落的处理方面,对原有代码块进行了增强,如果你在代码块后表明代码语言:
```python 

def 点赞机
(): 
if 文章不错: 
return 点赞 
else: 
return 差评
    ```

就能直接看到相应编程语言的语法高亮。

  • 要插入文章元素方面,它支持在 Markdown 里写表格,如果你这么写:
| First Header  | Second Header 
|
| ------------- 
| ------------- | 
| Content Cell  | Content Cell 
|
| Content Cell 
| Content Cell  |

就会显示成:

First Header Second Header
Content Cell Content Cell
Content Cell Content Cell

Github Flavored Markdown 是个很好的案例,说明了为什么会有人对原有的基本 Markdown 语法进行改进—— 就是为了满足各种原生 Markdown 没有提供的需求

除了 Github Flavored Markdown 之外,MultiMarkdown 也不能不提。事实上目前众多编辑器都或多或少从 Multimarkdown 获取了一些灵感,相比 Github Flavored Markdown,Multimarkdown 是一套功能更为强大,同时语法更复杂的体系。如果有兴趣,你可以去  官网 查看完整的语法文档。而你会在很多编辑器中都能发现,它们或多或少的支持了 MultiMarkdown 的语法。

不过如果你是初学者,我能给的建议是:先 不要一上来就接触太多不同的增强型语法,这样会使得你愈发困惑。如果在日后使用中遇到了某些特殊的需求,例如脚注,再去搜索了解有哪些语法和编辑器支持你想要的那些功能 1

对通用语法的修改

除了上面所说的对基本语法的修改,还有的编辑器会对某些在通用语法中出现过的标记字符进行定制。例如,删除线的语法通常情况下是~~要删除的文字~~,但是在 Bear 中,开发者将它定义成-要删除的文章-。

这种情况的出现,主要还是 不同的开发者对 Markdown 的标记字符的「好用」理解不同。遇到这种情况大可不必担心,一般的编辑器都会给出自己的标记字符文档,有的还会让用户做出选择,是使用通用的语法标记,还是这个编辑器专属的语法。

既然有了多种选择就有比较,而作为使用者,我认为我们只需认识到有这种「方言现象」的存在就好,如果过于纠结哪套语法更好,其实并不能提高多少使用上的效率。由于 Markdown 编辑器的效率高度依赖使用者的肌肉记忆,也就使得使用者的习惯才是最主要的影响因子。对于你来说, 你习惯的语法才是效率最高的

Markdown 的使用

前面是完整的对 Markdown 的介绍,看完之后,理论上你应该能上手 Markdown。这时「什么时候该用」和「用什么工具」的选择就会浮现出来。事实上,我并不希望作为初学者你一开始就陷入「对工具得选择」而忘记了 Markdown 的初衷,所以接下来对这两个问题的回答,我都只会提出一两个例子,作为引导,而非像之前力求全面系统的阐述。

Markdown 的局限性

「什么时候该用 Markdown」,其实是个回答非常个性化的问题。为了厘清 Markdown 和其他编辑器的边界,与其枚举一个个应用场景,不如把问题改为 「什么时候不该用 Markdown」

前文有提到,Markdown 只是一个「轻量级标记语言」,相比同为标记语言的 Latex 、Word 或 Pages 这类文字处理软件,更不用说 Indesign 这种专业级的排版软件,Markdown 在排版的功能上显得羸弱。与最熟悉的 Word 相比,稍微对比一下就能发现其中的缺陷:

  1. Markdown 无法对「段落」进行灵活处理。在 Word 中你可以随意插入文本框,调整它的位置。尽管这并不是一个常见的用法,但是这意味着,Word 能以段落为单位进行排版 (Latex 也可以做到相似的效果),相比 Markdown 只能线性的对文字排版,专门的排版软件无疑是更能满足专业需求的。
  2. Markdown 对非纯文本元素的排版能力很差,最常见的例子就是图片。诚然,现在很多编辑器都支持了图文混排,但是受制于纯文本格式,Markdown 编辑器几乎不可能做到 Word 一样对图片灵活的调整位置,更不用说文字围绕图片进行自适应排版之类的效果。

可以看出,这些弱势都来源于 Markdown 本身的纯文本格式,因为 Markdown 从一开始就定位为「文字输入工具」,排版功能也是基于 HTML 的延伸, 并不适合对排版格式自定义程度较高的文档进行排版。




参考资料:

markdown完全入门(上) https://sspai.com/post/36610  

markdown完全入门(下) https://sspai.com/post/36682