博客系统知多少：揭秘那些不为人知的学问（四）
上篇《博客系统知多少：揭秘那些不为人知的学问（三）》介绍了博客协议或标准。本篇终章介绍设计博客系统有哪些知识点。
1.“博客”的前世今生
2.我的博客故事
3.谁是博客的受众？
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. 博客协议或标准
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. 设计博客系统有哪些知识点
6.1 时区真的全用UTC？
6.2 HTML还是Markdown
6.3 MVC还是SPA
6.4 安全
7. 结束语
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/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，何时选择传统网站的参考：
https://docs.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/choose-between-traditional-web-and-single-page-apps
博客前台仍然选用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/wordpress-security-alert-pingback-ddos/），也能扫描服务器端口（https://www.avsecurity.in/wordpress-xml-rpc-pingback-vulnerability/）
结束语
设计一个优秀的博客系统，每一处细节都值得斟酌。这些设计绝对不可能一开始就能做对，而是得靠长期运营博客的数据去发现并思考。并且，市场会变化，用户行为会变化，标准会被淘汰，也会被发明，因此你的系统需要跟着进化。
任何看似简单的系统，就算普通到烂大街，也有背后看不见的一套完整体系。博客如此，电子商城、外卖、金融清算系统更是复杂，不要光凭自己表面看到的就开始做。就如同造飞机，造个纸飞机和真飞机，绝对不是一回事。
技术人员也不要觉得什么流行就得用什么，优秀的产品并不是堆砌时髦技术做出来的，而先得分析你的用户到底是怎么用你的产品，才能做最合适的选择。要记住，想要一件事情做成功，思路不要只局限于技术本身，学会分析市场，用户行为，才能更准确的选择和应用技术。
感谢读到这里的读者，如果大家有什么疑问和讨论，欢迎留言交流。