期望使用 Aria2 进行下载 about e-hentai-downloader

[ccloli]

由于网络状况是不确定的，有时 require 的资源是不能被用户访问的（主要是**地区），而且如果使用 require 的话，一旦资源发生了更新就可能会遇到不能使用的情况（比如现在 JSZip 更新到了 3.0，所有的旧有 API 基本已经不兼容了），所以我认为直接将库放在脚本中可以保证用户能正常使用。

其实应该放 .min.js 这种已经压缩过的脚本比较好，然而 GreasyFork 不允许压缩混淆，所以只好放源脚本了。

使用第三方下载器下载工作量确实会少很多，所以之前有人开 issue 时有考虑过脚本只负责导出图片地址，不过目前还没有加入计划中。另外 E-Hentai 的图片是有 time out 机制的（参考 #6 ），如果直接导出的话可能会有无法下载的情况，所以从这方面考虑的话似乎不是特别实用。

[ccloli]

另外这里有基于现有代码实现的 node-webkit 版本，这个 fork 的版本不需要 JSZip 之类的库而是直接将文件写在磁盘中，感兴趣可以看看： https://github.com/8qwe24657913/E-Hentai-Downloader-NW.js

[Mapaler]

Time out是怎么，正常浏览没有碰到过啊，几年前fffonion的xeHentai一直都能把Image Limits下完。用JS做倒是cookies比较关键，之前想做个osu!歌曲下载，结果cookies都是httponly，要扩展才有权限读取。刚才看了eh没有httponly，应该方便很多。

[ccloli]

Time out 是脚本早期版本经常遇到的问题，EH 的图片地址是有访问时间限制的，如果超过超时了会显示 "An error occured. (403)"，所以这个与 Cookies 没关系，是 H@H 自己的超时限制。

[Mapaler]

我看了你发的那个，是个本地程序的（和扩展意义一样），这种切来切去的并不方便。用Aria2的，可以把按钮放在页面中，点一下就开始进行。
而且我单位是走流量的，我每个月都要超好多钱，所以都是把链接发送回家里下载。

[ccloli]

请参考你楼上的回复，这是使用第三方工具下载的最大问题，而且很有可能会被 ban。

[Mapaler]

正是因为没有httponly cookie才可以纯js解析图片下载地址，通过RPC（http post）发送给设置好的aria2下载，不需要切换，比“右键用迅雷下载”还方便。
aria2可以伪装useragent、referer，发送各种header（包括cookie），限制同时下载数量和同时下载分段数，在设置好后，几乎不可能被发现。

[Mapaler]

aria2还有事件钩子（我没深入研究过），如果发生下载错误，让脚本重新解析怎么样？
一般不会同时产生特别大量的下载吧，会超时么？

[ccloli]

我认同你对 Aria2 的看法，然而我已经说过很多次了，H@H 提供的图片地址有 超时限制 。也就是说比如这个 URL 只能在 5 分钟之内有效，超过 5 分钟后你只能看到 "An error occured. (403)" 的错误提示，所以这是我认为使用类似 Aria2 之类的工具的限制。

另外我一开始就提到过目前还没有在计划中的打算，现在我想做的事情在 wiki 的 Todo List 里有说，至于后期会不会加只能看情况。

[Mapaler]

另一个话题，tag的汉化，你觉得用js好还是css好？我现在做了js的，但是网慢的时候就得等网页加载完了才出来。css用before伪类就可以很快的显示，但是编辑起来比较麻烦——因为现在没找到合适的地方做数据库编辑系统。

[ccloli]

个人认为 JS 活动性大些，但是没接触过这方面的功能所以不好下定论。

[Mapaler]

实际上最大的问题是我不知道用什么框架来做翻译的数据库。现在是全部手动写在脚本里。我是希望做成让所有用户可以自行添加编辑（类似wiki，但又不需要那么复杂）。自己从头做对账户系统的安全没信心，又不知道用哪个社会化登陆比较好。本来Personal挺好的，结果今年就要关了

[ccloli]

如果你是指翻译的话可以在 GitHub 上开 repo，让其他翻译者 pull request，或者有翻译者专门用的平台（比如 Transifix），你也可以尝试一下。

另外我认为现在讨论的范围已经超出了这个主题的范围了，如果讨论内容与本项目相关的话你可以新建一个 issue 进行讨论，如果无关的话可以去其他相关的交流社区问问。