上篇《部落格系統知多少：揭祕那些不為人知的學問（三）》介紹了部落格協議或標準。本篇終章介紹設計部落格系統有哪些知識點。
由於文章篇幅較長，本文將分為4篇推送，目錄如下：
- “部落格”的前世今生
- 我的部落格故事
- 誰是部落格的受眾？
- 部落格基本功能設計要點
4.1 文章（Post）
4.2 評論（Comment）
4.3 分類（Category）
4.4 標籤（Tag）
4.5 歸檔（Archive）
4.6 頁面（Page）
4.7 訂閱
4.8 版本控制
4.9 主題及個性化
4.10 使用者及許可權
4.11 外掛
4.12 圖片及附件的處理
4.13 敏感過濾及評論審查
4.14 靜態化
4.15 通知系統 - 部落格協議或標準
5.1 RSS
5.2 ATOM
5.3 OPML
5.4 APML
5.5 FOAF
5.6 BlogML
5.7 Open Search
5.8 Pingback
5.9 Trackback
5.10 MetaWeblog
5.11 RSD
5.12 閱讀器檢視 - 設計部落格系統有哪些知識點
6.1 時區真的全用UTC？
6.2 HTML還是Markdown
6.3 MVC還是SPA
6.4 安全 - 結束語
6.1 | 時區真的全用UTC？
儲存時間使用UTC在2020年應該已經是猿盡皆知的實踐了，部落格系統其實也是如此，我的部落格所有時間資料最終儲存都採用UTC時間。但部落格有個特殊的地方，即它不應該按讀者的時區去轉換UTC時間進行顯示，而應該按照部落格作者的時區去顯示時間。
這並不是技術上的原因，就算你按讀者時區去顯示時間也不會有程式碼爆炸，原因在於部落格的誕生初衷，就是為了彰顯個性，讓博主在網際網路上有自己的展示空間，因此突出博主本人的屬性非常重要，博主所在時區也是個讓讀者瞭解博主的屬性之一，因此，正宗的部落格系統都會給一個時區設定選項，並以此轉換UTC時間作為顯示，WordPress和我的Moonglade部落格系統均是如此。部落格系統不自動轉換讀者所在時區的時間，純粹就是個鮮為人知的情懷設計，但必須得尊重。
(圖：Moonglade 按博主設定的時區顯示文章發表時間)
那麼有意思的事情來了，搜尋引擎要怎麼理解部落格文章的時間？最好將UTC時間僅告訴搜尋引擎，不要給使用者顯示，方法也很簡單，用HTML5的time標籤的datetime屬性即可。在HTML5標準推廣以後，搜尋引擎更喜歡看標籤型別來判斷內容的含義，而不是根據標籤裡的內容來猜意思。
在C#裡，ToString(“u”)指的是Universal sortable date/time patter。
<time datetime="@Model.PostModel.PubDateUtc.ToString("u")" title="GMT @Model.PostModel.PubDateUtc">@DateTimeResolver.GetDateTimeWithUserTZone(Model.PostModel.PubDateUtc).ToString("MM/dd/yyyy")</time>對於剛才截圖裡的文章，時間的HTML為：
<time datetime="2020-04-29 11:41:02Z" title="GMT 4/29/2020 11:41:02 AM">04/29/2020</time>6.2丨HTML還是Markdown
許多技術人士編寫部落格系統的時候喜歡選用Markdown作為編輯器，如果單純只是個技術部落格，自己使用並沒有什麼問題。但如果你在給他人編寫部落格系統，請記住，不是每個人，都是程式設計師，不是每個人，都喜歡Markdown。
圖 | 網路
在這種情況下，一個WSIWYG的HTML編輯器（如TinyMCE）是不錯的選擇，HTML編輯器相對Markdown也支援更高階的排版方式。Moonglade 同時支援HTML和Markdown編輯器。
（圖：Moonglade 使用的TinyMCE編輯器）
儲存文章內容到資料庫時，Markdown格式需要選擇原始內容，而非生成的HTML，因為還需要支援後續編輯。HTML格式現在也不建議encoding儲存，畢竟都已經2020年了，市面上的主流資料庫都可以正確支援各種神奇的Unicode，比如文章中突然出現個emoji?，而如果你使用了encoding，就會像我的部落格一樣面臨一些福報：https://github.com/EdiWang/Mo...。並且encoding和decoding的過程會影響效能。我的Moonglade部落格系統也剛剛完成了去除encoding的改造。
6.3丨MVC還是SPA
許多社群裡寫部落格系統的程式設計師都偏向於使用SPA架構建部落格，而鄙視用MVC，覺得落後，真的是這樣嗎？這個問題就像是飛機為什麼不飛直線，是航空公司不會規劃嗎？關於這一點，我曾經在以前的部落格文章《我的 .NET Core 部落格效能優化經驗總結》中寫過：
2014年以後，隨著SPA的興起，Angular等框架逐漸成為了前端開發的主流。它們解決的問題正是提升前端的響應度，讓Web應用盡量接近本地原生應用的體驗。我也面臨過不少朋友的質疑：為什麼你的部落格不用angular寫？是你不擅長嗎？
圖 | 網路
其實並不是那麼簡單。實際上我任職的崗位的目前主要工作內容也是寫angular，部落格曾經的.NET Framework版的後臺也用過angularjs以及angular2，經過一系列的實踐表明，我部落格這樣的內容站用angular收益並不大。
其實這並不奇怪，在盲目選擇框架之前，我們得注意一個前提條件：SPA框架所針對的，其實是Web應用。而應用的意思是重互動，即像Azure Portal或Outlook郵箱那樣，目的是把網頁當應用程來開發，這時候SPA不僅能提升使用者體驗，也能降低開發成本，何樂而不為？但是部落格屬於內容為主的網站，不是應用，要說應用也勉強只能說部落格的後臺管理可以是應用。部落格前臺唯一的互動就是評論、搜尋，因此SPA並不適合這樣的工作。這就像你要去菜場買菜，騎自行車反而比你開個坦克過去方便。
在微軟官方文件裡也有同樣的關於何時選擇SPA，何時選擇傳統網站的
參考連結：
https://docs.microsoft.com/en...
部落格前臺仍然選用MVC的另一個原因，請回顧一下本文開頭“部落格的讀者是誰”，我運營部落格十餘年，統計的資料表明，幾乎所有的使用者都來源於搜尋引擎，都只點進來看一篇文章，然後關閉網頁。現在仔細想想，SPA解決的最大的問題之一是什麼？是不是通過只重新整理區域性來提高前端效能（可響應度）？而使用者從搜尋引擎過來，只看一篇文章就關閉網頁，真的用得到SPA只重新整理區域性的優勢嗎？使用者只看一篇文章，你用個SPA框架，使用者得載入一堆框架本身的檔案，其中包括導航、互動等功能，而99%的使用者根本就不會點到別的地方去，於是你只為了1%的使用者，去載入碩大的一個框架，值得嗎？這效能到底是提高了，還是降低了？
MVC框架雖然每次都會輸出伺服器端渲染的完整HTML，但由於99%的使用者只看一篇文章就關閉網頁，所以對於99%的使用者來說，他們所需要載入的資源，遠小於載入一套SPA，速度更快，還更SEO友好。SPA適合用在部落格的後臺管理portal，而不是前臺。
6.4丨安全
根據運營部落格多年的後臺監控資料，最常見的攻擊行為是全自動的漏洞掃描工具。他們會請求例如 data.zip, wp-admin.php, git目錄等常見的安全疏忽，或是想要通過某些部落格系統的已知漏洞進行攻擊。目的是為了控制伺服器，在你的部落格網頁里加入對使用者的惡意程式碼（例如勒索病毒、挖礦）等，有些也會將伺服器本身變成礦機。
（圖：Azure後臺捕獲的自動化掃描工具請求）
設計部落格系統時，常用的安全對策可參考OWASP（https://owasp.org/），但同時保留靈活性。例如，加入JavaScript的CSP時，請考慮正常部落格使用者可能需要新增三方統計外掛（如Azure Application Insights，國內的CNZZ等），請設計一定的黑、白名單或功能開關。
大部分設計者都知道要防範使用者的輸入，即部落格的讀者，輸入的入口通常只有評論和搜尋功能。但不要忘了，博主在部落格後臺管理中的輸入也需要防範，因為不一定是博主本人在操作。舉個例子，博主的賬號被盜，黑客在後臺將導航欄的連結指向黑客的伺服器或localhost上早已準備好的奇妙的機關（是的，不要以為localhost在正常人的電腦上不起作用），那麼讀者就會受到嚴重影響。
圖 | 網路
關於後臺登入的身份認證，能採用成熟的SSO的就優先採用SSO，例如Moonglade支援Azure Active Directory驗證，這樣能夠利用微軟這樣的專業服務管理授權認證，儘可能小的避免賬戶上產生安全問題。如果使用者沒有SSO的環境，才fallback到本地賬號認證。千萬不要認為用三方服務沒自己寫安全，覺得自己寫的邏輯沒人知道就不會被黑了，除非你是世界頂級大牛，不然自己寫的系統易黑程度遠高於三方服務。
另有一些攻擊通常由一些敵對陣營的無聊程式設計師發起，例如使用指令碼或工具持續不斷的請求部落格系統的某個URL，企影像DDOS那樣擊爆伺服器，對於這種無聊刷刷黨，部落格系統設計者只要加入有關URL endpoint的rate limit即可。對於真實的DDOS攻擊，只有雲端抗DDOS服務或硬體DDOS防火牆才能解決。
最後別忘了OWASP裡沒有的東西，部落格的協議也會有設計缺陷，例如pingback可以用來DDOS（https://www.imperva.com/blog/...），
也能掃描伺服器埠（https://www.avsecurity.in/wor...）
結束語
設計一個優秀的部落格系統，每一處細節都值得斟酌。這些設計絕對不可能一開始就能做對，而是得靠長期運營部落格的資料去發現並思考。並且，市場會變化，使用者行為會變化，標準會被淘汰，也會被發明，因此你的系統需要跟著進化。
任何看似簡單的系統，就算普通到爛大街，也有背後看不見的一套完整體系。部落格如此，電子商城、外賣、金融清算系統更是複雜，不要光憑自己表面看到的就開始做。就如同造飛機，造個紙飛機和真飛機，絕對不是一回事。
技術人員也不要覺得什麼流行就得用什麼，優秀的產品並不是堆砌時髦技術做出來的，而先得分析你的使用者到底是怎麼用你的產品，才能做最合適的選擇。要記住，想要一件事情做成功，思路不要只侷限於技術本身，學會分析市場，使用者行為，才能更準確的選擇和應用技術。
圖 | 網路
感謝讀到這裡的讀者，如果大家有什麼疑問和討論，歡迎留言交流。
掃碼關注微軟中國MSDN，獲取更多微軟一手技術資訊和官方學習資料！
