陽升之谷

在fnOS上通过Docker代理系统自带qBittorrent的WebUI（c3556e4）

Mon, 26 Jan 2026 01:49:53 GMT

开年第一篇文章，新年快乐～

前言

PeerBanHelper，通过WebUI与qBittorrent通讯。通过系统自带的资源监控不难注意到，飞牛OS系统自带的下载器后后端由qBittorrent和Aria2支撑，进程名称为trim-qbittorrent和trim-aria2c。但是飞牛OS没有提供系统自带qBittorrent的原生WebUI接口，xxxuuu/fnos-qb-proxy提供了一个Go语言代理WebUI的客户端，但是没有Docker部署。

让我这个Docker小白来试试。

本文其实就是Kainichy/fnos-qb-proxy/Docker-Install.md加几句话哈，水一篇文章美滋滋。已经PR给xxxuuu/fnos-qb-proxy了，应该不久就能在那里看见。

获取所需文件

到xxxuuu/fnos-qb-proxy: Releases获取fnos-qb-proxy_linux-amd64，到Kainichy/fnos-qb-proxy获取相应的Dockerfile和docker-compose.yml。

然后进行一些配置，如下。配置过程中将多次用到查找与替换的功能，建议使用支持相应功能的编辑器而非手动替换，以免出错。此外，除非您清楚地知道您在做什么，否则不建议修改其他位置的内容。

修改Dockerfile

请将如下字段中的fnos-qb-proxy_linux-amd64改为您下载的可执行文件的文件名：

COPY fnos-qb-proxy_linux-amd64 /usr/local/bin/fnos-qb-proxy

修改docker-compose.yml

如果您需要自定义代理容器在宿主机上暴露的端口号（效果相当于上文中通过--port参数传入的端口号），请修改如下字段中引号左边的7777为您所需要的端口号：

    ports:
      - "7777:8086"

如果您需要自定义qBittorrent WebUI的访问密码（效果相当于上文中通过-p或--password参数传入的密码），请修改如下字段中的fnosnb为您所需要的密码，注意，此处请勿将密码修改为非ASCII字符，否则qBittorrent的WebUI将错误转译密码导致登录失败：

    environment:
      - PASSWORD=fnosnb

⚠️ 只要您的用户名不是Kainichy，您必须将以下内容中的Kainichy替换为您的用户名：

    volumes:
      - /home/Kainichy/qbt.sock:/home/Kainichy/qbt.sock

然后开始构建并启动，如下。

构建镜像，启动容器

有两种方法完成这件事。

SSH

SSH访问您的主机，然后在含有Dockerfile、docker-compose.yml以及可执行文件的目录下执行docker compose up -d。

fnOS WebUI / 飞牛OS网页版

创建一个目录，并将Dockerfile以及可执行文件通过您喜爱的方式上传到您的飞牛，注意此时不要上传docker-compose.yml，否则可能会出现错误。并且请注意，目录需要上传到一个您接下来操作的账户能够访问的目录下。
登录您的飞牛OS网页版，进入Docker应用，在边栏中选择Compose，选择新建项目
填写项目名称，选择第一步中上传的文件夹，此时在对话框中上传docker-compose.yml，或者复制并粘贴docker-compose.yml的全部内容，注意不要打乱格式。
选择确定

此时您的容器应该正常运行，并且您将会在7777或您指定的端口号上访问飞牛自带的trim-qbittorrent的WebUI。

确保下载中心服务在Docker服务之前启动

我们注意到在fnOS中，Docker服务可能在下载中心启动之前完成启动，导致~/qbt.sock被Docker意外占用，进而导致下载中心携带的的qBittorrent进程无法正常启动。因此，我们需要确保下载中心服务在Docker服务之前启动，具体方法为如下。

在终端/SSH中运行sudo systemctl edit docker.service，默认情况下，这将打开一个由Nano编辑器承载的/etc/systemd/system/docker.service.d/override.conf编辑窗口，此时在

### Anything between here and the comment below will become the new contents of the file

（从1开始数，通常位于第2行）

以及

### Lines below this comment will be discarded

（通常位于第6行）

这两行注释（通常显示为蓝色）之间添加如下内容：

[Unit]
After=dlcenter.service

确保前几行看起来像是：

### Editing /etc/systemd/system/docker.service.d/override.conf
### Anything between here and the comment below will become the new contents of the file

[Unit]
After=dlcenter.service

### Lines below this comment will be discarded

### /etc/systemd/system/docker.service

这将使dlcenter.service（fnOS的下载中心服务，亦负责启动自带的qBittorrent）在docker.service之前运行。

最后，运行sudo systemctl daemon-reload来使得这些修改生效。

撒花🎉。如果是像我一样要通过Docker运行并接入PeerBanHelper，还可以通过docker inspect {Container}来获取Docker提供的容器DNS名称，解决容器间访问时的IP变换问题。

更好的BitTorrent网络环境，这何尝不是一种TECH OTAKUS SAVE THE WORLD呢。

电子邮件的退信 / Apple Support，很棒——如果你只问电池健康

Wed, 27 Aug 2025 22:41:00 GMT

叠个薄薄的甲。熟悉我的读者（虽然可能不多）应该都知道，我是老「果吹」了。我不是想抱怨，只是想说说这次和Apple的对话。

让我们从这个折磨我的问题开始。

“退回给发件人的未送达邮件”

要讲清楚这个问题，我们就从电子邮件的传递开始吧。

电子邮件的「发」与「收」

一封电子邮件从发件人按下「发送」，到出现在收件人的收件箱中，从不只是「发送」和「接收」那么简单。但，让我们把这个并不简单地流程，简单地讲一讲。

发件人在发件客户端按下「发送」时，信件先被交给了发信服务器。对于使用不同邮件服务的用户，他们的发信服务器也会不一样。接着，这封信按照约定的协议，投递进收件人的收信服务器。最后，收件人打开自己的邮箱客户端时，客户端从服务器取出信件，把它呈现给用户。

这一来一往，或许只花了几秒钟。可这封信背后，其实经过了两个客户端、两个服务器的接力合作。

比如说，我在Mac上用Mail.app通过iCloud Mail，给一位使用Outlook邮件服务和客户端的Android用户发邮件。邮件会先从我的Mac送到iCloud的发信服务器，再投递到Outlook的收信服务器，最后被对方的Outlook客户端拉取下来。就这样，一封邮件完成了它的旅程。

电子邮件的「退回」

就像现实中的信件有时会被退回，电子邮件同样有各种各样的退信情形。我们也可以简单地分为「发件服务器退信」和「收件服务器退信」，并简要地举几个例子。

发件服务器退信：

发件频率过高
邮件体积过大
邮件被识别为垃圾邮件
发件人标识配置错误或鉴权不通过
收件服务器不存在或不可及：例如，向@blackhole.kyki.moe发送邮件

收件服务器退信：

收件人邮箱已满
发信服务器身份验证失败
邮件被拦截列表或安全策略拒收
查无此人：例如向alice@kyki.moe发送邮件

两个属于AS714 APPLE-ENGINEERING的、遭拒的IP地址

如果去查询一下57.103.66.120和57.103.64.119这两个IP地址，很容易就能得知，它们目前的归属都是AS714 APPLE-ENGINEERING。

你可能已经猜到了，这两个IP地址肯定跟iCloud Mail有关。是的，它们是iCloud的众多发信服务器IP之二。但单独拿出来讲，它们有什么特别的呢？ 这两个IP在向Microsoft的收信服务器传输信件时，会遭到拒绝。

于是发件人会在几秒到几分钟后，在自己的收件箱里看到一封名为「Undelivered Mail Returned to Sender」的退信报告，说hotmail-com.olc.protection.outlook.com回复了错误代码550 5.7.1，并且反馈发件服务器在相应的拦截列表（S3150）上。

如果这时负责发送我邮件的发信服务器是我自建的，例如我在云服务厂商处租赁了一台（虚拟）服务器，并在该服务器上运行着我的发信服务，那我便可以轻松地找到云服务厂商，要求更换一个新的IP地址，或者要求云服务厂商联系Microsoft协商将该IP地址从拦截名单上移除，但……我的发信服务器是iCloud Mail的啊，所以……

好戏开始，我算是踢到钢板啦！

解决问题的尝试，以及本文的正题——与Apple支持的沟通尝试

“如果你仍需要协助”

在与 iCloud 邮件有关的邮件管理员信息 - 官方 Apple 支持 (中国)这篇Apple支持主题中，“如果你仍需要协助”章节，我们会看到这样一段描述：

如果你已遵循我们的最佳做法，并已查阅邮件日志来了解更多信息，但仍无法诊断和解决传送问题，那么你可以发送电子邮件到 icloudadmin@apple.com 并提供以下所有信息，以便联系我们的邮件管理员团队

这个地址并不是为iCloud Mail的用户准备的，而是为那些试图向iCloud Mail用户发送邮件但遇到障碍的邮件管理员准备的，但按常理来讲，既然声明的抬头是「我们的邮件管理员团队」，那就……应该不会只管收信，不管发信吧？所以我还是向icloudadmin@apple.com发了一封邮件，反馈部分发信服务器IP被Outlook收信服务器拦截的问题，结果……石沉大海。

数日后，我又看到同一章节的末尾还有一句

如果你不是系统管理员，并且需要 iCloud 邮件方面的协助，请联系 Apple 支持。

于是便有了和Apple支持的沟通尝试。

案例0165：邮件发送失败

说实话，这并不是我第一次和Apple支持沟通。反而，事实上，作为一个数年的Apple老用户，我联系Apple支持的次数并不少。或许是因为自己的技术不断精进，越到后来，越感觉和Apple支持沟通的过程中，反而自己更像是那个专业人士。

