|
检视你的笔记数据安全和由此引申出来的笔记工具选择问题。
星友刘杰提问:
我们记录在相关工具上的笔记及相关内容,会不会因为什么原因(比如,工具背后的公司倒闭了)而无法再查看和调用了呢?如果有,会是哪些原因呢?谢谢
能有数据安全意识,这一点非常值得肯定。我们录入了这么多笔记,还进行了精心的整理,如果真的因为某些特殊原因全部丢掉,可能耽误你的重要工作目标和研究进展。
我觉得星友提出的问题很重要,具备普遍性,所以写下这篇文章作为答复,也一并分享给你。
咱们这篇文章,不局限在星友提出的设定(「公司倒闭」问题),也不仅谈论可能造成笔记数据「无法再查看和调用」的原因,而是从更加全面的角度来审视你的笔记数据安全和由此引申出来的笔记工具选择问题。
笔记工具里的数据,也需要存储在某个物理空间。目前,根据笔记软件特性的不同,有的存储在本地,例如 Obsidian, Logseq 等;有的存储在远程(一般是 SaaS 类软件),例如 Roam Research 和 Tana 等。
有人会认为,数据存储在本地更安心。这我同意。但有的人进一步认为,本地数据存储一定比远程好,这就有偏颇了。一般来讲,笔记数据存储在远程,会更有利于团队协作和分享。往小了说,也适合你拿起一台新设备登录进去就能立即开始干活儿。所以,咱们不应该有「本地存储更优」这样的偏见。
只不过,如果你使用的笔记工具数据只存储在远程,那么一旦它的服务器故障或者公司停止运营,那确实有可能造成你的数据损失。
未雨绸缪的话,你就需要定期导出数据。在本地保留一份,避免损失。一般来说 SaaS 笔记工具(数据存储在远程)都提供数据导出功能。例如 Roam Research ,你可以直接选择导出全部笔记,还包括了各种不同的格式。
不过,若你跟我一样比较懒。想到每天(甚至每个小时)手动执行一次这样的备份操作,便会觉得麻烦,难以坚持。怎么办呢?
这个时候,如果有高手替你解决,那想必是好。我之前给你介绍过,Matthieu Bizien 做的 这个 roam-to-git
Github 项目,可以自动帮你导出 Roam Research 的数据,非常好用。
在线笔记可以通过这样的方式同步到本地,那么如果你的笔记原本就存储在本地,是不是就根本不用进行任何操作了?
当然不是,如果笔记只有一份,那即便它在你的机器上,也会面临风险。这个时候,你就需要备份了。
前两天,朋友来问我,他备份内容硬盘全盘的时候,就差最后一个盘符了,结果中间死机,他使用了强制重启,然后电脑无法启动。他后来把硬盘拿了出来,装进硬盘盒,放到其他电脑上也依然无法读取。可偏偏重要的文件,都存储在了最后这个盘符下面,所以他很是苦恼。
我于是就问,你有没有备份啊?
他说,没有。一直觉得电脑就放在家里,又不来回搬运,硬盘存东西应该挺安全的。
唉,这就比较悲惨了。今天的存储设备,看起来比从前强大鲁棒很多,但其实也是有故障发生几率的。所以你一定要有备份意识。
存储在电脑硬盘中的数据,该如何备份呢?
我上课的时候问学生。他们大多的答案,就是 U 盘或者移动硬盘。这固然比不备份要好,但是依然不够安全。
想想看,你出门儿办事儿,背包里同时放了电脑和 U 盘,然后背包丢了…… 对很多专业人士来讲,那里存放的数据,真的是比硬件要贵很多。
我推荐的备份方式,是云备份。
云存储最大的好处,就是原始数据和备份数据在物理上可以分置在不同的地理位置,不在同一个城市,甚至是同一个时区。这样本地数据和远程数据同时发生故障乃至灾难(洪水、火灾、地震等)的几率很低。当然了,如果连你存储在不同大洲的云空间数据,都和你本地一起同时毁坏…… 那时候你最需要担心的,恐怕就不是数据安全了吧?
只不过,在选择云存储作为备份工具的时候,你一定谨慎选择。有的云存储自身就不靠谱,今天发现一个漏洞,明天爆出用户数据外泄…… 这样的云存储可千万不要用。
有的云存储虽然来自名牌大厂,但是口碑极差,时常发生莫名奇妙不能正确同步的问题,甚至有时还弄丢用户的数据。既然有其他选择,对这种服务咱还是绕开为好。
前面说完了数据导出和备份,下面咱们来讨论一下星友提出的设定,也即如果发生「公司倒闭」问题,是否会影响你查看和使用自己的笔记。这里就要涉及到你笔记数据存储的格式通用性与开放性问题。
有的笔记工具,采用通用格式。 例如Obsidian,用的是 Markdown 格式。支持 Markdown 读写的工具数不胜数。下面是 ChatGPT 帮我列出的部分软件名称。因为其中几款工具我别说用,连听都没听过,所以我不敢保证这个表格信息 100% 准确(你知道的,ChatGPT以一本正经瞎编内容著称)。但是支持 Markdown 的软件工具数量很多这一点,肯定没错。
使用 Markdown 这种格式的好处,是即便 Obsidian 不存在了(我希望不会发生),你也可以用任何一款支持 Markdown 格式的工具打开你的全部笔记。单单从笔记内容本身来讲,损失相对会很小。
有的笔记工具,采用自定义开放格式,例如 Tana 和 Roam Research 都使用支持细粒度双链的数据结构,只用 Markdown 不足以支持这种特性。但是你可以把它们的整个儿笔记库导出 JSON 格式。
JSON 这种格式,也可以用任意一款文本编辑器打开,你的每一条笔记都可以用文本方式检索到,所以可算是开放。但是 JSON 其实本身是一种「数据库」表现形式,自定义程度较高,文件里面包含了开发者定义的大量字段,包含了元数据的定义、时间戳、块标识符等等,一般只有该款软件自身可以完美导入。如果某款软件真的停止运营了,普通用户拿到这样的 JSON 导出格式,会左右为难。你说数据有损失吗?记录的内容倒是都在;可你要说拿过来用,往往看着满屏幕的引号、冒号、逗号、大括号、中括号…… 用户又束手无策。
好消息是笔记软件之间可能保持了格式兼容。例如说 Tana 和 Logseq 都支持导入 Roam Research 的 JSON 导出格式。
假如某天 Roam Research 不再运营了(我希望这种事儿永远不发生),你换用 Tana 或者 Logseq ,之前的笔记还能继续使用,甚至还能使用其中的链接跳转。只不过,这种兼容并非 100% ,普通用户可能会体会到各种问题,例如块引用(特别是嵌入引用)失效,标签无法自动转换成 Tana 应用中的 Supertag 等等。
至于另外的一些笔记,使用的就是较为封闭的格式了。这种笔记应用有的已经持续运行了 10 几年甚至更久,积累了大量的用户和他们的数据。封闭格式客观上形成了较高的迁移壁垒,使得用户一想到把笔记搬运到其他应用,就会感到痛苦不堪,继续选择留下。既然用户不想走,这些笔记应用可能会增加广告弹出频率,索取更高的订阅费用,或者对免费用户增添更强的限制(例如减少同时在线的设备等)。这种应用一旦被收购,别说功能更新,可能连原有的维护都难以保障。如果你还没有开始订阅,我建议你尽量不要订购这种使用封闭格式的应用,免得将来被锁定。如果你是老用户,也可以多关注 其他应用提供的转换工具。
看到这里,你可能会武断认定采用通用格式(例如 Markdown )一定是最好的,自定义开放格式(例如 JSON 或者 EDN)就不甚理想。在很多论坛和社区中,我也经常看见有的小伙伴这样宣称,并且将这一标准奉为选择软件工具的圭臬。
其实情况并非如此。以 Markdown 为例,它根本就不是存储数据的理想方式,而是一种简化的 HTML 格式。从它发布之日起,就是为了形式与内容分离,让写网页不那么痛苦而已。经典款 Markdown 并不具备很多种数据类型的表达形式,尤其是缺乏笔记项目之间的关联能力。想当初某款以 Markdown 为基础的笔记软件为了想实现块引用(block reference)功能,不得不在 Markdown 语法基础上加了不少「魔改」操作。
这里还有一个效率问题。 Markdown 只是纯文本,你的笔记库的基础也就是一堆纯文本文件。随着笔记条目的不断增多,查询检索、批量更新同步等操作执行效率无法和专业级别的数据库相比,你可能会感受到明显延迟。
看到这儿,你可能会想这太让人纠结了。要格式开放、本地化存储的笔记软件,就得放弃各种高级特性和效率;要使用在线、功能强大的笔记应用,就无法用开放兼容的本地化形式实时存储与掌控数据了呗?
谁说的?
简单、开放、功能强大这些要素,在笔记软件这里其实并不矛盾。下面我用最近刚刚发布 1.0 版本的 Heptabase 举个例子。
Heptabase 早就把数据存储的方式从原本的 Markdown 转换成了专业数据库,而且本地优先存储。本地优先就意味着,离线的时候 Heptabase 可以照用不误,正常输入内容。
当然,Heptabase 也提供了在线同步选项,以便于多台设备实时同步数据。经过本人实际测试,目前在 MacOS, Windows 和 iOS 设备之间同步内容,速度非常快。
如果没有网络,你也可以在某台设备上随便修改。等有了网络链接,Heptabase 自动更新和同步内容。
在官方 Wiki 上,Heptabase 的开发团队说明了数据同步的安全性问题,加密等因素早就考虑在内。
那下面就是你最关心的问题了 ——Heptabase 数据开放性怎么样?万一 Heptabase 将来不继续运营了(再一次强调,我希望这种事儿不要发生),我的数据咋办?
Heptabase 不但把数据优先存储于本地,还给你提供了自动备份的选项。
例如我最近一段时间的 Heptabase 备份文件列表是这样的。
自动备份的文件是个压缩包。打开后,其中的 Card Library 包含了全部 Markdown 格式笔记。
就连 Heptabase 中全部的白板,也都在 Whiteboards 目录下用 Markdown 形式导出了。
在 Typora (一款我常用的 Markdown 编辑器)打开这里白板的 Markdown ,你可以看到里面包含了所有白板中卡片的链接。
而且,这里除了卡片,还有其他类型的内容分类。
只不过我打开的这个白板里面,没有 PDF 文件、Readwise 高亮等内容,所以这些部分是空的。
从上面的介绍中,你可以看到笔记应用可以同时满足本地优先、足够专业的数据库、支持丰富内容类型、自动多设备同步与备份,而且还能导出 Markdown 格式以便于其他工具的承接和数据利用。
我这不是给你强行安利 Heptabase ,而是告诉你上述功能的实现并非用户单纯的幻想。在笔记工具里,鱼(长期保存格式)和熊掌(功能保障),确实可以兼得。
下面,咱们接着来谈一谈你可能关心的另一个问题 —— 现在有这么多功能各异的笔记应用,究竟该如何选择?
首先,再次重申张玉新老师(善用佳软)的原则 ——「重器轻用」。你没有必要只选一款笔记应用,也没有义务把每一款工具的功能都面面俱到学习并且用到极致。你完全可以使用多款软件,组合成系统帮助自己完成任务。对其中的每一款应用,也可以只用它最擅长的特色功能。
以我个人为例,我确实非常喜欢 Heptabase 。目前凡是坐在电脑前的笔记输入和内容采集,以及之后的整理、整合输出初稿环节,我基本上都在 Heptabase 完成。它不仅在设备之间同步数据速度很快,就连和 Readwise Reader 的联动速度,也非常惊艳。
但是我目前的瞬时笔记录入更多采用 Tana 。Tana 的手机端应用叫做 Tana Capture 。
因为 Tana 的数据在远端,而且支持调用 AIGC (例如 ChatGPT 和 GPT-4)模型的 API,所以你可以用它完成非常惊艳的操作。包括但不限于 语音笔记录入和自动润色、文字 OCR、网址自动解析内容、一键整理打标签挪到对应日期……
对我来说 Tana 和 Heptabase 现在的状态有很大的互补性,目前二者配合起来使用,可以满足我大部分的笔记应用场景。当然,它们都不是开发者设计的终极形态,也都在快速进化中。
但是你是不是看到了我用 Heptabase 和 Tana ,就也要用这两款工具呢?
当然不是。你和我的笔记需求,或许有很大的差别。我们关注的笔记工具特性,可能也并不一致。适合我的工具,未必适合你。各种笔记工具群里,都有用户表达他们对当前使用工具的喜好,不管是 Roam Research, Logseq, flomo 还是 Workflowy,都有自己的拥趸,而且这些工具确实帮助用户们完成了自己的目标。
另外,你不应该忽略另外一个重要因素——成本。每个人,都有自己的预算约束。同样的价格,给每个用户的感受是不一样的。特别是要考虑到心理账户效应。有的人花好几百块去听演唱会,歌星台上不唱他跟台下观众一起自己唱,也觉得超值。但是一款软件应用年度订阅费超过了100元,他就觉得很烦怒,认为开发者用心不良,简直是来割韭菜的。
Obsidian 为什么这么受欢迎?因为它的基础功能是免费的,而且对很多用户来讲足够用。因为受众群体足够大,很多开发者愿意为Obsidian开发各种插件,这更强化了Obsidian的用户黏性。如果你尝试Obsidian觉得很够用,但这些插件和功能让你眼花缭乱,可以先看看 「Johnny 学老师」的免费教程,快速掌握基础功能。
如果 Obsidian 的功能可以充分满足你的要求,你也没感觉执行效率上明显的延迟,那么祝贺你 —— 软件和数据都在本地存储,免费,存储格式开放(Markdown),不必担心被锁死在特定软件里,perfect!
不过如果你跟我一样,积攒的笔记条目已经达到了这种量级,块引用的数量也成千上万,效率问题或许就不能忽略了。
这时候,恐怕还是选择数据库作为底层的软件工具,会更适合你。
本文从星友刘杰的问题讲起,咱们提到了数据在远程和本地的笔记应用,该如何分别处理导出和备份问题,保障数据的基础安全。数据存储与导出格式,对数据长期利用的影响。
远程同步,并不意味着不能「本地优先」;包含白板、PDF 标注阅读,支持视频、音频和任意文件格式,也并不耽误 Markdown 格式的全库导出。
咱们讨论了笔记应用的选择。我谈到了一些应该尽量避免的坑,再次强调了「适合自己」的原则与「重器轻用」的理念。
希望今天的介绍,对你从数据安全性和持久利用角度考察软件工具的选择能有帮助。
对了,提醒一下,如果你决定使用付费软件,付费之前一定要看看用户风评,另外查看一下有没有教育优惠。如果你是学生或教师,很多情况下都可以用更便宜的方式订阅和购买软件,千万别浪费了自己的权益。
祝笔记工具使用安全和愉快!
如果你觉得本文有用,请点赞。
如果本文可能对你的朋友有帮助,请转发给他们。
欢迎关注我的专栏,以便及时收到后续的更新内容。
Archiver|手机版|科学网 ( 京ICP备07017567号-12 )
GMT+8, 2024-12-22 16:28
Powered by ScienceNet.cn
Copyright © 2007- 中国科学报社