Tagged:E-H下载器

4月27日 2.40版E-H下载器更新的要素与知识点笔记

这周在忙完了空间的重布置后,花了大约1天的时间重写了下E-H下载器。 重写的原因有很多,最主要的是因为之前由于没有时间,所以2.3.3版本颇有赶工的味道——很多地方只是草草了事应付E站的更新而已,虽然用起来没什么问题,但是很多地方其实都有更好的处理办法。当时为了能尽快应付E站的改版,再加上当时正是期末,没有太多的时间全盘重写。这次有时间了,终于算是有了个机会把以前想要解决的问题一并解决掉。 这次的更新,最直观的改版就是大幅度调整了界面。中二的年级已经差不多过了,差不多也该明白,密密麻麻花里胡哨的界面并不美观了。就我自己来说,我喜欢强大但是简洁,可定制性强的软件——像Wordpress这样,而不是外表花哨,但是定制起来处处掣肘的——像QQ空间那样。现在看来,原本的E-H下载器下面的2行文字现在看来其实真的有点像牛皮癣一样了。我相信用软件的人天天看着那么2条莫名其妙一成不变而且颜色还花花绿绿(有超链接文字)的文字占据了软件至少1/4的界面肯定不会爽的。当初大概是觉得这样醒目的文字可以提高自己的知名度吧——真是小孩子的想法啊(苦笑)因此这次更新直接将那2个标签移除了。 不知道是从哪里养成的强迫症使得我对于紧凑感情有独钟——我设计界面的主要思路几乎永远都是 如何才能将所有的功能尽可能不留任何空余空间地“塞”入一个正方形的空间内。所以经常会为了某处该用combobox还是listbox而挠头许久。基本上我写的小工具都有一个共通的特点就是界面几乎没有空白。这样带来的一大问题就是,界面的布局很容易显得非常混乱——当界面上的控件数量数量很多时,这个问题就会凸现出来。 不得不说,windows的开始菜单这种抽屉式设计是我目前为止觉得最为成功的一个界面上的设计没有之一。所以我最近写或者重写的一些小工具(Ecotaku和E-H下载器之类)无一例外地采用了这种方式,将设置与不常用的功能放在可以折叠起来的菜单中,而在主界面上只留下最主要的控件。完全不用担心过多无意义的选项喧宾夺主的情况发生,也不会由于提示文字占用过多的空间而导致界面混乱。 这次更新后,原本在主界面上通过复选框来开启的功能开关全部被移到了左下角的选项菜单中,同时,原本的“下载完成后压缩为zip文件”的功能被取消了——这个功能之所以出现,是因为以前我使用的漫画阅读软件ComicGlass只接受Zip格式的压缩包,而winrar通过右键菜单的一键压缩功能又只能压缩为rar,如果要压缩为zip的话就要手动打开设置页面,非常蛋疼…所以才专门带上了命令行界面的7Zip主程序,通过调用它来自动压缩已经下载好的图片。但是在实际使用中时候,也发现了不少问题。 1 E站毕竟是国外站,而且又有访问限额的限制,一旦网络不好的话,下载过程中出现某几张图片下载失败简直是常事。这样的话,下载完成后必然要手动检查一遍,然后删掉损坏的图片重新下载,直到确认没有问题,才会最终打包。这样的话,这个功能实在是毫无意义啊。简单来说,这个功能的应用被限定得太死了…如同前面所说的,我不喜欢这样的设计。 2 调用7Zip时候居然会被360报毒…这搞毛线啊!究竟是我软件长得像病毒还是7Zip长得像病毒啊!360你敢不敢再抽搐点啊。每次一打包就被360砍死,软件连设置都来不及保存,这不是坑爹么… 3 也是最主要的原因:ComicGlass现在已经支持Rar压缩包的读取了,既然如此,压缩率不占优势的Zip包就已经没有存在意义了……(其实7Zip的Zip压缩本身比起Rar在体积上还是有一定优势的,但是倒霉催的ComicGlass不认极限压缩率下的7Zip压缩出的包…),每次直接通过Rar的右键菜单一键压缩就好了的话,干嘛还要去借助7Zip呢? 4 依然是强迫症的原因。我看着程序每次发布都要挂着个7za.exe真心受不了啊…还是单文件看起来舒服。 总之,由于各种各样复杂(其实一点都不复杂)的原因,这个功能就被取消了…说真的,如果想要一键压缩Zip包的话,还不如直接去装个7Zip来得方便。 除去这些界面上的更新外,下载器本身获取画册信息的方式也改变了。以前的下载器是直接使用http://g.e-hentai.org/codegen.php页面来获取画册的列表的。这是E-H提供的一个功能,可以直接生成用于发布在论坛、网页、wiki上的画册目录。超级好用——主要是因为通过它可以直接获得画册的名字、图片数量甚至每个图片的页面的地址与图片的原始文件名。等于从这个页面直接就可以列出画册的全部页面的目录了。但是在某次更新后,E-H修改了这个接口,现在这里生成的代码只会显示前几十张,然后就会给你画册地址来“Read more”…这就导致下载器从这里只能获得前40张图的地址,而超过40张图片的画册,后面的图片就没法下载了……岂可修! 好吧,万般无奈之下,我尝试着寻找了其它的接口。然而很不幸的是,E站本身似乎没有再提供类似的接口了…Faint! 其实还是有一个类似的接口的,也就是 通过H@H下载 选项中的hathdl索引文件。这个文件中有画册名、图片数量、上传者、上传时间、标签等很多重要信息。而且最重要的是,里面有画册里每一张图片的文件名! 嗯,文件名!老实说当时我刚看到这里时候简直是欣喜若狂,以为终于找到了入手点。但是事实证明狂喜总是空欢喜。仔细一看的话,这里提供的真的只是 文件名 而已。 没有路径,没有原始页面地址。 你一定是在逗我… 当然,仔细看一下这个文件名的话,还是可以发现入手点的,举个例子好了。柚子社的天色*アイルノーツ,第一张CG,其文件名是这样的。 1 0a80b4305808c46822383488ee6a4cca66e5027a-141352-1280-720-jpg EV101AA.jpg 而对应的,这张图片的网址是这样的 http://g.e-hentai.org/s/0a80b43058/631813-1 看出来了吗?地址的后2段,分别是图片名的前10个字符,与画册ID+图片序号的组合。也就是说,从图片名本身是可以推出图片对应页面的地址的。也就是说,从这个H@H的索引文件中,是可以直接转换出全部页面的目录的。 世纪大发现~!于是我立刻就按照这个思路写出了新的下载流程,然后执行——测试的目标是约炮的PS3版游戏的Visual Guide,http://g.e-hentai.org/g/695574/4ef5bf8d50/ 结果发现一个非常匪夷所思的现象…画册中,所有竖直页面都正常下载下来了,而横置(也就是宽大于长度)的页面全都没有成功下载。 一瞬间我以为闹鬼了,我可不记得我的程序在判定的时候会依据图片的长宽比产生不同结果啊喂。 不过程序员最大的特点就是相信科学。计算机是不会骗人的,出了错的话至少可以肯定的是,要不然就是我的代码错了,要不然就一定有哪些我没考虑到的情况发生了。 首先检查正则表达式,是不是把图片的长宽不小心写进表达式了导致一旦图片大小变化就会匹配失效……?这确实是最容易想到的原因,但是很不幸,不是。正则表达式完全没有问题。 那么就只好跟踪调试了,结果调试过程中发现每当到了横置的图片的页面,对图片的匹配都会失败。进一步跟踪发现,这时候获取到的页面信息是“不存在的页面”,也就是空白页面。 换言之,路径出问题了。 于是再点进画册,进到34页(也就是第一张开始出错的页面),终于发现问题所在了——这个页面的地址 完全不是根据图片名的前十位得出的。而是完全不同的字符串。 为什么会这样呢?总不会说E-H设计的算法是只有竖直的图片采用这种规律,而横置的图片就采用另一种规律吧——如果是真的,我一定要抽死那个程序员。 好吧,其实仔细一看,不难发现,从34开始的页面,地址都有了一些明显的变化……

