有关文档的标签式分类管理，在我目前所了解的资料中，这个↓
算是总结的比较全面了，对我的启发也比较大，建议感兴趣的同学可以认真看看，从中选取一种适合自己的方式来进行文档管理。
2021年7月22日，更新V1.8版
下载地址：dangerace.ys168.com
如何评价标签式文档管理和分类软件Document TagExplorer？ - danger ace的回答 - 知乎
另外，建议增加字体大小选择的功能，在2K分辨率下的显示字体大小太小，又不方便改DPI。看起来就很吃力
1 个赞
我觉得更习惯的操作模式是，先勾选几个文件，再去勾选要添加或替换的tag就自动打上tag就好。现在每次都是要先勾选tag，再勾选文件，让后再去点击菜单选择添加tag。操作没两次就觉得混乱
1.8版本还有一个bug。选择子标签添加后，并未选择父标签，但TE会自动添加父标签，但是实际需要是只添加子标签。
哈哈哈，这是个“feature”不是个“bug”。如果您阅读过所有的更新日志，大概就会明白了。
我在更新日志中提到过这个问题，
如上图，以某本电子书籍为例，它本身是一本有关“量子力学”的书籍，但也因此肯定是一本有关“物理学”方面的书籍，也因此肯定是有关“知识”方面的书籍。有鉴于以上类似于“继承性”的关系，当用户给这本书打上“量子力学”标签时，程序才会自动捎带上“量子力学”标签的所有上级标签。
关于这点，我的建议是您不必去操心这个事情，理论上说，标签越丰富越好，反正平时您也看不到这些标签，无论多少都眼不见心不烦，反倒是因为这个“特性”，会让您今后的搜索工作变得更加精准和灵活。
关于字体问题，是我疏忽了，我的开发机器是32寸的2K大屏，看起来还可以，但是忽略了如果是在十几寸的笔记本屏幕上可能会显得比较小。这块我考虑一下怎么办。
有关操作习惯的问题，首先，当前最新的V1.8版，已经支持快捷键操作了，您可以试试；其次，在软件设置上，是先选文件再勾标签还是先勾标签再选文件并未做规定，您完全可以按照您的操作习惯来使用，不过我估计可能是UI上，标签管理器和文件管理器的摆放位置，给您了一个可能是误导的暗示，导致您认为需要先选标签才能再选文件。这块我也考虑一下，尝试调整一下位置什么的，会不会更自然一些。
以上，无论如何都非常感谢您的建议，都很棒，我都已经记录，也将认真评估，如有可能会在今后的版本中进行修改完善。希望您继续关注和支持Document TagExplorer！
最新版下载地址：dangerace.ys168.com V1.8版
谢谢您的解答。
不过确实有时候是只需要子标签而不需要父标签
比如我有一个电子书分类的体系。下边有近期阅读，在读，已读等等分类。这时候我只需要标注阅读情况，而不需要电子书这个父分类。所以建议考虑一下
另外，我有一个功能上的需求。不知道您觉得合理不。
对于标签分类软件，我这边更需求的是分类之后，类似Mac端点击标签就能看到已经标注的相关文件。毫无疑问由于Windows磁盘系统的底层缺陷，这个功能只能外挂数据库实现。但是对比起每次查找都要点击一次搜索，这样的标签更符合直觉的需求。
所以另一方面来说，并不是“先选文件再勾标签还是先勾标签再选文件”。
而是被Mac,Picasa等传统标签系统培养了一个习惯：
- 点击文件再打标签是打标签的流程
- 点击标签就自动筛选出已经打了该tag的文件是另一个流程
用户的需求都是合理的，只是如何满足是需要考虑的。
关于自动加父标签的问题，我考虑也许可以用一个开关来解决这个问题，当然，在没有这个开关之前，其实您可以通过调整自己的标签体系来解决这个问题，例如您就建两个顶级标签（在读）和（已读），或者把“已读”和“在读”加入到“常用标签”中就解决这个问题了（常用标签中的标签在被添加给文档时，不会上溯上级标签）。
至于“点击标签马上列出文件”这个功能，如您所料，确实需要外挂数据库来实现（其实DTE在V1.0之前的好几个BETA测试版都是这么做的，后来才改成流文件机制标签），并且仅仅外挂一个数据库还不行，还得顺势要求用户的所有操作（对文件的更名、拷贝、移动等）都必须在本软件中完成才行，不然这个数据库就无法和实际环境保持一致。这相当于从底层原理上就把现在的DTE推翻了。
如果您确实需要上述功能（强需求），也许可以尝试一下taglyst之类自建数据库的工具软件。
用了这么几天 我比较同意之前myth提出的插件方式
DTE的整个标签流程完全依托于Windows资源管理器所提供的功能。修改为安装版本的插件形式更符合直觉，目前的版本更倾向于自建数据库的单独管理的使用范式。
目前市面上能做到Windows资源管理器增强标签管理的还没有做得很好的吧 
现在想想这也是我之前提到的安装版的原因，单文件的形式用起来实在是有点蛋疼。
安装版的标签数据库可以单独存储 通过云盘同步保证一次建库 多机使用
这里我可能理解的还不透彻，在我看来，DTE生成的数据库仅有一个taglist.edb（额外还有个运行目录下的config.ini），存放在主程序运行目录下的data文件夹内，您完全可以把整个程序文件夹放在云盘里，通过云盘在多个终端上共同使用，保证一次建库，多机使用，完全没问题啊。
因为…因为…因为我自己就是这么做的，我把DTE文件夹放在坚果云上，我单位、家里的四台终端都在同步使用相同的标签数据库，完全没有什么问题。
至于windows资源管理器的插件问题，坦白的说我目前还不会做，就是这么简单，不会… 
突然有个想法，关于这个需求，也许我可以在不加入数据库的前提下变相的实现它，大体上就是点击一个标签，程序会立即搜索当前路径下所有打了这个标签的文档，而不需要用户通过搜索菜单来引发这个动作，当然，这么做，在效率上肯定不如直接搜索内部数据库来的高，还是会有一个“搜索过程”的，但至少从操作习惯上是满足了需求了。
我来准备一下吧。
1 个赞
可以在更改标签内容绑定一个快捷键F2，就和文件改名的快捷键一样
正解！马上加上！
大体上就是点击一个标签，程序会立即搜索当前路径下所有打了这个标签的文档
我觉得这么做的问题是
标签的意义是打破文件夹系统的壁垒，有一个跨文件夹的同一属性的整合。而只是搜索本文件夹路径下的相关标签，就成了一个“筛选”（或者说标注）的功能。
当然从某些需求来说，筛选也是有用的。比如一个几百本电子书的文件夹下，筛选当前要读，和标注近期计划的图书。但是那就不能满足，譬如我按学科用文件夹分类了图书，那交叉学科下当前要读的计划就很难实现。
另外如果想要变现这么实现，我还有一个可行而且跨软件的用法，利用descript.ion文件。这个从DOS时代起就有不少软件支持的标注文件。Totalcmd的标注也是利用它。存在标注的每个文件夹下都有一个文件对该文件的注释进行处理。纯文本，utf-8或16bl编码，速度比数据库更快
@Qingwa 或者其他各位版主，想问一下，为什么最近我的发帖、回帖总会被要求需要审核？是我有什么案底导致我的帖子每一个都存在高风险需要审核才能发出来吗？
刚才正在和 @rt23i950 讨论，结果半路来个“需要审核”，得，只能明天再说了，郁闷的吐血！
这个“只搜索本文件夹路径下”的意思，其实并不只是“某个文件夹”，磁盘路径也是文件夹之一，您可以将默认文件夹设为存放数据的盘符，例如“D:"，那么搜索时就是搜索整个D盘了。其实这里本来我应该设计成，点击某个标签，就在所有磁盘中搜索，就达到您的最佳目的了，可惜目前我的搜索算法性能一般，如果搜索所有磁盘，赶上像我这样七八个硬盘，每个硬盘上几十万个文件的，搜索时间就太长了，不实用，所以不得已只能一个磁盘一个磁盘的搜索。
关于“descript.ion”的情况，我先学习一下，补充一下相关知识，然后再和您讨论。