toor/eh-downloader
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
13 Commits 1 Branch 0 Tags
2d3c322e34291bda389a2728cbdc655765ff853b
Commit Graph
6 Commits
Author SHA1 Message Date
toor 2d3c322e34 feat(油猴): 行内推送按钮 + 已推送画廊标灰 
需求两条：
  1) 列表页的复选框改成按钮，点一下直接推送到工具
  2) 推送过但没点进去的画廊，标题也要变灰（像浏览过的），
     这样刷新后还认得出哪些推过

一、行内推送按钮

复选框 + 底部「批量推送」两步走太啰嗦，列表页每行改成「📤 推送」
胶囊按钮，点一下直接调 /add。按钮三态：
  📤 推送  ->  ⏳ 推送中（禁用）  ->  ✓ 已推送（变绿）
底部悬浮条保留，改为「全部推送」+「重置状态」+ 本页计数。

二、标灰：:visited 伪造不了，只能自己记

E-Hentai 的灰色来自自带样式
  a:visited .glink, a:active .glink { color:#8F6063 }
但 :visited 是浏览器**受保护**伪类：脚本查 matches(':visited')
永远返回 false，加 class 也触发不了站点的原生规则。

所以改成自己记一份「推送过」的清单，再照抄站点的色值手动染色，
观感与原生 :visited 一致（hover 恢复站点的 #8F4701）。

三、清单存哪：工具端为主，浏览器端为辅

新增 internal/core/pushed.go —— PushedStore 独立于 Store，
单独存 %APPDATA%\EH Downloader\pushed.json。

为什么单独一个文件：state.json 里的 tasks 是「当前要下载的东西」，
用户点「清除已完成」就删掉了；但「这个画廊我推送过」是历史事实，
删了任务不该忘掉。所以推送历史与任务列表解耦。

新增桥口 GET /pushed 返回推送历史（与 GET /tasks 语义不同：
后者是当前任务列表，会被清除）。

油猴脚本侧：
  - localStorage（ehdl_pushed_gids）先渲染，刷新后立刻可见，
    工具不在线也能用
  - 工具在线时用 /pushed 校正一次（localStorage 可能被清，
    工具才是权威），以工具为准整体覆盖
  - GET /tasks 保留给需要看当前任务列表的场合

四、附带：state.json 事故的恢复工具

tools/recoverstate —— 修复被写坏的 state.json：
  1) token 先从下载目录的 .ehdl.json 清单里找
  2) 找不到的用 E-Hentai 的 ?next=<gid> 定位法去站点抓
     （该 URL 会返回以 gid 开头的 25 条列表，正则取 token，
     offset 0..5 轮着试）
  3) 抓不到的说明画廊在站点上已被删除

-dry 预演不写盘，写盘前先备份原文件。

配套回归测试：
  - internal/core/pushed_test.go   推送历史读写、任务删除后仍保留
  - internal/core/recover_e2e_test.go  恢复出的任务能真下载（71/71 页）
  - internal/eh/recover_verify_test.go 恢复出的 token 能解析画廊
  - app_test.go                    点「清除已完成」后灰标不消失
  - internal/core/bridge_test.go   /tasks 与 /pushed 的 token 校验

后两者需要能连 e-hentai.org，设 EH_TEST_PROXY 才跑。
 2026-10-25 00:16:03 +08:00
toor 1d7d261490 fix(eh): 标题不再带 " - Tags"，并附批量改名脚本 
meta description 的真实格式是
  "Free Hentai Misc Gallery:  <title> - Tags: a, b, c"
旧正则 `Gallery:\s*([^:]+):` 里的 [^:]+ 是贪婪的，
一路吃到标签段自己的冒号为止，把 " - Tags" 也吞进了标题，
导致下载目录/文件名结尾凭空多出 " - Tags"。

改为显式认 " - Tags:" 这个分隔符（Tags 段可选，无标签时认行尾），
reTitleSuffix 同时认 Tags 结尾，提取后再兜底剥一次。

线上实测（g/4239272）：标题由
  "Hinata l Boruto (CriticalHAI) [AI Generated] - Tags"
变为
  "Hinata l Boruto (CriticalHAI) [AI Generated]"

附带 remove-tags-suffix.bat/.ps1：递归去掉已有压缩包文件名结尾的
" - Tags"，覆盖 zip/rar/7z/cbz/cbr/cb7/tar/gz，幂等。
 2026-10-21 22:18:45 +08:00
toor a078a00f45 fix(eh): 自动放行 EH 的 Content Warning 拦截页 
现象：部分画廊（多被标成 Offensive For Everyone）解析必然失败，报
「页面结构无法解析（EH 可能又改版）」——这条报错是误导的，跟改版无关。

根因：EH 对这类画廊第一次访问只返回一个 3~4KB 的黄框拦截页，
<title> 和 meta 都在，但一个 /s/ 链接都没有，正则自然一条都匹配不上。
放行需要请求一次 ?nw=always，而 EH 靠下发的 nw=1 Cookie 记住
「别再警告」——可 Client 根本没设 CookieJar，Cookie 下发即丢，
于是永远过不去。

