Markdown 新解決方案：Typora+本地備份+GitHub 圖床

20200628

回想一下自己接觸 Markdown 已經有一年多了，在這段時間內也感覺到自己到前往碼農的道路上飛奔着，MD 以其簡潔、優雅、精准讓我放棄了幾乎其他所有的記錄方案，成為自己的主要輸出形式。

當然在這一過程中，自己也面臨着一些問題，其中最主要的就是對於圖片的處理，這里給出了 本地備份+GitHub 圖床 的解決方案，目前來看是比較理想的，因此記錄如下。其好處就是結合了本地存儲不會出現圖床失效、加載緩慢等問題，又能方便地上傳生成網絡圖片鏈接版本方便輸出到其他的平台。

另外，趁此機會總結了一下自己使用 Markdown 的場景，以及使用規范，比較個人向，若是沒有興趣的可以直接跳轉到第三部分閱讀。

Markdown 應用場景

進入大學以來，事實上自己記錄文字的經驗完全經歷一場電子化的轉變。因此，首先來整理一下自己使用 Markdown 的需求：

在進入大學以前，書寫問題的場景有二：1. 個人記錄；2. 學習筆記。前者主要是放在一個專門的本子上，而后者的呈現形式則是各種筆記本。在當時的學習場景下，自己還沒有整理、輸出文字的習慣，所以出現的問題可能在於筆記很亂，零散，並且很多時候不會去看第二遍，效率低下。

而進入大學以來，使用場景主要轉變為：1. 個人記錄；2. 課程筆記；3. 整理輸出。第一點還是沒有變，不過形式是從實體✍️轉為電子記錄。第二點也一直在發生變化，事實上關於這個話題可以另開一篇，在此略過，不給主要的趨勢還是電子化。第三點是新增加的需求，逐漸發現文字輸出是對於自我認知的再整理，有助於自己對於某一事物的理解（當然也方便之后的回顧），另外也不再一味從網絡上白嫖內容而更多了些內容生產的意識。

對於這三種需求，總結起來其實是一個問題：內容的輸出，而我在這里的選擇是全部轉向 Markdown。

接下來的一個問題，自然就是軟件的選擇問題，在這一點上我經過了各種嘗試之后，最終還是回到了 Typora 的懷抱中，滿足了絕大部分的對於 Markdown 編輯器的想象，減少了工具選擇的煩惱。

此外，與輸出之相關聯的問題自然是 內容的輸入，這里的需求問題就比較簡單了：需要清晰地對於各個方面的內容分門別類，最好能統一到一個軟件/生態/流程中，從而構建自己的知識體系。但是實現起來卻比輸出部分難了很多，自己也在不斷探索中，這里涉及到的更多是軟件取舍的問題，有機會另外寫一篇~

Markdown 使用規范

相較於富文本，MD 對於標記語法完全做了減法，在保障一些必要的形式之外刪去了其他所有的形式，這樣帶來的好處是：1. 可以讓人完全沉浸在寫作過程中而不需要去關注排版等細節，整個流程是連續的不會出現被打斷的情況；2. 因其通用的語法而具備通用性，除了在本地編輯之外可以支持博客（例如基於 Hexo 的），並且被一些網站原生支持（例如我常用的 CNblog）。

當然，其也會帶來一些不便，但就我目前的使用習慣來說都是 可以解決的 ，在此總結一下使用 Markdown 書寫的解決方案：

• 語法標記的單調性：
  • 例如對於強調語法來說，僅支持 斜體 和 加粗 ；初體驗可能不太習慣，但使用了之后其實完全取決自己的使用習慣，養成良好的書寫語法很重要，對於每一種語法需要有自己的理解；
  • 我之前的使用其實也存在着一些問題，例如幾乎不會用到 斜體（可能是我眼睛不太好？區分度有限），多用「引號」、加粗、行內代碼 語法；
  • 規范一下使用習慣：對於句子級別的標注來說，區分出重要程度，適度采用 斜體 和 加粗（雖然我還是認為中文斜體的使用並不是很舒服）；
  • 對於字詞/概念級別的標注，采用 加粗 或者是「引號」，而盡量少用 行內代碼 顯示；
  • 行內代碼的使用，應用場景應該是 代碼段、標記一些符號 等時候進行使用的；
  • 最后，在字詞級別的強調、代碼塊的使用前后，均加上空格進行區分；
• 對於表格的支持較弱
  • 本身就不怎么會用如 Word 的表格，操作起來很容易出現問題，可以說表格本身的復雜性就很高；
  • 而就 MD 的簡單語法來說（當然其實用的是 Typora），應付簡單的表格是完全夠用的（記得李如一好像在「一天世界」里討論過中文表格/表單的問題，似乎也是認為表格很難做得好看，慎用）；
  • 而如果有更為復雜的標記/嚴謹的表格需求的話，我會采用 PowerPoint 或者是 Latex 寫好再截圖到 MD 中；
• 圖片排版問題
  • 行間插入很符合我的使用習慣，不需要復雜的圖文排版，適合大多數的場景；
  • 偶爾需要多張圖片並排的場景，如上使用 PowerPoint 排好后截圖插入；

在整理這部分的時候，看到了 https://sspai.com/post/37270 這篇文章，介紹了不同 Markdown 的語法，講得很詳細；其實自己在使用的時候用得最多的自然是原生 Markdown 語法，對於那些語法還是需要抱着審慎的態度使用的。初步看了一下這一系列的文章質量都很高，而這篇 https://sspai.com/post/37271 提到的書寫建議，對於一些基礎的規范來說是很有意義的。

本地備份 + GitHub 圖床 解決方案

從一開始接觸到 Markdown 以后，似乎沒有用過多久本地存儲，就直接轉向圖床，然而在其選擇方面卻是幾經波折。

