共计 8304 个字符，预计需要花费 21 分钟才能阅读完成。
上篇 《博客零碎知多少：揭秘那些鲜为人知的学识（一）》 介绍了博客的历史、我的博客故事及博客的受众起源。本篇精彩持续，介绍博客根本功能设计要点。
因为文章篇幅较长，本文将分为 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 平安
- 结束语
01 文章（Post）
咱们每天可能都会浏览或长或短的 3 - 5 篇文章。文章是博客零碎的外围业务，因而博客文章的内容和品质十分重要。
那么，文章这个业务类型如何起名？数据库的表名和代码的变量名，类型名称用 article 吗？如同上学时候只学过文章叫做 article。其实博客类型的文章，正确的表白是 post，英文单词里 post 和 article 的区别在于，post 只是得心应手写的文章，而 article 指的是论文那样的通过精心雕刻，旁征博引，并且有可能在学术期刊上发表的文章。因而设计博客零碎的时候，尽量避免应用 article 这个单词来命名代码。更具体来讲，post 中能够呈现不谨严、口语化的表达方式，例如本文就算是个 post。而 article 考究语言上的标准，连“让咱们”，“咱们来看看”这种字眼都不能呈现。
图 | 网络
文章须要具备题目、Slug、创立工夫、公布工夫、批改工夫、摘要和内容等因素，也会蕴含所属分类、标签、浏览量和点赞量等主要信息。其中 Slug 是博客的特色，它指的是一篇文章的 URL。例如我的文章：《Try the New Azure .NET SDK》，它的 URL 为 https://edi.wang/post/2019/12…，其中 try-the-new-azure-net-sdk 即为该文章的 Slug。Slug 考究的是“人类可读”，个别状况下均为博客题目对应的英文表白，用中划线宰割英文单词，Slug 也对博客的 SEO 起到了关键作用。如果你的博客文章用的是数据库 ID、文章题目的 HTML Encoding 等做 URL，请更换为 Slug。特地是遇到中文文章，如果题目被 URL Encoding 了，那么对于 SEO 和链接分享，都是劫难。一个 Slug 一旦定下，尽量不要改变，尽管大部分博客零碎都反对批改 Slug，然而对于被搜索引擎支出的文章，改了 Slug 就会导致 404。比拟齐备的博客零碎（如 WordPress）反对采纳 301 重定向形式通知搜索引擎原文地址已变动。
摘要有两个作用，一是用于在列表视图中显示文章信息预览，二是用于 SEO，放在 description 这个 meta 标签中，能够帮忙搜索引擎精准定支出的内容。对于中文内容，须要留神是否输入的 HTML 源代码被 Encoding 过，ASP.NET Core 默认的 Encoding 会对 SEO 造成劫难（我的博客零碎因为面向英语用户，不思考中文反对，所以并不解决这个问题）。
(图：文章列表中的摘要)
(图：meta description 标签代码)
摘要能够主动抓取文章前几百字，也能够像微信公众号那样要求用户手工填写。我的博客采纳的是主动取文章前 400 字。联合 SEO 的关系，我的文章通常结尾段落就是概要，这样能够让用户在搜索引擎预览页面就能看到精确内容，而不是页面上无关紧要的 UI 元素。
(图：必应搜索引擎辨认的内容摘要)
文章的状态通常包含：草稿、公布、回收。用户仅能看到已公布的文章，管理员可在后盾更改文章状态。
02 评论（Comment）
评论是博客中作者和读者互动的次要形式。有些博客要求读者登录后能力发表评论，而有些能够容许游客评论（比方我的博客及 WordPress）。登录的益处在于能够辨认你的读者，并无效避免垃广告评论。但要求登录也会给用户造成操作上多了一个步骤，嫌麻烦的用户就不会进行评论。
我的博客及 WordPress 默认都设计为须要管理员在后盾审核评论后，能力放出显示。这也能无效防止垃圾广告、骚扰信息甚至是一些歹意的煽动性舆论。对于提供 Email 地址的用户，管理员也可能在后盾回复用户的评论，并由博客零碎向用户发送 Email 告诉。
（图：Moonglade 的评论区）
对于技术博客，评论可思考凋谢 markdown 格局。这是一种在程序员之间分外受欢迎的语法，在 GitHub 失去了广泛应用。
评论须要采纳验证码或其他人机验证技术，以避免机器人发广告。但依据教训，验证码并不能 100% 阻止垃圾信息，因为现代化的垃圾信息还真的是人组团发的，有专门的公司、团队、微信群等，国外也有。于是，你可能须要思考关键词过滤，购买三方过滤接口等。
评论也得记得做字数限度，不然也有可能会造成局部用户“灌水”、刷屏的景象。
如果不想本人写性能，还能够整合三方的评论服务，即博客零碎自身不实现评论性能，通过三方服务加载内部 JS，在文章浏览页面“注入”一个评论区，通常这要求文章的 URL 不变（WordPress 里叫做永久性 URL）。
03 分类（Category）
像建文件夹一样将文章依据内容进行辨别，即为分类。文章分类后，能够帮忙读者疾速检索同品种的文章。
例如写.NET、PHP、JS 的文章都属于“开发技术（Development）”这个分类。而技术圈新闻和职场教训分享和等文章，则属于“工作”分类，分类的划分齐全由用户管制。分类能够多对多。例如写一篇文章介绍了用 ASP.NET Core 开发 Angular 利用的文章，能够同时属于“.NET 技术”及“前端开发”分类。
分类须要一个题目、一个简介，以及一个路由名称。例如我博客，微软云 Azure 的分类，题目为 Microsoft Azure，简介为 The Best Cloud，路由名称为 azure。题目须要同时显示在标题栏，以便于 SEO。简介是对于题目的补充阐明，便于用户查看。设计路由名称的起因请参考下一段介绍的标签的设计。
(图：Moonglade 博客零碎的一个文章分类)
分类的另一个性能就是产生 OPML 及 RSS/Atom 订阅源，这个将在第五章介绍博客协定中解说。
04 标签（Tag）
一篇文章所提到的话题，即为文章的标签。和分类一样，标签也是多对多关系。标签能够作为检索文章的根据，相似关键词，疾速查找相干内容的文章。
标签须要思考到标签含意反复的状况，例如：VS 和 Visual Studio 是一个意思，VSCode、VSC 和 Visual Studio Code 也是一个意思。那么用户抉择标签的时候，最好应用智能提醒举荐用户应用已有标签。
对于博客零碎设计者来说，还要思考标签的 URL。如果 URL 用的是标签自身的内容，会导致很多问题。当标签名称为整个英文单词，例如 Excel，并不会产生问题，因为 URL 通常是 https://yourblog/tags/excel。然而如果标签内容为 .NET Core、C#、Robots.txt，事件就变的有意思起来。https://yourblog/tags/robots.txt 到底是在申请 tags 下的 robots.txt 文件还是在申请标签？本人作为博客零碎设计者，当然能够从程序上限度所有 tags 承受的路由参数都为标签，如同是解决了问题，但 SEO 和扫描工具可不这么认为，他们有大量 by convention 的规定会认为是申请文件。
对于须要 URL Encoding 的标签内容，更会导致 URL 不足可读性，从而影响 SEO。千万不要自作聪明地认为古代的搜索引擎能够解决好 URL Encoding，一个 URL 是否洁净对 SEO 的影响很大。特地是当标签是中文内容的时候，如果全 encoding 了，URL 就会十分简短，甚至影响到 SEO，也影响到博主分享链接。因而，我的博客零碎为了解决标签 URL，给每个标签都设计了规范化名称（normalized name），由零碎依据标签内容主动产生，如 .NET Core 通过 normalize，会变成 dotnet-core，最终产生的 URL 即 https://edi.wang/tags/list/do…。
(图：Moonglade 博客零碎的标签)
对于用户来说，最容易犯错之一的就是把标签用成搜寻关键词。例如用户写了一篇对于 Visual Studio Code 的文章，那么标签可能会同时打 VSCode、VSC 和 Visual Studio Code，但其实只有抉择一个标签即可。打太多同样含意的标签会导致读者无奈残缺检索到所有相干文章，对搜索引擎来说，也是如此。所以如何用好标签，是博客设计者和用户须要独特关注的要点。
标签云（Tag Cloud）是博客中用来列出最热门标签的性能。通常应用跟大号字、更显著的色彩来标识出对应文章较多的标签。标签云能够作为博客博主的个性化属性，一眼就能看出博主热衷于什么话题（比方 Windows Phone？0.0）。
05 归档（Archive）
以工夫（年、月、日）整顿的博客文章即为归档，它和分类的区别在于归档只以工夫为规范来划分文章。Archive 的 SEO 绝对于文章、分类、标签来说，并不那么要害。所以除了 URL 能够按年月划分以外，并没有额定的考究。
例如：https://edi.wang/archive/2019/9 示意 2019 年 9 月的文章。https://edi.wang/archive/2019 则示意 2019 年所有的文章。归档性能次要用于给读者按工夫查问，看看博主某个工夫都在干什么。设计这样的性能能够进步读者对博主的趣味，也是集体对外形象的一种展现。
(图：Moonglade 博客零碎的归档)
06 页面（Page）
页面是博客的可选性能之一，事实上，它更靠近于 CMS 的性能。有些内容并不适宜以文章的模式公布，比方“对于”页面。这样的页面通常与公布时候的工夫无关，内容也常常更新，排版设计也十分自在，不单纯是文字。
页面通常不须要评论、标签和分类等属性，但能够有公布和编辑工夫。和文章一样，页面也须要留神 Slug。
(图：我博客的对于页面)
在我的博客零碎中，页面也抉择是否暗藏侧边栏，用户也能够齐全编写页面的 HTML 及 CSS 代码，并把页面增加为导航菜单。WordPress 对于页面的解决更加齐备，靠近于 CMS 零碎。
07 订阅（Subscription）
读者订阅博客的次要形式有 Feed（RSS/ATOM）及 Newsletter。Feed 形式实质上是被动订阅，须要客户端软件发动申请给服务器，查看是否有新文章发表，能力显示到客户端里。Newsletter 个别采纳 Email 模式被动发送给订阅用户，但这要求博客零碎的编写者实现 Email 订阅性能，也要求管理员保护 Email 服务。订阅个别只推送近期发表的新文章，例如前 10、20 篇，而不会每次都推送全副文章导致客户端爆炸。
（图：Moonglade 的 RSS/ATOM 订阅源）
订阅个别可按文章分类提供，以便于只对某些分类感兴趣的读者浏览。有些博客零碎也提供文章评论的订阅源，以便读者观摩吐槽大会。
对于 RSS 及 ATOM 的具体介绍请看 5.1、5.2 章节。
08 版本控制
更靠近 CMS 的博客零碎通常提供版本控制性能，容许用户回滚文章或页面的历史版本。设计版本控制的时候，不能只思考往前回滚，得还能再滚得回来。通常，用户每次编辑一篇曾经写好的文章，就会产生一个新版本，相似于 git 对于一个文件的 commit。博客的版本控制也相似于代码版本控制，你能够抉择保留一篇文章的残缺内容作为历史版本，也能够抉择每次只保留变动量信息（delta）。保留残缺内容不容易后续破费大量工夫精力，然而会占用较多存储空间。保留内容变动量节俭数据库空间，但实现代码容易占用大量精力。
09 主题及个性化
好用的博客零碎通常反对主题，毕竟个性化是博客自身应有的特点之一。WordPress 积攒了大量的主题库，也容许自制主题。然而我的博客只反对更改主题色，还有很大回升空间。
10 用户及权限
博客零碎分为集体、团队及博客平台。集体博客零碎个别为单用户（例如我的博客），不须要设计权限、注册等性能。多用户博客则须要实现不同的角色和权限，比方博客管理员、审核专员、撰稿人、评论管理员等等。无论是单用户还是多用户博客，集成一套成熟的三方 RBAC 计划可能是最高效的抉择，少数三方计划也都反对 SSO，例如我博客反对的 Azure AD。
11 插件
插件性能能够在不更改博客代码的状况下，按需拓展博客的性能。WordPress 以及 BlogEngine 都反对插件，但 Moonglade 还不行。
（图：WordPress 的插件市场）
12 图片及附件的解决
图片格式
在 2020 年，图片格式曾经十分自在，个别的博客 JPG 居多，程序员的博客 PNG 居多（毕竟都是屏幕截图），像微信公众号那样采纳 WEBP 格局当初同样可取，只有读者的设施兼容即可。个别 BMP 格局因为体积大会导致网络传输慢，所以不举荐。同样情理，GIF 也要留神限度尺寸。
博客零碎输入图片时，须要采纳正确的 Mime Type，以保障客户端的兼容性。个别间接输入动态文件自身不须要博客编写者手工解决 Mime Type，但有专门图片解决逻辑的博客（例如我的 Moonglade）则须要注意保留图片本来的 Mime Type。
图片水印
给上传的图片主动加水印有助于爱护版权，水印内容个别是博客的地址或博主名字。增加水印时要留神图片尺寸调整水印的比例，免得挡住图中重要内容影响浏览。对于过小的图片，可选择性的疏忽水印。
另外，思考到博客有可能会在倒退过程中改名，倡议增加水印的时候在零碎中保留一份原始图片，以便于前期更新水印内容。
具体方法可参考我的文章《ASP.NET Core 给上传的图片加水印》。
图片存储
图片存哪里是个值得思考的问题。个别有 3 个中央寄存：文件系统、数据库、云上的 Blob 存储服务。Moonglade 反对文件系统及 Azure Blob 存储。这三者各有优缺点。
文件系统的劣势在于间接 serve static file 速度最快，但如果图片目录自身位于网站目录底下，会导致目录不只读而引起潜在平安问题。比方初中时候很风行的给 DVBBS 上传个改了拓展名的 ASP web shell，只管给 web 服务器上传可执行文件在 2020 年曾经根本绝迹了，但仍然存在隐患，就好比就算你家里请了 007 当保镖也是须要夜间锁好门。
数据库存图安全性最高，并且让博客的数据只位于一个地位，方便管理和备份，十几年前很风行这么做，但其实读写图片对数据库有肯定开销，并且再由网站输入，双倍开销，个别不举荐。
而云端 Blob 存储服务目前来说是最适宜这个时代的计划，将图片存储在 Blob 中不仅能保障服务器目录只读，又能采纳云自身的平安个性限度非正常拜访，还能通过 CDN 减速图片输入。要硬说毛病，就是云服务须要额定的金钱，而没钱，是本人的问题，不是云的问题。
图 | 网络
图片防盗链
作为网站开发者，咱们有时候不心愿本人网站的图片被其余网站间接援用。这在某些场景下会导致本人数据中心里微小的带宽耗费，也就意味着他人应用咱们的图片，咱们要为此付钱。例如，你的网站是 a.com，你有一张图片是 http://a.com/facepalm.jpg，而 b.com 在他们的网站上应用一个 img 标签来援用了你的图片，这导致网络申请是进入你的数据中心，耗费你的资源。因而博客可选择性的启用防盗链性能，具体方法可参考我的文章《ASP.NET / Core 网站图片防盗链》。
附件
通常程序员的技术博客会提供读者下载代码样例等附件。设计附件性能和设计图片存储十分相似，齐全可行。但我更倡议技术博客将代码示例等附件托管到其余网站（例如 GitHub）提供读者下载。
本人博客实现附件下载的害处有：
大文件
不同的 Web 服务器及防火墙产品对文件尺寸的限度不同，而部署博客的用户很可能无权治理这些限度，就会导致大附件无奈提供下载。
域及 IP 黑名单
某些公司或组织（特地是平安标准较高的软件公司）会屏蔽非白名单域的文件下载，只管你能够用浏览器失常关上该域的网页，但无奈下载文件（防火墙只容许 HTML/CSS/JS 等，而不容许 ZIP、EXE 等）。而程序员博客的读者很有可能就处在这样的公司里。
CDN 资源消耗
如果你的附件较多，较大，并且你也像设计图片存储一样给附件零碎套了个 CDN，此时依据 CDN 服务商计费模式的不同，如果按流量计费，恐怕你的附件下载会导致你的钱包减速瘦身。
而采纳三方文件下载（如 GitHub、OneDrive）的益处有：
√ 你的文件不仅能够分享到博客文章中，也能够分享到别的地位；
√ 这些三方服务有本人的 CDN，而不必放心耗费你本人的钱包；
√ 许多文件托管服务有残缺的治理性能，例如文件删除、复原、版本控制、权限等，要是本人在博客零碎里写一个这个，须要破费大量工夫……
13 敏感词过滤及评论审查
博客不免引来一些抱有敌意的人，也会引来发广告的人，所以通常须要敏感词过滤和评论审查。如果没有审查间接将用户的评论显示在文章下，那么可能会对博主和网站自身带来不良影响。例如，有人发了政治敏感的舆论或者不合规的广告，没有通过后盾审核就间接显示进去了，而你的博客部署在大陆，那么你的博客很可能会被马上关停整顿，并且本人也会解锁程序员从入门到如入狱的成就。也千万不要认为部署在境外就没事了，一些怨恨性质的舆论甚至能够帮你引来黑客，在你的博客里下毒，勒索你或你的读者。
因而我强烈建议集体博客启用敏感词过滤及评论审查性能。WordPress 及我的 Moonglade 博客零碎均反对敏感词过滤和评论审查。
14 动态化
晚期的新闻零碎、博客、CMS 为了进步大访问量下的响应速度，都会采纳动态化技术，行将服务端渲染完的页面保留为真正的 HTML 文件于磁盘上，进行 static file 的输入，Web 服务器输入 static file 的效率十分高，对于不变的内容，用户的后续拜访不会 hit 数据库，因而极大减小了服务器的压力。在 2020 年的明天，动态化曾经不是惟一的计划，Redis Cache 也能够帮忙咱们缩小对数据库的频繁拜访。对于集体博客来说，如果你的访问量不高，其实并不需要 996 一个动态化或 Redis 进去减少开发和保护老本。但如果你设计的是博客平台，那么最好还是用上动态化或 Redis 吧。
15 告诉零碎
博客通常通过 Email 的模式给管理员或用户发送告诉。然而没有标准或或约定示意博客是否肯定得应用 Email 进行告诉推送，可由博客零碎设计者自行决定。
告诉通常包含：
向博主发送的告诉：新评论、文章被别人博客援用（参见第 5.8, 5.9 章）。
向用户发送告诉：新文章公布（订阅 Newsletter）、评论被回复、评论审核通过或被拒。
Email 告诉零碎要留神垃圾邮件及用户隐衷爱护问题。
垃圾邮件发给博主自身问题并不大，但得留神邮件系统是否会容许未经博主许可的针对读者的邮件发送，其中可能会被人利用发垃圾邮件，从而导致服务器被封禁。有些服务器供应商，例如微软 Azure，对于邮件有更加严格的规定，部署在局部 PaaS 业务上的代码调用 SMTP 终端会被间接屏蔽。
对于用户隐衷问题，在用户向博客零碎提供 Email 地址的同时，须要告知用户该 Email 地址会被如何应用（可写在隐衷协定或页面可见区域），也能够让用户勾选是否容许博主应用该 Email 进行告诉推送。另一个问题是邮件地址裸露，这通常产生在 Newsletter 的订阅群发，如果把所有订户的 Email 地址都放在 To 或 CC 里，那么每个用户都会晓得其余所有人的 Email 地址，从而相互约炮、欺诈，因而 Newsletter 请采纳 BCC 或独自发送，并容许用户退订。
Moonglade 的告诉零碎采纳 Email 形式，但设计比拟根底。一个欠缺的告诉零碎须要采纳音讯队列及事件设计，并采纳三方服务。例如 Azure 上能够应用 Storage Queue + Function App + SendGrid，免得遇到大批量 Email 发送的时候原地爆炸。
今天将次要介绍【博客协定或规范】欢送关注！
扫码关注微软 MSDN，获取更多微软一手技术信息和官网学习材料！
