上篇《部落格系統知多少：揭祕那些不為人知的學問（三）》介紹了部落格協定或標準。本篇終章介紹設計部落格系統有哪些知識點。
目錄
由於文章篇幅較長，本文將分為 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 部落格系統均是如此。部落格系統不自動轉換讀者所在時區的時間，純粹就是個鮮為人知的情懷設計，但必須得尊重。
那麼有意思的事情來了，搜尋引擎要怎麼理解部落格文章的時間？最好將 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 編輯器。
儲存文章內容到資料庫時，Markdown 格式需要選擇原始內容，而非生成的 HTML，因為還需要支援後續編輯。HTML 格式現在也不建議 encoding 儲存，畢竟都已經 2020 年了，市面上的主流資料庫都可以正確支援各種神奇的 Unicode，比如文章中突然出現個 emoji😂，而如果你使用了 encoding，就會像我的部落格一樣面臨一些福報：https://github.com/EdiWang/Moonglade/issues/280。並且 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，何時選擇傳統網站的參考：
部落格前臺仍然選用 MVC 的另一個原因，請回顧一下本文開頭「部落格的讀者是誰」，我經營部落格十餘年，統計的資料表明，幾乎所有的使用者都來源於搜尋引擎，都只點進來看一篇文章，然後關閉網頁。現在仔細想想，SPA 解決的最大的問題之一是什麼？是不是透過只重新整理區域性來提高前端效能（可響應度）？而使用者從搜尋引擎過來，只看一篇文章就關閉網頁，真的用得到 SPA 只重新整理區域性的優勢嗎？使用者只看一篇文章，你用個 SPA 框架，使用者得載入一堆框架本身的檔案，其中包括導航、互動等功能，而 99%的使用者根本就不會點到別的地方去，於是你只為了 1%的使用者，去載入碩大的一個框架，值得嗎？這效能到底是提高了，還是降低了？
MVC 框架雖然每次都會輸出伺服器端渲染的完整 HTML，但由於 99%的使用者只看一篇文章就關閉網頁，所以對於 99%的使用者來說，他們所需要載入的資源，遠小於載入一套 SPA，速度更快，還更 SEO 友好。SPA 適合用在部落格的後臺管理 portal，而不是前臺。
6.4 丨安全
根據經營部落格多年的後臺監控資料，最常見的攻擊行為是全自動的漏洞掃描工具。他們會請求例如 data.zip, wp-admin.php, git 目錄等常見的安全疏忽，或是想要透過某些部落格系統的已知漏洞進行攻擊。目的是為了控制伺服器，在你的部落格網頁裡加入對使用者的惡意程式碼（例如勒索病毒、挖礦）等，有些也會將伺服器本身變成礦機。
設計部落格系統時，常用的安全對策可參考 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/wordpress-security-alert-pingback-ddos/），也能掃描伺服器埠（https://www.avsecurity.in/wordpress-xml-rpc-pingback-vulnerability/）
結束語
設計一個優秀的部落格系統，每一處細節都值得斟酌。這些設計絕對不可能一開始就能做對，而是得靠長期經營部落格的資料去發現並思考。並且，市場會變化，使用者行為會變化，標準會被淘汰，也會被發明，因此你的系統需要跟著進化。
任何看似簡單的系統，就算普通到爛大街，也有背後看不見的一套完整體系。部落格如此，電子商城、外送、金融清算系統更是複雜，不要光憑自己表面看到的就開始做。就如同造飛機，造個紙飛機和真飛機，絕對不是一回事。
技術人員也不要覺得什麼流行就得用什麼，優秀的產品並不是堆砌時髦技術做出來的，而先得分析你的使用者到底是怎麼用你的產品，才能做最合適的選擇。要記住，想要一件事情做成功，思路不要只侷限於技術本身，學會分析市場，使用者行為，才能更準確的選擇和應用技術。
感謝讀到這裡的讀者，如果大家有什麼疑問和討論，歡迎留言交流。
下篇將主要介紹【設計部落格系統有哪些知識點】歡迎關注
