Obsidian同步Hexo方案
随笔
分享下,个人将Obsidian同步到Hexo的方法
近2日写脚步,完善脚本,基本可以无缝衔接了
包括本篇笔记也是用脚本同步上Hexo的
(再次测试下效果= =)
写写实现过程
一开始其实有上网查下有没有现成的方案
看了几篇文章,拿以下两篇举例
博主们都是采用将整个Hexo站点文件导入Obsidian作为一个库使用,相当于有两个库
而如果合并为一个库情况下,会导致如下情况
- 库中有些信息不方便公开(证件号、个人信息、收货地址等),但Hexo一渲染就同步出去了
好像可以设置哪些不同步,但想想现有的存量,以及每次都要设置、放弃
- 破坏原先的Obsidian库目录体系
Hexo的文件夹与Obsidian的文件夹混杂在,对于极简主义、喜欢简洁的人简直就是灾难
由于都不是个人想要的效果,就自己动手写个脚本
这博主也有类似的做法,但个人看到比较晚,看到已经写完脚本了😅,要不可以轻松些(借鉴)
一个自动同步 Obsidian 指定文章到 Hexo 博客的脚本 | Depp Wang’s Blog
其实怎么说,想要达成个人想要的效果,永远只能自己动手,因为总归会有些细节上的区别
一个剑客,如果同时是铁匠
你说他能不能打造出一把自己最趁手的兵器?
举些例子吧
例如Front-matter
写法的区别tag
有些人的写法是#电脑 #软件
而个人的写法永远是采用yaml的数组写法
tags:
- 电脑
- 软件
medata
有些人会采用双引号将值括起来、有些采用单引号,而个人直接不用,每个人都不尽相同
扯远了~
实现
个人想要的效果
- Obsidian写作(笔记、日记)
- Hexo单纯作为一个对外分享的窗口
写的文章,想要分享的,就使用脚本将这篇文章直接分享
脚本会将文章拷贝到一份到Hexo,同时将该文章引用的所有图片都自动拷贝到Hexo目录下
使用Python实现、不会NodeJs
要不其实可以考虑做成插件集成到Obsidian中过去,不过目前用的也很顺手
使用上Quicker后的效果图如下:
解决问题
过程要解决的问题
- 文章的发布(Obsidian——>Hexo)
直接遍历Obsidian库,找到要发布的文章,复制拷贝到Hexo目录下
- Front-matter属性名称不同
Obsidian和Hexo的属性名称不同
像名称:Obsidian是
name
,Hexo必须是title
时间:Obsidian是
date created
,Hexo必须是data
所幸之前个人有为了批量处理md文档,专门写个处理的脚本,直接引用
直到昨天才发现有个致命Bug!!!每次提取正文,最前面的一行就会没有了,也就是正文第一行消失了,想想以前批量处理的Markdown文档,泪两行😓,昨天检查问题后,修改回来了
对复制后的副本(Hexo)进行修改转换
- 图片的引用问题
简单,使用正则提取链接
遍历Obsidian的图片库,复制过去就行 - Callout的转换
原本没打算写,但Hexo转换后太丑了
两者对比图
还是写下,这两天完成,Fluid主题有相应的标签可以转换
所以将Callout的字符串替换为对应的标签字符串就好了,
今天看到个不错的插件hexo-admonition,后续也考虑将字符串替换为这个
目前的callout转换只支持4种
项目地址
详细写了文档,所有配置和使用方法都有讲到,拿来即用
同时适用于小白和熟悉Python的人
复盘过程
后续还可以完善(折腾)的地方还有双链的实现
其实整体写起来不是很难,主要涉及文件处理(复制)、字符串处理这两块
但还是耗费了挺长时间(1-2天)
百行代码写这么久,说出去估计要给其他人笑死
想下,问题在于Bug、功能的完善、发布,写ReadMe、
功能完善
callout
例如,一开始没有考虑写callout的转换,但后面还是花费了时间写和测试
也是写法的没有统一导致,callout有文本块、折叠块两种,有以下4种写法
个人有时候就是随性写,所以都要考虑到,每个写法写出来进行了测试
![xxxx]
:文字块,标题在前![note] xxxx
:文字块,标题在后面![xxxx]-
:折叠块,标题在前![note]- xxxx
:折叠块,标题在后面
图片
图片问题也是,写法没有统一,后续又倒过来完善
一开始只考虑了只有文件名的情况![](../images/xxxxx)
但后面想到有时候用Typora写,会变成相对路径的情况
所以后面完善了,变成支持3种写法
- 相对路径
- 绝对路径
- 单纯图片名
Front-matter的Bug
这个属于第二占时长的,不属于语法错误,算是语义错误
所以找了1、2小时
这个Bug不是写这个小项目还真不知道有这个Bug,而且还挺严重
每次使用会导致正文开头少一行,如果用这个进行批量处理,不敢想= =
以前没有发现这个问题,是因为Front-matter区域一般下面会留有空行,正文少了开头一行空格,渲染出来,完全不影响感官,所以没怎么注意
而这次因为测试Callout的转换效果,要一直用,执行>2次,就少了2行,就很明显发现问题了
测试的时候,第一个大标题给没了
一开始以为是Front-matter区域属性值转换导致的错误,所以挨个思考尝试
其实这两天发现一种更好的思考解决问题的方式
平常个人思路是
遇到问题——>思考问题产生的方式——>想到一个——>尝试解决
这种方式,每次想到解决方案就尝试
如果一开始方向就是错误的, 会导致解决问题的时间变长
原本解决问题的方向在东边,如果一直向西边,再努力也无济于事
而且思路太局限了,只盯着手头这个解决方案
更好的思考方式是,先思考可能产生的问题的是什么,把所有可能性罗列出来
然后再思考哪种可能性比较高(优先级排序)
再挨个尝试
这种思路方法更佳,当然目前思考总结知道,但实际还要一直锻炼运用
配置
考虑到分享他人使用和方便修改,后续就将配置信息都存储到json文件中去了
发布和文档
虽然说初衷只是开发自己用,但也想分享出来,别人也可以用
所以分享到仓库和阿里云
然后因为前面功能完善一直修改的原因,结果导致仓库和阿里云的资源也要一直更新= =
文档也跟着一直更新