所以我已经很久很久没有联系过Apple支持，说真的，每次一想到“明知他们完全帮助不到我，又抱着一丝丝希望联系上他们，最后又失望而归”的老生常谈……我下一次还联系Apple支持的可能性就又下降一点。每一次都保不齐是我最后一次联系Apple支持的尝试。只是这一次我尤其火大。

按照惯例，能不打电话的时候，绝不打电话，我先是选择线上对谈，然后得知需要打电话，把案例提升给Senior Advisor（高级顾问）……好吧，习惯了，虽然在我的感官上他们的Senior Advisor也没有“高级”到哪里去。

电话接通后，高级顾问简要问了几个问题，然后打开了我的屏幕共享，然后不出我所料，又是那两个Apple支持的万能雷区——预览版软件和虚拟专用网络，被拿出来作为拒绝将这个案例发送给Engineering Team（工程师团队）的理由。

这并非我第一次因为类似的原因被Apple支持拒绝提供帮助，我也清楚在Apple Beta Software Agreement也写道：

During Your participation in the Beta Program or in a particular seed, Apple is not obligated to provide You with any maintenance, technical or other support for the Apple Software.

但是需要注意的是，结合全文，我本人（或许是水平有限）也完全不能得出这一段“No Support and Maintenance”条款适用于「并非预览版的服务」。也就是说，我不认为这个协议摘掉了Apple为我订阅的服务提供支持的义务。

之前一些界限比较模糊，不太好确定是软件还是服务的问题，我一次次被拒绝，基本上是合理的，我也从来没有微辞。

这一次的体验实在是过于糟糕，过于不合乎逻辑和理性。我并不想，也没有必要，向一个顾问解释电子邮件系统究竟是怎么运作的。但我已经强调我脱离预览版软件环境（例如，使用iCloud.com网页版）之后仍然有这样的问题，我已经尽全力试图让其理解，为什么这不是一个「软件」问题，而是一个服务器端的问题。我甚至说，我现在并不使用任何Apple设备和软件，这样就没有任何预览版软件了，我在一台Windows 11 PC上使用Google Chrome访问iCloud.com网页版发送邮件，遇到这样的问题了，现在可以为我提供技术支持，把案例提交给Engineering Team了吗？

还是遭到拒绝。

我被拒绝这么多次，第一次这么恼火。这就像是我去一家精酿酒馆想买一些酒，有时会遇到打酒的机器泵出液体不畅的问题，我和店员说“是不是向负责人反馈一下”，然后店员以我来买酒时开的汽车经过改装为由拒绝听取我的意见……

Excuse me???

我理解如果鸡毛蒜皮的小问题，甚至是用户使用不当造成的错误，都报告到工程师团队，必然引起不必要的麻烦。

但能不能不要一看到用户在使用预览版软件，就像收到惊吓的乌龟缩在壳里一样只会重复念叨让用户刷机？

我喜欢Apple的产品是真的，我讨厌Apple支持的水平和态度也是真的。

祝大家都用得开心，用得稳定，永远不需要联系Apple支持那是最好。

如果遇到了Apple支持不能解决的问题和糟心事……这里我给自己打一个小广告，欢迎来知乎找我付费咨询～

家庭影院杂谈和小明V1 Ultra使用体验

Wed, 05 Mar 2025 12:59:16 GMT

如果你正在陽升之谷阅读本文，文中所有商品链接均已去除推广标记，如有需要查看请放心点击。

梦开始的配置

从最开始的一套雏形到今天，我的家庭影院总算是让我完整地规划好了。让我来简单地聊聊一些心得和体验。流水账式写法致歉。

我最开始的配置如下：

Redmi投影仪 Pro，二手，2024年中入手价约¥850
Apple TV 4K (3rd generation)，64GB Wi-Fi版，原销售地区美国，全新，2024年中入手价约¥950
Apple HomePod (1st generation)，国行特殊SKU，二手，2021年底入手价约¥1200

我很难想象当时的我脑子抽什么风，什么都没调研无脑选了粗粮家的东西~~（难道是爱？）~~。促使我真正开始研究投影仪各项参数的因素是Redmi投影仪 Pro非常蛋疼的1080P分辨率，以及只有30Hz的刷新率。直至我打算换机器的时候我都一直还没有注意到投影仪还有亮度这个重要参数。开始在网上真正开始找一台优秀的千元投影仪的时候，我才在人们的讨论中幡然醒悟——原来我之前白天拉窗帘也看不清楚的投影画面并不是什么特别正常的现象，150ANSI流明简直是低了又低。我是笨蛋。

这么暗，换个投影仪罢（恼）

看看LCD技术

看到非常高性价比的两台机器是哈趣K1 Pro和小明Q2 Pro。截至发稿这两台机器在我看来仍然非常有竞争里，在一个¥1000以下价位里。所以我在这里稍微聊一聊我光靠纸面参数得到的见解。

亮度方面，哈趣K1 Pro在标准模式下 60寸投影画面实测亮度为330.88lm左右（来源：知乎 @投影卡卡），小明Q2 Pro 100寸投影画面实测亮度为241.37lm左右（来源：知乎 @投影卡卡）。但这两个数据并不公平，因为投影画面的大小并不一样。100"对角线，16:9的画面大小约2.7429m²；而60"对角线，16:9的画面大小约为0.9768m²。所以把哈趣K1 Pro的作者误差值去掉，再乘以$2.7429/0.9768=2.8080$，再把作者误差加回去，我们可以得到$(330.88-50)*2.8080+50=838.71104$。宇宙安全声明：我是纯纯半桶水晃荡晃荡，这一段里的算法找ChatGPT聊出来的，如有误还请纠正～

其他参数我直接列个表格，如下。其他参数基本一样的，不表。

	哈趣K1 Pro	小明Q2 Pro
USB	未标注版本号	USB3.0
以太网	一个RJ45，速率未知	❌
Dolby Atmos	未标注	可解码可播放
扬声器	2*5W	2*3W
OS	当贝OS	FengOS
MEMC	❌	✅
原生服务接入	腾讯START云游戏	小米米家

关于FengOS的一些体验我会在下面有关小明V1 Ultra的内容里聊到。别的不表了，因为我是云用户（不是）。

又看了看DLP技术，下单了

最后因为市场原因两台都没买。于是想着体验一下DLP技术好了，去海鲜市场淘了一个坚果J6s，战争成色，2025年初入手价约¥450。遇到了好多不满，如下。

战争成色让我不爽的：

DMD上微镜坏了俩。边缘两个白点，不过不是显示区域内，这点问题不大。
棱镜烧黄了一块。大概半个显示区域全是黄澄澄的。

机器本身让我不爽的：

完全不支持HDMI CEC。每次开机都得拿两个遥控器，关机也是。
色彩管理非常非常差。尤其红色，Apple Music图标的颜色看起来像纪梵希的小羊皮306（宇宙安全声明：我是不懂美妆的技术宅，现场去橙色购物软件搜了一个很相似的颜色而已）。

DLP技术让我不爽的：

彩虹纹。肉眼几乎不可见，但需要扫码或者屏摄分享时影响很大。
散斑。稍微近一点很容易看到。周末跑到极米家看了一下也很明显……有种4K抖成1080P的美，没错是高抖低。

LCD永不为奴？小明V1 Ultra主观体验报告

截至发稿，最后我的做法是加预算上了小明V1 Ultra。另外还买了又一个HomePod，组成立体声，所以配置变成了这样：

小明V1 Ultra，全新，2025年初入手价约¥1800
Apple TV 4K (3rd generation)，还是那台～
Apple HomePod (1st generation)，原来那台，以及另一台：国行，二手，2025年初入手价约¥950

顺便提一嘴，所有国产投影仪厂商似乎对于产品命名这一块都有点让人摸不着头脑。小明「V1」的迭代产品叫New V1，那再迭代一次呢？「New New V1」吗？不仅小明，包括哈趣在内的一众厂商都喜欢New来New去的，让我想起了Linus（LTT那位）的New New Vault了。嗨，这我没意见，整活而已，而且内部NAS他想怎么命名也不至于混淆它的观众。问题是他们的旗舰店里还有一款小明V1，他们的店铺主页上打着「新品」的徽记。结果点开是「V1」而不是「New V1」。这边私以为还是把这个迭代产品叫做「V2」甚至是「V1（第二代）」比较合适呢。下面来从几个方面聊聊这台机器，从一个个人用户的视角，以及大家都聊过的东西我就不再聊了，接下来的我希望给到我的读者一些不一样的内容。

音响

即使是手持HomePods Stereo的我，拿到这台机器的时候也被它的音箱震撼到了。或许是太久没见过一个优秀的内置音响？并不是高音或者低音有多么强悍，也不是人声解析力有多高，2*6W的规格，没标大小的音腔，能给到的也就是这么点了。单论这几个项目肯定是连单个的HomePod都打不过的。真正震撼到我的是它的声场。真的是相当相当开阔了，比放在床头的HomePod厉害不少。听的是Severance的Main Titles（顺便安利一下Apple TV+原创剧集《人生切割术》Severance，截至发稿，第二季正在连载）。不过我在想把HomePod顶在头顶上是不是也会有这么好的效果🤔。

MEMC

没用过MEMC的可能没感觉，这属于用过了就回不去的技术。我个人更喜欢看起来fps更高的画面，即使MEMC的加入导致一些场合可能不那么符合原著，我仍然非常喜欢这些画面。

700CVIA亮度

是的，这个亮度甚至被他们自家的新机New V1（现在知道上面为啥要提这个命名了吧）吊打。New V1的亮度是950CVIA了。不过似乎可以理解。像素多了之后透光性能当然地会下降，以及新设备估计也有光源上的新突破。但是700CVIA也完全够我在夜晚或者是白天的窗帘背后看内容了。观看SDR内容，我并不觉得有什么大问题。

自带云台

