John Gruber：深入Markdown
- - 博客 - 伯乐在线“有时候一件事情的真相，不是来自于对它的思考，而是来自于对它的感觉. 这儿有个问题：你最近一次听到足以改变你内心想法的论述是什么时候. 不仅仅是关于那些你没怎么想过的问题，也包括在听到这个论述之前你原本相当确信的观念. 也就是说，你最近一次认识到自己在某个观念上彻底错了是什么时候. 如果你的回答是“从来没有”，或者是“很久以前”，那么这是否就意味着你总是正确的.
John Gruber：深入Markdown
标签：
互联网
Email
John
Gruber
Markdown
写作
| 发表时间：2012-08-17 09:12 | 作者：张 重骐
出处：http://blog.jobbole.com
“有时候一件事情的真相，不是来自于对它的思考，而是来自于对它的感觉。” ——STANLEY KUBRICK
要点1
这儿有个问题：你最近一次听到足以改变你内心想法的论述是什么时候？不仅仅是关于那些你没怎么想过的问题，也包括在听到这个论述之前你原本相当确信的观念。
也就是说，你最近一次认识到自己在某个观念上彻底错了是什么时候？
如果你的回答是“从来没有”，或者是“很久以前”，那么这是否就意味着你总是正确的？
这里有我的一个故事。
一月份的时候，关于Postel法则在解析XML聚合信息流（比如 RSS和 Atom这样的格式）的软件中的应用，曾经有过一次争论。这次争论简而言之，就是 Postel法则认为：“自己做的时候要谨慎，对别人的东西要宽容”，而XML规范则明确说明：“一旦发现致命错误，解析器就不能再继续正常的解析流程了（比如，绝不能继续将字符数据和文档结构描述信息还用标准方式传递给应用程序）。”
那么，解析XML聚合信息流的软件该如何抉择呢？是依照Postel法则，包容遇到的错误？还是依照XML标准，一遇到严重错误就中端处理？
Brent Simmons（Mac系统上的主流新闻聚合阅读器NetNewsWire的开发者）和 NIck Bradbury（Windows系统上主流新闻聚合阅读器FeedDemon的开发者）都认为在处理Atom和XML信息流时，他们的软件应该采取严格的标准。很多牛人都同意他们的看法。
“客户端的标准应该严格”的论点，我觉得可以归结为一下几点：
1、正确、规整的XML要好于有语法错误的XML；
2、要写出能生成正确、规整的XML的软件并不是那么难（就像 Tim Bray说的，“任何不能用规整的XML写聚合信息流的人都是无能的蠢货”）。
3、如果主流的XML信息流阅读软件都要求正确、规整的XML数据，那么就会促使生成信息流的应用不再输出糟糕的XML。
这三点我都同意，因此，我坚定地站在“客户端解析时应该有严格标准”的阵营中。
但之后我读了Mark Pilgrim的“ 思想实验”。Pilgrim不仅是信息流解析应该宽松的倡议者，而且他公开了自己的所有代码，还写出了著名的开源信息流解析器 Universal Feed Parser
Pilgrim的观点，至少在我看来是这样的：如果你在做处理XML信息流的软件，而你的解析器非常严格，那么你的用户在遇到异常数据的时候就会遭殃。事实上，你的用户终究是会遇到异常数据的；这种情况发生的话，也许错在造成数据异常的人，但最终受害的却是你的用户，就因为客户端被强加的严格检查。
读过之后，我认真思考了他的思想实验，最终意识到我之前彻底错了，他是对的。（Simmons也改变了他自己的想法，看以到 这里和 这里看后续的故事。）
Pilgrim仅凭借他在“ 思想实验”中的论述，就让我认识到自己错了。但有意思的是，他说服我的时候， 并没有反驳任何一个让我一开始站在“严格解析”阵营的事实。
这就是我要说的第一点：当我最终改变某个观点的时候，通常并不是因为我掌握的事实有误，而是因为我没有选对事实。
要点2
回头来看，所有博客软件背后的基本理念，其核心似乎都很简单。你是在管理一系列的文章，而不是有一系列网页的网站，博客软件会帮你将文章转换成网页。
博客软件对一般人的吸引力很容易理解。没有博客软件，他们就没法发布站点。
但博客软件对行家们——就是完全有能力用HTML手写出一个博客网站的专家们——的吸引力在哪儿呢？当然了，确实有 一些人坚持手写。但是对大多数人，甚至包括世界上 最博学和 最著名的web工程师，都在用博客软件包（或者是 开发自己的博客发布程序）。
答案是方便，灵活。博客软件免去了更新站点的过程中绝大多数的单调劳动。我必须承认——直到我2002年发布Daring Fireball的几个月前才明白这点。我能手写一整个网站出来而且还觉得写代码很容易，这样的事实让我忽视了在这个过程中有很多很多机械重复性的工作。
下面是我每次往Daring Fireball上发布一篇新文章实际上会发生的事：
1、新文章出现在首页的顶部（同时从首页移去最旧的文章）；
2、新文章有一个单独的永久页面；
3、在我的RSS信息流中更新这篇文章；
4、标题和新页面的链接被添加到我的 存档页面；
5、新页面的标题和链接作为“下一篇”被添加到上一篇文章中。
我只需要一个操作——发布一篇文章——然后Movable Type就会创建一个新文件，并且更新其他四项。这些任务都不 难手动完成，其实很大程度上就是拷贝-粘贴的事儿。这些工作确实很无聊——而且即使确实不 难，我仍然很可能出错。我会犯错，因为我可能烦了，或是忘了操作其中哪步。单调的重复性工作正是计算机所擅长，而不适合人类的。
另外，博客软件的这种封装也显得很自然。写一篇文章——或是对现有文章做出修改——感觉上就应该是一项任务。我要编辑的是文章，而不是文章所出现的页面。
因此，我要说的第二点是：不能仅仅因为一件事情不难，就认为它应该这样做。
下面我要试着将要点1和要点2结合起来，说说Markdown的事儿。
让我们先回退一步。之前我说了，博客软件让你将站点当作文章的集合来管理，而不是页面的集合。
那么什么是一篇 文章？
常见的说法是，一篇文章就是一个HTML代码段。不是完整的HTML文档，仅仅是一段HTML格式的文本——博客软件负责生成完整的HTML（或者XML）文档。你的博客模板里有关于文档结构的所有标签——<html>, <head>, <body>, 等等——以及给你文章预留的位置。一旦你发布，你的博客软件就把你的文章当作HTML代码短插入你的HTML模板中。
在我写Daring Fireball的第一年里，即从2002年8月到2003年8月的整整一年，我非常认可“文章就是HTML代码段”的说法。我甚至从来没有考虑过别的可能性。我在Daring Fireball中写的每一篇文章，都是标准的HTML格式。（其实是XHTML，但这种区别现在不重要。）
当然，除了一点之外，那就是HTML 代码段不能被作正确性验证，因为HTML是一种文件类型。你可以写出 规整的HTML代码——确保关闭每一个标签，转换每一个&和<>符号——但你却不能将HTML代码段放到 W3C HTML Validator上做检查，也不能用BBEdit的HTML语法检查工具。
我期望的工作流程是：
1、在BBEdit中写文章，编辑，修订；
2、搞定后，登录MT的web界面，将文章粘贴进去，然后发布。
但我的实际工作流程看起来却是这样的：
1、在BBEdit中写文章；
2、在 浏览器中预览：
3、切换到BBEdit中修订；
4、重复上面的步骤，直到搞定；
5、登录MT，粘贴文章，然后发布。
最终，我领悟到： 这太愚蠢了。用电脑写文章的最大优势就是编辑起来比较直接。写、读、修订，都在同一个窗口中、同一种模式下完成。
用HTML格式直接写文章的理由——我用了很多年的理由——是HTML并不难。这点 我仍然认同。HTML很容易学会，而且一旦学会，就能马上用起来。专业的web开发？那确实很难。但HTML的基本tag和规则——足够能让你用HTML代码直接撰写博客的HTML知识——是很简单的。
但像 Lynx这样的纯文本浏览器也不直接给你显示HTML源代码，是有原因的。因为HTML本身就不是要作为一种可读格式存在的。用一种没有可读性的格式来写作，你不觉得很奇怪吗？突然间，我感到自己很荒唐。
要点1的应用：我没说写HTML源代码很难，而且仍然同意它很容易。我在论述完全不相关的另一个观点——我们所说的容易，是指讲文章标记上各种标签很容易，而不是阅读和排版容易。
要点2的应用：即使你仍然坚持认为，用HTML源代码写文章很容易，但难道这样不是很繁琐吗？要写”AT&T”而不是直接写”AT&T”，这难道不无聊吗？（更别提要把URL的&符号进行编码。）
现在是2004年了！你的电脑难道不应该有能力判断你的文章哪里是分段，哪里是副标题吗？
别跟我说Movable Type的“转换分段符”功能可以实现这个效果。2.661版MT的“转换分段符”功能将会把输入的如下两行：
<h2>This is a header.</h2> This is a paragraph
转换成：
<p><h2>This is a header.</h2> </p><p>This is a paragraph.</p>
这效果真是够矬的。TypePad显然能做到不在块级别的HTML标签外再嵌套一层没用的<p>标签——因此MT3.0大概也能做到——但这仍然无法改变其所生成HTML代码的冗余和难看。
为什么桌面版的博客编辑器需要提供“预览”模式呢？你在发送一封电子邮件之前，不需要“预览”——您写完邮件，回过头读一下，然后编辑修改，就行了。
实际上，我很喜欢写电子邮件。电子邮件是我最喜欢的写作媒介。在过去的5年里，我发送的邮件超过16,000封。电子邮件的纯文本传统让我能清楚、准确地表达我自己， 中途不会有别的东西来干扰我。
就这样，Markdown诞生了。电子邮件风格的web写作方式。
其他多数的“文本-HTML”转换器都基于这样的假设，即HTML的标签很难用，所以他们用自己的标签来替代HTML的标签，结果是相较于HTML既不“更容易”也不“更可读“。而且，最终的结果是当用户遇到问题时，很难自如翻阅手册，不得不再次捡起HTML来。
其他的转换器都意在替换HTML，而Markdown则考虑的是别的东西。它希望能最有效解决问题，既能让人在必要的时候很容易地使用原生的HTML，也能让你在只需要写字的时候可以专心地写纯文本。
多数博客应用提供的一些标签快捷按钮——斜体、加粗、链接、图片、引用——并不是你一开始就需要考虑的。把插入这些标签做的这么容易，并不会让写作更容易，相反，会让你的文章结构更难被辨识。
但当你真的需要使用内嵌的HTML源码时——比如说，要用自定义的类属性来创建一个特殊样式的有序列表——你应该能直接就写HTML。不用做字符转义，不用特殊的模式转换标记，就直接用标签好了。Markdown让你能这样做，因为它是专门被设计为只作为HTML预处理器的。
（如果你确实需要将Markdown格式的文档转换为非HTML格式，只需要先将它转换为HTML，然后使用现有的HTML转换器就行了。）
尽管我确实认为HTML很简单，但在一个特定领域它真的很棘手（如果不能说难的话）：用HTML标记语言来写关于HTML标记的东西实在很让人头痛。当你写 有关代码的东西的时候，你应该只用关注示例代码本身——而不是每一个涉及<, &, < 以及&符号的转义问题。
除了让在文档中添加内嵌HTML变得容易之外，Markdown也让在代码段中添加 示例 HTML标签变得容易了。
深入Markdown
感觉 vs 思考
纯文本在印刷上的局限性——单一的字体，单一的字号，没有斜体和加粗——跟打字机的局限性非常类似。设想有个不错的人给你买了个礼物：一个用原始打字机打印出来的一本经典小说的手稿，就比如说是Fitzgerald的“了不起的盖茨比”吧。你可以坐下来静静读这本手稿，从头到尾，这样获得的阅读体验，与你阅读一本精心排版和包装后的书的体验几乎是一样的。没错，那种感觉贯穿在打字机充满油污的、等宽Courier式的字体中，以及用下划线代替斜体的习惯，等等。——但文字依旧流畅，从纸面飞跃到你的心中，就像Fitzgerald所期望的那样。
我在文章开头引用的Stanley Kubrick的名言是我最喜欢的话之一。当你读或者写用HTML标签标记的文字时，这些标记在强迫你集中注意力去思考他们。而我希望Markdown格式的文本所传达的是一种感觉。
英文原文： dive into markdown 编译：张重骐（ @candyhorse）
相关文章
相关 [john gruber markdown] 推荐：
John Gruber 悼乔布斯
- tossking - Apple4.us本文原载 Daring Fireball，发表于 2011 年 10 月 6 日，作者：John Gruber. 四个月前的 WWDC 主题讲演结束后，我近距离见到了乔布斯. 那种老无法用年龄衡量，是一种不可想象的老. 用疲劳一词形容并不确切，应该说是过劳. 他是病人，但用生病形容也不对，或许「古老」才是恰当的形容词.
使用node.js建markdown静态博客，文章总汇(8篇)
- genedna - CNode社区这篇从我的javaeye博客上转过来的，有点像学习笔记. 在学习node.js的过程中，顺便做了个静态博客，边写博客边编码，一段时间下来写了８篇文章. 从文件上传开始, 进入node.js的世界. 将使用npm管理的node.js项目部署到vCloudLabs. 用node.js建博客(一) – node.js安装及Express框架简介.
Mou – Markdown 语言编辑器 [Mac] | 小众软件 > Mac
- Z - 小众软件Markdown 算是一门新兴语言，现在 7-8 岁了吧. 它设计的初衷就是让写字的人专注于写字，用纯文本简单的符号标记格式，最后再通过工具转换成鬼畜的 HTML/XHTML. 如果你玩过 wikipedia，基本是很类似的意思. Mou 是 Mac 上的 Markdown 编辑器，两栏界面，直观清爽，功能简洁到位，会用的才知道.
Markdown - 引领未来科技写作的博客利器
- - UX 一淘体验中心一、什么是Markdown?. 通常可以这样理解，对于网络上写作的人，Markdown 是 一种text-to-html (文本到 html)的转换工具. 它提供给你一种方便阅读、方便书写的纯文本格式，然后把纯文本转换成符合语意并且结构化良好的 HTML 或者 XHTML.. HTML/XML/SGML/TeX一样，Markdown 同样是一种 Markup Language(标记语言).
写了一个小 wiki 玩具 in web.py，无数据库，默认支持 markdown 标记
- wang - python.cn(jobs, news)我用写了一个轻量 wiki 玩具名为 ZWiki （大小写敏感）, 仅仅是因为妹子回家无聊，它不会像 mediawiki 那么庞大、强大和臃肿. - 基于 web.py 写，部分脏活粗暴直接调用 find grep 来干. - 支持 markdown 标记. - 不用数据库，粗暴直接读写文本文件，你可以用 Firefox + It's all text + 任意编辑器更新 wiki ，或者直接 修改对应的文本文件.
腾讯开源的Markdown编辑器，开箱即用、轻量简洁、易扩展
- - 程序猿DDMarkdown是我们开发者最为热爱的文本格式，自从爱上Markdown之后，我们的笔记、博客、留言等都希望有Markdown的支持. 所以，Markdown编辑器已经是前端非常重要的一个组件了. 之前有推荐过一些开源的Markdown编辑器，今天继续推荐一个由腾讯开源的Markdown编辑器： Cherry Markdown Editor.
I Am Learner（我是個學習者） : John Connell
- Sean - www.johnconnell.co.ukI do learn from others, but what I learn is rarely, if ever, what is taught to me, and rarely, if ever, what others learn at the same time from the same teachers.
对话jQuery之父John Resig：JavaScript的开发之路
- zhibin - 技术改变世界 创新驱动中国 - 《程序员》官网在参加完CSDN组织的TUP对话大师系列演讲活动后，27岁的jQuery之父John Resig接受了本刊总编刘江的深度访谈，这篇对话文章，让我们一窥这位著名程序员的人生及技术感悟. 《程序员》：你是如何开始编程的. John Resig：第一次编程大概是在初中，14、15岁，当时有个朋友带来张软盘，里面有QBASIC.