下载文件名问题和zip描述信息改动等

dynilath commented 5 years ago

1，新的文件名控制。在exhentai浏览画廊单独一页时，比较大的png都会变成jpg，比较小的png会保持png。具体是否会压缩的分界点和图片源的链接带宽有关系。这也即是说原本是png的画廊下载的文件实际是png还是jpg完全无法简单预计。除此之外，gif文件也会被下载成jpg。这里采用了另一种办法：在ehentai的画廊页面里，每一页预览的title里面包含了原本的文件名。单独一页中的顶部和底部显示的文件名是压缩转码后的文件名。我使用这些文件名取代了原本的reload_map机制。

2，zip描述信息改动把h.json里面的一些信息搬到了zip里，包括gjname、gnname、tags、total、title、rename_ori、download_ori、url、fid_fname_map。最后这个task.fid_fname_map是上述的文件名控制用到的，用于描述第几页文件名为何。这使得zip文件能够自我描述比较完整的画廊信息，在TASK_STATE_SCAN_PAGE阶段中，这些信息也用于检测zip文件是否需要重新下载等等。这也使得载入其他方式转移来的文件成为可能，让xehentai有可能成为一个下载画廊管理软件。

3，scan_downloaded等扫描已下载文件改动由于上述文件名控制原理，到TASK_STATE_SCAN_IMG的时候才能知道实际的文件名。这里我在scan_downloaded方法中，把目标目录中文件的文件名，和其大小信息存入task._file_in_download_folder。在TASK_STATE_SCAN_PAGE阶段，从单独页面上不仅读取文件名，也把旁边的文件大小读取进来，与实际文件体积对比后确定是否需要重新下载文件。（download_ori = True的情况下这个逻辑还没有完善。）

4，一些小问题画廊名称结尾有数个.时可能导致一些问题。更改了一下filename_filter。由于重新启动时，图片源的ip会发生变化，甚至画廊会更新，tag也会更新。所以重新载入TASK_STATE_DOWNLOAD状态的任务时，改为退回到TASK_STATE_GET_META状态。

5，其他 log文本完全没动，所以会出现输出“将下载1，共13”，实际上由于6个图片没有通过SCAN_PAGE检查，结果实际下载了7个图片，并输出7个下载完成信息的情况。

fffonion commented 5 years ago

感谢贡献pr👍因为这个pr比较大，能否将每个功能的变更去除一些耦合放在不同的commit中？这样review起来清晰一些😃

dynilath commented 5 years ago

emmm，我研究一下怎么整理这玩意儿（

fffonion commented 5 years ago

麻烦的话就蒜了🌚我先看一下代码 On Fri, Nov 9, 2018 at 9:21 AM dynilath notifications@github.com wrote:

emmm，我研究一下怎么整理这玩意儿（

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/fffonion/xeHentai/pull/52#issuecomment-437431271, or mute the thread https://github.com/notifications/unsubscribe-auth/ACCVlRmTRwCcrIgIf9RzgGwSvNBp0X6Zks5utbmVgaJpZM4YW9wt .

fffonion commented 5 years ago

我粗略地看了一下对task.py的修改，是否可以完全删除原有对关于reload_map的代码，这样可以减少一点diff？

另外建议变量名和方法名还是不要用驼峰命名，而用task_exists这样的命名，不过这个可以等最后再做，IDE应该有现成的refactoring功能。

fffonion / xeHentai

下载文件名问题和zip描述信息改动等 #52