虽然只有一个范围为5～15°的俯仰轴，但是对于我来说还是完全足够了。前面说过我的安置位置要求我的投影仪必须倾斜放置，但是这个单轴云台又弥补了这一点。不过市面上大部分有云台的投影仪应该都是单轴的？航向轴基本上都是靠直接转动底座完成的了。横滚轴的话……真的要调投影仪的横滚轴吗？

吵死了，而且很费电

真的是很吵。官宣噪音小于30dB，我没有分贝仪，不敢说这个数值对不对，但是真的挺吵的。所有HomePods Stereo用户建议把音量从静音向上按3下。

整机功耗更是来到了惊人的120W左右，这还是我音响完全没有工作的情况下。

不支持HDMI ARC/eARC，CEC支持不完善

是的，Apple TV+HomePod还想再加一个PlayStation然后爽用HomePod打游戏的用户请慎买。

是的，CEC只能电视控盒子，反过来不行。

服务很好

我在峰米服务微信公众号提了一下这个CEC单向的问题……没想到还有电话跟进。虽然那个给我回电的客服啥也不懂，但是我大概听出来了意思就是不打算适配😅。

FengOS

出厂系统版本号我忘了😅，不过我也用了一段时间的出厂版本，然后才升级到最新版本的。变化主要有以下几点：

FengOS自己的桌面没了，直接变成银河奇异果。这一点我还挺喜欢的。作为一个投影仪本体不联网的外接播放用户，比起之前FengOS断网界面的亮色背景，银河奇异果断网界面的深色背景让我感觉更舒服。
宣传页吹的的「AIPQ画质增强」删掉了。感知不强……？这个功能挺鸡肋的，我的肉眼看不出开和不开的区别。我猜无非是自动的亮度、对比度、饱和度、锐化调节。甚至删掉之前除了对比一下效果我根本就没开这功能。
「蓝牙音箱模式」从实验室功能变成了正式功能。
启动速度有了比较显著的提升。之前的启动是：风扇开转 - FengOS启动画面 - HDMI连接中。现在是：风扇开转 - HDMI连接中。而且这不是仅仅删了一屏而时间没变，启动时间确实缩短了。
新增连接峰米小程序快捷入口。

以及一些我认为可圈可点的地方有：

墙面颜色自适应。如果家里的墙颜色并不是纯白色，甚至如果家里的墙是白色，但是白得不够标准，这个功能还是能够体现出一些区别的。经过Apple TV的色彩平衡和这个墙面颜色自适应修正之后纯粹对比iPhone的屏幕，我认为投影画面的颜色准确度可以说相当高了。
米家/小明同学（小爱同学）原生接入。小明的生产厂商峰米科技是光峰科技和小米联合投资的子公司，于是理所当然地有了接入米家生态的能力。原来的Redmi上面有一个我用着非常舒服的功能就是米家原生接入。在我看剧的时候告诉我“电饭煲烹饪完成”确实是我觉得很有用的功能，虽然这个功能目前由我的Apple Watch负责，我仍然认为原生的米家接入非常适合小米生态用户。而且小明系列产品，以及峰米系列产品，其性价比在我看来确实高过小米的自有品牌小米和Redmi。

我确实不理解那些把自己电视上的语音助手接入深度求索大模型当作卖点的厂商到底在想什么。所以呢？我可以方便地在电视上用语音助手和大模型沟通？如果接入的是别的模型，可能还有读屏之类的功能值得使用，但是深度求索-V3和深度求索-R1这两个模型根本就没有多模态支持……看起来完全就是蹭热度的行为了吧。

FengOS出彩的地方其实不多，但没有广告，没有杂七杂八没用的功能，我认为这才是一个电视OS该有的样子。

LCD永不为奴！

这台投影仪确实非常特别，作为我在购物平台上看到的唯一一台LCD原生4K投影仪，它确实非常特别。不需要DLP和抖DMD来显示4K，不会有白点，不会有彩虹纹，更不会有散斑。即使对比度、亮度以及色彩都比DLP要差一些，可能不足以弄出很好的HDR效果，我还是喊：LCD永不为奴！

所有DLP投影仪厂商在宣传页上几乎都会大肆宣称自己的色彩、亮度、对比度好于单LCD投影，并且把单LCD称为“行业正逐渐淘汰的技术”。实际上DLP除了确实在色彩上显著优于单LCD投影，其他指标并不是必然好于单LCD。例如，让我们对比我在淘宝直接按销量降序得到排名第一的DLP投影仪极米Z6X第五代，以及同样方式得到排名第一的单LCD投影仪小明Q5 Pro，这两者的一些参数，如下。

	极米Z6X第五代	小明Q5 Pro
亮度/CVIA流明	500	600
色域	121% Rec.709	确实是“根本不敢讲色彩”
对比度	未展示	2000:1
售价（无补贴）	¥1771	¥1299

不否认高端产品上的DLP规格也会显著高于低端产品，但是直接硬吹一切DLP，硬踩一切单LCD的宣传确实可以斟酌一下是不是有点夸张。

在购置DLP投影仪的时候，做过一些研究的人会考虑到DMD芯片尺寸这个参数。但非常奇怪的是，在横向对比DLP投影仪和单LCD投影仪的时候却几乎没有人思考过这个问题。好像在单LCD投影仪上这个参数就不存在了似的。

除了像素点的个数，芯片的尺寸在这两种投影仪里也都起着非常重要的作用。DLP投影仪中的DMD芯片的典型尺寸在0.2"到1.38"不等。而单LCD投影仪里的LCD面板动不动就好几英寸。投影仪通常离光屏/投影面的距离并不近，很多时候都能达到3～4m，芯片/面板的尺寸在此时便开始显得尤其重要。

周末去店里看~~（白嫖）~~了极米RS 10 Plus，上来就问芯片尺寸，店员一看就知道我不是过来买的，保不齐是过来找茬来了，没多说话。说是0.47"的DMD，投影距离大约2m，观看距离在1m的时候就能明显看出一些散斑了，还是在抗散斑功能启用的情况下。

说完了，体验也记录得差不多了。希望能对你有所帮助～

Bug+1: 时间机器无法完成备份

Sun, 03 Nov 2024 23:28:47 GMT

这个主题的代码字体里的u长得好像v，请注意辨别。

是收到了这样的错误：

Time Machine couldn't complete the backup to ((Target))
Time Machine did not finish backing up because some files were unavailable. Backups will resume when your Mac is unlocked.

然后查询Log（使用Mints），可以抓到这段错误代码：

Backup failed: BACKUP_DELAYED_UNFINISHED_PROTECTED_FILES (104)

通过搜索引擎找到有帮助的答案是：https://apple.stackexchange.com/questions/433761/time-machine-shows-no-backup-after-backing-up。依照其中的指示，可以通过下面的命令获得更详细的日志：

log show --style syslog --last 30m --predicate 'senderImagePath contains[cd] "TimeMachine"' --info --debug

获取日志之后，在其中查找形如下面内容的日志条目：

localhost backupd[256]: (TimeMachine) [com.apple.TimeMachine:EventCollection] Adding event for inaccessible protected file ((Path)) | EventDatabase.swift:569

其中((Path))就是Time Machine无法访问从而导致上述104错误的文件。

继续根据上述答案文章中的指示，我们可以通过如下命令排除所有无法访问的文件，从而正常完成备份：

sudo tmutil addexclusion -p ((Path))

但是，我们也可以试图修复文件的访问权限，从而避免备份缺斤短两。实践中可以得知，Time Machine的访问权限是和当前用户相同的。所以做法也很简单，就是chown+chmod大法：

sudo chown -R ((Username)):staff ((Path))
chmod -R u+r ((Path))

如此便可放行当前用户对异常文件的访问了。并且这么操作还可以避免对异常文件的排除，让备份更加完整。

Make Time Machine Great Again!

后记

遇到这个问题并不是毫无来头。我也是在从Time Machine恢复了Mac之后，再备份时出现的这个问题。

可以认为从Time Machine恢复Mac会导致部分文件的所有和访问权限出现问题。因为Time Machine在备份失败时报的错误就是部分文件不可用，所以期间我也多次使用CleanMyMac X的Repair Disk Permissions和Time Machine Snapshot Thinning功能试图解决，但结果显然是毫无效果。

希望能够帮到你。

通过VS Code历史记录恢复误删文件

Wed, 01 May 2024 03:22:58 GMT

如果你误删了，并且试图恢复一个曾经用Visual Studio Code保存过的文件，按下⌘ + ⇧ + P（对于Windows：Ctrl + Shift + P）呼出主命令面板，输入并运行Local History: Find Entry to Restore命令，即可浏览和查找VS Code为你保存的文件历史记录。

是的，我要连发两篇文章。

看到这个标题，而且两篇文章挨这么近，就很难不想象是不是发生了一些事情（汗）。要知道，在笔者，本站站长，陽楷锴，写完上一篇文章（邂逅电邮假冒和其承载的钓鱼网站）之后，不知道脑子抽什么风，就想着要更新一下主题。于是很快啊，啪的一下就打开了GitHub，然后saicaca/fuwari最新Zip直接就下载下来，Safari直接就自动解压，然后往项目文件夹里直接就复制，粘贴，全部替换。

没错，直接就复制，粘贴，全部替换，一气呵成。有的时候我自己都佩服我自己的动作居然这么行云流水。我打开VS Code，打算用它提供的图形化Git看一下我的自定义修改啥的，得兼顾主题更新和自定义内容啊，而且Astro框架和主题高度同构，我的文章源文件还得从Git恢复回来呢。于是，发现，其中没有显示Deleted状态下红色文件名的encounter-email-spoofing-and-more.md。我怕了，于是转念一想，当时「一气呵成」的时候好像忘了……把上篇文章的源文件stage到Git里，更没有commit，更没有push到GitHub。

