支持使用裁剪后的标题进行api_dump.sqlite匹配

[HibernalGlow]

我fork测试了一下，这样子能够匹配进来的成功率大大提高，像我这种下画师合集的，基本上就没有跟原来标题保持一致，用这个方法能导入不少

[HibernalGlow]

或者可以加个开关？

[yu45020]

我觉得这个方法有隐患，容易导致错误匹配。 举个栗子：库里有2本书 分别名为　" 叡知な本　総集編１.zip" 和 " 叡知な本　総集編2.zip"。 只取部分文件名匹配很可能就会都配到同一本书。 可怕的是你不知道会匹配到什么书。

我目前的做法是再api_dump.sqlite 里加一张表， 把里面所有的文件名都提取出来，包括title, title_jpn, 和 torrents里的。 每个名字对应一个gid。

导入新书后，跳过软件，直接更新 database.sqlite 和 metadata.sqlite： 匹配文件名的gid，写入对应的tags。

如果你的书数量不多，也可以尝试直接用模糊配對来直接更新数据库，不过建议先将配对的结果保存出来核对一次。

[HibernalGlow]

我觉得这个方法有隐患，容易导致错误匹配。 举个栗子：库里有2本书 分别名为　" 叡知な本　総集編１.zip" 和 " 叡知な本　総集編2.zip"。 只取部分文件名匹配很可能就会都配到同一本书。 可怕的是你不知道会匹配到什么书。

我目前的做法是再api_dump.sqlite 里加一张表， 把里面所有的文件名都提取出来，包括title, title_jpn, 和 torrents里的。 每个名字对应一个gid。

导入新书后，跳过软件，直接更新 database.sqlite 和 metadata.sqlite： 匹配文件名的gid，写入对应的tags。

如果你的书数量不多，也可以尝试直接用模糊配對来直接更新数据库，不过建议先将配对的结果保存出来核对一次。

我后面也想到了这个问题了，然后我的做法是跟你差不多，我是强制标题完全匹配，然后再根据未裁剪前的完整标题进行相似度匹配 选相似度最高的那个（然后因为我这个做法不需要哈希值，还可以直接索引标题加快速度）

[HibernalGlow]

[yu45020]

我以我的喜用习惯做了一个。在模糊配对里，先用bm25找出几个首选标题，然后用模糊配对找出最有可能的，最后在校验页面里手动确认。

#285