Closed Nacosia closed 6 months ago
Ljzd-PRO
commented
6 months ago 用多种方式获取文件名主要是考虑到下载链接末尾部分可能没有给出文件名，比如可能会有重定向的情况。
从请求返回的Header获取文件名应该是最标准的方法，但是如果每个下载目标都要先建立HTTP连接才能获取文件名的话，检查重复文件的效率就会很低，所以先用一些快捷的方法获取文件名，检查重复文件，优先顺序是：
alt_filename，也就是手动指定的文件名检查发现没有重复文件，建立连接后，实际保存的文件名采用的优先顺序是：
alt_filename，也就是手动指定的文件名这个 Bug 主要问题应该是，实际采用的文件名可能是从 Headers 获取的，但没有再次进行重复文件的检查，而是直接创建文件，就可能导致异常。
Ljzd-PRO
commented
6 months ago 变量的命名确实也挺混乱的，得改一改。然后会再补充一些注释
Ljzd-PRO
commented
6 months ago 如果确实存在一个作品有多个文件，文件名相同，也是会漏掉那些重复的。不过这个要解决的话就比较麻烦了，如果不放弃 Header 获取文件名的方法的话。只依靠 API 获取文件名也不够，因为有些情况 API 返回的文件名是空的，一般好像是Kemono外部服务器提供的文件会出现这种情况。
Nacosia
commented
6 months ago 好家伙, 肝啊佬 O.O
如果确实存在一个作品有多个文件，文件名相同，也是会漏掉那些重复的。
的却, 重复的文件名会导致遗失一些文件. 所以我启用了桶模式, 以确保不会遗漏任何文件. 原始存储模式不确定的文件名使其难以反向定位对应的json数据.
不过这个要解决的话就比较麻烦了，如果不放弃 Header 获取文件名的方法的话。只依靠 API 获取文件名也不够，因为有些情况 API 返回的文件名是空的，一般好像是Kemono外部服务器提供的文件会出现这种情况。
API的name为空情况时, Kemono貌似会以"Untitle"字符作为name. 不过也可能有意外情况.
从headers获取文件名是下载器的标准行为, 因为其需要应对复杂的无法确定的情况.
KToolbox具有明确的下载目的, 我认为Headers这种健壮性方案是可以舍弃的, 虽然大多数时候为空, 但其带来的不可预知是致命的.
以下是我个人使用的方案. 由于其对于已存在的文件是破坏性的修改, 会使得现有已下载文件重复下载 所以此方案不适合作为发布版本, 仅供参考.
file.name除去其中不标准的字符后, {filename[:128]}_{hash[:6]} (取hash六位是防止重复文件)Ljzd-PRO
commented
6 months ago 把hash加入到自定义命名规则里可能也可以，这样就提供一个选择，遇到有重复文件名的情况就可以使用。另外按照数字顺序命名的话也可以解决，只要下次更新的时候该作品没有在中间新增什么文件。
Nacosia
commented
6 months ago 主要是不好判断重复文件的顺序, 虽然List理论上是固定的, 但是天知道服务器会不会进行一些奇怪的排序😕. 所以我的文件即使不重复也是应用hash的. 缺点就是再次进行creator-sync时, 如果文件发生变化, 会留下很多不必要的文件(然而我本就存储了所有文件)
所以关于重复文件的问题也许还需要考虑, 这可能只是少数需求, 目前看来不太值得花精力去修改.
以下两处不同的filename, 可能出现不符合校验预期的结果. (当
_alt_filename与_filename不一致或_alt_filename为空时)考虑统一
_alt_filename与_filename的使用场景 或弃用在L195独立的filename获取?https://github.com/Ljzd-PRO/KToolBox/blob/4439af52542cb89d8606832a6687da231c047003/ktoolbox/downloader/downloader.py#L150
https://github.com/Ljzd-PRO/KToolBox/blob/4439af52542cb89d8606832a6687da231c047003/ktoolbox/downloader/downloader.py#L195