我开始上网搜索Mac恢复文件的办法，因为我在废纸篓里根本没看到这个文件。看到好几个数据恢复软件，但是一上来就要我许可证，我感觉不太靠谱，就像骗子公司生产的骗子产品，比上篇文章里的诈骗邮件还像骗子，毕竟是装都不装了直接要钱～

根本不敢用那些数据恢复软件之下，我打开了Time Machine。发现我没有连接备份盘的情况下，Time Machine不会创建任何快照。上一次连接是两天前啊……自然是找不到这个该死的encounter-email-spoofing-and-more.md了。

重新写的心都有了，想想花了两三个小时写的，有这时间不如去打点游戏，或是睡点觉……想放弃的时候，想起来VS Code在我刚刚前往它的图形化Git功能的时候还打开着那个该死的encounter-email-spoofing-and-more.md，虽然它好像当时显示着找不到该文件和一个令人害怕的红色叉叉。我觉得这是我最后一线希望了，翻着一个又一个菜单，我仍然没能找到相关入口，心越来越慌了。

最后呢？我重写了吗？没有。去Bing查了一下VS Code到底有没有恢复文件的功能，结果还真的给我找到了：vscode 恢复被删除的文件 - 知乎。我跟看到救星一样又跑到VS Code里，一套⌘ + ⇧ + P然后Local History: Find Entry to Restore，像刚才全部替换的时候一样一气呵成，终于，我找到了这个文件。谢天谢地，直接恢复到覆盖前的版本，找回了我几个小时的心血。

呜呜呜，再也不嫌弃VS Code体积大了，也再也不乱删它的缓存了，说不定哪天就……哎，真的都是泪。

Visual Studio Code，听我说谢谢你。

Astro，听我说，我也谢谢你。

邂逅电邮假冒和其承载的钓鱼网站

Wed, 01 May 2024 00:52:42 GMT

背景

最近新入手一个域名。对其用途有清晰的设想，但是设想中的相关项目还远远达不到可以启动的地步……遂先行注册该域名并在项目启动前长期持有。 ~~无论如何这个新域名都是我年轻时候宏伟梦想的象征了。~~

接连不断的RUA报告

本文所称「电子邮件假冒」是指Email Spoofing（Wikipedia）。由于我实在不知道这东西的正式中文名称是什么，于是先用Cloudflare的翻译「电子邮件假冒」（出处：什么是电子邮件假冒？）称呼之。

自从我于2024-04-10注册下这个域名，并且配置好大部分保护性措施（包括DMARC、SPF、DKIM记录等）起，截至撰稿时（2024-05-01凌晨），12封由于违反DMARC规则的RUA报告（Aggregate Report）邮件抵达了我的邮箱……平均两天就有一封多。

根据Cloudflare DMARC Management给出的报告，可以得到以下结论：

按来源分类：

AS4134（No.31,Jin-rong Street）：8封
AS9929（CHINA UNICOM Industrial Internet Backbone）：4封
AS56046（China Mobile Communications Corporation）：1封

按去向分类：

google.com：6封
docomo.co.jp：4封
GMO Internet Group Inc.：1封
kddi.com：1封

很显然，所有违规邮件都来自同一个地区，而去向则都与发件服务器所在地区不同。

由于这些收件服务器都没有向我发送RUF报告（Forensic Report），所以我并没有办法搞清楚这个域名究竟被用作了什么邮件的发件人。我相当烦恼，但更多细节在一封特别的邮件中被清楚地展示在我面前。

特别的邮件：退信

This is the mail system at host mail.chun2.ne.jp. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system

我收到了一封以上面引用块中的文本为开头的电子邮件。大胆推测应该是收件服务器检测到DMARC违规，但没有按照记录中的要求发送RUA或是RUF报告给规定位置，而直接发送了未送达通知到原发件地址。此时，由于我为我的域名设置了MX记录，自然地，这封未送达通知就到了我的收件箱里。

为什么说这封邮件特别？首先因为它不是规范的RUA或是RUF报告，而更重要的是，这个独特的收件服务器（mail.chun2.ne.jp），在未送达通知中附上了邮件原文。这也是我称之为「退信」的原因。

于是乎我得以窥探某些人用这个域名所发邮件的内容的一角。

首先仍然是来源和去向。该邮件来自位于AS4837（CHINA UNICOM China169 Backbone）的一台发件服务器，去向为po.chun2.ne.jp。接着，下面是邮件内容：

<summary>Apple机器翻译</summary>

发件人：MasterCard 标题：万事达卡:非法使用嫌疑的安全检查。正文：

感谢您使用【Mastercard】。这次，因为有想确认是否是本人使用的交易，所以非常抱歉，限制了部分卡的使用，并联系了您。因此，请在以下页面访问后，配合确认卡的使用情况。给您添麻烦和担心，非常抱歉。请您多多谅解。如果没有回答的话，卡的使用限制可能会持续，请提前知悉。

▼确认使用情况请看这里

非常抱歉给您带来不便和担心，请您多多谅解。

发行人 Mastercard 东京都涩谷区樱丘町26-1 Cerulean Tower 16楼

所有用户均被视为已批准并同意本网站客户的隐私使用条款。 ©1994-2024 Mastercard. Mastercard作为机会均等的雇主进行企业活动。

卡丢失、被盗、紧急情况下的账户信息访问等，365天24小时，无论是国内还是海外，都接受万事达卡会员的咨询。https://www.mastercard.us/content/dam/mccom/global/documents/global-services-phone-numbers.pdf

可以搜索包括无接触结算和手机结算在内的信用卡、借记卡、预付万事达卡的加盟店和最近的ATM机。

https://www.mastercard.co.jp/ja-jp/personal/get-support/mastercard-nearby.html

发行人 Mastercard 东京都涩谷区樱丘町26-1 Cerulean Tower 16楼

</details>

发件人：MasterCard 标题：MasterCardカード:不正使用疑惑のセキュリティチェック正文：

【Mastercard】利用いただき、ありがとうございます。このたび、ご本人様のご利用かどうかを確認させていただきたいお取引がありましたので、誠に勝手ながら、カードのご利用を一部制限させていただき、ご連絡させていただきました。つきましては、以下ヘアクセスの上、カードのご利用確認にご協力をお願い致します。お客様にはご迷惑、ご心配をお掛けし、誠に申し訳ございません。何卒ご理解いただきたくお願い申しあげます。ご回答をいただけない場合、カードのご利用制限が継続されることもございますので、予めご了承下さい。

▼ご利用確認はこちら

ご不便とご心配をおかけしまして誠に申し訳ございませんが、何とぞご理解賜りたくお願い申しあげます。

発行者 Mastercard 東京都渋谷区桜丘町26-1 セルリアンタワー16階

すべてのユーザーは、このWebサイトの顧客のプライバシー利用規約を承認および同意したものと見なされます。 ©1994-2024 Mastercard. Mastercardは、機会均等雇用主として企業活動を行っています。

カードの紛失・盗難、緊急時のアカウント情報へのアクセスなど、365日24時間、国内からでも海外からでも、Mastercard会員様よりのお問い合わせを受け付けています。https://www.mastercard.us/content/dam/mccom/global/documents/global-services-phone-numbers.pdf

コンタクトレス決済やモバイル決済を含むクレジット、デビット、プリペイド Mastercardのご利用いただける加盟店や最寄りのATMを検索をいただけます。

https://www.mastercard.co.jp/ja-jp/personal/get-support/mastercard-nearby.html

発行者 Mastercard 東京都渋谷区桜丘町26-1 セルリアンタワー16階

</details>

日语我看不懂一点，所以只能用机器翻译，见谅。好在这不影响对这封邮件的分析。可以看出，这是一封诈骗邮件，谎称收件人的Mastercard卡片被限制，需要在线恢复卡片功能。另外也不难看出写这封邮件的人水平其实不怎么样，连Mastercard这个名字的大小写都没搞清楚，发件人和标题都错写成了“MasterCard”。

其中给出的“确认使用情况”链接是https://clck.ru/3ALtcH。访问该站点的主页并进行一些简单的查询就很容易发现这是Yandex的短链接服务，攻击者应该是通过该短链接服务来隐藏真实URL以逃过邮件安全系统的检测。该链接最终会跳转到http://vmu178.com/?index=205。忽略令人诟病的明文HTTP协议，该网站的反侦查意识还是有一点的。如果直接访问，会看到无内容的白屏页面。此时需要一个日本IP来显示该页面的内容。

至此，我们就能发现该页面的真面目：骗取银行卡信息（卡号、持卡人姓名和其他信息、有效期、CVV等）的钓鱼页面。从而我的域名在被我注册前都被用于做些什么事情也可见一斑。

怎么办？

作为域名所有者，我已经设置了有效的SPF、DKIM和DMARC记录以有效阻止这些恶意邮件真正抵达收件人邮箱。按照我的现行DMARC规则，所有无法通过SPF或DKIM验证的发件服务器发送的邮件都会在发送违规报告到指定位置后被丢弃。

是的，某些人仍然可以宣称自己的邮件来自我的域名，这是电子邮件运作的基本原理。但是他们能做的也就只有宣称而已。

后记

VS Code，听我说，谢谢你。

关于这些年自建网站的一切

Sat, 20 Apr 2024 22:53:07 GMT

是的，我删掉了很多文章

主要是因为看起来过于……腻歪，就好像我为了建站而建站。虽然事实上我确实是通过这段时间的网站建设学到了很多东西，也可以说就是为了建站而建站吧。另外就是觉得那些文章写得还是有点太水了，或者说过于稚嫩，不是很想继续展示在外面。就像是……黑历史一样。倒是删掉的都是关于自建网站的内容，总感觉直接丢弃颇有浪费之意，于是便有了这篇文章以及这个标题。

关于域名

