1. 程式人生 > >和微信公眾號編輯器戰鬥的日子

和微信公眾號編輯器戰鬥的日子


作者:靈魂畫師牧碼

本文提到的 Markdown Nice 體驗地址:https://mdnice.com

公元 2019 年,微信公眾號排版能力孱弱,始終為運營者所詬病,秀米、135 編輯器等工具割據一方。

但無論是微信原生工具,還是其他編輯器,都讓創作者不得不將有限的創作經歷分散到排版設計上。

Markdown 解決排版的靈丹妙藥,應運而生。

一、引子

1.1 Markdown 是什麼?

Markdown 是一種排版語法,擁有極簡的輸入方式和極低的學習成本。

富含了標題、引用、加粗、連結、圖片、程式碼段、公式等一切在文字創作中需要的排版格式。

擁有它,讓人專注於內容本身,而不被格式所打擾。

1.2 怎麼和微信公眾號結合?

這麼優秀的排版語法,可是微信公眾號也不支援呀。

別急!Markdown Nice 來幫你解決問題!

1.3 Markdown Nice 是什麼?

一款開源 Markdown 編輯器,寫完後即排版成功,複製即可貼上到微信公眾號。

So what? 只有這點麼?

當然不是!Nice寶寶你還有什麼特性呀?

  • 支援圖床、腳註、程式碼、公式
  • 支援 8 種排版主題和 7 種程式碼主題
  • 支援自定義樣式,可提交主題供人瞻仰
  • 除了公眾號外,還支援知乎、掘金、部落格園和CSDN等平臺
  • 我顏值高呀

這麼多優秀的特性擺在你面前,還在等什麼?

地址:https://mdnice.com

快讓你的微信排版 Nice 起來!

二、正文

沒想到你還在看

咳咳、、、

不要小看Nice寶寶我,為了能夠使用 Markdown 進行公眾號排版,我可是和微信公眾號編輯器做了半年的鬥爭,才贏得了現在的戰果!

想聽聽我是如何戰鬥的?下面且聽我娓娓道來!

2.1 戰鬥序章

微信公眾號編輯器源於百度 FEX 前端團隊的開源的 ueditor 專案,這可是寶寶我扒取了網頁程式碼發現的,如圖所示:

因為 ueditor 是富文字編輯器,所以我即將面臨的是 markdown->富文字 的轉換戰役,在開源界或者軟體界這種轉換戰役有了相當多的優秀實現。比如:

  • Web端:editor.md、mavonEditor
  • PC端:typora、MWeb

但是上述工具都存在一個問題,沒有很好地將 CSS 樣式融入富文字中,進而適配微信編輯器,以至於國內其他各大平臺的富文字編輯器。

那麼有沒有嘗試彌補這一問題的工具呢?其實是有的:

  • Web端:md2all、wechat-format
  • 瀏覽器外掛:markdown-here

但是上述工具也各自有不完美的地方,於是Nice寶寶我發現了這個契機,把自己生產了出來,解決一切不完美!

Markdown Nice 是一個開源專案,由很多開源技術合體而成,其中主要包括:

  • React:facebook 開源的 js 檢視層框架
  • markdown-it:markdown 轉換富文字解析器
  • juice:將 CSS 類選擇器轉換為行內樣式的工具
  • codemirror:網頁程式碼編輯器
  • ant-design:React UI元件庫
  • mobx:狀態管理庫
  • highlight.js:程式碼高亮庫
  • MathJax-node:公式轉圖片庫
  • axios、ali-oss、qiniu-js等

注:下文會提到上述某些開源庫,開源庫具體作用請參考此處。

在擁有上述技術傍身之後,我向微信編輯器宣戰,打響了戰鬥第一槍!

2.2 戰鬥第一槍:程式碼主題

微信公眾號在2018年以前,是完全不支援程式碼塊的,目前的支援也很單一,並且存在程式碼字型較大的問題。