我了个槽,中间的数字变短了暂且不说,图片后缀名居然变成JPG了啊有木有。这是闹哪样啊。 好吧,那么现在看一看,是不是jpg图片采用了一个不同的规律呢……如果是真的,我还是要抽死那个程序员。 很不幸的是,看了将近10分钟,我也没研究出这个规律到底是啥。最后不得已放弃了,决定去吃饭… 具体的探索过程就不再详细说了,这里直接说结论吧。 图片33的大小足有2.63MB,是png格式,而34只有不到200kb,很明显的,jpg图片都是被压缩过后的,实际上,这些页面的下方确实都有 下载原始图片 的链接。那么,这些页面的地址大概是对应未压缩的图片的吧,而hathdl索引文件中提供的是压缩后图片的文件名,因此从这个文件名是无法推出原始的文件的文件名的,自然也无法推出每个页面的地址了。而这个文件名的前半部分全部是用0-9的数字与a-f的字母组成的。这很明显是十六进制,(第一个想到的自然是MD5),总而言之这应该是图片的特征码,每个图片完全独立,这样H@H这样的P2P客户端,根据这样的特征码,不需要更多的信息也完全能够下载到所有的图片了。 既然是特征码,要进行反推就基本上不可能了,因此通过hathdl创建索引页面的想法被彻底推翻。可恶,白写了半小时的代码… 当然,在没有图片被压缩过的画册中,这个规则是还是可以很好地工作的… (在此吐槽一下E站的自动压缩机制,同样大小的图片,1600*900就要被压缩,900*1600就不压缩,这是闹哪样呢…) 总之呢,现在的E-H还是采用了遍历画册的目录页面的最原始办法。简单粗暴但是有效,可惜的是在有50个页面的大画册上的表现就不再有以前那么高效了(以前只需要访问1次,现在要访问50次,差距好大的…) 不过我在这里将遍历画册页面的操作放在了下载的过程中,而不是分析的过程中,所以其实延迟的时间被分成了小块,也就基本感觉不出来了…我也只能做到这了。 如果有哪位朋友有发现了我没有注意到的其它的接口,请一定要不吝赐教……ORZ 最早写出下载器的时候,下载器原本是使用instr方式查找图片的。现在几年过去了回头一看简直蠢爆了…这次最主要的一个(表面上看不到)的更新就是将所有的匹配方式换位了正则表达式。这样不论效率还是维护方便程度都提升了非常多。 顺便这里记录一下学习的笔记。正则表达式中,匹配空字符串的方式是 ^$,但是一般来说根本用不到这个东西,例如 你要匹配(?:A|B|空字符串)的情况的话,你完全可以直接用(:?A|B)?来实现…然后,正则表达式中匹配”包括换行符在内的所有字符”的方式,虽然有些教程上说了可以使用[.n],但是实际上,“.” 在一般情况下匹配除 “n” 以外的任何字符,但在“[]”内只匹配自身,所以“[.n]”这样的写法无法匹配任意字符,而在RegexOptions.Singleline选项下,“.”代表任意字符,包括“n”,因此匹配任意字符有2种方式,1是使用RegexOptions.Singleline选项,然后直接使用“.”来匹配。或者是使用[sS]。 然后,比较重要一点的更新,同时也是新追加的选项,也就是下载原始图片的功能。这个功能也是在评论中收到的建议。但是之前由于我的水平所限,一直搞不定HttpWebRequest的Cookie…所以这个功能就拖了下来。后来前段时间在水月阿姨的帮助下,终于解决了,在这里发一下解决的办法。