撰稿时，本站使用的域名已经是第二个了。至于为什么弃用了原来的域名，只能说少不更事选了非常中二的而且现在的我相当不喜欢的一款，哎。如果关注了本站很久的话应该知道有更换域名的事情，当时我设置了307 - Temporary Redirect来提示访客，现在已经停止重定向，原来的域名也已经在出售中。但是估计真的知道这件事而且不在我交际圈里的人并不存在。无论如何，我并不希望原先的域名出现在任何地方，或是被互联网记住。如果真的知道本站原来的域名，而又恰巧看到原来的域名在任何公开的位置出现，请按照关于中的邮箱地址联系我，十分感谢。如果是在非公开的位置记录下了本站原来的域名，还请进行更改。

关于渲染引擎：Hexo和Astro

心路

从一开始我使用的是Hexo这款“快速、简洁且高效的博客框架”，至于原因，是因为入门时看到了大量有关Hexo的入门教程，这也反映出Hexo社区大、文档完整，在博客框架界的口碑也相当不错。

期间一直使用的主题是Material。因为从一开始其实是一个Android用户。大概是在在从Windows转移到macOS后，如何不那么别扭这篇文章发布前后买了台Mac，然后才慢慢进入了苹果生态。Android用户的话，就很喜欢Google的那套Material Design，而且这个主题当时就排在Hexo官网的主题页面很前面的位置。遇到这个主题也是一种缘分吧。

期间因为自己的折腾心就加了各种各样的魔改在主题里，可以去我的fork看一看：https://github.com/Kainichy/hexo-theme-material。

后来因为看久了有点审美疲劳，再加上Google自己都把Material Design从尖锐的矩形风格迭代成圆润的样式，再加上访问速度真的有点堪忧，再加上……忘了。就由于这些各种各样的原因，我一直盘算着换个主题。悄悄说：本来还打算一年一换的。后来发现自己好像还是有点太忙了，于是一直搁置着换主题的事情。

一直到2024年4月12日，想到每次Cloudflare Web Analytics给我发摘要邮件都会飙红的指标，我下定决心换一个主题。

本来打算用Sukka大佬的Suka，然后因为有点太简约又想去换个新的，兜兜转转，最后看到了Vivia。这个主题好啊，简约又符合当代各个科技厂商都倾向的圆润的大方向，结果一打开就是醒目的：

[!NOTE] This project is no longer actively maintained. If you are interested in this theme, it is recommended to use the new Astro version.

本项目已不再活跃维护，若对本主题感兴趣，建议使用新的 Astro 版本

于是我就自然而然地用了“新的 Astro 版本”。后来就是各种各样的迁移忙活了我两个周末，再后来就是你现在看到的这样啦。

为什么是Astro

对于我来说，Astro引擎加上Fuwari主题的好处还是相当明显的：

访问速度明显加快
暂时缓解审美疲劳
又能学到新东西了
Cloudflare Pages自带构建模版：以前用Hexo由于我技术力不够Cloudflare Pages老报错，非得回退到老版本的Pages构建环境才行

而其缺点也不少：

主题与引擎同构，欲更换主题比Hexo麻烦得多，此外主题的更新也成了问题
对于一些主题来说，可供自定义的选项貌似过少，例如像我使用的Fuwari，如果需要修改文章的路径将是一个大工程
使用很多插件都相当不方便，例如@astrojs/sitemap和@astrojs/rss。比起Hexo需要配置的地方多得多
项目文件夹过于复杂
社群小，教程少，文档不成熟

但麻烦是一时，流畅是长期问题。于是最后权衡之下我留在了Astro。

关于静态博客托管服务：GitHub Pages、Netlify、Vercel和Cloudflare Pages

心路

一开始还是因为大量教程选择了老牌的GitHub Pages。后来还是因为大量教程尝试了Netlify，试图搭建CMS并失败。后来又因为大量教程尝试了Vercel。最后是Cloudflare Pages最特别，给我发了推广邮件我就去试用了。

为什么是Cloudflare Pages

最后是因为我用它当权威DNS和CDN而一直用了下去。就是这么简单。颇有种「肥水不流外人田」的美。其实真要说的话也完全有道理的，能省下很多Cloudflare的CDN回源的时间，从中间环节加快了访问速度。而且他们碳中和啊。

各家服务的客观对比

以前对比优缺点，现在对比可用性，哈哈。针对的环境很明确的，不过多赘述。

GitHub Pages：

控制台（GitHub主站）连通性不佳
默认域名连通性不佳
自定义域名连通性正常，速度一般

Netlify：

控制台连通性不佳
默认域名连通性不佳
自定义域名连通性正常，速度一般

Vercel：

控制台连通性不佳
默认域名连通性不佳
自定义域名连通性正常，速度较慢

Cloudflare Pages：

控制台连通性正常
默认域名连通性正常，速度一般
自定义域名连通性正常，速度一般

下面是摘录的一些有关各平台主要功能限制的对比。但是我觉得大部分时候没有必要在意平台限制的，因为基本达不到。

<summary>我觉得没有必要的对比</summary>

GitHub Pages：

自定义域名：一个。
限制：
- （Git仓库）单个文件大于50MB将受到警告。
- （Git仓库）单个文件大于100MB无法上传。
- （Git仓库）项目总大小「强烈建议」少于5GB。
- 每小时可构建10次，每次不超过10min。
- 每月流量100GB。详情可见：https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages#guidelines-for-using-github-pages

Netlify：

自定义域名：多个。
限制：对于每个账户：
- 同时只能构建一个站点。
- 每月流量100GB。
- 每月构建时间300分钟。详情可见：https://www.netlify.com/pricing

Cloudflare Pages：

自定义域名：100个；
限制：
- 每月构可构建500次，每次不超过20min。
- 文件数量最多20,000个。
- 单个文件大小不得超过25MiB。详情可见：https://developers.cloudflare.com/pages/platform/limits

Vercel：

自定义域名：50个。
限制：
- 每日可构建100次，但每小时不超过32次。每次不超过45min。每月总计不超过100h。
- 单个Git仓库支持连接3个Vercel项目。
- 每月带宽100次。详情可见：https://vercel.com/docs/platform/limits

</details>

只能说希望大环境好一点。

写在最后

很感谢你能看完这篇文章，因为几乎没什么营养，就是一些无用的记录。虽然好像我的大多数文章都是这样。那么就先写到这里，期待接下来在Astro的驱动下我能有更好的写作体验，你能有更好的浏览体验。当然前提是我有心情和时间更新（）。

此致顺颂时祺。

通过Apple快捷指令更新Cloudflare Gateway绑定IP

Thu, 02 Jun 2022 21:13:20 GMT

TL;DR

获取Cloudflare Account ID、包含Account.Zero Trust:Edit权限的Cloudflare API Token、Location的ID后，使用此快捷指令即可更新Cloudflare Gateway绑定IP：

https://www.icloud.com/shortcuts/8e625a57927b4079a4a682aab430d6aa
https://kyki.moe/posts/update-Cloudflare-Gateway-IP-shortcuts/Update%20Cloudflare%20Gateway%20IP.shortcut

两个链接内容一致，站内链接权当备份。

根本没仔细测试过Apple的Shortcuts Setup能不能用的问题。根据我对Apple的认知，很可能会遇到变量导入的问题，尤其是涉及到有两个字符串需要转换为布尔值。如果遇到相关问题，建议直接把你的内容硬编码到快捷指令里，然后给我留个评论，谢谢～

（我相信都用着Cloudflare Zero Trust而且还能找到这里来的人应该不差这点能力的，吧。）;-）

背景&介绍

Cloudflare Gateway是一款运行于DNS层或HTTP层的安全网关。其具有不错的可自定义程度。在基于DNS使用时，其提供IPv4/IPv6 :53 UDP、DoT、DoH几种接入方式。

在通过IPv4 :53 UDP接入其DNS服务时，由于IPv4地址非常稀缺，每个人分配到的接入点都将是一个相同的Anycast IP地址。因此需要在Cloudflare登记客户端IP地址以进行个性化配置。

很不幸，Cloudflare没有提供DDNS支持，而我的路由器又不支持DoT、DoH，更糟糕的是，我的ISP到现在都没有提供IPv6互联网……所以很长一段时间我都只能手动进行IP地址更新。

直到最近我突发奇想，决定通过Cloudflare API对Cloudflare Gateway绑定IP进行定期更新。

前提&准备

Cloudflare API Token

首先，为了使用Cloudflare API，我们需要一个至少包含Account.Zero Trust:Edit权限的Cloudflare API Token。可以在https://dash.cloudflare.com/profile/api-tokens进行生成。

Cloudflare Account ID

打开Cloudflare Zero Trust仪表板，登入账户后，在页面的URL中应该可以非常方便地看到你的Account ID，不做过多赘述。

Gateway Location信息

生成符合条件的API Token之后，我们需要获取Gateway中对应Location的ID。这一步有两种获取方法。

通过网页仪表板获取

打开Cloudflare Zero Trust仪表板，登入账户后，在边栏选择Gateway > Locations，并选择或新建一个想要使用的位置，对其进行至少一次编辑（如名称、ECS支持、是否为默认等）。此时你需要记录该Location的名称。

然后在边栏中转到Logs > Admin，查看对应的Update location事件，在log的json中寻找关键字为id的字符串。注意不是account_id，也不是network关键字下的id。

通过API获取

执行

GET https://api.cloudflare.com/client/v4/accounts/:identifier/gateway/locations
    Header: Authorization: Bearer :token
    Header: Content-Type: application/json

即可获得你所有可用的Gateway Locations。在返回的json中寻找关键字为id以及name的字符串。如果你使用curl，则可以执行：

curl -X GET "https://api.cloudflare.com/client/v4/accounts/:identifier/gateway/locations" \
     -H "Authorization: Bearer :token" \
     -H "Content-Type: application/json"

