就算ob的开发者挂了，ob的本地文件又不会消失，ob这个应用又不会失效打不开，你安装的插件该用用，甚至转移到logseq也可以，要是还担心logseq挂了，logseq开源的，你自己接着开发都行。不要还没开始就担心结束。
1 个赞
下划线 _ 作为文件名称的一部分在常见的操作系统上都没问题，
iOS 安卓 windows Linux等；
搜索时也没什么影响，
可直接搜索 _ ，_ 符号在正则表达式中也并不会引起冲突。
兼容性好得很，请放心使用。
我也有个疑问：
为什么不直接使用
机械设计_62_a类_同步带尺寸选择_20230422174954
这样的文字明文编码，
而要使用
TH122-62_a
这样的咋一看根本看不懂的编码方式呢？
这个是中图法，T是工业类，TH是工业下的机械类，TH12是机械类下的，机械设计、计算与制图类，TH122是机械设计，-62是总论复分表，代表手册、名录之类的。
看不太懂的原因是因为这玩意一般图书管理员用得上，需要把那本厚厚的指南读一遍。
我不是所有的笔记都要这么干的，是对于我目前研究的一些重要课题，进行分类，建立层级结构，所以不必担心花时间，而且是后期笔记累计到一定程度，需要建立关系才开始建立编码分类。
采用中图法的原因，国外的杜威法也行，是要规范自己的命名，以及参考前人的分类方式。
因为我的话就存在一个问题，就是同一个东西，我隔一天起名就不一样了，拿TH126举例，我写机械制图，隔天工程制图，隔天我就写了工图，虽然这三个对我来说是一个东西，但对于计算机不是。方便计算机识别，因为是代码的关系，中图法本身就有层级关系。并且我自己建立的分类就存在分类不合理的情况，倒不如拾人牙慧，且对一门新的学科，我完全不了解，不如用前人的经验。
1 个赞
谢谢，请问您对2.关于每级编码的位数问题，是否要统一长度？3.关于时间戳的位置，有什么高见吗
所以我打算采用非中图法所用的符号如“
_”、“~”
同意楼上说的, 下划线对搜索良好,
但注意, 不少markdown工具对 aa_bbb_cc 里 bbb 的解释是不一样的, 这段文本贴在正文里, 楼主需要试试 Ob编辑/Ob预览/其他常见软件 呈现效果能否接受, 有些软件会把中间变斜体
每级编码的位数问题，是否要统一长度
我理解没必要, 非等宽字体下, 其实对齐位数了也会显示成一坨, 中英混排更乱
另外这个 @ 会阻碍检索
关于时间戳的位置
首先时间戳该不该搁文件名里是需要讨论的,
这里先认为该搁文件名里, 那么通常是放最后吧, 顺便当笔记版本用
最后, 一些我目前的理解:
做笔记首先对人优化, 先要看起来直观, 其次才是对机器和搜索优化
文件名承载的信息有限, 不可能把我们关心的 “所有重要信息” 全编码进去
替代方案: YAML FrontMatter 是存元数据的好位置, 直接写相关段落里也行, 对段落标 tag 自然也属于笔记, 这蕴含了更具体的信息
管图书和管知识其实很不一样
中图法 / 杜威法都是图书分类方案, 维基可能是比较好的知识记录方案
但我也尊重楼主的选择
简单说下好了。
首先中图分类号没必要非得在标题中，使用文件夹或者在yaml中一样可以起到汇总知识的作用。另外也不影响通过编程统计数据。这样也就不会有特殊符号的限制问题了。在这种情况下，补不补位问题也就不大了，因为其已经成为了独立的信息，不再需要拆分。
其次，“卢曼编号”在这种情境下价值可能不会很大，其实完全可以使用更细的中图类目来替代。如果中图没有更细的类目，此时你的“卢曼编号”也就是在建立一个更细分的类目。这又可以通过上面说的方法进行管理。
第三，时间戳也可以放在yaml中。你对时间戳本质就两个需求。一是方便统计，二是防止链接丢失。在第一个需求上，放在yaml中现在直接就会有现成的插件（dataview）帮你统计，记忆曲线插件也不会用你标题中的时间。哪怕自己写程序，放在yaml里也不是什么问题。在第二个需求，其实现在obsidian会自动全局更新链接，完全不用担心链接丢失。再退一步，假设ob不更新了，这种也是凭借全局正则替换就能轻松做到的事情。再再退一步，其实用文字也能简单做到不重名。不过这点凭你自己喜好吧，我个人不太推荐把时间戳放入标题，降低可读性。
最后建议一句吧，既然都研究中图法了，其实可以多研究一点点。多研究一些你就会发现，其实很多“管理方法”是没必要做的，直接照抄前人结果就好了。
1 个赞
请问您说的维基具体指的是什么，能否指个详细介绍的链接，是指的wiki链接吗？
还有就是您不用下划线_作为分隔符，该用空格是否可以呢？
您说的多研究一点，指的是不采用中图法，改用yaml等管理吗，yaml我也有用，用于添加一些副标题，交叉分类号之类的
中图法实际是信息组织学中的一种方法。其他的方法还有主题法等等。对信息组织学有更深入的了解以后，其实你就很容易根据现有的功能设计出一个自己的简单高效的组织方法。
信息组织，周宁，2017。
分类法主题法导论，曹树金，2000
看这个吧
好的，非常感谢您
就是各种维基百科啊, 哪都有
我自己用空格, 但我不是你这种编号标题
我遇见的空格标题的坑:
- 转出网页时, 空格不是合法的 url 字符, 会被转为
%20 - 中英混排时两侧加不加空格的人都有, 对精确搜索有一点干扰
- 如果附件存放路径跟标题有关, 则附件路径会传染这个空格, 有时会麻烦 (能解决但毕竟麻烦点)
其他没啥大问题, 楼主可以批判参考
感谢您的回答！
- 请问这个转义会发生在什么时候，您说的转出网页是什么？是OB官网的发布服务吗
- 您指的混排是这样是吧，中文、英文、数字之间要有空格，我这个是苹果官网的截图，像大厂就很注重排版，而我一般不会输入空格，像这样子“RMB333/月起或RMB7999起，还可折抵换购。”。您指的对精准搜索有影响的话，是指的什么呢，比如我的主题名是复制像苹果这样的排版，没有改成我的习惯，也就是不带空格的，在检索时会搜索不到，是这个意思吗
- 您说的第三点，存放路径会传染是什么意思呢，我的话附件默认存放路径设置如下，并使用了插件paste image rename，保证被引用的图片和文件名一致，这样我能在知识库中很快找到相应的图片
您说的污染路径如下吗
这样的路径会有什么问题吗？是不方便阅读吗，还是ob中只用这样的结构，因为每次都要输入%20替换空格，不方便修改路径吗？
通过您的解答，我突然想到一个问题，就如果我的，主题名是英文的话，那就完蛋了，主题名是一句话话必然有空格，这样不利于python程序识别、以及不利于用 Dataview进行生成MOC等操作
都是小问题, 建议知道了就完了, 别太在意
- 空格转义主要是发布网页时, 以及 “导出一组相互链接的文件或附件” 时
- 精确搜索是说双引号括起来搜索时, 空格容易碍事, 比如搜
"Obsidian 插件", 其实不加空格的写法也有 - 第三点也类似空格转义, 我应该写一起的, 第三点主要是说不同软件对空格转义有不同的解释
比如下面是同一图片, 路径带空格, 可以试试在 Obsidian, Typora, VSCode 里分别打开, 容易血压高
以下 wikilink 形式, 不转义, 应该可以显示
![[nested/folder with space/img with space.png]]
以下 wikilink 形式, 转义, 应该可以显示
![[nested/folder%20with%20space/img%20with%20space.png]]
以下 markdown link 形式, 不转义, 应该可以显示
以下 markdown link 形式, 转义, 应该可以显示
最后, 这都是细节, 看具体需求都能解决,
我个人觉得空格免不了, 该用就用吧
2 个赞
明白了，谢谢您，经过这么一说的话，我还是采用下划线"_"吧，不用空格分隔字段了，而且输入英文的句子也会用到空格，用空格的话，到时候自己编程不方便拆分编码，容易出问题。还有就是-这个符号也不能用，英文里是连字符，到时候一堆问题
这样每次记笔记的时候，不会增加记录的负担吗，不知道题主现在体验的如何了？
严重同意，还没有开始就在担心了