知识管理、文件（标签）管理的一种尝试

[SuperMild]

一般来说，一个知识管理系统可以考虑的方案主要有以下几种：

1. 全部数据进数据库，每次需要使用的时候再从数据库中读出，通过软件界面呈现给用户。
2. 文件保留在文件系统中，只把与文件一一对应的标签、描述、评星等数据保存在数据库中。
3. 不使用数据库，而是生成一个与文件对应的描述文件，在该描述文件中记录对应文件的标签、描述、评星等数据。

第 1 种方案最常见，比如 Evernote, OneNote 等都采用这种方案，这种方案自然有很多优点，但也有一个明显缺点：无法与其他软件合作。比如，如果用 Evernote 来储存图片，就无法用看图软件直接看图，也无法用修图软件直接修图。

第 2 种方案也能偶尔见到，一般懂编程的人自己想写一个软件来管理本地文件，很可能采用这个方案。

我现在就是想做一个本地的 文件管理工具, 具体来说就是文件的标签管理工具。本该采用第 2 种方案，但是我突发奇想，能不能采用最容易被否定的第 3 种方案？

第 3 种方案由于会产生大量小文件，因此被人讨厌。但当我真的去把它做出来的时候，经过试用，发现它也有很多好处啊！

多仓库共存

• 采用第 1 种、第 2 种方案时，通常一台电脑里只能有一个账号（或仓库），但我采用第 3 种方案后，发现多仓库共存变得非常容易。
• 比如，用户可能希望把工作和生活分开，建立各自独立的仓库。
• 也可能希望对一类文件单独建立仓库，比如全部自己拍的照片一个仓库，除此之外的其他文件一个通用仓库。
• 由于现在很多人使用笔记本电脑，硬盘容量有限，于是很可能希望在电脑硬盘里建立一个小仓库，在移动硬盘里建立一个大仓库，定期把小仓库的文件移动到大仓库里。

在不同的仓库之间交流时，不需要导入导出。

• 如果使用 Evernote, 如果你想把一份笔记发给朋友，或者你自己有两个账号，想把其中一个账号的笔记移动到另一个账号里，那就需要先导出笔记，再导入笔记。
• 而采用第 3 种方案就很方便了，直接复制或剪切即可。
• 比如上面“多仓库共存”里所述的最后一种情况，把小仓库的东西移到大仓库里的情况，采用第 3 种方案就非常非常方便，直接移动文件即可。

随意移动文件位置，文件夹随意改名。

• 第 2 种方案有一个缺点，移动文件位置、文件夹改名、文件改名都需要在软件界面里进行，因为它的数据库必须对应文件位置和文件名，一旦移动，就对应不上了。
• 而第 3 种方案，信息都在“描述文件”里，只要移动文件的时候把描述文件一起移动即可，信息与文件位置无关。
• 实际使用中，我发现移动文件位置和文件夹改名是很频繁发生的操作，这导致第 2 种方案很不方便。

局部备份到网盘

• 如果采用第 2 种方案，局部备份到网盘将是一个很麻烦的任务，因为标签等信息都在数据库里，与文件是分离的，如果只上传一部分文件到网盘，文件位置（目录）可能发生变化，数据库就对应不上。
• 而如果采用第 3 种方案，那就非常轻松、简单了，完全不受文件位置（目录）的影响，网盘那边随便建一个文件夹即可，只要连同描述文件一起，就可以心情轻松地上传, 重点：信息全在描述文件里！ 不需要备份数据库，不需要管文件位置。

容易定制，容易扩展