这一步中的:identifier是指你的Cloudflare Account ID，:token是指你的API Token，下文同样。注意在替换为你的个人内容时不要保留:，例如，如果你的Account ID是example123456，你应该使用https://api.cloudflare.com/client/v4/accounts/example123456/gateway/locations而非https://api.cloudflare.com/client/v4/accounts/:example123456/gateway/locations。

编写快捷指令

这一步建议在macOS中进行，因为iOS上的快捷指令对HTTP请求的配置界面很奇怪。我用着并不是很明白。如果你没有macOS设备，可以使用前文中已编写完毕的快捷指令~~，或者硬着头皮上~~。

由于作者使用的是英文版操作系统，可能一些翻译不是非常准确，敬请谅解。

主要流程为：

获取当前IP地址：外部，IPv4

获取URL内容：
    https://api.cloudflare.com/client/v4/accounts/:identifier/gateway/locations/:uuid
    方法为PUT
    Header：
        Content-Type: application/json
        Authorization: Bearer :token
    请求正文格式为json，包含：
        networks，类型为数组/阵列（Array），包含：
            一个字典（Dictionary），包含：
                network，类型为字符串/文本（Text），值为:ip/32
        name，类型为字符串，值为:name
        client_default，类型为布尔（Boolean），值为:client_default
        ecs_support，类型为布尔，值为:ecs_support

此处:identifier和:token的定义与上文（#通过API获取）一致，不再赘述。:uuid指需要更新的Location ID。:ip指你在快捷指令的第一步中获取的外部IPv4地址。:name指你希望将此Location重命名为的名称。若不欲重命名，填写为原来的名称即可。:client_default指你是否希望此Location成为默认选项（目前我尚不知道此选项的作用）。注意，如果你希望将此项目的值设为False，你需要保证你有一个另外的Location作为默认值，否则其值必须为True。:ecs_support指你是否希望此Location的DNS服务启用ECS，建议设为True来提高性能。

Cloudflare API Documentation给出的样例请求正文格式为：

{"name":"Austin Office Location","networks":["192.0.2.1"],"client_default":"false"}

这是不对的。如果按照此方式进行请求，我们将得到一个错误，消息为json: cannot unmarshal string into Go struct field LocationRequest.networks of type api.NetworkRecordJSON以及json: cannot unmarshal string into Go struct field LocationRequest.client_default of type bool。我不知道Cloudflare为什么会在一个示例里出现两处错误。正确的样例请求正文格式应为：

{"name":"Austin Office Location","networks":[{"network": "192.0.2.1/24"}],"client_default":false}

此处我也遇到了问题。搜索后参考了Cloudflare Community里的一篇文章解决了问题。十分感谢。

至此，可以直接通过Apple平台上的快捷指令完成对Cloudflare Gateway绑定IP的更新了。后话就是建议添加自动化获得更加体验了。

Face ID全新戴口罩识别功能测速

Fri, 28 Jan 2022 14:04:43 GMT

题图来自MacRumors

本文章有视频版本，欢迎观看： <iframe src="//player.bilibili.com/player.html?aid=978589854&bvid=BV1444y1p7qN&cid=494729663&page=1&high_quality=1&danmaku=1" allowfullscreen="allowfullscreen" width="100%" height="500" scrolling="no" frameborder="0" sandbox="allow-top-navigation allow-same-origin allow-forms allow-scripts"></iframe>

Apple在北京时间今日凌晨发布了iOS 15.4的第一个开发者预览版。其中包含一个很亮眼的新功能：Face ID可以识别佩戴口罩的脸了。不同于之前iOS 14.5中发布的通过Apple Watch解锁，之前的功能受信号环境干扰较大。而这次的功能并不需要你拥有Apple Watch。也就是说，iPhone终于可以依靠自身的Face ID组件来识别被口罩覆盖的面部了。

除开安全性，我们最关心的便是解锁速度。那么让我来测试一下戴口買与不載口置时Face ID识别速度区别有多大。

测试方法：

通过Mac上的QuickTime来录制iPhone的屏幕
将录制的视频导入Final Cut Pro
对Face ID动画的帧数进行计数

不戴口罩与戴口罩的情況分别测试。为了计数方便，我在将视频导入Final Cut Pro时选择的帧率为60fps，实际视频帧率低于该值。动画的起始与结束帧均计算在内。

测试条件：

设备型号为iPhone 12
作者始终佩戴同一副眼镜
自然光源始终从作者的右侧照入

以下是测试结果：

首先是不戴口罩的情况：

可以看到动画起始帧为6:30。动画结束帧为7:1。

共计有32帧。原视频帧率为53.241fps。计算得Face ID不戴口罩情况下识别时间约为601ms。

然后是佩戴口罩，触发iOS新功能的情况：

动画起始帧为7:28。动画结束帧为8:20。

共计有53帧。原视频帧率为56.06fps。计算得Face ID佩戴口罩情況下识别时间约为945ms。

复盘一下：

不戴口罩识别用时约601ms
佩戴口罩识别用时约945ms

慢了大约57.24%。总体主观感觉，能感觉到慢了，但不多。

App+1: 带壳截图工具capXDR

Sat, 09 Jan 2021 17:55:36 GMT

截图，对于大部分用户来说都是非常常用的一个操作，对于一些科技行业的文字工作者或许使用得更是无比频繁。

我们也常常想要生成像设备厂商宣传页面上那样的带有设备外型的截图，像这样的：

对于移动设备已经有了一些App来为我们进行后期处理，比如Snapmod。那么在桌面端有没有办法做出这么漂亮的图片而不打开专业的图片处理工具呢？

少数派给出了使用截图神器ShareX的方案：一日一技 | 使用 ShareX 快速为截图套壳 - 少数派然而看起来实在是太麻烦了。还涉及到抠图、配置文件修改之类的操作实在是难以操作。

所以我希望介绍一款能够轻松完成截图加壳处理的App：capXDR。这是一个民间大佬开发的macOS App。目前只有Intel版本，M1用户也可以通过Rosetta运行。看一下设置菜单好了：作者画了不少机壳模版了，可以通过导入的方式选择。

下载地址：

App本体：https://cdn.jsdelivr.net/lihaoyun6/capXDR-plugins/app/capXDR.dmg
插件列表：https://github.com/lihaoyun6/capXDR-plugins/blob/master/thumbs/textlist.md

项目repo地址：

GitHub：https://github.com/lihaoyun6/capXDR-plugins
Gitee：https://gitee.com/lihaoyun/capXDR-plugins

关于隐私

Sat, 19 Dec 2020 23:05:50 GMT

你或许想不到，一个静态博客居然会有隐私说明。为什么是说明而不是条款呢？因为如果你看到了这里，你已经把我的小破站看得很深入了……可以说使用即同意吧。

你的数据将被通过以下方式收集：

Cloudflare Web Analytics的JavaScript所得数据：https://static.cloudflareinsights.com/beacon.min.js；
Cloudflare CDN与客户端的连接数据；

简要地说明一下你被收集的数据：

你访问本站使用的的User-Agent字符串（用于分析你使用的浏览器、设备类型和操作系统）；
你访问本站的哪个子域名；
你从什么网站跳转到本站；
你访问本站的哪些目录/页面；
你的IP地址（用于了解你所在的国家/地区和模糊的访客识别）；
你使用的HTTP版本和TLS版本；
你在本站停留的时间以及进行的操作（包括但不限于鼠标滚动、光标移动、鼠标点击）。

你被收集的数据会被如何使用：

我不会对你的数据做任何处理，仅供我个人参考；

当然，如果你不愿意被收集如此详细的数据，完全可以直接屏蔽前文提到的URL来防止采集你数据的JavaScript脚本被执行。如果你不希望你的IP地址被收集，当然也可以直接通过Tor或代理来访问本站。这里没有任何~~恶心的~~类似BlockAdBlock之类的限制。

来点音乐

Sat, 12 Dec 2020 11:45:15 GMT

这个页面是用来分享一些我喜欢的音乐的。由于我使用的是Apple Music，如果你并不使用的话，可能这个页面对你来说并不是非常方便。无论如何，你都可以选择阅读我的播放列表。

所有内容在Apple Music US店面提供。

我的Apple Music个人资料

关注我的Apple Music，更方便地收听我喜欢的音乐。

只有一个的播放列表

Test Audio 收集了一些我认为比较能够体现设备音频素质的音乐，且不同的曲目有不同的特点。得益于Apple Music Hi-Res Lossless的高音质，如果你有DAC等设备，这将是非常不错的选择。另外，建议你在不同的乐曲中分别选段播放，播放整个列表将耗费非常多时间。

Apple Music自动生成：电台

Apple Music自动生成：播放列表

Apple Music自动生成：Replay播放列表

生成你的Replay播放列表：REPLAY。打开后登录你的Apple ID然后Get Replay Mix就好。

格式为：歌手 - 曲目，以换行符分隔。你可以通过任何你偏好的服务使用它们。

希望能满足你的耳朵。

Bug+1: 用终端commit GitHub远程仓库时用户识别错误

Sat, 24 Oct 2020 00:08:29 GMT

这是一篇比较水的文章。

闲着没事去本博客所在的GitHub repo看了看，结果发现一堆其他人的commit。

遂点开commit详情查看内容，发现确实是我提交的东西。。。这我就很奇怪了，于是打开那个人的首页，发现并没有看到有在我的repo里有过任何提交。。。

难道这是个bug？

于是乎我去联系了GitHub Support，发现是我在复制GitHub提供的no-reply邮箱地址的时候少了一位，结果出现了这样的问题。

但是我很好奇的是，为什么会出现这样的问题，因为我只是填错了邮箱地址，但是我的GitHub Personal Access Token是正确的。也就是说，我用一个不存在的邮箱地址，以及SkyYkb的Token，就能把commit放到别人的名义下面去，虽然并不会在别人的首页显示。

