下载文件名问题和zip描述信息改动等（掺入一些灵魂的

[dynilath]

和之前的那个pr差不多，主要是修了些问题。

1，新的文件名控制。

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

• 在TASK_STATE_SCAN_PAGE阶段，从画廊获取原文件名，存入fid_2_original_file_name_map
  此时如果出现重名，添加"_1"到文件名末尾，仍然重名则使用"_2"，以此类推
• 在TASK_STATE_SCAN_IMG阶段，从单独页上获取实际文件名（主要是扩展名），存入fid_2_file_name_map
• 在TASK_STATE_SCAN_IMG阶段，从单独页上获取文件体积信息，存入fid_2_file_size_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和prescan_downloaded

由于上述文件名控制原理，到TASK_STATE_SCAN_IMG的时候才能知道实际的文件名。

prescan_downloaded负责扫描zip文件的描述信息。通过以下四个方面决定如何操作该zip：

• fid_fname_map是否存在，其长度是否等于total。不存在或者小于total都表示这个文件不太像这个软件下载的，由于可能是早前版本下载的，所以先解压出来重新下。
• download_ori不匹配，解压出来重新下。但如果zip文件download_ori为True，而task的download_ori为False，那就不管。
• rename_ori不匹配，最好的办法我想是根据fid_fname_map直接在TASK_STATE_SCAN_PAGE后就改名。但目前是解压出来重新下。
• url不匹配。这种情况很可能是想用4k扫图替换风大扫图，解压出来重新下。

scan_downloaded主要负责下了一半的东西暂停继续。将下载目录中的文件和fid_2_file_size_map中的数据对比，如果通过对比则不会加入page_q。

4，一些小问题

画廊名称结尾有多个.时会被win系统全部吃掉。更改了一下filename_filter。
由于重新启动时，图片源的ip会发生变化，画廊会更新（尤其是ongoing的画廊），tag也会更新（尤其是早前下载的新画廊）。所以重新载入TASK_STATE_DOWNLOAD状态的任务时，改为退回到TASK_STATE_GET_META状态。

[fffonion]

那么♂多，待我看看