各位读者及会员，喜迎双年，UNTAG 也将推出持续一个月的 Premium 年度特辑。
UNTAG Premium 年度特辑的形式为“一配多”。一篇 UNTAG 成员的年度推荐，加上多篇其它成员的常规 Premium 内容分享。
本期的年度推荐来自文刀漢三，年度推荐的品类为相机。
本期内容目录：
- 年度硬件：相机
- 为什么要在日历做倒数日
- 一个解剖在线文章的新维度：标出所有链接（附自动化）
- 哔哩哔哩第三方 TV 客户端
- DEVONthink 自动化：自动把特定的 HTML 转换为 PDF 的方法
- 自动跳过验证码的 AI - Chrome 插件推荐
- macOS 杂症自查：为什么两千块钱的移动硬盘慢得像 USB 2.0
- 我出门一定会带上的拓展插座
年度硬件：相机
作者：@文刀漢三
手机拍照越来越好，为什么还要买相机？
早在 2016 年，Flickr 发布的年度报告中就表示，手机已经是最受欢迎的相机（其中 iPhone 是最受欢迎的拍照手机），紧接着才是佳能、尼康等传统相机厂商。拍照，已经成为近几年智能手机的兵家必争之地，从计算摄影，到色彩方案，再到大底传感器，很多发布会甚至拿出单反样张作为对比，社交媒体也常常对“猜猜这张照片是手机还是单反拍的”这类游戏乐此不疲。手机，似乎已经有了一股追赶相机之势。
那么，在手机拍照功能越来越强的今天，我为什么还要买一台“传统”相机？
首先，是画质的区别。我在用手机拍照的时候，光线稍微一暗，就常常觉得画面噪点多了起来。尤其我又喜欢用 2 倍（50mm）的焦距拍摄，弱光环境下画质更是直线下降。
受限于便携性和镜头尺寸，手机使用的传感器尺寸往往在一英寸以下，而主流相机采用的传感器尺寸则是半画幅（APS-C 画幅）和全画幅。通过下面这张图，你可以明显看到两者的尺寸区别：
传感器尺寸对于画质的影响很明显，摄影圈也一直盛传着“底大一级压死人”的说法，这里的“底”，指的就是传感器的尺寸。同样技术条件下，更大的传感器，意味着更大的单像素尺寸和更高的像素数量，弱光环境下照片噪点更少，画面的纯净程度也更高。
其次，是裁切的自由。一次构图到位当然是最理想的摄影，但现实并不如此，尤其是拍摄一些生活中出其不意的场景，能拍到才是最重要的，因此往往需要借助裁切进行二次构图。
iPhone 默认的 1200 万像素稍微裁切放大一下，马赛克就很容易显现出来，很不经裁。虽说 iPhone 14 Pro 已经可以拍 4800 万像素，但出于储存容量的考虑，把 4800 万像素当作日常拍摄还是有些压力。
主流相机通常在 2000 万像素以上，裁切后在手机屏幕上仍然能保持很高的画面质量，不用过于担心前期构图的不足。
最后，是虚化的自然程度。iPhone 的人像模式诞生于 2016 年，随 iPhone 7 Plus 发布，即使发展到今天已经快 8 年了，仍然有一定的失败概率，遇到眼镜、发丝、半透明材质等场景时，稍微放大一点就很容易露馅。用 iPhone 的正常模式拍照的话，虚化则几乎弱得看不出来。
如果去苹果的官网看一眼 iPhone 参数表，你可能会很纳闷，iPhone 的主摄光圈已经达到 ƒ/1.78，理论上应该可以算作“大光圈”呀，为什么拍不出相机那样的虚化效果呢？其实，iPhone 的光圈是在“等效焦距”下算出来的，而照片的虚化程度和光圈、实际焦距、距离这三个因素有关。把 iPhone 14 Pro 主摄像头 24mm 的等效焦距换算成全画幅的焦距，大约才 6.86mm，虚化效果自然大打折扣。
选相机总要放弃一些东西
我没法在这篇文章里给出一套全面的选购指南，因为我自己在对相机的研究过程中，发现相机是一个无法做到各方面都尽善尽美的器件。画质、焦段、便携、设计、其它功能（如闪光灯、滤镜等），总有几个方面不如预期。我们只能权衡轻重，挑选对自己的最重要的几个属性，然后放弃一些执着。
比如我，画质的要求是半画幅以上够用，像素在 2000 至 3000 万像素之间，储存压力不会太大。自己不会调色，所以首选富士，自带一系列很耐看的滤镜。焦段和便携，我选了后者。所以最后是买的是富士 X100V，等效 35mm 焦距，可进可退——靠近一步可拍人像，后退一步可拍风景。定焦的好处是画质更好、光圈更大、镜头尺寸更合理一些。此外 X100V 还带有很好看的外观设计，增加带出去的欲望。类似的相机还有富士的 XE4，区别是可换镜头，不过今年可能会出新款，大家谨慎购买。
更爱用手机拍照了
对于我来说用相机拍照是一种模式的转换，意味着“要开始认真拍照了”，因此会更加专注观察身边的事物，明暗的光影、跳脱的色彩、有趣的人和物，那些动人的瞬间开始密集地钻进我的眼睛里。我并没有因此错失对这些瞬间的体验，反而因为观察得更加仔细，更能享受到这些氛围内。
享受用相机拍照，并不意味着手机被我冷落。在不携带相机的日常里，我发现自己更爱用手机拍照了，也更容易发现日常生活中那些值得记录的时刻，然后用随身携带的手机拍下。
One More Thing，年度小配件：Lightning 转 SD 卡读卡器
手机拍照强大的一点在于从拍摄到后期再到分享的全流程打通，而相机的后期和分享流程则没那么方便。各家相机厂商虽然都有推出对应 app，但无线传输太慢，连接也不稳定。在我认识的爱拍照的朋友里，居然很多都不知道苹果出过一款 Lightning 转 SD 卡读卡器，用自带的相册应用就能读取，传输速度比无线快很多，并且还会识别哪些已经保存过，方便筛选。
补充一个读卡器小技巧：在导入预览界面，双指捏合一下照片，即可放大预览显示。
最后祝大家快乐拍照，拍照快乐！
为什么要在日历做倒数日
作者：@Hum
@Minja 上周写了一篇文章介绍了在 iOS 设备上用日历做倒数日的方法。如其在文末所提，创意来源于和我的一次交流。然而我看了 Minja 的文章后，意识到我们用日历做倒数日的目的和方法都不太一样，所以在此也分享一下我的理由。
iOS 上，做一个展示每天随时可以看到各种我需要的信息的 Dashboard，是我一直以来的愿望。特别是用了 iPad 之后，这个拿在手里的屏幕太适合做一个浏览关键数据的 Dashboard。但是一直以来没有合适的 App。本来最有可能实现我愿望的 Panic 的 Status Board，最后也下架停止维护……
在这个 Dashboard 里，倒数日是个很关键的功能。因为很多事情，记它的 Deadline，只会让你措手不及。比如纪念日、假期、产品保修结束等，都是需要提前做好准备的事情。
iOS 14 之后，第三方 App 也可以跟进桌面小组件（Widget）。那为什么还要在日历里做这个倒数日？我这里的理由有两个。
第一，充分利用 iPad 的大日历部件空间。iOS 14 之后，苹果原生日历 App 的大 Widget 震惊了我。这确实是个从各个维度展示日历事件的好方式：
- 短期可以展示时间块
- 长期可以展示 4 天的全天日历事件
- 还对今天的日历事件有特写
这一下让原生日历从日历品类 App 里脱颖而出（起码在展示方面）。既然把日历的 Widget 放到桌面，再放个倒数日，就会有点浪费空间的感觉。
第二，倒数日 App 不够灵活。如果说第一项只是审美原因，第二项则是功能性原因。
倒数日 App 的 Widget，只能长期显示几个固定的事件倒数，而不能做到该显示的时候显示。它相当于你挂了一堆“全天日历事件”在那个位置。
拿纪念日来说，用倒数日类的 App，过了之后还剩 364 天它也要给你挂着占个地方。好一点的它会把这个日期降到列表底端。而用日历做倒数日则不同。它只是根据你的设置，提前几天才显示。每年循环的纪念日，我们要提前一周订餐馆准备礼物。那可以设置每年这一周在日历上显示“纪念日还有7天”直到“纪念日还有1天”。
这样，日历 Widget 里的倒数日就是在不停轮换的。每个需要倒数的事件都是在需要它出现的时候才出现，不会长期持续置顶。
原则上，日历 Widget 完全可以替代倒数日 App 部件。但是毕竟日历是比较聚合的工具，并非为倒数日设计；肯定有人会因为使用惯性拒绝。对于前者，Minja 已经写了教程和分享了 Shortcuts。对于后者，可以先试试把一些常规的倒数日事项放到倒数日 App 里，把一些临时的放到日历里。也许慢慢就能感受到用日历 Widget 来做倒数日的道理。
一个解剖在线文章的新维度：标出所有链接（附自动化）
作者：@Minja
李敖和读文章可以像品菜，不直接下筷子，而是观、闻、戳上一番，在正式阅读之前先从各个维度观察一下，有所准备再下嘴。我最近养成一个新习惯，就是读文章时用 Keyboard Maestro 自动标出其中的链接。
你可以在这里下载 Keyboard Maestro 动作，用于在 Safari 中自动标出所有链接（默认快捷键是 ⌘Command-K），也可以直接使用下面的 bookmarklet 版本。
javascript:var%20%24jscomp%3D%24jscomp%7C%7C%7B%7D%3B%24jscomp.scope%3D%7B%7D%3B%24jscomp.arrayIteratorImpl%3Dfunction(a)%7Bvar%20b%3D0%3Breturn%20function()%7Breturn%20b%3Ca.length%3F%7Bdone%3A!1%2Cvalue%3Aa%5Bb%2B%2B%5D%7D%3A%7Bdone%3A!0%7D%7D%7D%3B%24jscomp.arrayIterator%3Dfunction(a)%7Breturn%7Bnext%3A%24jscomp.arrayIteratorImpl(a)%7D%7D%3B%24jscomp.makeIterator%3Dfunction(a)%7Bvar%20b%3D%22undefined%22!%3Dtypeof%20Symbol%26%26Symbol.iterator%26%26a%5BSymbol.iterator%5D%3Bif(b)return%20b.call(a)%3Bif(%22number%22%3D%3Dtypeof%20a.length)return%20%24jscomp.arrayIterator(a)%3Bthrow%20Error(String(a)%2B%22%20is%20not%20an%20iterable%20or%20ArrayLike%22)%3B%7D%3Bfor(var%20%24jscomp%24iter%240%3D%24jscomp.makeIterator(document.querySelectorAll(%22a%22))%2C%24jscomp%24key%24node%3D%24jscomp%24iter%240.next()%3B!%24jscomp%24key%24node.done%3B%24jscomp%24key%24node%3D%24jscomp%24iter%240.next())%7Bvar%20node%3D%24jscomp%24key%24node.value%3Bnode.setAttribute(%22style%22%2C%22background-color%3Alightblue%22)%7D%3Bvoid+0)
这个貌似强迫症——而且还是颜值很低的强迫症——的做法，背后其实是一整套的阅读体系。我在《当代人的丛林狩猎：在线阅读》中借用了“狩猎”隐喻，认为读文章就像打猎，需要辗转多个场所，而浏览器也只是其中一环，还不到真正“读”的时候，尚在判断文章要不要精读。但我发现，网页文章中链接甚多，总是读着读着就忍不住点下去——有时候是真的不懂，需要阅读前文；更多时候是按耐不住好奇心——这把我一次又一次拉回狩猎场，惹得一身泥泞，无法脱离网络、专心解牛。为了抵抗链接引力，我不得不接受“延迟阅读”的新方式，先把每篇文章中感兴趣的链接都打开，从中挑选需要进一步阅读的文章，待满载而归中之后才开始阅读。
在打猎式的阅读流程中，相当一部分力气花在信息筛选上，因而也需要降低阻力的工具，比如说，标出文章中的所有链接，省得我盯着正文一个一个去找——那就要通读一遍，太花时间了（更不要说有些网页的链接特意做得很隐蔽，不仔细看都不知道有链接）。现成的工具主要用于过滤，比如 DEVONthink 可以挑出文中所有链接，Brett 开发的 LinkChecker 同样是汇集链接，遇上排版矜持的网站还不错，但撞上那种侧边栏塞满东西的页面或者在广告里面插播文章的网站，抓出所有链接似乎不是好主意。我转而想到一个简单而可靠的方法，就是用 Javascript 找到文中所有链接，然后把它们设置成特殊的样式，示例动作是蓝色底色的高亮，模仿淡蓝色荧光笔。
如上处理之后，我可以快速扫过文章，看到链接时就停一停，瞄一眼上下文，感觉非读不可就打开，然后对打开的页面一一如法迭代，不一会儿就可以梳理出一簇需要读的文章；另一方面，垃圾链接也会被提前标出来，当场就可以用各种工具删掉（BBC 就喜欢往正文里面插文章推荐，且字体与正文一致，实属非常恶劣的误导，我曾经读着读着感觉不对劲，才发现文章被动了手脚）。此般网罗相关材料，之后就可以放心地在本地阅读，而不需要读几段就停下来上网找资料。
哔哩哔哩第三方 TV 客户端
作者：@沨沄极客
过年期间，常有好友来家中做客。有时候想分享一些最近看过的视频。然而家中最适合大家一起欣赏的设备：电视，却不太有用武之地。
无论是投屏还是打开 TV 版本电视应用，视频流媒体总会给出一些令人难受的限制，比如哔哩哔哩的官方 TV 版不提供弹幕，比如爱奇艺部分影片无法投屏……关于这件事，以后我再分享我的破局方法。
今天我想推荐一个第三方的哔哩哔哩 TV 版客户端 BBLL。据开发者称，这个客户端没有任何破解行为，是对于哔哩哔哩已有的 API 进行封装，所有的数据都来自于官方 API。
? GitHub 链接
BBLL 作为第三方客户端主要解决了几个问题，一是打破了未登录用户仅有 360P 画质的限制，二是补全了官方 TV 客户端缺失的弹幕功能，三是能够观看超出官方 TV 客户端限制范围的视频。光是这几点就已经非常值得一试了。
在这个基础上，BBLL 还做了一套适合 TV 端使用的 UI 界面，布局也比较合理，适合使用遥控器进行操作。
DEVONthink 自动化：自动把特定的 HTML 转换为 PDF 的方法
作者：@Hum
在《一种将线上内容精简格式后保存到本地的方法》里，我提到我们可以利用 DEVONthink 的 Smart Rule 来自动把保存了的 HTML 给转换为 PDF。
这个操作的思路非常简单，大家一定能意识到它的原理是：
- 当——发现 HTML 格式的文件
- 就——把这个 HTML 文件转化为 PDF
这个思路是可行的但也是非常粗糙的。因为它会错误地把不属于文章的网页给转化了。比如说我们因为设计精美而保存的那些网页，保存为 PDF 会让很多设计元素消失。
所以在这里，我们必须动一个小脑子。这个小脑子很基础也很重要。基础在于，它只是在 HTML 里加了一小段代码；重要在于，是个通用思路，并非仅能在 DEVONthink 的这个场景下里使用。
实操过程
当我们用 Keyboard Maestro 把网页自动保存的时候，我们是在保存它的 HTML 代码。所以，这些代码都是可以修改的。所以，我们可以往 HTML 代码里加一段东西（比如 HTMLtoPDF）。然后告诉 DEVONthink，只要识别了这段东西，就把它转为 PDF。
在一个以文章为主体的 HTML 里，通常有两个部分，一个是 <head>，一个是 <body>。<head> 给这个 HTML 定义了很多属性，<body> 则是网页的本体。
如果我们粗暴地在 <body> 里加东西，然后让 DEVONthink 去匹配这段文字。那首先会影响文章内容；其次如果匹配的关键字没