仿佛看到了什么危险的东西啊。。。

解决方案

经过一番Google，发现一个Gist提供了解决方案：

git rebase -i HEAD~<number of commits> -x "git commit --amend --author 'Author Name <author.name@mail.com>' --no-edit"

但是缺点是会导致在GitHub上显示出的commit时间是你执行之后的时间。但无论如何作者变回来了。但是在GitHub的边栏仍然会留有那个神秘人物的名字。

这个时候就直接找GitHub Support说明情况就可以了。或者稍微等一等也可以。

我们为什么需要HTTP/3

Sat, 17 Oct 2020 22:09:08 GMT

什么是HTTP/3？

继HTTP/1.1和HTTP/2之后的全新版本HTTP协议。

HTTP/3协议废除了TCP协议，改用QUIC。全名叫Quick UDP Internet Connection，读作“quick”，~~一听就知道很快嘛。~~从名字我们不难看出，这是个基于UDP的协议。大佬们就是用这个80年代协议加上个传输安全，成了QUIC。

再说说QUIC的前身gQUIC。其实早在Chrome 55的时候Google就已经实现了gQUIC协议，然后添加了一个Chrome flag，而且现在还存在，使用Chrome的读者可以到chrome://flags/#enable-quic进行考古。但是gQUIC也不同于QUIC，它只能用于发送HTTP流量，而QUIC除了应用在了HTTP/3，还可以用于发送DNS、SSH、Telnet之类的流量。完全取代UDP应该问题不大。

在2015年，Google把QUIC提交到了IETF，然后整出来一个叫HTTP-over-QUIC的东西，又后来改了个名字，称为HTTP/3。

HTTP/2是怎么运作的？

要说新技术，肯定要把老技术拿出来说一说。

HTTP/2以及之前所有版本的HTTP协议，都是基于TCP协议构建的。在你的设备与服务器开始安全的（经过TLS加密的）交换你想要的数据之前，他们首先需要建立连接，然后进行三次握手，你的设备就能确定服务器的身份，然后开始传输加密的数据。（这里假设你不想要握手时候证书之类的数据，当然除了应用程序也没什么人会想要这个）

那它有什么不同？好在哪里？

~~唯一的不同，是处处都不同。~~（老苹果了）

从一开始你可能就要想了，UDP不是上世纪80年代的~~比站长还老的~~东西了吗？怎么还翻出来炒冷饭呢？我们知道，DNS协议就是基于UDP实现的，一大原因就是因为它的速度。就算服务器远在灯塔国，一个基于UDP的DNS请求去回一趟（注意是去了又回来）都只用100+ms。

于是从上文不难得出答案，那就是快，因为不需要建立连接，原先的TLS三次握手被简化为一次。同时还具有很好的兼容性，HTTP/3在QUIC的基础上仍然支持了传统的TLS三次握手。

同时，不需要建立连接还带来了新的好处，就是免中断。在TCP连接建立好之后，如果你的网络环境在传输过程中发生了改变，如你突然连接上了虚拟专用网络，又或者是你从无线局域网跑到了蜂窝移动数据，通常你就需要重新建立连接来传输完整的数据。在Chromium浏览器中，这体现为“ERR_NETWORK_CHANGED”的报错。于是你就需要刷新页面重新加载了。

但QUIC不需要，他只管发数据包，反正没有连接。但是这里又有一个转折了：如果你的网络环境发生了改变，你的公网IP势必会发生变化，这样如果服务器还往原来的地方发数据包，你岂不是收不到了？这个时候，你的设备往往只需要朝服务器再发一个数据包，包含了刚开始握手时给的唯一ID，并且要求服务器更改传输地址就可以了。

并且不同于TCP完全由操作系统实现，QUIC通过应用程序层面实现的方式不需要理会系统的优化程度，只管自己实现就好。

综上，我能看到的最舒服和最迫切的应用前景就是DNS了。传统的UDP DNS太不安全，轻松劫持，DoT、DoH三次握手太慢，DNSSec又不是大多域名都启用，所以DNS这块应用HTTP/3可以说是完美解决大部分问题。

那它难道没有缺点？

Every coin has 2 sides.

它肯定是有缺点的。但其实都不是它本身的缺点：

浏览器目前对HTTP/3的支持尚不完善，Chrome、Edge、Firefox都是只有每夜构建版才支持。（前两者的叫Canary，最后者的叫Nightly）甚至还需要加flag或者config。Curl甚至还得自己编译。
由于NAT设备优化的问题，可能会使丢包率高于原先的TCP连接。
有些NAT设备会重写UDP报文的header，然后当场爆炸。

完。

在从Windows转移到macOS后，如何不那么别扭

Sun, 10 May 2020 12:24:37 GMT

经历相关：从Windows转移到macOS约半年时间。本文基于从Windows 10 1909切换到macOS Catalina撰写。

你当然可以通过直接安装Windows来解决使用习惯的问题，但是那样就失去了Mac的灵魂，也会导致性能、优化弱鸡。所以我推荐通过安装第三方软件解决问题。要解决麻烦，首先要知道区别在哪里。在我体验macOS之后，有比较强烈的缺失感的有：

窗口贴边吸附
剪贴板历史记录
一个「比较好」的压缩软件
NTFS读写
开始菜单

于是本文将分为四个部分推荐软件。

1. 窗口贴边吸附

一说到这个，肯定会有人提到Magnet。但我不推荐它。因为它在App Store要¥12才能使用。这就非常之难受：难道Windows自带的功能我macOS要用第三方软件不说，还得付钱？所以我发现了这样一款挺不错的软件：Rectangle 这个软件支持好多种窗口位置，看图：并且每一个都支持自定义快捷方式：支持鼠标拖拽贴边隐藏。体验下来基本可以做到Windows用户不别扭、直觉操作的水平。下载地址：https://github.com/rxhanson/Rectangle/releases/latest

2. 剪贴板历史记录

Windows 10某个版本中，加入了一个功能，叫做剪贴板历史记录：这个功能非常人性化、方便啊，只需要按下Windows徽标键+V就能呼出剪贴板历史记录，双击直接粘贴，就不用跑来跑去。用过这个功能的人应该都是深有体会。其实macOS也有这样的第三方软件，叫CopyLess 2。主界面整体而言比Windows更修长，并且还多了复制来源的软件。在安装助理程序之后，还能支持双击直接粘贴到当前激活的编辑框。那Pro版本有啥功能呢？

iCloud同步
最多保留1000个粘贴条目

其实我觉得性价比并不高。因为我到现在也还没碰到免费版的条目数量限制…… 并且还有Windows没有的特色功能：连串拷贝&粘贴。你可以通过CopyLess来不断复制，然后一并粘贴到一个编辑框中。下载地址：CopyLess 2

3. 一个「比较好」的压缩软件

Windows下面，有一个非常好用的软件Bandizip。它当然也有macOS版本，不过并不是免费的，似乎费用还挺高。这里推荐eZip。功能不赘述了，基本与Bandizip齐平。并且支持在压缩时忽略macOS系统临时文件，对Windows用户更友好。下载地址：eZip - 专为 macOS 而设计的压缩软件！

4. NTFS读写

这里也有几款非常有名的软件，如Paragon、Tuxera之类的软件。但是它们都收费，都收费！这里推荐Mounty这款体积非常非常小的插件：完全免费，随用随开。它并没有图形界面，启动后只会在菜单栏显示一个小图标：然后就可以实现NTFS读写了。非常方便。安装方法：

Homebrew安装： brew cask install mounty
dmg直接安装： https://mounty.app/releases/Mounty.dmg

5. 开始菜单

其实macOS并不是没有开始菜单，只是拆分到了几处：

位于左上角Apple Logo的电源菜单
Launchpad
访达边栏的目录快捷方式

然而有没有办法可以合在一起呢？很遗憾，没有。但是可以稍微曲线救国一下。因为大多数Windows用户打开开始菜单就是奔着应用程序去的，所以我们可以设置一个触发角（系统偏好设置》桌面&屏幕保护程序》屏幕保护程序》触发角），在左下角的地方直接呼出Launchpad。这样当你鼠标移动到屏幕左下角的时候，就会弹出Launchpad。也算是曲线救国。

结尾。

Include Video in the Posts

Mon, 01 Jan 2001 00:00:00 GMT

Just copy the embed code from YouTube or other platforms, and paste it in the markdown file.

---
title: Include Video in the Post
published: 2023-10-19
// ...
---

<iframe width="100%" height="468" src="https://www.youtube.com/embed/5gIf0_xpFPI?si=N1WTorLKL0uwLsU_" title="YouTube video player" frameborder="0" allowfullscreen></iframe>

YouTube

Bilibili

Simple Guides for Fuwari

Mon, 01 Jan 2001 00:00:00 GMT

Cover image source: Source

This blog template is built with Astro. For the things that are not mentioned in this guide, you may find the answers in the Astro Docs.

Front-matter of Posts

---
title: My First Blog Post
published: 2023-09-09
description: This is the first post of my new Astro blog.
image: ./cover.jpg
tags: [Foo, Bar]
category: Front-end
draft: false
---

Attribute	Description
`title`	The title of the post.
`published`	The date the post was published.
`description`	A short description of the post. Displayed on index page.
`image`	The cover image path of the post.<br/>1. Start with `http://` or `https://`: Use web image<br/>2. Start with `/`: For image in `public` dir<br/>3. With none of the prefixes: Relative to the markdown file
`tags`	The tags of the post.
`category`	The category of the post.
`draft`	If this post is still a draft, which won't be displayed.

Where to Place the Post Files

Your post files should be placed in src/content/posts/ directory. You can also create sub-directories to better organize your posts and assets.

src/content/posts/
├── post-1.md
└── post-2/
    ├── cover.png
    └── index.md

Markdown Extended Features

