dynilath
commented
5 years ago 额，补充一些内容 1、由于重新启动时，图片源的ip会发生变化，甚至画廊会更新，tag也会更新。所以重新载入TASK_STATE_DOWNLOAD状态的任务时，会直接退回到TASK_STATE_GET_META状态。 2、rename_ori = True 遇上相同文件名的情况还没整（被打 3、log文本完全没动，所以会出现输出“将下载1，共13”，实际上由于6个图片没有通过SCAN_PAGE检查，结果实际下载了7个图片，并输出7个下载完成信息的情况。（感觉也是要被打
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的时候才能知道实际的文件名（在rename_ori = False的时候其实可提前在TASK_STATE_SCAN_PAGE就知道文件名，但我目前还没做）。 这里我在scan_downloaded方法中，把目标目录中文件的文件名，和其大小信息存入task._file_in_download_folder。在TASK_STATE_SCAN_PAGE阶段，从单独页面上不仅读取文件名，也把旁边的文件大小读取进来，与实际文件体积对比后确定是否需要重新下载文件。（download_ori = True的情况下这个逻辑还没有完善。）
4，一些小问题 画廊名称结尾有数个.时可能导致一些问题。更改了一下filename_filter。