Closed huajideshutiao closed 1 month ago
目前的书籍存储中有个问题,使用书名而不是id对书籍进行唯一性判断。正常来说这种方式没啥问题,但是某些书源(在此点名某红色球状蔬菜)相当喜欢改名,满10万字系统就会自动生成一个名字进行替换。
我想到的解决方案是,对于改为id判断后添加的书籍来说,要求书源同时传递一个书籍id参数即可。对于改为id判断前添加的书籍,大部分源的详情页都是固定url+book_id组合的形式进行传递,那么直接解析详情页url规则(bookUrl),其中从页面获取的变量极大概率就是id。如果详情页url使用js进行处理,那就直接缺省,也没必要进行解析,要求更新规则即可。
考虑到很多情况下,会从n多盗版源找同一本书,那么不同源url的书籍可以回落到原本的判断方式。
至于为什么不使用详情url,因为详情url中路径、参数众多,有时候只要源站详情页稍微改一个附加参数就会导致要重新搜索。所以这个思路主要是为了方便同站点进行维护的。
话说回来,好像没看到阅读内部有更新详情页url的操作,也就是说详情页url失效就只能重新搜索?
无
No response
3.24.041219
安卓14
红米k70pro
整错了,这个应该放需求
确认 / Assignments
问题描述 / Describe Bugs
目前的书籍存储中有个问题,使用书名而不是id对书籍进行唯一性判断。正常来说这种方式没啥问题,但是某些书源(在此点名某红色球状蔬菜)相当喜欢改名,满10万字系统就会自动生成一个名字进行替换。
我想到的解决方案是,对于改为id判断后添加的书籍来说,要求书源同时传递一个书籍id参数即可。对于改为id判断前添加的书籍,大部分源的详情页都是固定url+book_id组合的形式进行传递,那么直接解析详情页url规则(bookUrl),其中从页面获取的变量极大概率就是id。如果详情页url使用js进行处理,那就直接缺省,也没必要进行解析,要求更新规则即可。
考虑到很多情况下,会从n多盗版源找同一本书,那么不同源url的书籍可以回落到原本的判断方式。
至于为什么不使用详情url,因为详情url中路径、参数众多,有时候只要源站详情页稍微改一个附加参数就会导致要重新搜索。所以这个思路主要是为了方便同站点进行维护的。
话说回来,好像没看到阅读内部有更新详情页url的操作,也就是说详情页url失效就只能重新搜索?
复现步骤 / How to reproduce
无
确认 / Assignment
其他信息 / Additions
No response
日志提交 / Relevant log output
No response
阅读版本 / Legado version
3.24.041219
Android版本 / Android version
安卓14
机型 / Model
红米k70pro