Mon, 01 Jan 2001 00:00:00 GMT

GitHub repository cards

You can add dynamic cards that link to GitHub repositories, on page load, the repository information is pulled from the GitHub API.

::github{repo="Fabrizz/MMM-OnSpotify"}

Create a GitHub repository card with the code ::github{repo="<owner>/<repo>"}.

::github{repo="saicaca/fuwari"}

Admonitions

Following types of admonitions are supported: note tip important warning caution

:::note Highlights information that users should take into account, even when skimming. :::

:::tip Optional information to help a user be more successful. :::

:::important Crucial information necessary for users to succeed. :::

:::warning Critical content demanding immediate user attention due to potential risks. :::

:::caution Negative potential consequences of an action. :::

:::note
Highlights information that users should take into account, even when skimming.
:::

:::tip
Optional information to help a user be more successful.
:::

The title of the admonition can be customized.

:::note[MY CUSTOM TITLE] This is a note with a custom title. :::

:::note[MY CUSTOM TITLE]
This is a note with a custom title.
:::

[!TIP] The GitHub syntax is also supported.

> [!NOTE]
> The GitHub syntax is also supported.

> [!TIP]
> The GitHub syntax is also supported.

Markdown Example

Mon, 01 Jan 2001 00:00:00 GMT

An h1 header

Paragraphs are separated by a blank line.

2nd paragraph. Italic, bold, and monospace. Itemized lists look like:

this one
that one
the other one

Note that --- not considering the asterisk --- the actual text content starts at 4-columns in.

Block quotes are written like so.

They can span multiple paragraphs, if you like.

Use 3 dashes for an em-dash. Use 2 dashes for ranges (ex., "it's all in chapters 12--14"). Three dots ... will be converted to an ellipsis. Unicode is supported. ☺

An h2 header

Here's a numbered list:

first item
second item
third item

Note again how the actual text starts at 4 columns in (4 characters from the left side). Here's a code sample:

# Let me re-iterate ...
for i in 1 .. 10 { do-something(i) }

As you probably guessed, indented 4 spaces. By the way, instead of indenting the block, you can use delimited blocks, if you like:

define foobar() {
    print "Welcome to flavor country!";
}

(which makes copying & pasting easier). You can optionally mark the delimited block for Pandoc to syntax highlight it:

import time
# Quick, count to ten!
for i in range(10):
    # (but not *too* quick)
    time.sleep(0.5)
    print i

An h3 header

Now a nested list:

First, get these ingredients:
- carrots
- celery
- lentils
Boil some water.

Dump everything in the pot and follow this algorithm:

 find wooden spoon
 uncover pot
 stir
 cover pot
 balance wooden spoon precariously on pot handle
 wait 10 minutes
 goto first step (or shut off burner when done)

Do not bump wooden spoon or it will fall.

Notice again how text always lines up on 4-space indents (including that last line which continues item 3 above).

Here's a link to a website, to a local doc, and to a section heading in the current doc. Here's a footnote [^1].

[^1]: Footnote text goes here.

Tables can look like this:

size material color

9 leather brown 10 hemp canvas natural 11 glass transparent

Table: Shoes, their sizes, and what they're made of

(The above is the caption for the table.) Pandoc also supports multi-line tables:

keyword text

red Sunsets, apples, and other red or reddish things.

green Leaves, grass, frogs and other things it's not easy being.

A horizontal rule follows.

Here's a definition list:

apples : Good for making applesauce. oranges : Citrus! tomatoes : There's no "e" in tomatoe.

Again, text is indented 4 spaces. (Put a blank line between each term/definition pair to spread things out more.)

Here's a "line block":

| Line one | Line too | Line tree

and images can be specified like so:

Inline math equations go in like so: $\omega = d\phi / dt$. Display math should get its own line and be put in in double-dollarsigns:

$$I = \int \rho R^{2} dV$$

$$ \begin{equation*} \pi =3.1415926535 ;8979323846;2643383279;5028841971;6939937510;5820974944 ;5923078164;0628620899;8628034825;3421170679;\ldots \end{equation*} $$

And note that you can backslash-escape any punctuation characters which you wish to be displayed literally, ex.: `foo`, *bar*, etc.

Expressive Code Example

Mon, 01 Jan 2001 00:00:00 GMT

Here, we'll explore how code blocks look using Expressive Code. The provided examples are based on the official documentation, which you can refer to for further details.

Expressive Code

Syntax Highlighting

Regular syntax highlighting

console.log('This code is syntax highlighted!')

Rendering ANSI escape sequences

ANSI colors:
- Regular: [31mRed[0m [32mGreen[0m [33mYellow[0m [34mBlue[0m [35mMagenta[0m [36mCyan[0m
- Bold:    [1;31mRed[0m [1;32mGreen[0m [1;33mYellow[0m [1;34mBlue[0m [1;35mMagenta[0m [1;36mCyan[0m
- Dimmed:  [2;31mRed[0m [2;32mGreen[0m [2;33mYellow[0m [2;34mBlue[0m [2;35mMagenta[0m [2;36mCyan[0m

256 colors (showing colors 160-177):
[38;5;160m160 [38;5;161m161 [38;5;162m162 [38;5;163m163 [38;5;164m164 [38;5;165m165[0m
[38;5;166m166 [38;5;167m167 [38;5;168m168 [38;5;169m169 [38;5;170m170 [38;5;171m171[0m
[38;5;172m172 [38;5;173m173 [38;5;174m174 [38;5;175m175 [38;5;176m176 [38;5;177m177[0m

Full RGB colors:
[38;2;34;139;34mForestGreen - RGB(34, 139, 34)[0m

Text formatting: [1mBold[0m [2mDimmed[0m [3mItalic[0m [4mUnderline[0m

Editor & Terminal Frames

Code editor frames

console.log('Title attribute example')

<!-- src/content/index.html -->
<div>File name comment example</div>

Terminal frames

echo "This terminal frame has no title"

Write-Output "This one has a title!"

Overriding frame types

echo "Look ma, no frame!"

# Without overriding, this would be a terminal frame
function Watch-Tail { Get-Content -Tail 20 -Wait $args }
New-Alias tail Watch-Tail

Text & Line Markers

Marking full lines & line ranges

// Line 1 - targeted by line number
// Line 2
// Line 3
// Line 4 - targeted by line number
// Line 5
// Line 6
// Line 7 - targeted by range "7-8"
// Line 8 - targeted by range "7-8"

Selecting line marker types (mark, ins, del)

function demo() {
  console.log('this line is marked as deleted')
  // This line and the next one are marked as inserted
  console.log('this is the second inserted line')

  return 'this line uses the neutral default marker type'
}

Adding labels to line markers

// labeled-line-markers.jsx
<button
  role="button"
  {...props}
  value={value}
  className={buttonClassName}
  disabled={disabled}
  active={active}
>
  {children &&
    !active &&
    (typeof children === 'string' ? <span>{children}</span> : children)}
</button>

Adding long labels on their own lines

// labeled-line-markers.jsx
<button
  role="button"
  {...props}

  value={value}
  className={buttonClassName}

  disabled={disabled}
  active={active}
>

  {children &&
    !active &&
    (typeof children === 'string' ? <span>{children}</span> : children)}
</button>

Using diff-like syntax

+this line will be marked as inserted
-this line will be marked as deleted
this is a regular line

--- a/README.md
+++ b/README.md
@@ -1,3 +1,4 @@
+this is an actual diff file
-all contents will remain unmodified
 no whitespace will be removed either

Combining syntax highlighting with diff-like syntax

  function thisIsJavaScript() {
    // This entire block gets highlighted as JavaScript,
    // and we can still add diff markers to it!
-   console.log('Old code to be removed')
+   console.log('New and shiny code!')
  }

Marking individual text inside lines

function demo() {
  // Mark any given text inside lines
  return 'Multiple matches of the given text are supported';
}

Regular expressions

console.log('The words yes and yep will be marked.')

Escaping forward slashes

echo "Test" > /home/test.txt

Selecting inline marker types (mark, ins, del)

function demo() {
  console.log('These are inserted and deleted marker types');
  // The return statement uses the default marker type
  return true;
}

Word Wrap

Configuring word wrap per block

// Example with wrap
function getLongString() {
  return 'This is a very long string that will most probably not fit into the available space unless the container is extremely wide'
}

// Example with wrap=false
function getLongString() {
  return 'This is a very long string that will most probably not fit into the available space unless the container is extremely wide'
}

Configuring indentation of wrapped lines

// Example with preserveIndent (enabled by default)
function getLongString() {
  return 'This is a very long string that will most probably not fit into the available space unless the container is extremely wide'
}

// Example with preserveIndent=false
function getLongString() {
  return 'This is a very long string that will most probably not fit into the available space unless the container is extremely wide'
}

Collapsible Sections

// All this boilerplate setup code will be collapsed
import { someBoilerplateEngine } from '@example/some-boilerplate'
import { evenMoreBoilerplate } from '@example/even-more-boilerplate'

const engine = someBoilerplateEngine(evenMoreBoilerplate())

// This part of the code will be visible by default
engine.doSomething(1, 2, 3, calcFn)

function calcFn() {
  // You can have multiple collapsed sections
  const a = 1
  const b = 2
  const c = a + b

  // This will remain visible
  console.log(`Calculation result: ${a} + ${b} = ${c}`)
  return c
}

// All this code until the end of the block will be collapsed again
engine.closeConnection()
engine.freeMemory()
engine.shutdown({ reason: 'End of example boilerplate code' })

Line Numbers

Displaying line numbers per block

// This code block will show line numbers
console.log('Greetings from line 2!')
console.log('I am on line 3')

// Line numbers are disabled for this block
console.log('Hello?')
console.log('Sorry, do you know what line I am on?')

Changing the starting line number

console.log('Greetings from line 5!')
console.log('I am on line 6')