剪藏网页到本地的自动化思路（以 Keyboard Maestro 为例）

线上的内容——包括您正在阅读的这篇文章——从来都不属于读者，除非你把它从线上扒到本地。在 《一种将线上内容精简格式后保存到本地的方法》 中，Hum 介绍了我们保存网页的基础思路。

很明显，即便是方案设计者本人也不会照本宣科，每次都走一遍连篇累牍的操作。一旦确定操作流程，我就着手将剪藏网页的步骤打包成自动化动作。这篇文章基于 Safari 和 Keyboard Maestro，给出一套自动（或许是半自动）获取阅读模式 HTML 的方案，将前文的方法变成简单的一次点击。

>> Keyboard Maestro Macro 下载 <<

本文方案理论上也可以用 Shortcuts 实现，但涉及太多键鼠操作的模拟，恐怕还是 Keyboard Maestro 最为直接。示例文章为 Timothy Furstnau 的 GARDEN AS SHELTER。

操作过程

将网页剪藏为洁净的 PDF，主要分两步，第一步是获取阅读模式的 HTML，第二步则是将该源码转化为 PDF，本文只负责前一环节——也是操作最复杂的部分。尝试过手动复制网页源码的读者，都会面对一个仪表盘一样复杂的界面；对于不懂网页开发的人而言，这就像一个刚刚打开的胸腔，而一旁的助手正把手术刀递给你。

即便对整个流程轻车熟路，我也不喜欢手动抓取数据，就好比能够用无创器械自动完成手术，就没有必要开膛破肚搞得血肉模糊。尽管整个流程较长，但不过是一系列的鼠标点击和键盘点按操作，完全可以打包成固定的 Keyboard Maestro Macro。¹下载文章开头的 Macro 后，安装，启用（Enable），然后根据你的电脑语言调整开头的几个步骤。

盖此动作模拟点击 Safari 菜单栏，而不同语言环境下的菜单栏项目名称当然不同（更不要说不同的浏览器）。例如英文系统下的“Show Web Inspector”，在中文环境中就应当是“显示网页检查器”。²鉴于只是模拟操作，日后即便 Safari 改动了菜单栏和快捷键，Keyboard Maestro 这边也只需要作出对应调整，而难以想象原则上的不兼容。

Macro 中有很多容错设计，比如无论当前是否进入阅读模式，Macro 都会根据实际情况作出判断，确保最终能够打开阅读模式。但如果你曾经点击过 Web Inspector 的其他标签页，则需要先手动切换回 Elements 页面，才能获取 HTML 源码。³

接着，调整保存 HTML 文件的位置。本方案原本是为 DEVONthink 设计，保存位置当然是 DEVONthink 的收件箱（Inbox）文件夹，完整文件路径即图中的 /Users/min/Library/Application Support/DEVONthink 3/Inbox/%SafariTitle%.html。这个路径只是我电脑中的情况，你可以自行修改，例如直接丢到下载文件夹：~/Downloads/%SafariTitle%.html。当然，Keyboard Maestro 在图形化上走得很远，点一下图中的粉紫色文件夹图标即可选择保存位置，不需要手动输入路径。⁴

至于原路径中的 %SafariTitle%，这是 Keyboard Maestro 的一个自带变量，用于获取 Safari 当前页面的标题，借此可以用文章标题来命名 HTML 文件。如上配置之后，Macro 应可正常运行；其他无需的更改的细节，则不再提及。

此外，我出于个人偏好而在剪藏的 HTML 文件中插入了网站链接，以免日后找不到原始出处。阅读模式并不会抓取网页的链接信息，而通过 DEVONthink 生成的 PDF 也不再带有链接元数据（直接从浏览器打印的 PDF 则有），因此我增加了这一信息，如果介意，可以删掉 Macro 中的如下步骤。

获得 HTML 文件之后，即可在 DEVONthink 中进一步编辑，当然，一般来说 Safari 阅读模式的效果已经足够干净，例如下图，不需要太多后续加工就很清爽——这正是我最初认同用阅读模式来排版的原因：足够省心。

最后一步，就是导出适合阅读的 PDF，用 DEVONthink 生成的连续 PDF 最大程度上保留了阅读模式在 Safari 上的观感，保有背景，仿佛至于素色书桌上的白纸。当然，这个效果见仁见智，比如我本人在使用一段时间后就觉得太奢侈，在笔记本电脑上用恐怕太占空间——这正是后续文章的一个起点。

和对照翻译结合

径直收藏原文，固然看上去有些格调，但如果因此阻碍了阅读，恐怕就是打肿脸充胖子。在 《一种几乎永不失效的网页中英对照翻译方案》 中，我设计了一套通行于主流浏览器的对照翻译方法，而获得的页面，同样可以用本文的自动化方法剪藏至本地，以便阅读。

保存 PDF 的本意就是方便阅读，就像有些人会把文档打印成纸质件，再摆开文房诸宝，大战一场；我还不到这个地步，但在 PDF 上纵横捭阖一番，用上各种批注工具，也总比直接读网页来得舒服。既然是为了读，则当然不介意带上译文：先用 前文 方法获得一行原文一行译文的页面，再用本文方法获得 HTML 源码。

获得 HTML 源码后，同样可用 DEVONthink 生成或连续或间断的 PDF，留待阅读时批注。惟需留意，连续的 PDF 通常不分页，即便分，也只是在页面太长时剖作两三份，已不复有“页码”的概念，可能不便于日后引用；我在 《Keyboard Maestro 页面链接》（十月下旬发布） 中介绍的页面链接方案，与连续的 PDF 并不兼容。毕竟 PDF 本身限制较多，没法做到两头都甜，我能给出的建议就是：能分页就分页。不分页，主要是为了避免图片被腰斩，如果文章全是文字或仅在开头出现一张题图，则没有生成连续 PDF 的必要——顺便也省去折腾 DEVONthink 或其他工具，直接在 Safari 中打开 HTML 文件，按下 ⌘Command-P 即可。即便是有配图的文章，也可以先做成分页 PDF 看看效果，如果并没有图片被截断或者其他显示异常，则并无太大必要制作连续的 PDF（除了审美方面的原因）。

在 Hum 的 文章 发布后，部分读者感到不解，何不使用现成的网页剪藏服务？相信这一节已经给出了答案。如果使用已经设计好的服务，即便我有办法把对照翻译方案融合进去，那也只是为一个特定工具——很可能是特定插件——写插件，相当于在摇摇欲坠的叠叠高（Jenga）之塔上再放一块积木，实在不保险。

小结

网页剪藏是一门生意，你可以看到很多号称一站式解决问题的服务，并且它们的野心远远不止剪藏，还包括笔记、稍后读乃至复习回顾。最后，服务总会变成一个社交网络，而讨论这些工具孰好孰坏，也就容易引发拖家带口的争论，毫无营养。

本文只是对 Hum 文章的一个补充，将原本复杂的手动操作封装为自动流程，但不敢号称是结案式的解决方案；相反，我更喜欢当前这种松散的工具集合（set），盖任何一个步骤出现问题，都可以找到替换工具。试想一个木匠的工具箱，如果里面少了一把锤子，他只需要找一块不算太滑溜的鹅卵石凑合；而当他的墨线老化断裂时，也可以从针线盒里抽一段较粗的缝纫线顶上。考虑到阅读是一件如此私人而长期的事，前述的灵活与自在，可能比依赖某个具体软件更好。

🛍 我撰写的付费栏目《信息管理，文件为本位的方案》正在 UNTAG 售卖，对本文话题有进一步讨论，欢迎选购。

🔗 付费栏目链接