INIT (I swear I will never re-init this repo again)
This commit is contained in:
commit
3db85006cc
GPG key ID:
5ADFCC948BAA473A
105 changed files with 16927 additions and 0 deletions
132
content/posts/百草园/理想乡构筑手记/理想乡构筑手记（1）：Hello，Hermeneutics.md
Normal file
132
content/posts/百草园/理想乡构筑手记/理想乡构筑手记（1）：Hello，Hermeneutics.md
Normal file
|
|
@ -0,0 +1,132 @@
|
|||
---
|
||||
title: 理想乡构筑手记（1）：Hello，Hermeneutics
|
||||
date: 2025-01-22
|
||||
summary: 写了个主题捏
|
||||
description: 本文介绍了作者在期末考试后，利用 AI 编辑器 Cursor，以野心开发模式快速构建其博客新主题「Hermeneutics」的经历。新主题采用 UnoCSS 框架，样式灵感主要来源于 Innei 的 Mix Space Shiro。文章详细描述了如何向 AI 提出需求、快速迭代，并最终完成一个可用的主题。尽管遇到了一些挑战，例如代码风格混乱和部分功能需要手动实现，但作者仍然认为这种结合 AI 的开发模式对于个人项目来说高效且具启发性。最后，作者解释主题命名源于一首同名歌曲，并留下了一个值得读者思考的问题。
|
||||
categories: ["百草园"]
|
||||
series: 理想乡构筑手记
|
||||
tags:
|
||||
- 博客
|
||||
- Hermeneutics
|
||||
- Cursor
|
||||
slug: hello-hermeneutics
|
||||
featuredImage: https://img.viento.cc/cover/hello-hermeneutics-cover.webp
|
||||
---
|
||||
|
||||
各位老友们好，我是 Chlorine。
|
||||
|
||||
如各位所见，小氯也是成功从荆棘遍野天堑绝崖的期末寄活下来了。尽管是考得一团糟，但是你就说活没活下来吧（`骄傲脸.avif`）。
|
||||
|
||||
那么既然考完了，报仇雪恨般的摆烂自然是必不可少的。当然，小氯的摆烂不是打游戏或者刷一天的视频，而是折腾自己喜欢的东西，例如小氯心爱的园子，或者是（后续）学一学 Rust、Python，或者是机器学习和统计学。
|
||||
|
||||
> 你这哪叫什么摆烂？
|
||||
|
||||
你说得对。小氯不知道，节奏不快的自我提升什么时候都成了摆烂了。
|
||||
|
||||
好的，回来。既然有了充足的时间，那么园子的一周年庆典就要提上日程了。小氯打算开一个新系列，仔细说一说小氯装修园子的过程，以及一些有的没的的感想。由于没有找到什么好的名字，就随便起了一个「理想乡构筑手记」。构筑和手记都明显，而这里的「理想乡」，来自于园子英文名的直译。
|
||||
|
||||
> Chlorine's Eutopia
|
||||
|
||||
本期是「 [理想乡构筑手记](/series/理想乡构筑手记) 」的第一篇，主题是园子的新主题——「Hermeneutics」（中文直译：解释学 / 诠释学）。
|
||||
|
||||
这篇文章还可以有一个更加学术化的名字：
|
||||
|
||||
> 基于 Cursor 的野心开发模式——以 Hugo 主题为例
|
||||
|
||||
不过就其详细程度而言，其远远担不起这个名字。
|
||||
|
||||
> [!warning]
|
||||
> 下文所述的开发策略具有很强的场景和个人局限性，可能不适用于所有的场景，请自行取舍。
|
||||
|
||||
## 前言
|
||||
|
||||
如各位老友所见，小氯非常喜欢 [Shadcn UI](https://ui.shadcn.com) 的风格。至于到底喜欢什么部分，难说，可能是其流畅的动画、美观的圆角、微妙的阴影和大胆的黑白撞色吧。然而，小氯并没能成功将其应用于自己的任何一个主要项目，只在几个单页 HTML 中（在 AI 的帮助下）实现过一些类似的风格。
|
||||
|
||||
小氯之前的博客主题是基于 [Landscape](https://github.com/kkbt0/Hugo-Landscape) 魔改的 Efímero（浮光）。确实是很美观且有特色的主题，而且在小氯持之以恒的魔改下，基本上复刻了 Fuwari 大部分的功能（除了 Banner 高度的变化）。但是小氯对这个主题也只能魔改，把主题整个的样式布局拆了重来，对小氯来说还是太难了，而令人又爱又恨的 Swup 也是不忘每时每刻为小氯上血压，至今小氯也没能完美地修复 KaTeX 的加载问题。
|
||||
|
||||
而前几日（应该是前很多日了），[时雨](https://shiyu.dev)老友自己动手做了一个新的博客 <https://test.shiyu.dev/>，效果相当不错。于是，小氯动了换个主题的心思，打算做一个 Shadcn 风格的主题，奈何没这个能力知道吗（范大将军音），而且在期末寄搞这个无异于紫砂，于是小氯就把这件事搁下了。
|
||||
|
||||
这一转眼，寄也寄完了，那么这些工作也该提上日程了。当然，这么大（迫真）的项目，普通的 AI 辅助是胜任不了的，小氯打算试一试最近很火的 [Cursor](https://www.cursor.com)。
|
||||
|
||||
小氯最早是在 [Pseudoyu](https://pseudoyu.com) 老师的博客了解到的 Cursor。Yu 老师对 Cursor 的评价相当高，称其「体验感和可用性已经和我想象的形态越来越近了」。[^1]在后续几个渠道了解到的评价中，都对 Cursor 赞不绝口。
|
||||
|
||||
于是小氯花了一点时间去搜集了一下 Cursor 的相关信息，大致就是一个超高校级的 AI Editor，可以结合整个项目、在线文档等满足你的代码需求，甚至直接上手帮你改代码。虽然说不开源，但是功能也是真的很强。
|
||||
|
||||
Cursor 虽然没有教育账户，但是有一个试用期，应该是足够我完成这个项目了（事实证明并非如此，不知道为什么，我的免费额度用得极快，这一个项目干碎了我六七个免费账户，没办法，为了完成项目只好先亏欠一下 Cursor 了）。
|
||||
|
||||
## Tech Stack
|
||||
|
||||
Hugo 的主题自然是不能请 React 等乱七八糟的前端神仙的，~~就算能小氯也不会~~。于是，小氯打算只用一个不算是框架的 UnoCSS。至于 Swup，哪凉快哪待着去，再处理那些 JavaScript 加载问题我要疯了。
|
||||
|
||||
## 主题风格
|
||||
|
||||
如前文所述，小氯原本是想做一个 Shadcn 风格的主题的，不过做着做着就跑偏了。现在的主题可谓是 Anything But Shadcn（雾）。大体上也没什么风格可言了，高情商的说法可能是简洁、优雅和响应式，低情商的说法我不敢想。
|
||||
|
||||
不过，对于经常逛博客圈子的老友来说，这个风格应该不难看出其溯源：**拾壹老师（[Innei](https://innei.in)）的 Mix Space Shiro**，准确来说应该是「白い」。尤其是首屏，不能说是很相似吧，只能说是一模一样。
|
||||
|
||||
作为一位前端开发的大神，拾壹老师的个人网站堪称我见过最美观的，甚至可以说没有之一。虽然说小氯还做不到像拾壹老师做得那么好，但是小氯自己已经比较满意了。
|
||||
|
||||
这里再说一下版权和许可的问题：Shiro 以 AGPLv3 开源，「白い」是闭源的。小氯做的主要是参考样式，最多是把网页截图之后扔给 AI 做参考图，控制台都没开几次，代码更是**完全没看**。所以，小氯认为这份代码应该不受 AGPLv3 传染性的制约。而且小氯的主题本身也是以 MIT 协议开源的，应该不会有什么法律风险。
|
||||
|
||||
那么下面，就简单说说开发的问题吧。小氯不会讲具体的开发流程，因为小氯也忘记了 (/ω＼)
|
||||
|
||||
## 野心开发
|
||||
|
||||
这个词是小氯现想出来的，不过也确实有这个词。Aggressive Development，也可以翻译为激进开发、侵略性开发。简单来说就是用各种手段，以极快的速度搓一个 Production-Ready 的 MVP 产品。对于抢占蓝海市场份额或者是初创公司的 IPO 这样的场景来说，这个策略很有用。
|
||||
|
||||
小氯只是开发一个自用的主题，自然谈不上抢占市场份额，事实上，小氯只是「急功近利」而已——希望以最快的速度完成一个可以实装到园子的主题。而且，就小氯的经验来说，AI 写的代码如果没有关键性 Bug，大部分都是可用但是风格和性能不甚佳的。Cursor 的 AI 再聪明，应该也逃不出这个规律，那用来做这种 MVP 可是再合适不过了。
|
||||
|
||||
具体来说，小氯只做了这样几件事：提要求，检查是否可用，如果可用，下一个 feature，否则改。例如在写 `index.html`（现在的 `home.html`）时，小氯直接把拾壹老师的首页截了个图扔给 AI，告诉它「我希望这样的首页效果」；而在写最新文章时，小氯则是用比较复杂的自然语言描述了一下我希望的效果，事实证明 Cursor 对其理解得还行。
|
||||
|
||||
此外，也有一些部分是 AI 搞不定的，例如 Twikoo 的美化。可能是因为 Twikoo 本身不算是一个大众的东西，也并没有完整的 CSS 文档。
|
||||
|
||||
小氯采取的策略依然是拾人牙慧。博友圈中，有谁用的是 Twikoo，而且样式比较美观呢？第一个想到的肯定是[洪哥](https://zhheo.com)。很可惜，洪哥的 Heo 主题是闭源的，于是我盯上了[安知鱼老师](https://blog.anheyu.com)的主题。AnZhiYu 主题是开源的，于是小氯获得了一个 `Twikoo.styl`。
|
||||
|
||||
当然这个东西是不能直接拿来用的，不仅是因为其是 Stylus，就算把 Stylus 转回 CSS，好多变量小氯也没有。就算是把变量都抄下来，也不符合小氯主题的风格（~~你事怎么这么多？~~）。于是小氯也只好动手自己写。
|
||||
|
||||
结果就是花了大概大半个晚上，小氯拿着浏览器的控制台和开发者工具一点点地调，终于做出了一个看着还行的效果。然而现在 Twikoo 的样式还有问题，例如在回复中展开表情面板会被卡片遮挡，这个以后还要修。
|
||||
|
||||
插一句话，Twikoo 中按钮的颜色，其实就是小氯虚拟形象头发颜色的柔化版 (/ω＼)
|
||||
|
||||
做个不太详细的总结的话，野心开发对于这种急功近利的场景还是可以的，建议大致就是以下几条：
|
||||
|
||||
- 尽可能详细地描述你的要求，但是不要使用「非通用性的语言」。例如，你说「iOS-style」，AI 是懂的；但是你说「类似 Innei 的设计风格」，AI 就很难听懂了，因为这并不是一种被业界广泛认可并且形成固定模式的风格，自然不能被 AI 很好地预先学习。
|
||||
- 先完成最主干的部分，例如整体的布局、大块组件，把动画、细节优化和配色调整这种事情放到以后做。
|
||||
- 不要想着能看懂所有代码再继续，那不现实。AI 开发的代码规模增长速度远超你的预期。你只需要关注关键部分，保证不被落得太远即可。
|
||||
|
||||
当然，野心开发也是有很大的缺点的，最主要的就是「太着急了」，造成代码风格的混乱以及整体的难以理解（人类跟不上它的速度）。此外，AI 直接生成的代码虽然说可以跑，但是大部分时候也就是可以跑而已。代码风格的不统一和缺功能不说，很多地方还有一些离谱的 bug（或者是 feat），比方说在页面内点击目录链接居然还会触发加载动画。这些都需要小氯一点点自己改。当然，小氯把这个工作主要放到了 Alpha 之后，方式主要是 `⌘ + K` 唤出 AI 进行细粒度编辑，以及自己手动审查和修改。后者能费点时间，但是效果好一些。
|
||||
|
||||
## 命名
|
||||
|
||||
最后，说点有趣的东西，就是「Hermeneutics」这个奇怪的名字是怎么来的。
|
||||
|
||||
下面的解释引自 Wikipedia：[^2]
|
||||
|
||||
> 解释学（英语：hermeneutics），又称诠释学、阐释学，是关于文本解释的理论。在中世纪欧洲，主要是对于《圣经》的解释。18世纪施莱尔马赫把解释学扩展到解释文本意义和文化意义的一般规则的理论。
|
||||
>
|
||||
> 广义的解释为意义之理解(understanding)或诠释(interpretation)的理论或哲学。由于意义经常有许多歧义，须透过理解诠释方能把握全部涵意，诠释学即是探究如何形成理解及如何实践理解之科学理论。
|
||||
|
||||
这么看来，「Hermeneutics」似乎是一个极简的、高度文字性的主题，然而事实并非如此：Hermeneutics 做得相当精致（至少我自己是这么认为的），同时也谈不上文字主导。
|
||||
|
||||
OK，事情是这样的：小氯在期末季的时候偶然听到了一首歌：《[解释学 Hermeneutics](https://www.bilibili.com/video/BV18S4y1v7gV)》:
|
||||
|
||||
> If it comes first, they call that true love
|
||||
>
|
||||
> If it comes second, they call that infatuation
|
||||
>
|
||||
> They call that memory when it is over
|
||||
>
|
||||
> But I call them all delusion, all delusion, all delusion
|
||||
>
|
||||
> Beautiful delusion
|
||||
|
||||
小氯很喜欢这首歌，于是打算将其作为主题的名字（甚至把这段歌词直接放到了主题的 readme 中）。如果这个主题还是当初希望的 Shadcn 风格，这个名字应该是相当合适的，不过现在，就外观而言，可能就没那么贴切了。
|
||||
|
||||
不过，各位，想想小氯的主题大部分的代码都是由 AI 生成的。
|
||||
|
||||
**所以，这是否也是一件值得「解释」的事呢**？
|
||||
|
||||
[^1]: Pseudoyu. 周报 #69 - AI Coding 体验与学习的源动力\[EB/OL\]. (2024-08-19)\[2025-01-21\]. <https://www.pseudoyu.com/zh/2024/08/19/weekly_review_20240819/>.
|
||||
|
||||
[^2]: Wikipedia. 解释学\[EB/OL\]. \[2025-01-21\]. <https://zh.wikipedia.org/wiki/%E8%A7%A3%E9%87%8B%E5%AD%B8>.
|
||||
|
||||
227
content/posts/百草园/理想乡构筑手记/理想乡构筑手记（2）：Hello，Céfiro.md
Normal file
227
content/posts/百草园/理想乡构筑手记/理想乡构筑手记（2）：Hello，Céfiro.md
Normal file
|
|
@ -0,0 +1,227 @@
|
|||
---
|
||||
title: 理想乡构筑手记（2）：Hello，Céfiro
|
||||
date: 2025-02-18
|
||||
slug: hello-cefiro
|
||||
featuredImage: https://img.viento.cc/cover/hello-cefiro-cover.webp
|
||||
categories:
|
||||
- 百草园
|
||||
tags:
|
||||
- 邮件
|
||||
- 博客
|
||||
series: 理想乡构筑手记
|
||||
summary: 邮件系统也值得你水一篇文章吗？！
|
||||
description: 本文介绍了作者对个人域名邮箱、临时邮箱和事务性邮件的需求及最终选择方案。在个人域名邮箱方面，作者详细对比了国内外多种服务，最终选择了iCloud+ Mail，主要看重其与Apple生态的集成、相对较低的价格以及基本够用的功能和隐私性。对于临时邮箱，作者选择了Cloudflare Email Route，利用其便捷性和可扩展性，将邮件转发至现有邮箱。事务性邮件方面，作者选择了Resend，因其提供每日100封的免费额度和易用的API。文章也提到了配置iCloud+ Mail的一些细节和注意事项，以及对邮件隐私性的深入思考，强调了技术隐私的重要性。
|
||||
wikilinks:
|
||||
---
|
||||
|
||||
诸位老友，下午好。这里是再次回到学校~~坐牢~~的 Chlorine（悲）。
|
||||
|
||||
这几天（~~明明是十几天~~）小氯的 `_drafts` 文件夹里面已经躺了无数的草稿了，然而这个笨蛋一直在鸽（悲）。
|
||||
|
||||
那么今天讲讲园子邮件系统翻新的事吧。这是一篇水文，嗯。
|
||||
|
||||
前置介绍：园子的信息系统叫作「Viento」，西班牙语的「风」。而 Viento 的邮件系统——Viento Mail，有其专门的名字——Céfiro（字面意思为「西风」）。Céfiro 拥有园子内的任何邮递服务的唯一经营权。~~好吧好吧你开心就好~~。
|
||||
|
||||
## 小氯的需求
|
||||
|
||||
小氯大概需要这么几样东西：
|
||||
|
||||
- **个人域名邮箱**：作为平时的主力邮箱。
|
||||
- **临时邮箱**：用来注册一些随用随抛的服务，~~或者是拿来薅新手免费额度~~。
|
||||
- **事务性邮件**：用于园子的评论通知和 Newsletter 等（~~暂时还没有~~）。
|
||||
|
||||
### 个人域名邮箱
|
||||
|
||||
- ~~邮件服务一定要能发邮件——将军~~
|
||||
- 可以接受的国内速度
|
||||
- 足够的隐私性
|
||||
- IMAP / SMTP 支持
|
||||
- 自定义域名
|
||||
- 不太高的价格
|
||||
|
||||
### 事务性邮件
|
||||
|
||||
- 有足够的免费额度
|
||||
- 易用的 API
|
||||
- 良好的发件送达率
|
||||
|
||||
看起来这个和第一个可以合并，例如使用 `infochan@本站域名` 发送事务性邮件。但是小氯不太喜欢这样，因为使用一个「个人」性质的邮箱去发送大量（迫真）的事务性邮件其实并不是什么好事，会增加被判定为 Spam 的风险。再说，Info 酱也不是小氯的附属品，分配一个这么私人化的地址有点不太好（~~Info 酱：我没意见喵~~）。
|
||||
|
||||
## 个人域名邮箱的选择
|
||||
|
||||
这是个漫长的过程。小氯纠结了好久，最终才下定了决心。国内外的域名邮箱多如牛毛，在这里报菜名疑似确实有点水长度了。所以小氯还是重点介绍一下自己**考虑过**的吧，余下的一笔带过即可。
|
||||
|
||||
此外，需要提前说明一点：**隐私性和匿名性是不同的**。隐私性有点像是医院的病历，这些信息和你强关联，但是医院承诺这些数据不会被无关人等或者恶意攻击者查看（但愿如此）；而匿名性就像假面舞会，任何人都可以参加和观察，但是他们不知道「那是你」。虽然说 Mailbox 使用各种方式（例如最小注册信息）也可以实现很高的匿名性，但是下面我们的讨论主要集中于「高隐私性」的象限。
|
||||
|
||||
|
||||
|
||||
### 国内的免费邮箱
|
||||
|
||||
目前已知的大概有这么几个：
|
||||
|
||||
- 阿里邮箱（依然可注册，但是入口很难找）
|
||||
- 腾讯邮箱（可注册，需开通 WeCom）
|
||||
- 网易邮箱（应该是免费的）
|
||||
- 飞书邮箱（可注册）
|
||||
|
||||
如果要从其中对比一下的话，阿里邮箱和飞书邮箱应该算是体验比较好的。不过除非您对国内速度有着极端苛刻的要求并且不太在乎某些方面的问题，否则小氯不太推荐您碰这些东西。
|
||||
|
||||
### 国内的付费邮箱
|
||||
|
||||
嗯哼？
|
||||
|
||||
### 国外的免费邮箱
|
||||
|
||||
很遗憾，几乎没有。唯二可以算进这个类别的大概是 Lark（飞书的国际版）和 Zoho。Zoho 免费版不支持自定义域名，Lark 算是还不错的，但是据说有一些奇奇怪怪的限制，小氯没有过多研究。
|
||||
|
||||
### 国外的付费邮箱
|
||||
|
||||
#### Google Workspace & Microsoft 365
|
||||
|
||||
两个大厂的产品。优点是老牌、认可度高且成熟，而且附带其他的高级功能，例如办公套件；缺点是相对较贵（Google Workspace 7 USD / mo，Microsoft 365 商业基础版 46 CNY / mo）。此外，这两个服务的隐私性有一定争议。虽然说牢谷和牢软的 Enshitification 大法应该还没修炼到第三层，但是鉴于 Gmail 和 Outlook 的情况，还是认真一点为好，例如把地区选到 GDPR 辖区（如果您能接受这个延迟）。
|
||||
|
||||
#### iCloud+ Mail
|
||||
|
||||
牢果的 iCloud+ 的一个小的附加服务。
|
||||
|
||||
iCloud+ Mail 的第一优点自然是与 Apple Eco 的深度集成，对小氯这种 Apple Eco 使用者来说很友好。此外，还有一个更重要的点是：**它便宜**。iCloud+ 美区的 50 GB 套餐只需要 0.99 USD / mo，堪称是所有域名邮箱中最便宜的。当然，由于奥斯曼帝国的传统艺能，土区的 iCloud+ 定价比美区、国区都便宜一些。不过就我们 50 GB 的套餐来说，只便宜了 1 ~ 2 CNY，对于小氯这个还需要用 iCloud 和 Apple ID 的家伙来说，实在是不值得大费周章。[^1]
|
||||
|
||||
当然，iCloud 的缺点也很明显：首先，与 Apple 生态强绑定，在其他系统的设备使用只能依靠网页端或者第三方邮件客户端，不如 Mail app 那么顺滑；其次，只有基本的邮件收发功能，没有高级的企业功能；以及，只支持五个自定义域名，每个域的地址只能设置三个。这么看，iCloud+ 大概定位上就是一个单纯的「个人或家庭用的域名邮箱」，而不是企业邮箱。当然，这不是什么大事：由于小氯只给自己用，开一个 Catch-All 即可。
|
||||
|
||||
至于隐私性嘛……只能说比 Gmail 和 Outlook 强吧。虽然说牢果主要卖硬件，不像牢谷那样完全靠吃数据过活，而且还有官方承诺「不扫描用户邮件**用于广告目的**」（我们姑且相信这是真的），但是，美国公司，你懂的。不过，虽说把数据交给大公司本身就不是个好主意，但有句老话说得好，「All big techs are awful, but some techs are more awful than others」（~~奥威尔：版权费交一下谢谢~~）。
|
||||
|
||||
#### Fastmail
|
||||
|
||||
著名的邮件服务，风评很好。存储空间慷慨，对于个人使用非常实惠（Individual 套餐有 60 GB）。价格方面中等偏高：Individual 套餐 6 USD / mo（年付 5 USD / mo）。不过如果是家庭装拼车 + 年付的话（假设这东西可以拼车），可以压到不到 2 USD，倒也算能接受。
|
||||
|
||||
唯一的缺点大概是价格，对于一个赛里斯的学生来说，一个月 30 多听着还是高了点，而且也没有教育优惠。
|
||||
|
||||
至于隐私性，小氯认为还是可以的，应该比牢果还强一些，对于我们这个级别的使用很不错了。但也并不特别值得放心。很简单：**澳大利亚属于五眼联盟**。FVEY 对待个人隐私是啥德行，我也不用多说了。
|
||||
|
||||
#### Zoho Mail Lite
|
||||
|
||||
Zoho Corporation Pvt. Ltd. 是牢印的一家公司（~~干净又卫生呐~~），在……嗯，基于云平台的企业级应用软件解决方案方面比较有名。其整套产品包括办公套件、CRM、企业邮箱、财务 / 人力 / 项目管理、客户支持、商业智能分析、低代码平台和营销自动化等。
|
||||
|
||||
Mail Lite 是 Zoho 的轻量级付费计划，1 USD / mo，性价比很高。不过据说有一些漏信的情况，咱也没试过，不能给出准确的评价。隐私方面的话，不能指望它有多好，但是肯定比 Gmail 强就是了。
|
||||
|
||||
#### ProtonMail / Tutanota
|
||||
|
||||
E2EE 邮箱两兄弟，由于有端到端加密，隐私性极好。价格中等偏高。缺点是使用自有的 E2EE（某种意义上说这也算是个优点），因此不能使用一般的 IMAP / SMTP 客户端。
|
||||
|
||||
#### RunBox / Mailbox / Migadu / Startmail ...
|
||||
|
||||
欧洲的活宝们，由于 GDPR 的制约，隐私性可能会比较好。小氯有点脸盲症，所以挑几个列个表格好了。
|
||||
|
||||
| 服务商 | 最低计划 | 国家 | 价格 | 存储空间 | 域名 / 别名数目 | 收发件限制 |
|
||||
| --------- | -------- | ------- | -------------- | ----- | ------------------------------------------------------------------------------------------- | ------------------------ |
|
||||
| Mailbox | Standard | 🇩🇪 德国 | 3 EUR / mo | 10 GB | 25 aliases @mailbox.org, 50 aliases @customdomains | 不明 |
|
||||
| Runbox | Mini | 🇳🇴 挪威 | 84.95 USD / 3a | 10 GB | 5 email domain names, 100 aliases @runbox domains, Unlimited aliases on your domains | 不明 |
|
||||
| Migadu | Micro | 🇨🇭 瑞士 | 19 USD / a | 5 GB | [Almost Unlimited](https://migadu.com/pricing/#what-is-the-domains-limit-on-the-micro-plan) | 200 in / d, 20 out / d |
|
||||
| Startmail | Personal | 🇳🇱 荷兰 | 4.99 USD / mo | 20 GB | one custom domain, Unlimited email aliases | 不明 |
|
||||
|
||||
很明显，小氯要多提一句 Migadu 这个显眼包。这个收发件限制看着实在是太离谱了，虽说你有无限的域名和别名，但是小氯也不用那么多啊（虽然说，从运营者的角度说，限制收发件数目而不是别名数目确实能更好地控制成本）。此外，虽然这家服务商位于瑞士，**但是他们的数据中心在法国，而且数据不加密**。用[他们自己的话说](https://migadu.com/procon/#in-switzerland-but-servers-are-not)：「We find EU privacy laws much more elaborate and restrictive than the Swiss ones. Switzerland used to be famous for banking secrecy, but that has nothing to do with digital data.」这话的对错我们姑且不评判，不过这么说确实……很有个性，不是吗？
|
||||
|
||||
### 自建邮箱
|
||||
|
||||
也就是自己找一台服务器或者 VPS 或者别的什么东西，自己搭一个邮件服务。优点是紫柚，缺点是除此之外。你不仅需要一个很干净的 IP，还需要部署一个合适的邮件服务器，配置各种乱七八糟的东西（IMAP / SMTP，SPF，DKIM，DMARC……），然后长期维护。虽然对于各位老友来说，这不算是高不可攀的技术门槛，但是整天自我运维也属实够累人的。
|
||||
|
||||
### 奇技淫巧
|
||||
|
||||
下面这些方案都挺偏门的，大家谨慎尝试。
|
||||
|
||||
#### Cloudflare + Resend
|
||||
|
||||
作为互联网大善人，Cloudflare 经常被用来搭各种奇怪的服务，临时邮箱算是其中一个，例如：
|
||||
|
||||
{{< github repo="dreamhunter2333/cloudflare_temp_email" >}}
|
||||
|
||||
这个服务可以搭配 Resend 这样的发件 API 以及 Proxy Server，作为一个真正的邮件服务。不得不说，开源社区的创造力是无限的。不过具体可用性如何，小氯就不清楚了。
|
||||
|
||||
#### Disroot + 捐赠
|
||||
|
||||
[Disroot](https://disroot.org) 是一个荷兰的非营利组织，以对抗科技巨头的垄断和数据收集为己任。他们提供了一系列的免费公共服务，电子邮件是其中之一。
|
||||
|
||||
根据 [Disroot 官方的说法](https://disroot.org/en/services/email)，他们为每一位捐赠金额达到或者超过 12 杯咖啡的捐赠者提供**终身**的自定义邮件域名服务。小氯不喝咖啡，因此不太清楚 12 杯咖啡是多少。不过如果打算长期使用的话，应该还是比订阅制服务合算的。
|
||||
|
||||
存储空间方面呢，Disroot 为每个注册账户的人都免费提供 1 GB 的空间，轻度使用倒是够，但是确实少了点。可以付年费扩容，不过价格也不算低。
|
||||
|
||||
## iCloud+ 配置
|
||||
|
||||
小氯最后选择的方案是 iCloud+ Mail（~~从长度也可以看出来~~），毕竟 iCloud+ 对小氯也是有用的，那为什么还要额外花一笔钱呢。
|
||||
|
||||
至于隐私性的问题？的确，小氯前面说了，iCloud+ 的隐私性也并不太好，容我解释一二。
|
||||
|
||||
由于电子邮件这种通讯方式本身的限制，其隐私性很难提高到一个接近完美的级别。例如，PGP / GPG，足够安全了吗？似乎是的。但是在量子计算机面前，RSA 和 ECC 也很难说立于不败之地。更严重的是，GPG 是没办法很好地加密邮件的元数据的，例如收发件人的地址和邮件的主题。这一点可以给社工学攻击留下巨大的漏洞。[^2]
|
||||
|
||||
除了技术问题，道德和政治问题也是值得考虑的问题。当我们说「我们信任某一家服务商」时，我们都或多或少地对这家服务商以及其宣誓效忠的法律寄予了一些道德上的信心。例如，我们一般认为 EEA 内的邮件服务比较可靠，是因为著名的 GDPR，但这也需要我们认为，除非是元首带着鸡农回来了，否则欧洲各国无论如何都会坚持保护用户的隐私，而不是将其用作武器和资源。此外，各种各样的军事和情报组织也值得警惕：例如，德国、荷兰等国是「十四眼联盟」（~~千手百眼巨人~~）的成员国，所以其官方监管的担忧要比北欧五国严重一些（**注意我说的不是「危险更高」**）；而北欧五国内，瑞典和丹麦的情况可能比较复杂（例如瑞典 FRA 曾经被指控与 NSA 合作），挪威、芬兰和冰岛的风险则相对低一点。但是**上面提到的所有国家都是北约国家**。瑞士一向自称（和被认为）是永久中立国，但是近些年的一些事情，也让人对所谓的「永久中立」难以寄予厚望。所以，小氯信任技术隐私的程度是远远高于道德隐私的。如小氯之前说过的：「**在进行任何技术实践时，都应以最坏的恶意度测人心**。」
|
||||
|
||||
所以，既然知道我们只能做这么多，那么为什么不选一个平衡隐私性、便利性和性价比的选择呢？而且，一般来说，除非您被顶级的社工学黑客或者某个国家的情报机构盯上了，否则只要您防着些社工学攻击，同时会耍一点 GPG，我们现在的邮件服务隐私程度就已经足够安全啦。如果您真的需要极高的加密级别，那小氯推荐您还是别用电子邮件了，加密即时通讯它不好嘛。
|
||||
|
||||
### 配置
|
||||
|
||||
关于 iCloud+ Mail 的配置，可以参考[芙樱竹老友的博文](https://blog.muna.uk/archives/iCloud-plus-mail.html)。iCloud+ 需要持续订阅，由于英区的 PayPal 绑不到美区的 iCloud，同时 BOC 的 Mastercard 也被拒付了（~~嘤嘤嘤~~），小氯采取的方法是往 Apple 账户里提前充好一笔钱，也就是买礼品卡，这个还是蛮容易的，Alipay 和 Apple 官网都可以操作。
|
||||
|
||||
### 其他问题
|
||||
|
||||
目前用了一个多月了，似乎也没有遇到什么问题，感觉还是不错的。
|
||||
|
||||
小氯在调查 iCloud Mail 的名声时，发现了极多的负面评论。不过它们的年代都比较久远了，大概是 iCloud Mail 刚出的时候。那个时候的 iCloud Mail 确实还有很大的进步空间。现在 iCloud Mail 的情况似乎已经改善不少。
|
||||
|
||||
之前还听过一种说法，iCloud+ Mail 不能用自定义域名地址发信。这应该也是比较老的说法，现在的 iCloud+ 已经支持了。只需要在登录第三方客户端时，使用你**原本的 iCloud Mail 地址登录**即可，而 Mail App 则有原生适配（如果您发现小氯发给您的邮件的地址不是 `hi@本站域名` 请一定一定要告诉小氯一声！ (＞ｍ＜)）。
|
||||
|
||||
## 临时邮箱
|
||||
|
||||
我们这里把临时邮箱理解为「Receive-only」的。临时邮箱的实现思路大致有两种：
|
||||
|
||||
- （拟）全功能：通过某种技术手段（例如 Cloudflare 全栈或者一个轻量级 IMAP 服务器），实现直接在服务内收取、存储和读取邮件。代表如各种基于 Cloudflare 的临时邮箱服务（可以看[这里](https://github.com/zhuima/awesome-cloudflare)）。
|
||||
- 转发：服务本身并不存储邮件，而是作为代理将邮件转发到一个现成的邮箱地址。代表如 Forward Mail 和 Cloudflare Email Route。
|
||||
|
||||
小氯用的是 Cloudflare Email Route。简单来说，Cloudflare Email Route 就是通过将你的邮件相关 DNS 记录指向 Cloudflare 的服务器，让 Cloudflare 接管你的收件行为，例如发送至特定地址、发送到 Worker 或者直接抛掉。
|
||||
|
||||
这种方式最大的好处是简单，一分钟之内就能搞定。而且，这种方式可以给予你最大的潜在自由度。例如，小氯现在想把邮件内容解析一下发到 Bark？没问题，写一个 Email Worker 就行。接入一下大模型智能提取验证码？也可以，在 Email Worker 加入一个 API 调用就行。只要你懂一点 Cloudflare Workers 开发，你可以把这个服务玩出花来。
|
||||
|
||||
缺点嘛，大概就是：你需要先有一个值得你信任的邮箱地址。此外，你还得信任 Cloudflare。不过对于 Cloudflare 小氯还是比较信任的，总比牢谷牢软它们强多了吧。
|
||||
|
||||
邮件路由的配置极其简单。拿好你的域名，在侧边栏选择「电子邮件」-「电子邮件路由」，单击「开始使用」，跳过入门指南。然后按照「设置」的提示，添加相关的 DNS 即可。然后可以设置一个 Catch-All 规则，把所有地址的邮件转发到一个地址。
|
||||
|
||||
这个方法也可以用来创建无数个「不那么临时」的域名邮箱，用来注册各种服务。小氯就是这么干的。
|
||||
|
||||
如果您也想这样做，小氯这里有一点对防御黑客和社工学攻击可能有用的建议：
|
||||
|
||||
- 最好不要选择与主域名一致的域名，而是单独注册一个，最好能没有什么个人色彩，而是和公共邮件服务很像（如 `awesome-mailbox.net` 之类的）。
|
||||
- 最好选择随机化前缀，配合密码管理器使用。例如，`giuln2iuy783y7@yourdomain.tld` 比 `chatgpt@yourdomain.tld` 好得多。
|
||||
|
||||
## 事务性邮件
|
||||
|
||||
事务性邮件提供商也很多，例如 SendGrid，Mailgun，AWS SES 等。小氯用的是 [Resend](https://resend.com) 。Resend 提供每天 100 封的免费额度，大体来说还算够用（~~够用：指用量不到 5 %~~）。
|
||||
|
||||
Resend 的配置没有太多好说的，注册账户，配置 DNS 记录再创建 API Key 即可。对于 Twikoo 来说，其使用的 Pushoo 没有对 Resend 的原生支持，因此需要手动配置各项信息。
|
||||
|
||||
- `SENDER_EMAIL`： `username@yourdomain.tld`
|
||||
- `SMTP_SERVICE`：留空
|
||||
- `SMTP_HOST`：`smtp.resend.com`
|
||||
- `SMTP_PORT`：465
|
||||
- `SMTP_SECURE`：`true`
|
||||
- `SMTP_USER`：resend
|
||||
- `SMTP_PASS`：Your API Key
|
||||
|
||||
目前用着还是不错的。关于送达率，小氯测试了以下邮箱：
|
||||
|
||||
- ✅ Gmail：完全正常。
|
||||
- ✅ QQ 邮箱：完全正常。
|
||||
- ⚠️ Outlook：会进垃圾箱（不过我也能料到，毕竟 Outlook 连牢软自家的邮件都敢扔垃圾箱）。
|
||||
- ❌ 126：暂时性拒收，无报错信息。这个应该不是我的问题，是 126 邮箱服务器本身的问题。
|
||||
|
||||
如果发现 Céfiro 的邮件进了垃圾邮件，还请您手动捞一下 qaq
|
||||
|
||||
## 后记
|
||||
|
||||
似乎……也没什么可说的了？那就这样吧。~~你这个水文章的杂鱼杂鱼杂鱼~~！
|
||||
|
||||
## Honor Code
|
||||
|
||||
- [我的域名邮箱选择 - atpX](https://atpx.com/blog/my-email-domain-selection/)
|
||||
- [使用 iCloud+ 自定义你的电子邮件域名 - 芙樱竹的博客](https://blog.muna.uk/archives/iCloud-plus-mail.html)
|
||||
|
||||
[^1]: 截至小氯写作本文，iCloud+ TR 50 GB 的价格是 24.99 TL（即 TRY，新土耳其里拉），按照小氯写下本文字时的国际货币汇率，大致相当于 5.04 CNY。而国区的价格为 6 CNY，美区的价格为 0.99 USD（大致相当于 7.22 CNY）。
|
||||
[^2]: 这方面做得最好的应该是 Tuta。有 E2EE，能加密部分元数据，以及采用了后量子加密算法（[至少他们自己是这么说的](https://tuta.com/blog/post-quantum-cryptography)）。
|
||||
311
content/posts/百草园/理想乡构筑手记/理想乡构筑手记（3）：Hello，Nieve.md
Normal file
311
content/posts/百草园/理想乡构筑手记/理想乡构筑手记（3）：Hello，Nieve.md
Normal file
|
|
@ -0,0 +1,311 @@
|
|||
---
|
||||
title: 理想乡构筑手记（3）：Hello，Nieve
|
||||
date: 2025-02-21
|
||||
slug: hello-nieve
|
||||
featuredImage: https://img.viento.cc/cover/hello-nieve-cover.webp
|
||||
categories:
|
||||
- 百草园
|
||||
tags:
|
||||
- 博客
|
||||
- 图床
|
||||
- Obsidian
|
||||
series: 理想乡构筑手记
|
||||
summary: 其实你一共也没有几张图片啊
|
||||
description: 本文介绍了作者构建名为 Nieve 的图片服务系统的过程。由于原先使用的缤纷云图床出现加载问题，博主决定迁移至又拍云作为主图床，并以 Cloudflare R2 作为备份。迁移过程中，使用了 `rclone` 工具进行图片备份和上传。为了优化 Obsidian 中的写作体验，博主弃用了原先的 Image Converter 插件，转而利用 Shell Commands 插件调用自定义脚本。这些脚本实现了图片粘贴时的自动压缩（使用 `cavif`）、重命名、相对路径计算，以及发布文章时查找图片、上传至又拍云（使用官方工具 `upx`）并替换链接的功能。整个过程涉及了多种工具，包括 Python 脚本、AppleScript、`ripgrep` 等，最终构建了一个自动化、高效的图片处理与发布流程。
|
||||
wikilinks: true
|
||||
---
|
||||
|
||||
诸位老友，上午好，这里是 Chlorine。
|
||||
|
||||
本期是「理想乡构筑手记」的第三篇，实际也是最早进行的一篇，主题是园子的图片服务系统——Nieve。本来是想放到新的一期周报里面讲的（~~没想到吧，园子的周报还活着~~），但是这部分内容实在是太琐碎了，遂单题一篇。~~水，你接着水~~。
|
||||
|
||||
Nieve 这个名字，也是很久以前就想好的。这个词是西班牙语，意思是「雪」。
|
||||
|
||||
## TL ; DR
|
||||
|
||||
- 在 Obsidian 写作时粘贴图片前使用 Shell Commands 的自定义脚本压缩图片为 AVIF，并获取压缩后链接。
|
||||
- 使用 Shell Commands 的另一个自定义脚本上传博客图片到又拍云和 Cloudflare R2
|
||||
- 又拍云作为主图床，Cloudflare R2 作为对外的图片服务和备份图床
|
||||
|
||||
## 前言
|
||||
|
||||
作为 Vercel 上的静态博客，园子的图片当然使用的是图床。小氯使用的图床服务几经变易，从免费图床的良心之作 [SMMS](https://smms.app) 到牢巴（Alibaba）的 OSS，再到缤纷云，期间甚至还写了[[Markdown图片管理实践|一篇将近一万字的文章]]去讲 Markdown 图片管理（当然那篇文章其实挺水的）。缤纷云提供了相当慷慨的免费额度，具体来说是：
|
||||
|
||||
- 前 50 GiB 存储
|
||||
- 每月前 10\*3 GB HTTP/HTTPS 流量（每日每项限 5 GB）
|
||||
- S4 出口流量 10GB/月
|
||||
- 内置 CDN 回源 S4 流量 10GB/月
|
||||
- 内置 CDN 出口流量 10GB/月
|
||||
- 每月前 10\*3 万次请求（每日每项限 1 万次）
|
||||
- S4 请求数 10 万次/月
|
||||
- 内置 CDN 回源 S4 请求数 10 万次/月
|
||||
- 内置 CDN 请求数 10 万次/月
|
||||
|
||||
回来。小氯使用缤纷云已经有快一年了，总体而言速度和稳定性还算可以，有了备案之后还可以用他家的 CDN，可以省一些回源流量之类的（没错，速度其实没快多少）。当然，为了避免免费服务的传统艺能——跑路。小氯也把图片在赛博活佛 Cloudflare 的 R2 上存了一份。和国内的各大对象存储以及 Amazon S3 等同行相比，Cloudflare 的免费额度简直多得不像话，一个月有 10G 的免费空间，1M 次的 A 类操作（存储和删除等），10M 次的 B 类操作（读取等），无限流量。如果不在意国内速度慢一点，那么 Cloudflare R2 堪称是对象存储中的椎间盘——为何你如此突出。
|
||||
|
||||
插一句话，小氯写到这里的时候，习惯性地希望使用中文，然后发现自己似乎不知道 Cloudflare 的中文名字……等等，Cloudflare 有中文名字吗？
|
||||
|
||||
这个还真难说。Cloudflare 的官网在调为简中后，还是叫作 Cloudflare；而 `cloudflare-cn.com` 使用的是「科赋锐」（注意：小氯不清楚这个网站和 Cloudflare 官方是否有关，请谨慎），说实话，这个名字……真的让小氯很不满意，就和把 Google 翻译为「谷歌」一样。小氯还没有找到一个被 Cloudflare 官方认可的中文名字，但是从社区来看，似乎有一个不错的选择：**云帆**。
|
||||
|
||||
「云」对应 cloud，由于「云计算」「云存储」这些词汇的广泛使用，所以用这个词代表相关的技术领域没什么问题；而「帆」是 flare 的音译（其原意为火焰）。这个词整体读起来还比较顺口，而且寓意也很好，「直挂云帆济沧海」。不过如果在正式的技术讨论里面，还是用 Cloudflare 为好。
|
||||
|
||||
回来。不过最近（其实离文章发出来已经是几个月之前了），小氯接到了一些老友的反映，博客的图片加载明显变慢了，甚至很多裂掉了（即无法加载）。直接用 URL 看一下，发现 403。奇怪的是，小氯并没有为这种情况加任何的访问限制，而图片也都好好地在那。而当我希望将新的自定义 URL 添加到 CDN 中时，也是一直提示「未备案」（实际上 ICP 和公安备案已经过了快一个月了）。这可不是什么好兆头，说明缤纷云的后端设施可能出了一些问题。此外，小氯发现自己的流量似乎也出了点差错，其用量比实际应该有的流量高。而其分布也比较均匀，不像是攻击（~~而且谁闲着没事去攻击小氯酱这条杂鱼啊~~）。
|
||||
|
||||
总而言之，种种因素作用吧，小氯打算换个图片服务了。
|
||||
|
||||
## 图片服务的选择
|
||||
|
||||
市面上的图片服务——准确来说，能直接或者间接作为图片服务的服务不胜枚举。虽然说小氯不介意花点小钱，但是如果是像流量费这种很可能让人倾家荡产的服务，小氯还是希望尽可能避免的。于是小氯开始收集各种有免费额度的服务，当然这里指的是国内的。我没备案用的是国外的图片服务，备案了用得还是国外的图片服务，那我这不是白备案了嘛。
|
||||
|
||||
具体过程不多说了，极其曲折。小氯甚至想过用服务器 + 一些 CDN 搭一个，但一是没有合适的服务器，二是这种方式相当不稳定。举个例子：[杜老师](https://dusays.com)的[去不图床](https://7bu.top)，可以说是博友圈最著名的自建图床了（甚至没有之一），也时常会出现许多奇奇怪怪的问题，小氯可不认为自己的运维能力和服务器集群的质量比杜老师强。所以还是老老实实地找对象存储去了。
|
||||
|
||||
几番搜索，小氯找到了一个看起来还可以的选择。这个家伙大家也都不陌生：[又拍云](https://upyun.com)（这个链接不带 AFF，放心点击）。
|
||||
|
||||
牢拍也算是小有名气的商家了，跑路的风险不大，而且也没有大到像套路云、凉心云那样令人讨厌的规模。此外牢拍有一个著名的 League，简单来说就是在自己网站底下挂上牢拍的 logo 可以持续领到代金券，均摊一下也就是每个月 10G 的空间和 15G 的流量，基本上够用一段时间了。而且牢拍的代金券是和账户而不是域名挂钩的，这意味着你只需要找一个备案过的域名挂一下，然后就可以随便用了。
|
||||
|
||||
那么……就是你了。
|
||||
|
||||
## 使用 `rclone` 备份图片
|
||||
|
||||
在转移到牢拍之前，我们当然需要把整个图片目录备份下来。这里小氯打算试一下新玩具 [rclone](https://rclone.org)。
|
||||
|
||||
rsync 咱都知道，一个有趣的文件传输（这里说的是上传、下载和同步）工具。rsync 的花样很多，甚至可以用它部署静态博客到服务器（这可能是最好的方案之一，不需要装 Gitea 等一堆东西）。rclone 大体可以理解为云存储版的 rsync，支持一大堆各种各样的云存储和云盘。
|
||||
|
||||
```bash
|
||||
brew update && brew install rclone
|
||||
```
|
||||
|
||||
先创建一下配置：
|
||||
|
||||
```bash
|
||||
rclone config
|
||||
```
|
||||
|
||||
下一步输入 n，新建一个配置，选择 S3 - 其他，把 Access Key ID 和 Secret Key ID 之类的参数扔进去就行。
|
||||
|
||||
配置好以后，运行：
|
||||
|
||||
```bash
|
||||
rclone ls your-service-name:your-bucket
|
||||
```
|
||||
|
||||
如果能输出你的桶目录结构那就配置成功了，可以下载了：
|
||||
|
||||
```bash
|
||||
rclone copy your-service-name:your-bucket /your/path
|
||||
```
|
||||
|
||||
完工。
|
||||
|
||||
## 又拍云的配置
|
||||
|
||||
### 申请又拍云联盟
|
||||
|
||||
略。注册之后在[这里](https://www.upyun.com/league)申请即可。一般来说审核会有 1 ~ 3 天，小氯的用了大概二十分钟，相当快。
|
||||
|
||||
### 创建存储服务
|
||||
|
||||
和缤纷云不同的是，牢拍的云存储自带 CDN，所以只创建一个存储服务即可。
|
||||
|
||||
### 使用 `rclone` 重新上传图片
|
||||
|
||||
USS 兼容 S3，这就意味着我们可以用我们熟悉的各种小道具去把玩 USS。这里为了方便，我们还是使用 rclone 吧。这里小氯踩了点坑，因此说得详细一些。
|
||||
|
||||
首先我们需要获得 USS 的 S3 兼容凭据。这可不是你那个操作员的操作凭据，需要在存储服务的控制界面 - 存储管理里面找这里：
|
||||
|
||||
|
||||
|
||||
把东西记好喽。
|
||||
|
||||
回到终端，创建一个 rclone 配置：
|
||||
|
||||
```bash
|
||||
rclone config
|
||||
```
|
||||
|
||||
输入 n 新建配置，名字随便起，这里我使用 `test` 作为演示。
|
||||
|
||||
下面依次跟随指示，键入以下配置。这里的数字是以 `v1.69.0` 为基础的，在键入前，请检查你的版本的相应配置对应于哪个数字：
|
||||
|
||||
- `Storage`：4（Amazon S3 及其兼容服务）
|
||||
- `provider`：34（其他 S3 兼容服务提供商）
|
||||
- `env_auth`：直接回车，使用默认配置即可。
|
||||
- `access_key_id`：你刚才获取的那个 `access_key_id`。
|
||||
- `secret_access_key`：还是刚才那个。
|
||||
- `region`：直接回车，使用默认配置即可。
|
||||
- `endpoint`：`s3.api.upyun.com`
|
||||
- `location_constraint`：直接回车，使用默认配置即可。
|
||||
- `acl`：直接回车，使用默认配置即可。
|
||||
- 高级设置：直接回车，使用默认配置即可。
|
||||
|
||||
最后保存后，使用 `rclone ls test:` 即可测试是否成功配置。
|
||||
|
||||
## Obsidian 配置
|
||||
|
||||
小氯在 Obsidian 的配置上花了很多的时间，终于找到了一个自己满意的方案。下面我把思路整理一下。
|
||||
|
||||
小氯的需求大概是：
|
||||
|
||||
- 图片重命名（语义化命名）
|
||||
- 使用相对链接
|
||||
- 自动压缩为 WebP 或者 AVIF
|
||||
- 发布博客时上传到图床并替换博客文件的链接，而原本的文件保持不变
|
||||
|
||||
为了方便，我们就叫粘贴处理和发布处理好了。
|
||||
|
||||
### 粘贴处理
|
||||
|
||||
能实现一部分功能的 Obsidian 的图片插件有很多，例如 Paste Image Rename，Unique Attachments 等。不过小氯最喜欢的还是这个：
|
||||
|
||||
{{< github repo="xRyul/obsidian-image-converter" >}}
|
||||
|
||||
这个插件的功能非常全面，从压缩、格式转换、自定义附件位置到标注、裁剪、缩放、对齐都有。而作者也是位乐于听从社区意见的开发者，更新迭代和 Issue / PR 回复都很勤。小氯给这个插件提了个小小的 PR（改了一个拼写错误），混到了人生中第一个 Contributor 认证 (/ω＼)
|
||||
|
||||
不过插件的功能虽多，但是小氯主要是用其中的压缩和自定义附件位置，因此整体的功能也有些冗余了。而且，其会和我常用的 Attachflow 插件冲突。至于压缩问题，Image Converter 插件在 1.3.7 版本加入了 AVIF 压缩功能，不过有一个问题：**它异常耗内存**，经常转换着转换着就内存不足崩掉了（虽然说 FFmpeg AVIF 这玩意本来就吃资源）。虽然可以回退到 WebP，但是总归不是最优的解决方案。
|
||||
|
||||
那看来只有发挥主观能动性了。那么纵观 Obsidian 的插件，能让小氯在这个意义上发挥主观能动性的插件似乎只有一个：
|
||||
|
||||
{{< github repo="Taitava/obsidian-shellcommands" >}}
|
||||
|
||||
Obsidian Shell Commands，我愿称之为 Ob 可玩性的 Top3 之一（另外两个小氯认为是 Local REST API 和 Quickadd）。这个插件的功能就是让你在 Obsidian 中调用系统的 Shell 执行命令，支持自定义变量、预输入和自动触发等。说到这里，大家应该也能想象到这个插件的可玩性有多强了。
|
||||
|
||||
而且，小氯本身也要用 Shell Commands，既然我们能少装一个插件，那么「如非必要，勿增实体」，自然是极好的。
|
||||
|
||||
首先，由于小氯的图片使用的是相对路径，因此需要先获取图片相对于当前笔记的路径。笔记路径有 `{{file_path}}` 变量，图片由于是我们自己规定的，因此也不难获得。问题在于路径的计算。macOS 没有现成的命令行工具计算相对路径，于是小氯写了个 Python 脚本：
|
||||
|
||||
```python
|
||||
#!/usr/bin/env python3
|
||||
|
||||
import os
|
||||
import sys
|
||||
import argparse
|
||||
|
||||
|
||||
def get_relpath(base_dir, tar_file):
|
||||
try:
|
||||
relative_path = os.path.relpath(tar_file, base_dir)
|
||||
return relative_path
|
||||
except ValueError:
|
||||
return None
|
||||
|
||||
|
||||
def main():
|
||||
parser = argparse.ArgumentParser(description="计算 target 相对于 base 的相对路径")
|
||||
parser.add_argument("base", help="起始目录）")
|
||||
parser.add_argument("target", help="目标文件")
|
||||
args = parser.parse_args()
|
||||
|
||||
base_dir = os.path.abspath(args.base)
|
||||
tar_file = os.path.abspath(args.target)
|
||||
|
||||
if not os.path.isabs(base_dir) or not os.path.isabs(tar_file):
|
||||
print("Err: Please input absolute path.", file=sys.stderr)
|
||||
sys.exit(1)
|
||||
|
||||
relative_path = get_relpath(base_dir, tar_file)
|
||||
|
||||
if relative_path is not None:
|
||||
print(relative_path)
|
||||
else:
|
||||
print("Err: Please input correct path.", file=sys.stderr)
|
||||
sys.exit(1)
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
|
||||
```
|
||||
|
||||
然后赋予执行权限，移动到 `~/.local/bin` 了事。
|
||||
|
||||
下面我们需要读取剪贴板的图片，这里由于是 macOS，我们使用最原生的 AppleScript 即可。
|
||||
|
||||
```applescript
|
||||
on run args
|
||||
set outputFile to POSIX file (first item of args)
|
||||
try
|
||||
write (the clipboard as «class PNGf») to outputFile
|
||||
return POSIX path of outputFile
|
||||
on error
|
||||
return "ERROR: 剪贴板中没有图片"
|
||||
end try
|
||||
end run
|
||||
```
|
||||
|
||||
然后把图片存储到临时文件 `TMPFILE="$(mktemp "/tmp/pasteboard-XXXXXX.jpg")"` 中。当然不要忘了加一个 trap 自动清理。
|
||||
|
||||
然后我们需要获取新图片的名字。为了满足小氯的需求，我们加一个 Preaction，让我们可以自己输入文件名。
|
||||
|
||||
|
||||
|
||||
然后我们就要开始压缩了。小氯第一个想到的自然是古神 FFmpeg，不过大家也知道，FFmpeg 尊者是出了名地脾气古怪，只要你稍微不慎，就会让他老人家掀桌不干。小氯反反复复调了好几次，遇到的问题包括但是不限于：
|
||||
|
||||
- 压缩极慢。
|
||||
- 都把输出重定向到 `/dev/null` 了，还是莫名其妙地冒日志。
|
||||
- 好不容易能压缩了，结果透明度数据没了，告诉我 libaom-av1 不支持 YUVA 编码。
|
||||
|
||||
……好好好。
|
||||
|
||||
那我不用 FFmpeg 还不行吗？！
|
||||
|
||||
```bash
|
||||
rustup update
|
||||
cargo install cavif
|
||||
```
|
||||
|
||||
这玩意也不是不能用，而且比 FFmpeg 快多了。
|
||||
|
||||
压缩之后，我们就可以把图片移动到对应的附件文件夹，并且向剪贴板写入我们的相对路径链接了。小氯也尝试过把数据写入剪贴板，但是 macOS 似乎不直接支持写入 AVIF。
|
||||
|
||||
完整版的脚本放在[这里](https://gist.viento.cc/chlorine/e644da399d2d48c29bc9177622233ef6)了，大家按需取用。
|
||||
|
||||
### 发布处理
|
||||
|
||||
由于小氯的 Hermeneutics 支持 Wikilink 和 Alert，所以我们只需要上传图片并替换即可。这里我们还是写脚本解决问题。
|
||||
|
||||
这个脚本比较简单，使用 ripgrep 查找图片，再通过文件的路径构建出图片路径，然后一个循环把图片送上去即可。小氯用了 Cloudflare R2 测试成功后就放心地把脚本归档了。直到小氯写[[理想乡构筑手记（2）：Hello，Céfiro|上一篇文章]]，希望调用脚本上传图片时，才发现：
|
||||
|
||||
> 你根本没在又拍云！你在哪呢？
|
||||
|
||||
图片并没有被上传到又拍云。于是，小氯开始了兵荒马乱的排查过程，最终在单独测试 `rclone copyto` 时发现了一大堆奇奇怪怪的报错，不是超时就是缺少 Key 或者各种万泉部诗人的奇怪报错。这可能是因为牢拍的存储空间不完全符合 AWS S3 的标准，所以说 rclone 没办法很好地兼容。
|
||||
|
||||
好好好。支持，但是不完全支持。
|
||||
|
||||
万般无奈之下小氯开始寻找替代方案，在把又拍云的文档翻了个底朝天之后，小氯终于找到了这个东西：
|
||||
|
||||
{{< github repo="upyun/upx" >}}
|
||||
|
||||
这个东西不能用 Homebrew 安装（或许小氯可以自己维护一个？），同时小氯的系统里已经有一个叫 `upx` 的家伙了（一个压缩可执行文件的工具，可以把 C++ 编译出的 `./hello-world` 大小压缩一半~~并且使得其报错~~）。所以，我们采取一下自定义安装策略。
|
||||
|
||||
首先把东西下载下来：
|
||||
|
||||
```bash
|
||||
wget https://collection.b0.upaiyun.com/softwares/upx/upx_0.4.8_darwin_arm64.tar.gz
|
||||
```
|
||||
|
||||
然后解压缩（或者直接用命令行解压缩也行，看您方便），再移动到 PATH 里面：
|
||||
|
||||
```bash
|
||||
sudo mv /path/to/upx /usr/local/bin/upyun
|
||||
```
|
||||
|
||||
然后验证一下就可以了。
|
||||
|
||||
这个命令行工具不支持使用文件验证，所以我们把凭据写到环境变量里面就好。
|
||||
|
||||
```bash
|
||||
alias upyun="/usr/local/bin/upyun"
|
||||
upyun login {{_UPYUN_SERVICE_NAME}} {{_UPYUN_OPERATOR}} {{_UPYUN_SECRET}}
|
||||
```
|
||||
|
||||
然后上传完成退出就好了。
|
||||
|
||||
这个方法非常别扭，但是没办法，这是目前小氯找到的唯一一个能跑起来的方法了。
|
||||
|
||||
同样的，老友们可以[自取脚本](https://gist.viento.cc/chlorine/4f9d0a497ca647e5ab35154fb2408693)。
|
||||
|
||||
Shell Commands 真的是太强大了，小氯写了若干个脚本，几乎完全替代了 Image Converter、Git 等插件。如果再配合一下 Local REST API 和 Obsidian URI，大概可以把目前小氯的大部分插件都替代掉了。
|
||||
|
||||
## 后记
|
||||
|
||||
又清掉了一篇草稿，好耶 ～(∠・ω< )⌒☆
|
||||
289
content/posts/百草园/理想乡构筑手记/理想乡构筑手记（4）：新的域名及一些杂谈.md
Normal file
289
content/posts/百草园/理想乡构筑手记/理想乡构筑手记（4）：新的域名及一些杂谈.md
Normal file
|
|
@ -0,0 +1,289 @@
|
|||
---
|
||||
title: 理想乡构筑手记（4）：新的域名及一些杂谈
|
||||
date: 2025-02-22
|
||||
slug: hello-chlor-me
|
||||
featuredImage: https://img.viento.cc/cover/hello-chlor-me-cover.webp
|
||||
categories:
|
||||
- 百草园
|
||||
- 逍遥游
|
||||
tags:
|
||||
- 博客
|
||||
- 域名
|
||||
series: 理想乡构筑手记
|
||||
summary: 再水的话园子要发洪灾了……
|
||||
description: 本文介绍了作者更换博客域名为`chlor.me`的来龙去脉，并详细讨论了各种域名后缀（TLD）的类型、特点和适用场景。作者首先讲述了新域名的由来，认为`chlor.me`更简洁、更贴合其网络身份。随后，文章详细介绍了更换域名所需的操作，包括301重定向、搜索引擎更新、备案等。最后，文章重点讨论了各种域名后缀，包括gTLD（原始gTLD和新gTLD）、ccTLD（半通用ccTLD、一般开放ccTLD、限制性ccTLD等）以及其他特殊用途的TLD。作者对独立博客选择域名后缀给出了建议，强调「喜欢」是首要原则，但不推荐使用免费域名、低价域名、年抛域名和二级域名（少数特殊情况除外）。总的来说，作者认为除了少数域名外，各种TLD在SEO方面表现相近，选择域名后缀主要看个人喜好和网站定位。
|
||||
wikilinks: true
|
||||
---
|
||||
|
||||
诸位老友，晚上好。这里是 Chlorine。
|
||||
|
||||
是的，小氯在继续清自己的废稿（悲）。
|
||||
|
||||
## `chlor.me` 的来历
|
||||
|
||||
说是来历，其实也没什么太多好说的。
|
||||
|
||||
小氯的第一个域名购买自园子诞生的当天，服务商为 Dynadot。域名本身没什么特别出彩的地方，`yoghurtlee.com`，我过去的英语名字加上最为人熟知的 `.com`。当时的小氯还不叫小氯，或者用一句看起来高深莫测的话来说，还没有形成一个完整的互联网身份架构。
|
||||
|
||||
后来，由于各种各样的原因，小氯陆续买了一大堆域名，由于贫穷，其中最贵的也就是 `.me`。也想过买一下 `.dev` 和 `.cl`（这是智利的 ccTLD，和小氯的名字的一种最简写法一致），不过最后还是没下手。
|
||||
|
||||
随着时间的推移，小氯对这个域名开始不那么满意了。第一个太长，第二个和小氯（Chlorine）以及园子的名字都没什么联系。不过由于一直没找到合适的替代，而且这个域名的 SEO 也养了有一阵了，所以也就一直没换。
|
||||
|
||||
然而，在园子一周年这个很适合做 BREAKING CHANGE 的时间点，小氯还是按捺不住了。于是，小氯又开始趁着摸鱼时想域名。
|
||||
|
||||
好的 `.com` 基本没戏了，所幸我对 `.com` 也没什么执念，换一个 TLD 也不错。奈何由于 Chlorine 这个词实在是太常见了，因此几乎没有什么可用的后缀，而好的变体同样抢手。小氯挑来挑去，挑了一个 `chloryn.com`。当时感觉还不错，但是过不了几天看着就不是很好了。斟酌了一段时间，最后用了 `chlor.me`。
|
||||
|
||||
这个域名的含义很明显，`chlor` 就是 `chlorine` 的简写，对于比较熟悉英语的老友，即使是没有联想到，也至少是 `chloride`，也差不多。这个词根也有「绿色」的意思，例如 Chlorophyll（叶绿素）。`.me` 是黑山的 ccTLD，广泛用于个人网站，例如大佬 Anthony Fu 的博客就是 `antfu.me` 。而且，这个域名也非常简短，这是蛮不容易的。别的不说，<https://chlor.me> 看着比 <https://yoghurtlee.com> 干净多了，`hi[at]chlor.me` 也比 `me[at]yoghurtlee.com` 短很多。
|
||||
|
||||
其实当初小氯挑出的两个是 `chlori.me` 和 `chlor.dev`。两个域名都挺有特点的：`chlori.me` 会显得可爱一点（但是不多），而且接近 Chlorine 的原始拼写；而 `chlor.dev` 就是很简洁硬朗的技术风格，不过 `.dev` 是不能备案的（没错，`.me` 可以，也不知道是什么时候改的）。最后思来想去，反正 `chlor` 和 Chlorine 的联系已经够明显了，`chlorime` 也容易让人读错，那干脆就 `chlor.me` 好了。
|
||||
|
||||
由于 Spaceship 和 Porkbun 的 New Price 都不便宜，因此我就直接在套路云注册了，也方便备案。不过 `.me` 比 `.com` 的续费贵一些（大概贵了 30r），也算是可以接受吧。~~其实可以把域名转出去续费几年之后转回来，只要不被套路云的备案核查检测到即可。~~
|
||||
|
||||
目前来说，小氯对这个域名相当满意，未来很长一段时间应该不会再有更改了。不过很有趣的是，这么短的一个域名，却似乎没有被任何人注册——至少是使用过——我在 Google、Bing、DuckDuckGo、Baidu 没有找到任何记录，Web Archive 也没有。或许是因为想到用 Chlorine 这个词做 Nickname 的人实在不多吧——毕竟，这个词本身也似乎不太适合做 Nickname。
|
||||
|
||||
## 更换域名的工作
|
||||
|
||||
换个域名所需要的操作还挺多的，这里简单备忘一下吧。
|
||||
|
||||
### 301
|
||||
|
||||
这个自不必说。这里小氯提供两种方式：Cloudflare 的 301 和 Vercel 的。
|
||||
|
||||
#### Cloudflare
|
||||
|
||||
在 Cloudflare 中选中你需要的域名，点击边栏的规则 - 页面规则，添加一个这样的页面规则即可。
|
||||
|
||||
|
||||
|
||||
#### Vercel
|
||||
|
||||
把域名绑定到 Vercel，然后在重定向方式里面选择 301 即可。
|
||||
|
||||
### Google 和 Bing 的更改域名
|
||||
|
||||
这个事情挺难搞的。不是说操作，操作的话只需要登录 Google Search Console，按照[文档](https://support.google.com/webmasters/answer/9370220?hl=zh-Hans)的做就可以，Bing Webmaster Tools 也差不多。主要的问题是 SEO 的迁移很费时间，而且并不完全。
|
||||
|
||||
### Algolia Docsearch
|
||||
|
||||
给 Algolia 发个工单，再把爬虫配置的域名改了就可以了。
|
||||
|
||||
### 重新备案
|
||||
|
||||
如果您不打算备案，跳过这段即可。
|
||||
|
||||
我们需要再开一个 ICP 备案申请，网站名字可以和原本一样，这个不耽误事。公安备案的话，把原本信息的主域名 / 从域名改一下就好，交互式网站也不需要重新做安全评估。当然，各个地方管局的政策可能不一样，注意根据自己所在地区做评估。
|
||||
|
||||
### 更新加入的组织的域名
|
||||
|
||||
例如萌 ICP 和开往。这个一般不难。
|
||||
|
||||
### 更改各种社交网站的域名
|
||||
|
||||
废话。
|
||||
|
||||
### 通知链接你的网站和网页
|
||||
|
||||
这是件几乎不可能完全做到的事，大家各自尽力就好了，
|
||||
|
||||
## 关于各种域名后缀
|
||||
|
||||
开始之前我们有必要明确一个基本原则：**您喜欢是第一位**。如果一个域名您真的喜欢得不得了，那就别管小氯下面如何聒噪，买就好了。
|
||||
|
||||
我们首先科普一下，TLD 分几种。
|
||||
|
||||
TLD 的分类极其复杂，如果希望太长不看，那么大致可以分为通用顶级域（gTLD），国家和地区顶级域（ccTLD）和其他。具体说，可以分为（原始）通用顶级域（一般就简称为 gTLD）、（开放的）新通用顶级域（New gTLD）、赞助顶级域（sTLD）、国家和地区顶级域（ccTLD）、国际化国家和地区顶级域（IDN ccTLD）、品牌顶级域（Brand TLD）、互联网基础设施顶级域（ITLD）、测试顶级域（Test TLD）等。
|
||||
|
||||
### gTLD
|
||||
|
||||
gTLD 从出现的时间来说，大致可以分为原始 TLD 和新 TLD（New gTLD）；而从注册限制来说，大致可以分为开放注册和限制注册（虽说当然没有不允许注册的 gTLD，但是有几乎不允许的）。我们使用第一个分类方法吧。
|
||||
|
||||
#### 原始 TLD
|
||||
|
||||
这些域名都是互联网的老古董了，从域名这玩意出现开始就有了。最初它们都有限制，不过现在很多都开放了。
|
||||
|
||||
| TLD | 原始用途 | 现状 |
|
||||
| ------ | ----------------------- | ---------------- |
|
||||
| `.com` | Commercial，商业机构 | 几乎无任何限制，最通行的 TLD |
|
||||
| `.org` | Organization，非营利组织 | 几乎无任何限制 |
|
||||
| `.net` | Network，网络服务提供商 | 几乎无任何限制 |
|
||||
| `.int` | International，国际条约组织 | 严格限制 |
|
||||
| `.edu` | Education，（美国认可的）高等教育机构 | 严格限制 |
|
||||
| `.gov` | Government，（美国）联邦政府 | 严格限制 |
|
||||
| `.mil` | Military，（美国）军队 | 严格限制 |
|
||||
|
||||
这里我们能注册的就是前三个，这也是非常受欢迎的三个博客 TLD。如果您能注册到后四个，那您是大哥。
|
||||
|
||||
原始 gTLD 三剑客的最大优点大概就是经典，认可度极高，而且不算贵，目前市价也就是不到一百 CNY 一年。
|
||||
|
||||
#### 开放性的 New gTLD
|
||||
|
||||
这事说来话长。在 2013 年，ICANN 搞了个新通用顶级域名 (New gTLD) 计划，希望扩展一下 TLD 的疆域，其中对所有人开放注册的那部分就是我这里说的「开放性的 New gTLD」。
|
||||
|
||||
开放性的 New gTLD 的家族极其庞大，如果我们在这里一个一个介绍，那么水个几十万字肯定是没问题的。所以我们只举少数几个例子——（吸气）
|
||||
|
||||
`.click`, `.cyou`, `.icu`, `.link`, `.online`, `.one`, `.work`, `.site`, `.space`, `.top`, `.website`, `.xyz`, `.accountant`, `.app`, `.art`, `.baby`, `.beauty`, `.blog`, `.book`, `.cafe`, `.club`, `.design`, `.dev`, `.doctor`, `.eco`, `.fashion`, `.film`, `.finance`, `.fit`, `.game`, `.green`, `.health`, `.law`, `.live`, `.makeup`, `.media`, `.moe`, `.movie`, `.music`, `.news`, `.page`, `.photography`, `.restaurant`, `.shop`, `.show`, `.ski`, `.social`, `.sport`, `.store`, `.tech`, `.travel`, `.video`, `.london`, `.nyc`, `.tokyo` , `.vip`, `.xin` ……
|
||||
|
||||
这些 TLD 的价格不是很统一，从便宜的 `.top`、`.vip`、`.work` 到贵得要命的选择一应俱全。不过和原始 gTLD 三剑客比，它们的价格一般都偏高。
|
||||
|
||||
我们举几个（我周围的小样本的）博客里面常见的吧：
|
||||
|
||||
##### `.top`
|
||||
|
||||
没什么特别的寓意，顶级的、顶上的。
|
||||
|
||||
##### `.xyz`
|
||||
|
||||
同样寓意不明，所以使用也比较广泛。最著名的应该是 Alphabet（Google 的母公司）的 `abc.xyz`（很合理啊）。
|
||||
|
||||
##### `.vip`
|
||||
|
||||
寓意明显。之所以传播比较广泛，主要是因为便宜。
|
||||
|
||||
##### `.dev`
|
||||
|
||||
开发，技术范的后缀。
|
||||
|
||||
##### `.icu`
|
||||
|
||||
其现在的含义和医院那个 Intensive Care Unit 关系不大，主要是 I See You 的意思。
|
||||
|
||||
##### `.moe`
|
||||
|
||||
「萌」的英语化，蛮可爱的域名后缀。
|
||||
|
||||
##### `.space`
|
||||
|
||||
个人空间？
|
||||
|
||||
##### `.blog`
|
||||
|
||||
看着是给博客设计的，实际上用的人不太多。
|
||||
|
||||
#### 赞助顶级域（sTLD）
|
||||
|
||||
也就是受到特定组织资助的 TLD，一般注册审核都比较严格，比如用于加泰罗尼亚文化的 `.cat`（没错，这个域名的意思真的不是「猫」）。
|
||||
|
||||
严格来说，此处说的是赞助性新顶级域，因为 `.edu` 这些也可以算是 sTLD。
|
||||
|
||||
#### 品牌顶级域（Brand TLD）
|
||||
|
||||
顾名思义，开放给特定品牌的 TLD，咱们不能注册。比如 `.google` 和 `.apple`。
|
||||
|
||||
### 国家和地区顶级域（ccTLD）
|
||||
|
||||
要来力（喜）
|
||||
|
||||
每个国家都有自己的两字母顶级域，根据 ISO 3166-1 国家和地区代码标准分配。此外一些地区和非国家实体也有，如香港的 `.hk` 和欧盟的 `.eu`。
|
||||
|
||||
#### 半通用 ccTLD
|
||||
|
||||
这些 ccTLD 已经极度普遍，以至于脱离了其原始的国家和地区含义，而被赋予了新的意义。我们举几个例子。
|
||||
|
||||
##### `.me`
|
||||
|
||||
来自黑山。由于和 `.me` 高度重合，因此广泛用于个人网站，例如我很喜欢举的例子，Anthony Fu 大佬的域名 `antfu.me`。园子目前的主域名也是 `.me`。
|
||||
|
||||
##### `.tv`
|
||||
|
||||
来自图瓦卢。没什么可说的，电视，因此用于电视、视频、流媒体，如 Bilibili 的短链 `b23.tv`，Bangumi 的 `bangumi.tv`。
|
||||
|
||||
##### `.fm`
|
||||
|
||||
来自密克罗尼西亚联邦。FM 和一种有点古老的事物——调频广播（Frequency Modulation）的简写一样，因此可以用于广播电台、音乐平台、播客平台等。
|
||||
|
||||
##### `.ai`
|
||||
|
||||
来自安圭拉。也没什么可说的，人工智能。比如 Anthropic 的 `claude.ai`，马牢板的 `x.ai` 等。这个 TLD 奇贵，导致安圭拉很大一部分收入都是卖域名得到的。
|
||||
|
||||
##### `.io`
|
||||
|
||||
来自英属印度洋领地（BIOT）。[^1]由于和输入 / 输出（Input / Output）以及互联网组织（Internet Organization）简写一致，在技术领域非常受欢迎。当然，价格也比较贵。
|
||||
|
||||
##### `.cc`
|
||||
|
||||
来自科科斯（基林）群岛。由于其可解读性过高，已经成为了类似 `.com` 的泛用域名。
|
||||
|
||||
##### `.co`
|
||||
|
||||
来自哥伦比亚。常被视为 `.com` 的替代品，用于各类公司和商业网站。
|
||||
|
||||
#### 一般的开放 ccTLD
|
||||
|
||||
这些 ccTLD 不像上面的 TLD 那么通行，但是注册的限制较少。例如 `.fi`（芬兰），`.is`（冰岛）等。
|
||||
|
||||
#### 限制性 ccTLD
|
||||
|
||||
这些 ccTLD 的注册有一定限制，如 `.cn` 必须要具有中国大陆身份并实名认证，`.jp` 必须要在日本拥有物理地址。其中也有一些限制比较严格的，例如梵蒂冈的 ccTLD `.va` 只被允许用于与圣座有关的网站，不对外开放注册。
|
||||
|
||||
#### 国际化国家和地区顶级域（IDN ccTLD）
|
||||
|
||||
简单来说就是本地化的国家顶级域，例如 `.中国`，`.рф`，`.مصر`。实际操作的时候一般使用 Punycode 表示。
|
||||
|
||||
### 其他
|
||||
|
||||
下面的 TLD 大家肯定都是注册不了的，看个乐子就行。
|
||||
|
||||
#### 互联网基础设施顶级域
|
||||
|
||||
这个群体目前只有一个成员，就是 `.arpa`。
|
||||
|
||||
ARPA 是「地址和路由参数区域」的简写，其专门用于互联网的基础设施，如 `in-addr.arpa`（反向 DNS 至 IPv4）、`ip6.arpa`（反向 DNS 至 IPv6）等。其注册由 IANA 严格控制，不对外开放。
|
||||
|
||||
……当然，这也不是说 `.arpa` 就一定是基础设施，也有少数显眼包拿这个域名整活，比如有一个跑在 `.arpa` 的 GoToSocial 实例——<https://1.6.0.0.8.0.0.b.e.d.0.a.2.ip6.arpa/>。小氯对此不评价。
|
||||
|
||||
#### 测试顶级域（tTLD）
|
||||
|
||||
比如 `.localhost`，`.invalid`，`.test` 等。这些 TLD 只在测试环境使用，不会被解析到公共 DNS。
|
||||
|
||||
#### 本地网络顶级域
|
||||
|
||||
即 `.local`，主要用于多播 DNS（mDNS）。它在 RFC 6762 中被指定为用于本地网络名称解析的特殊域名。
|
||||
|
||||
#### 无效顶级域
|
||||
|
||||
> 还有这玩意？
|
||||
|
||||
理论上来说，有。例如，你可以通过修改 host 文件实现本地的任意的 TLD，例如 `.chlorinechan` 也是可以的。
|
||||
|
||||
## 独立博客用什么域名后缀？
|
||||
|
||||
如前文所说挺久之前，小氯曾经专门写过[[独立博客选什么域名后缀？|一篇文章]]将这个问题，虽说以小氯现在的眼光看那是篇水文，但是其中一些观点还是有用的。
|
||||
|
||||
这里小氯也更新一下自己的观点吧。总体而言就是这么几个原则：
|
||||
|
||||
- 非常不推荐使用免费域名
|
||||
- 不推荐使用低价域名（如 `.top`，`.vip`，`.ru`，`.de`，`.work`，数字 `.xyz` 等）
|
||||
- 不推荐使用年抛域名
|
||||
- 除了少数特殊存在外，不推荐使用二级域名
|
||||
|
||||
### 非常不推荐使用免费域名
|
||||
|
||||
免费的域名大概有 `.tk`（托克劳的 ccTLD），`.cf`（中非的 ccTLD），`.ml`（马里的 ccTLD），`.ga`（加蓬的 ccTLD）和 `.gq`（赤道几内亚的 ccTLD）几个，由大名鼎鼎的 Freenom 运营。不过现在 Freenom 停止免费域名注册了，不知道以后会怎么样。
|
||||
|
||||
免费的东西，世界各地的人们肯定都喜欢薅，就拿 `.tk` 来说，根据 [Domain Name Stat](https://domainnamestat.com/statistics/tld/others) 的数据，`.tk` 在所有 TLD 中的注册数量达到了惊人的 27,547,091 个，仅次于 `.com` 和 `.cn`。
|
||||
|
||||
当然，咱们良家少年 / 少女喜欢，那些不怀好意的人也喜欢。`.tk` 被大量用于钓鱼、诈骗等非法网站，跟 `.tk` 的名声比，缅北都算是童叟无欺的。而且，有句话说得好，免费的才是最贵的。谁知道哪一天，免费的域名就要收费了，或者出了什么奇奇怪怪的政策。
|
||||
|
||||
### 不推荐使用低价域名
|
||||
|
||||
这个理由嘛，和前面基本一样。毕竟，不用花钱的域名和一年 1 CNY 的域名其实也差不太多。嗯……尤其是 `.top`，虽然说小氯的老友们用 `.top` 的还蛮多的。VX 已经到了看见 `.top ` 就想拦截的程度了。就连 `.top ` 的注册局（江苏邦宁科技有限公司）都被 ICANN 警告了，您想想这个 TLD 的名声能好到哪去呢。
|
||||
|
||||
### 不推荐使用年抛域名
|
||||
|
||||
年抛域名是对一类首年价格低廉但是续费价格比较高昂的域名的统称，例如普通的 `.xyz`、`.shop`、`.love` 等（很大一部分新 TLD 都属于这个范畴，只不过高昂的程度不同）。
|
||||
|
||||
年抛域名的名声也不太好，原因很明显：哪些人会隔一段时间就换个域名呢？~~那当然是某只元素娘啦~~自然是那些干完坏事就换个壳子重生的非法网站。
|
||||
|
||||
### 一般不推荐使用二级域名
|
||||
|
||||
这个事情也比较好理解，连个自己的顶级域名都不想买，那很难让人相信你的专业性（虽然这个联想有点无厘头）。而且许多二级域名是免费的，例如 `.us.kg` ——嗯，自然也是被薅秃了。不过有一些二级域名除外，比如 `.github.io`（GitHub Pages 的二级域名），以及有特殊用途的 `.js.org`，`.com.cn` ——不过这些二级域名也很少用在博客上就是了。
|
||||
|
||||
……那么 `.vercel.app` 和 `.netlify.app` 呢？
|
||||
|
||||
说实话，咱能别用这个，还是别用了吧……
|
||||
|
||||
---
|
||||
|
||||
余下的域名，小氯的观点是：**喜欢哪个用哪个**。因为除开上面提到的这些牛鬼蛇神，现在的各种 TLD 在 SEO 方面的表现其实差不多，主要看的还是你的网站和内容。只是说，`.com` 最为大众所熟知而已，如果你的网站是完全大众导向的（并且你假定你的目标读者中大部分人都是互联网文盲），那么 `.com` 才会占有比较大的优势。
|
||||
|
||||
[^1]: 2024 年 10 月 3 日，英国宣布将英属印度洋领地主权将移交给毛里求斯。按照 ICANN 的规定，这意味着 `.io` 域名将会在不久的未来消失。
|
||||
Loading…
Add table
Add a link
Reference in a new issue