深入Markdown
前兩天參加圖靈社區的 iTran 樂譯活動，翻譯這篇《 Dive Into Markdown》，作者就是發明了 Markdown 的 John Gruber，從這篇文章中可以了解到他做 Markdown 的初衷。作者的引言、要點 1 和要點 2 都很有啟發性。
“有時候一件事情的真相，不是來自于對它的思考，而是來自于對它的感覺。” 。
——STANLEY KUBRICK
要點1
這兒有個問題：你最近一次聽到足以改變你內心想法的論述是什么時候？不僅僅是關于那些你沒怎么想過的問題，也包括在聽到這個論述之前你原本相當確信的觀念。
也就是說，你最近一次認識到自己在某個觀念上徹底錯了是什么時候？
如果你的回答是“從來沒有”，或者是“很久以前”，那么這是否就意味著你總是正確的？
這里有我的一個故事。
一月份的時候，關于 Postel 法則在解析 XML 聚合信息流（比如 RSS 和 Atom 這樣的格式）的軟件中的應用，曾經有過一次爭論。這次爭論簡而言之，就是 Postel 法則認為：“自己做的時候要謹慎，對別人的東西要寬容”，而 XML 規范則明確說明：“一旦發現致命錯誤，解析器就不能再繼續正常的解析流程了（比如，絕不能繼續將字符數據和文檔結構描述信息還用標準方式傳遞給應用程序）。”
那么，解析 XML 聚合信息流的軟件該如何抉擇呢？是依照 Postel 法則，包容遇到的錯誤？還是依照 XML 標準，一遇到嚴重錯誤就中端處理？
Brent Simmons（Mac 系統上的主流新聞聚合閱讀器 NetNewsWire 的開發者）和 NIck Bradbury（Windows 系統上主流新聞聚合閱讀器 FeedDemon 的開發者）都認為在處理 Atom 和 XML 信息流時，他們的軟件應該采取嚴格的標準。很多牛人都同意他們的看法。
“客戶端的標準應該嚴格”的論點，我覺得可以歸結為一下幾點：
-
正確、規整的 XML 要好于有語法錯誤的 XML；
-
要寫出能生成正確、規整的 XML 的軟件并不是那么難（就像 Tim Bray 說的，“任何不能用規整的 XML 寫聚合信息流的人都是無能的蠢貨”）。
-
如果主流的 XML 信息流閱讀軟件都要求正確、規整的 XML 數據，那么就會促使生成信息流的應用不再輸出糟糕的 XML。
這三點我都同意，因此，我堅定地站在“客戶端解析時應該有嚴格標準”的陣營中。
但之后我讀了 Mark Pilgrim 的“思想實驗”。Pilgrim 不僅是信息流解析應該寬松的倡議者，而且他公開了自己的所有代碼，還寫出了著名的開源信息流解析器 Universal Feed Parser
Pilgrim 的觀點，至少在我看來是這樣的：如果你在做處理 XML 信息流的軟件，而你的解析器非常嚴格，那么你的用戶在遇到異常數據的時候就會遭殃。事實上，你的用戶終究是會遇到異常數據的；這種情況發生的話，也許錯在造成數據異常的人，但最終受害的卻是你的用戶，就因為客戶端被強加的嚴格檢查。
讀過之后，我認真思考了他的思想實驗，最終意識到我之前徹底錯了，他是對的。（Simmons 也改變了他自己的想法，看以到這里和這里看后續的故事。）
Pilgrim 僅憑借他在“思想實驗”中的論述，就讓我認識到自己錯了。但有意思的是，他說服我的時候，并沒有反駁任何一個讓我一開始站在“嚴格解析”陣營的事實。
這就是我要說的第一點：當我最終改變某個觀點的時候，通常并不是因為我掌握的事實有誤，而是因為我沒有選對事實。
要點2
回頭來看，所有博客軟件背后的基本理念，其核心似乎都很簡單。你是在管理一系列的文章，而不是有一系列網頁的網站，博客軟件會幫你將文章轉換成網頁。
博客軟件對一般人的吸引力很容易理解。沒有博客軟件，他們就沒法發布站點。
但博客軟件對行家們——就是完全有能力用 HTML 手寫出一個博客網站的專家們——的吸引力在哪兒呢？當然了，確實有一些人堅持手寫。但是對大多數人，甚至包括世界上最博學和最著名的 web 工程師，都在用博客軟件包（或者是開發自己的博客發布程序）。
答案是方便，靈活。博客軟件免去了更新站點的過程中絕大多數的單調勞動。我必須承認——直到我 2002 年發布 Daring Fireball 的幾個月前才明白這點。我能手寫一整個網站出來而且還覺得寫代碼很容易，這樣的事實讓我忽視了在這個過程中有很多很多機械重復性的工作。
下面是我每次往 Daring Fireball 上發布一篇新文章實際上會發生的事：
-
新文章出現在首頁的頂部（同時從首頁移去最舊的文章）；
-
新文章有一個單獨的永久頁面；
-
在我的 RSS 信息流中更新這篇文章；
-
標題和新頁面的鏈接被添加到我的存檔頁面；
-
新頁面的標題和鏈接作為“下一篇”被添加到上一篇文章中。
我只需要一個操作——發布一篇文章——然后 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 語法檢查工具。
我期望的工作流程是：
-
在 BBEdit 中寫文章，編輯，修訂；
-
搞定后，登錄 MT 的 web 界面，將文章粘貼進去，然后發布。
但我的實際工作流程看起來卻是這樣的：
-
在 BBEdit 中寫文章；
-
在瀏覽器中預覽：
-
切換到 BBEdit 中修訂；
-
重復上面的步驟，直到搞定；
-
登錄 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 標簽變得容易了。
感覺 vs 思考
純文本在印刷上的局限性——單一的字體，單一的字號，沒有斜體和加粗——跟打字機的局限性非常類似。設想有個不錯的人給你買了個禮物：一個用原始打字機打印出來的一本經典小說的手稿，就比如說是 Fitzgerald 的“了不起的蓋茨比”吧。你可以坐下來靜靜讀這本手稿，從頭到尾，這樣獲得的閱讀體驗，與你閱讀一本精心排版和包裝后的書的體驗幾乎是一樣的。沒錯，那種感覺貫穿在打字機充滿油污的、等寬 Courier 式的字體中，以及用下劃線代替斜體的習慣，等等。——但文字依舊流暢，從紙面飛躍到你的心中，就像 Fitzgerald 所期望的那樣。
我在文章開頭引用的 Stanley Kubrick 的名言是我最喜歡的話之一。當你讀或者寫用 HTML 標簽標記的文字時，這些標記在強迫你集中注意力去思考他們。而我希望 Markdown 格式的文本所傳達的是一種感覺。
來自: blog.makto.me