多台机器、多个旧书库合并之后,Calibre 书库很容易变成这样:
书名不规范的连锁反应:Calibre-web / Jellyfin 显示难看、ebook-convert 批量抽取时文件名混乱、检索「西游记」永远搜不到那本 Xi You Ji。
我用 WorkBuddy 开发了一个技能 calibre-chinese-title-normalizer,对自己的真实书库(1689 册)做了实测:需治理 666 册,占 39.4%,其中纯拼音/英文 590 册。本文记录从扫描到首批 65 本改名完成的完整过程,以及踩过的三个坑。
治理书库最怕两件事:改错了回不去、脚本失控写坏 metadata.db。所以这个技能从设计上就规避:
报告会把所有需关注的书按四类分组列出 book_id / 当前书名 / 路径,直接作为下一步的映射表底稿。
CSV 格式四列:
两个实用技巧:
不加 --apply 就是预览模式,逐条显示 旧名 → 新名 和校验结果。
确认无误后加 --apply,每批 10 本,跑完重扫一遍核对数字变化。我首批 65 本,扫描报告从 666 册降到 601 册,精确 -65,一本不多一本不少。
现象:每本书都报错退出。原因:Calibre 主程序运行时锁住书库,官方 CLI 拒绝并发写——这其实是保护机制。解法:改名前退出 Calibre 主程序(连后台残留的 calibre-parallel.exe 也一并确认退出)。
现象:calibredb 返回 rc=1,报 site.py 相关错误。原因:某些 AI 工具链会设置 PYTHONPATH 环境变量,污染 Calibre 自带的私有 Python 解释器。解法:调用 calibredb 前清掉 PYTHON 系列环境变量(技能脚本里已内置环境隔离,子进程以干净环境启动)。
这是最隐蔽的一个:calibredb 的执行顺序是先把新标题提交进数据库,再搬迁磁盘上的书目录(复制新目录、删旧目录)。搬迁环节偶发失败时进程报错退出,但标题其实已经写进去了。如果这时盲目重试,防漂移校验反而会报「书名不匹配」。
解法:以数据库现状为准做增量续跑——重扫书库,已是新书名的自动剔除,只对真正没改成功的继续执行;最后统一对账,清理搬迁半途留下的孤儿副本目录(我用这方法清了 44 个)。判据很简单:DB 里 title 字段对了、磁盘上存在 DB 路径指向的目录,就算治理完成。
项目 | 结果 |
|---|---|
治理规模 | 1689 册书库,首批 65 本中文化 |
需关注书目占比 | 39.4% → 35.6%(后续批次推进中) |
数据安全 | 执行前备份 metadata.db,可整体回滚;零直写数据库 |
耗时 | 扫描 1 分钟 + 映射表起草 10 分钟 + 分批执行 10 分钟 |
有任何问题欢迎评论区交流,祝大家的书库早日告别 Xi You Ji。
本文方法纯 Python 标准库实现,零第三方依赖,欢迎按流程复现并交流。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。