• 我根据上述的理念，写了一堆处理描述文件的脚本程序，但我没有把它们整合为一个大而全的软件。
• 虽然我写了一堆程序，有 GUI 界面，可以对文件添加标签、修改标签，对标签进行一些简单管理。但说做了一个软件却不太准确，因为这套东西甚至没有一个固定的形态。
• 比如我这套东西里面最最核心，最重要的就是那个所谓的“描述文件”，是一个 json 文件，但就连它都是可以随意定制的。
• 准确来说，我是考虑到上面所述很少人采用的第 3 种方案的优点，做了一个尝试和示范，结果发现还蛮好用的。
• 由于这个理念本身非常简单，就是处理 json 文件而已，任何编程语言，最基本的编程知识就能做到，因此如果你也想尝试用第 3 种方案来打造自己的知识管理系统，大可以参考这个办法，用自己熟悉的技术栈来做。

代码: https://github.com/ahui2016/bijibiji-project （水平有限，请多包涵）

[aoaoho]

开放式（非私有格式&工具）的文件管理方式也是我特别看重的，我尝试过一些方案，都没有达到预期，包括现在在用 DEVONthink。

楼主有没有用过 DEVONthink （主界面见图 1 ）？说几点供你参考：
1. 它支持多库，每个库其实就是一个文件夹，在软件内创建的文件会按照扩展名（先不评价这种方式）放在文件系统内（见图 2 ）；
1. 文件在软件内也有选项供使用外部应用打开；
1. 它其中一个功能是，可以把操作系统的文件夹「挂载」到软件内（见图 1，中栏，蓝色的 Blog 文件夹），但索引数据是存在当前所在库的索引文件内。当挂载的文件夹 /文件被外部应用增删改后，它实时监测，并及时更新索引数据；
1. 它支持很多种类型的文件预览和处理，同时在标签、标注、搜索方面都不错。

[imn1]

我用方案 3 自写脚本，不过仅自用
这个方案对媒体文件管理更有用

[SuperMild]

@aoaoho 感谢提供参考。

文件管理、知识管理真可谓众口难调，要达到真正好用，需要做非常多、而且非常考虑细节的功能才行。DEVONthink 已经做得很不错，对于如何把操作系统里原有的文件整合进来，也有不错的解决办法。

比如监控文件变动，自动更新索引，这个功能很不错，也符合很多用户的需求。但是，对于我自己来说，我希望减少自动、减少智能，尽量把更多技术细节呈现给用户，让用户知道发生了什么。所以现在我的解决办法是做一个扫描器，让用户手动扫，如果有文件被移动过，就通过两个列表来反映这个事实：1.在旧的位置文件不见了 2.在新的位置出现了新的文件。

DEVONthink 属于我说的第 2 种方案，它对于小仓库移到大仓库、不同用户不同电脑之间的分享、局部上传到网盘等等，都有着天然的难点需要攻克。

而且，DEVONthink 也属于 “掌控力很强的老管家”，很多事情它都可以帮忙安排得很好，但是总觉得它站在我和数据之间、站在我和我的文件之间，让我离我的数据很远，一旦全面拜托它来管理文件，我的迁移成本就会很高。

而第 3 种方案，每一个文件都是独立的，每一个文件都是自由的，没有老管家掌控一切，而是有很多个谦卑的小仆人（一堆零散的脚本程序），这些程序每个都很小，源代码是容易理解和掌控的，所实现的功能也很有限。

用着这些简陋的东西，反而让我内心特别安稳。

[SuperMild]

@imn1 能不能分享一下？我觉得方案 3 的生命力在于，如果有人也用这种方案，那就可以迅速参考借鉴。而且可以针对不同种类的文件来定制特殊功能。

[imn1]

@SuperMild
分享就算了，不是什么好东西，当初写的时候就是想到什么就加什么，很多路径都直接写到代码里面，现在都懒得改了

媒体文件都在 win 下面，所以用 powershell 写的，而且 powershell 写 GUI 比较方便
GUI 主要是为了拖放，处理多个文件，尤其路径不同、或者文件名有日韩字符时，拖放还是方便些

