缘起
我在考虑为自己的MacBook选择笔记类和创作类应用时，曾对这两种活动作出区分，认为前者需要跟原文进行较多交互，更适合用富文本应用，后者中文学性创作则不需要太多对材料的整理，更适合纯文本应用。 这样的区分有一定意义，但不够深刻。更重要的是从信息流入和流出的角度来区分：笔记是一项整理活动，信息是流入方向，自然需要富文本的支持来应对广泛的信息来源；创作是一项产出活动，信息是流出方向，更需要不被打扰的环境，自然纯文本的方式更利于集中注意力。 从这一个角度上，我便理解了为什么Evernote在客户端编辑器如此不友好的情况下仍能如此受欢迎：Evernote不是一项应用，而是一项服务。这项服务更有竞争力的部分是它对其他来源信息的收纳和整合以及接口上的广泛性。它的客户端从设计上并非从创作出发的，而是定位于一个多种信息来源的入口（手写、语音、扫描、网页剪贴等）。因而，这也是它相对其他笔记类应用的护城河：你可以从不少文档标注、写作应用中找到“导出到Evernote”的出口，但其他笔记类应用很少能做到这一点。 下面，我对自己在文本信息整理和输出与文件存储同步方面的实践做一个整理，可以看作是信息方法论系列的续篇。
文本信息
正如我在“缘起”一节中讨论的，我的信息处理活动可按照信息流向来区分：收集、整理和归档等需要“富文本+”处理工具，而创作需要“纯文本+”工具。作为信息流入方，信息本身是带有各种格式的，而作为信息产出方，信息脱胎于键盘上敲出的每一个字符。
富文本+
包括：各种格式的文本（通常来自网络）、代码块（非项目源码）、文档文件（PDF等）、手写笔记及扫描件、部分图片（如截图）、录音和少量视频，对这些媒介间需要超出单纯文件夹管理的整理过程
推荐服务：OneNote、Evernote等
存储方式：整合多种格式文件和文字的“超文本”（通常为服务商定义）
纯文本+
包括：少量格式的文本（Markdown），项目代码等，仅通过文件夹就能在逻辑上进行整理分类
推荐应用：Ulysses、Typora等写作类应用（带有文件管理功能）配合DropBox等同步服务，VS Code等文本编辑器配合Git等版本控制工具
存储方式：文件夹整理下的纯文本文件（及少量静态文件）
文件存储与同步
原则（分先后）
- 非本地：原文件一定要在云端有备份，而非仅存在于设备中
- 跨平台：多终端访问、跟其他服务接口充分
- 集中性：某一类型的信息（如图片）尽量使用同一服务
- 就地性：优先考虑跟设备深度集成的服务
“热”数据和“冷”数据
“热”与“冷”本是数据中心对用户数据的区分，自身的文件管理中不妨也引入这一区分：使用中(Working)和已归档(Archived)。使用中则使用同步优先的服务，已归档则考虑存储。举例来说，常用设备上的应用软件数据显然属于“热”数据，而某次互动/任务产生的项目文件等则可以整理后归档，成为“冷”数据。 对于“热”数据，易获取和定期备份是首要需求，因此要求多平台的同步服务。而对于“冷”数据，长期可靠存储则可优先考虑，但对特殊的信息类型，我们还需要智能化的整理和索引，如Google Photos对照片的整理、Evernote和OneNote对文本文档的OCR索引等。
云同步与存储
偏向存储：
- Box(10G): 归档的文档文件（课件、电子书等）
- Google Drive(15G): Android系统配置的备份、Gmail附件等
- Mega(50G): 大型备份（私人文件备份、安装包等）
- Google Photos(unlimited): 照片、录像、保存的图片 偏向同步：
- DropBox(3G): 常用的文档文件跨平台同步
- iCloud(5G): macOS和iOS生态中应用文件同步（如MarginNote, Ulysses）
- Evernote(unlimited): 归档且有检索需求的文档文件、私人文件等
- GitHub/BitBucket(unlimited): 项目代码
- 自建NAS: 仅用于局域网跨平台同步
硬件存储
- 设备存储：Android, Linux, Windows尽量不作为唯一存储位置（常更新），Mac上可存储部分媒体文件和备份
- 移动硬盘：收藏的多媒体、照片录像等的源文件、系统备份、安装包备份等
总结
个人数字内容的管理对于我来讲是个不小的挑战，如何在数字时代更好的处理信息并为我所用，是我要持续思考的课题。