• 一開始是在 macOS 上用 PicGo + GitHub 的方案，本地改名后上傳，復制鏈接到 Typora，其面臨的一個問題就是 GitHub 的鏈接訪問有時候會出現問題，甚至需要開全局才能加載出來圖片；另外上傳復制鏈接也存在着操作上的中斷；
• 在軟件方面，后來嘗試過 iPic，僅有 macOS 版本；一個更為良心的軟件是 uPic，Windows 和 macOS 均提供了流暢且免費的使用體驗（微信產品交流群的討論也很棒）；
• 但一個問題就是圖床的選擇：GitHub 有上面說的一些問題，SMMS 的上傳和加載太慢太慢了，新浪的似乎掛了？Gitee 挺棒的，不過有圖片大小的限制（似乎是 1M）超過就無法加載；
• 自己對於圖床的想象，自然是希望穩定性高、省心、最好能是免費的；到最后排除法下來，其實也就剩下了 GitHub，優點在於，雖然 Typora 下有時加載會有問題（不過最近沒有出現過），Chrome 下是沒問題的；

因此，若是能夠本地存儲，同時快速上傳到 GitHub 生成網絡版本（以便發表到網絡上），無疑是較為完美的方案。

以下的方案受到了 https://zhuanlan.zhihu.com/p/106836441 的啟發，對其進行了一定的補充和說明（主要是加入了之前圖片的轉移）。以下是總體的思路：

想法就是本地建立一個圖片文件夾；同步到 GitHub 上；手動修改 Markdown 文件中的圖片鏈接生成新的網絡版本。

第一步，在 GitHub 上新建一個 repository，由於此方案不需要配合圖床軟件，因此沒有必要生成 key 等操作，簡單創建一個即可；

然后 clone 到本地，我用的是 GitHub Desktop 操作簡單速度也比較快，注意選取一個合適的位置，之后的所有圖片均保存在此目錄下；例如，假設我有一個單獨的 Markdown 目錄，repo 名為 BlogImg ，則我會把圖片放在 Markdown/BlogImg/imgs/ 下；

在 Typora 中進行相應的配置

用相對位置，還是絕對位置糾結了挺久。相對位置的好處是整個 Markdown 文件夾可以整體遷移；但考慮到自己的文件管理還不夠規范，可能面臨文件結構調整的問題，還是選擇了用絕對位置。

圖片轉移的部分我放在下一節介紹。

下面是從本地上傳至 GitHub，自己也是第一次接觸，寫得詳細些，在本地文件下發生變動后，左側會顯示出具體的變化情況；若需要合並，需要在左下角填上 commit，點擊下面的按鈕后，左側鏈表清空，但此時並未進行上傳，右上方的那個 Fetch origin 會變成 Push origin，點擊此完成上傳。

完成上傳后，核心的步驟是將本地圖片版本的 Markdown 文件轉為網絡版本的鏈接形式，這里附上 https://zhuanlan.zhihu.com/p/106836441 中的源碼

# coding:utf-8
import os
import argparse

# 線上線下圖床位置已經確定不變
path_offline = r"E:\我的堅果雲\我的堅果雲\博客圖床\One-click-picgo\imgs" + '\\' # 本地圖床目錄
path_online = "https://raw.githubusercontent.com/your_github_id/repo_name/master/imgs/" # 線上圖床目錄

path_out = 'notes/' # 轉換完成后的md文件保存路徑
if not os.path.exists(path_out):
    os.mkdir(path_out)

ap = argparse.ArgumentParser()
ap.add_argument("-p", "--path", help="the path of your md file")

if __name__ == '__main__':
    args = ap.parse_args()
    path_md = args.path

    # 被處理的md文件可以和本py文件處於同一目錄，也可以處於py文件的下一級文件夾內
    if '\\' in path_md:
        folder, name = path_md.split('\\')
    else:
        name = path_md
    path_out_md = "notes\\" + name
    print("在線版markdown文件生成在目錄：", path_out_md)

    with open(path_md, 'r', encoding='utf-8') as f: # 需要手動指定解碼的格式
        lines = f.readlines()

    out = [l.replace(path_offline, path_online) for l in lines]

    with open(path_out_md, 'w', encoding='utf-8') as f:
        f.writelines(out)

放置在存儲 Markdown 文件夾下，輸入相應的命令即可完成轉換。

本地文檔遷移

上文給出的方案是默認所有的鏈接已經保存在了本地 Git 文件夾下的，若原本的本地保存地址並未在這一文件夾下，就涉及到 圖片的轉移問題，比如我用從存儲 Markdown 的文件夾下的 img 轉移到 ./BlogImg/imgs 下.

因此，需要做的是事先轉移圖片，然后批量替換文本中的鏈接，簡單寫了個 Python 文件以實現：對於所需的某個文件夾下的 Markdown 文件進行遍歷，修改圖片鏈接形式，並輸出到新的文件夾中。

import os

g = os.walk("path_to_markdown/99-CNblog-專業筆記/")       # 需要遍歷的文件夾
new_store_location = "path_to_markdown/BlogImg/imgs"
out_fold = 'out'            # 輸出文件夾，原本的要求是替換，不過終究還是不放心，先緩存在新的文件夾中

for path,dir_list,file_list in g:
    for file_name in file_list:
        if file_name.endswith(".md") and not file_name.startswith("."):     # 檢測是否為 MD 內容文件

            in_filepath = os.path.join(path, file_name)
            with open(in_filepath, 'r', encoding='utf-8') as f:
                lines = f.readlines()

            out_filepath = os.path.join(out_fold, file_name)

            out = [l.replace("../img", new_store_location) for l in lines]		# 修改鏈接中的圖片位置

            with open(out_filepath, 'w', encoding='utf-8') as f:
                f.writelines(out)