实测：4166903 / 4021921 / 3799635 / 3627469 四个画廊修复后
分别解析出 45/95/36/73 页，与站点声明完全一致。

改动：
- Client 持有 cookiejar 并挂到 http.Client.Jar
  （Go 1.26 起 http.Transport 已经没有 Jar 字段了，只能挂 Client）
- 新增 getTextAutoWarn：撞上拦截页自动 ?nw=always 放行一次再重试，
  nw=1 进 jar 后全站不再警告
- 放行失败时的报错明说是内容警告，并提示去浏览器点一次，
  不再甩锅给「EH 可能又改版」
 2026-10-11 11:41:00 +08:00
toor 7243f73d33 fix: 解析大画廊时连接泄漏 + 解析阶段无进度反馈 
用户反馈：点开始下载后 6 个画廊（都是 2000 张级）一直显示「解析中 0/?」，
看起来像卡死。排查发现两个问题：

1. 连接泄漏（真 bug）
   httpClient() 每次请求都新建 http.Transport，用完丢弃。Transport 被丢弃后
   它持有的 keep-alive 连接不会立刻释放（要等 IdleConnTimeout=90s），
   于是每发一个请求留下一条僵尸连接。
   现场实测：91 条 Established 连接，而解析是串行的，正常应该只有 1 条。

   修复：Transport 全局复用，只在代理配置变化时重建，
   重建时 CloseIdleConnections 关掉旧连接；新增 Client.Close()。

   实测：20 次请求从 20 条连接降到 1 条；100 次并发请求只用 22 条。

2. 解析阶段毫无反馈
   2000 张 = 100 屏串行翻页，整个解析阶段界面都显示「解析中 0/?」，
   完全没有进度，用户只能干等。

   修复：FetchGalleryPage 增加 ParseProgress 回调，每翻完一屏上报一次
   （已解析张数/总张数/当前屏），界面显示「已解析 340/2000 张」。

另外：用户设置里请求间隔是 1000ms（1 秒），全局限流让 5 个画廊共享
1 请求/秒 —— 500 次解析请求需要约 8 分钟。这是配置导致的慢，不是 bug，
但可以在界面上看到进度后就不会以为卡死了。

测试从 74 增至 80，新增：
- TestTransportIsReused / TestTransportReusedUnderConcurrency（连接复用）
- TestSetProxyRebuildsTransport（改代理要重建）
- TestParseProgressCallback（进度回调，含最后一屏）
 2026-10-09 10:02:50 +08:00
toor 0447875b6d feat: 双层并发 + 全局限流 + 整轮扫尾 + 画廊目录清单 
原实现只能「多画廊并行，每个画廊串行下」，单张大画廊下得很慢。
按用户多年使用习惯（5 画廊 × 每画廊 8 张）改造为双层并发。

- 双层并发：画廊并发(默认5) × 页并发(默认8) = 最多 40 张同时下载，
  两个值都在设置面板可调（1-20）。页级 worker 池 + mutex 保护计数。
- 全局限流：对齐参考实现的 nextRequestTime 算法，限所有请求
  （含 /s/ 解析与图片本体），默认 0 秒关闭。
- 整轮扫尾：跑完后自动重扫失败页 1 轮（同样走完整 4 次退避重试），
  仍失败则停下并标记 partial，换线路后手动点开始即可续传。
- 画廊目录清单 .ehdl.json：记录 gid/token/总页数/已完成页，
  即使 state.json 丢失也能算出「应该多少张、还差多少张」。

顺带修复：
- Start() 双重加锁导致死锁（引擎完全无法启动）
- clampInt 越界时返回默认值而非边界值（设 30 会静默变 8）
- 直链正则写死 hath.network，CDN 换域名会全军覆没 -> 加图片 URL 兜底
- ReconcileTask 会误报「有改动」

测试从 37 增至 62，其中并发/限流/扫尾用 httptest 模拟 EH 实测：
- 页并发峰值 = 8、画廊并发峰值 = 5（完全生效）
- 12 次请求限流 80ms 实测 966ms（期望 880ms）
- 断点续传 4 张已存在时只发 5 次请求
 2026-10-09 00:11:38 +08:00
toor 0f927147cd feat: EH Downloader 用 Go + Wails v2 重写 
原 Electron 版在这台 Windows 机器上无法启动（0x80000003 崩在 V8 初始化），
整个业务逻辑用 Go 重写，前端界面与协议结论完全保留。

- internal/eh: 协议核心，画廊页分页 -> /s/ -> hath 直链 -> 下载
- internal/core: 并发引擎 / 状态存储 / 目录模板 / 油猴桥口
- app.go: Wails 绑定层，替代 Electron IPC
- frontend/js/api.js: 适配层，renderer.js 一行未改
- 37 个测试，含 httptest 模拟 EH 的端到端链路验证

相比 Electron 版：90MB -> 12.4MB，180MB 内存 -> 27MB，构建 90s -> 2s。

顺带修掉原版代理探测的 bug（永远返回第一个端口，从不等连接结果）。
 2026-10-08 23:28:16 +08:00