說來很氣,微信公眾號編輯器的開發者,就木有想過程式碼塊對程式設計師群體是多麼重要麼??

為此我找來了highlight.js程式碼高亮神器,幫助解決程式碼主題單一的問題。

經過一定的篩選後,最終選定了 atom-one-dark、atom-one-light、monikai、GitHub、vs2015、xcode 和微信程式碼主題共 7 個程式碼樣式供大家選擇。

其中微信程式碼主題由於其不屬於highlight.js的歸屬範疇,故而其結構需要從微信公眾號編輯器原始碼中獲取,下面兩張圖展示瞭如何獲取:

highlight.jsmarkdown-it 解析器是關聯使用的,故而工具中存在 2 個 markdown 解析器,分別用於解析微信程式碼主題和其他程式碼主題,原始碼參考。

除了上述問題外,很多技術類公眾號程式碼中會存在:一行程式碼過長導致的多行顯示問題。

該問題使用以下 CSS 程式碼即可解決:

pre code {
  display: -webkit-box !important
}

對比效果如圖所示:

從此以後使用 Markdown Nice 的同志們程式碼更美觀啦!

2.3 戰鬥第二槍:圖片上傳

一篇好的文章怎麼可以沒有圖片?

(某些技術人員說:我的就沒有)

圖片管理是每一個成熟編輯器都會遇到的問題。

Nice 寶寶最開始使用 SM.MS 圖床,該圖床由一位大佬在運維,非常感謝!

使用該圖床雖然能夠上傳圖片,但是貼上到微信編輯器時,失敗率極高(想踩死微信編輯器),如圖所示:

真是{喜聞樂見|hē hē hē hē}呀!

為了解決上述問題,Markdown Nice 先後支援了自定義阿里雲和七牛雲圖床,通過購買阿里雲和七牛雲的服務使用自建圖床。

但是!讓使用者自己配置,儘管有配置文件,但是整個配置過程複雜無比,簡直慘絕人寰!

於是,Nice 寶寶又使用自己的賬號,自建圖床,設定儲存時間為一天,提供臨時排版使用的 mdnice 圖床。至此,工具中的圖片上傳支援情況如下:

圖床 費用 有效期 失敗率
mdnice 免費 1天
SM.MS 免費 長期
阿里雲 參考 自定義
七牛雲 10G免費 自定義

這場圖床的戰役中,最大的難度在於需要閱讀阿里雲 OSS 和七牛雲 KODO 的文件,並且使用其開源出來的工具包 ali-oss 和 qiniu-js 。

這其中又涉及到了 FormData、file物件、base64 和 blob 之間的神奇轉換,原始碼參考。

總之,這場戰鬥打的不亦樂乎。

2.4 戰鬥第三槍:數學公式

微信公眾號排版中,數學公式是一個噩夢!

因為微信編輯器做了以下三件事情:

  • 不支援公式編輯
  • 不支援 html 和 css 生成的公式,因為字型無法匯入
  • 不支援 svg,放入後提示失敗

這三件事情簡直像魔鬼的步伐,把公式需求者放在光滑的地板上摩擦、摩擦....

目前唯一可行的方案就是將公式轉換成圖片,再將圖片直接貼到公眾號裡,Nice寶寶覺得自己這個想法簡直是完美!

但是,怎麼做呢......

忽然靈機一動,想到了朋友曾經推薦的一個轉換公式網站 codecogs,這個網站能夠做到將任意公式轉換成png圖片並給出可訪問連結。

但是由於圖片穩定性,無法直接使用該連結,會存在和第二場戰役一樣,圖片貼上失敗的情況,讓人苦不堪言。

  • 這個問題該怎麼解決呢?如果能夠自建公式轉png圖片服務就好了。
  • 有沒有這樣的開源庫?有!MathJax-node 就可以!

於是Nice寶寶自建後臺服務,封裝 RESTful 介面供前端呼叫,實現了公式轉圖片的功能!經過測試,完全可以使用,粘貼後再根據排版情況調整圖片大小即可。