其实说穿了很简单…主要需要知道的就只有如何将WebBrowser.Document.Cookie转换为CookieContainer的格式而已了…webbrowser的cookie是全都在一起,用“;”分割的一串String。所以将其拆分后分别转化为单条cookies再赋值给CookieContainer就好了。 此功能默认开启。如果从不登录E-H的使用者,请将下载原始图片选项关闭…否则会下不到图片。 再然后就是登录状态管理功能。 评论中出现最多的问题,基本上都是——里站登录不上去,cookie搞不定,换浏览器清理cookie无效……之类的问题,总而言之归纳起来只有一点,就是 搞不定cookie。所以这次我特地写了登录信息管理的功能…可以直接通过程序自带的webbrowser模拟提交表单进行登录,也可以直接遍历所有cookie,将E站的所有cookie一键删除…由于是程序内置的功能,不需要和其他浏览器联动。这次应该再也不会出现这种问题了吧。 当然这个功能比起以前手动清理,最大的一点优势就是,不会将其他网站的cookie一起清除掉了。这样E站的账号切换也就很容易了。 这个自动登录的部分其实基本上是从Ecotaku的模块中直接拆出来的…由于前面写的时候已经积累了很多经验,所以这次几乎没遇到多少困难就弄出来了。 最后就是流量限额的查看功能。 这个功能是只针对登录用户有效的。在http://g.e-hentai.org/home.php页面上,你是可以直接查看到自己当前的流量限额状态,并可以使用GP或Credits来恢复限额的。这里只是把这个功能集成到了程序中而已,当然对于从不使用账号的使用者来说,这个功能就无所谓了…