可以说一下大致思路：
1.把真实文件扔到带编号 id 的文件夹，或者文件名本身带 id
我自己准备了一堆正则模板，方便编号和改名，把流水 id 加上去
2.我习惯用 csv，json 不太熟，而且文本编辑器(如 emeditor)打开 csv 很直观，有时一些微改动不需要还上脚本改
3.增删改查都是小事，也不用说了
4.做这个最主要是两个
一个是入库(csv)的工作，利用文件名以及一些预设正则方案，把必要可知信息写入 csv，当然不全，需要后期对字段编辑，但基本上给了 id 后，真实文件就不怎么需要动了，方便固定路径
二是出库，既然入库就已经固定路径，读取自然也不应随意变更，所以我全部采用虚拟路径，主要是用不同的 tag 写 junction 或者 symlink，前者有个好处是无需 admin 权限，后者需要提权才能生成，虚拟路径自己怎么命名都没所谓，完全不影响实体文件，还可以多对一，同一个 id 在不同分类的虚拟路径都有软链
有些媒体文件我会搜索 tag 后，生成 playlist 让播放器直接打开

以前试用过 tagspace，不过免费版还是比较弱
而且这些工具对我有一点是无法用下去的：图片管理，我的图片千万级，这些工具全部默认是文件管理，而我对图片管理只需要目录管理就够了，采用文件级 tag 的我用过 N 个的全部崩溃

知识管理我觉得也是目录 /文件夹管理比较好
目前没找到一个可以左边树目录，右边打开预览或浏览的工具，例如 mhtml，还是要在 chrome 打开
不过相信一个工具要支持这么多格式还是比较难

[my101du]

Eagle 应该就是这么做的。添加一个库后，会把图片全部存到这个库里，每个图片一个描述文件，打开看就是 json，描述了它的一些 meta 信息.（色调，tag，宽度什么的）

对它的索引感到好奇，毕竟这些描述文件分散在多个目录里，搜索的时候怎么跨这么多目录来高效检索数据呢？

[loveour]

我最近也在考虑写一个文件管理软件，不过我是为了超过 100TB 的媒体文件，自从 4K 开始普及硬盘空间明显吃紧。第三个方案优点很多，但是描述文件如果和媒体文件放在一起，会不会显得太杂乱？就像来以前的 SVN，会在每个目录下面生成一个.svn 的文件夹，还是说我的理解有误？而且，我要管理的还有照片库，文件量会很大。所以我大概会采用第二个方案，用数据库存储描述，做一些方便迁移的设置比如导入导出到 csv 或者 json 的 txt，以及监控文件夹变动。主要还是我的需求不一样，我没有频繁移动文件的需求，因为我的仓库目录是相对固定的，移动会很少，要发生也会是批量的。想了想，与其说我想写的是文件管理软件，不如说是媒体管理软件吧。用过几个，总觉得不是特别合自己的意。

[SuperMild]

@imn1 学习了！虚拟路径多对一这招很有启发，生成 playlist 很实用，难怪你专门用来管理多媒体文件。

如果你的图片管理只需要目录级，也许可以考虑对每个目录配一个描述文件，然后每个目录随机抽取十几或几十张图缩小合并，形成一张比较直观的印象图。


@my101du 竟然真有软件敢这么简单粗暴用一堆 json 啊……那个，扫描一次 json 文件其实也不慢，我的做法是扫了之后写入 sqlite, 需要检索的时候实际上是借助 sqlite 的，我猜 Eagle 也可能是这样。

[SuperMild]

@loveour 显得杂乱是个大缺点，但是我移动的需求比较大，只能忍受这个，一般的话第 2 种方案就很好。

你的文件虽然体积大，但个数其实不多，这种情况下用第 3 种方案效率也很高，第 3 种方案只怕数量多，不怕体积大。就是一堆描述文件会很乱是真的，我感觉一般人都忍受不了这个缺点。折中一下改成 .svn 或 .git 那种形式也可以考虑。

[tinywhale]

描述文件.... 其实操作系统早就有了 Thumbs.db .DS_Store，可以在它的基础上加内容