其中對於大量公式的轉換,前端合理使用了非同步請求,並非一個個轉換而是並行執行,效能上達到了10個公式也能2秒轉換完畢的效果,完全可用於公式排版。

2.5 戰鬥第四槍:微信外鏈轉腳註

眾所周知(不知道也得知道),微信不支援外鏈,除了域名為https://mp.weixin.qq.com/的合法連結外,其他的連結出現後都會被自動刪除。

而新增外鏈的唯一官方方式就是在閱讀全文處,當然,直接將連結本身放到文中或者製作二維碼圖片也是可以的選擇。

而 Nice 寶寶則提供了將微信外鏈轉為腳註的方式解決該問題,是不是很優雅呢?

其中連結和腳註的使用區別如下:

連結:[文字](連結 "文字")
腳註:[文字](腳註解釋 "腳註名字")

這裡又涉及到了一個常見的問題,就是很多公眾號作者的文章中,原來在其他平臺釋出時都是連結,而到這裡排版時需要進行挨個修改,實在是讓人頭大。

於是Nice寶寶我又做了一個小改進,就是在貼上文章的時候會自動監測是否存在外鏈,並提示作者是否一鍵轉成腳註,這樣就不必手工修改了,贊不讚!

2.6 戰役總結

和微信公眾號編輯器對抗,是個極其有意思的過程。除了上述提到的問題之外,還有很多的細節點需要注意,在此就不一一討論了,感興趣歡迎閱讀原始碼。

Markdown Nice 的戰鬥之旅還遠遠沒有結束,官網製作、瀏覽器外掛、本地工具和排版糾正等功能蓄勢待發。

三、談點和戰鬥無關的

3.1 設計理念

大多數人而言,內容重於排版,排版重於設計。

內容是吸引讀者的核心,所以最重要。

而排版與設計之間的比較,作為一個曾經的微信美術編輯,隨著排版經驗的增多,發現文章的效果並不在於額外的花邊、點綴。

整齊、舒服、簡單是硬道理!

3.2 內容、排版與設計

設計 = 排版 + 創意


因為:大多數人不會獲取創意,或認為創意成本過高。

所以:大多數人不做設計,富文字設計不適合單純的內容編輯者。


雖然:大多數人也不會排版,或認為排版成本過高。

但是:Markdown Nice 將使用者從排版中釋放出來,只關注內容本身。

3.3 關於開源

開源是個既簡單又困難的過程:

  • 說簡單是因為:筆記、書單、工具、平臺所有有價值的東西都可以在 GitHub 中輸出,做起來很簡單
  • 說困難是因為:努力做到對別人有價值,始終堅持輸出,做起來很困難

正如上面描述的那樣,做開源其實是在做一款產品,有可能是技術產品(比如 redis、ant design),也有可能是業務產品(比如 Markdown Nice),只有做好了才可能對別人產生價值。

做產品的過程曲折而漫長,對照 Markdown Nice 開發過程,可以看到以下的步驟:

  1. 要有一個 idea,並且驗證其可行性和必要性,去和同類產品比較,做到心中有數
  2. 抓住痛點,掌握核心價值,站在使用者角度思考,多聽反饋意見
  3. 螺旋上升,不斷迭代,產出精品
  4. 最最重要一點,做產品不只要寫程式碼,還要宣傳呀!!酒香也怕巷子深!!

參與開源,一路走來,甚是不易,望君珍惜。

最後,感謝每一位開源參與者,歡迎更多人蔘與到開源中來,還有好多程式碼等著有人來寫呢!


『講解開源專案系列』——讓對開源專案感興趣的人不再畏懼、讓開源專案的發起者不再孤單。跟著我們的文章,你會發現程式設計的樂趣、使用和發現參與開源專案如此簡單。歡迎留言聯絡我們、加入我們,讓更多人愛上開源、貢獻開源~