Sleazy Fork

感谢你的脚本, 我写了一个脚本, 引用了你脚本很多代码, 在此感谢。

在使用中, 发现了很多不匹配的, 例如下面这些, 代码应该是正确的, 最起码在某个番号中是正确的

aczd: ["h_019","00"],
ako: [""],
arso: ["1"],
bank: ["h_1495"],
bbtu:[""],
bfd: ["24b","00"],
bfkb: ["h_1285","00"],
bjd:[""],
bkynb: ["1","00"],
blb:[""],
bskc:[""],
clot: ["h_237"],
davk:["55"],
erofc:[""],
fbos:[""],
fneo: ["h_491"],
gar: ["1","00"],
gas: ["71"],
gone: ["h_1133"],
havd: ["1","00"],
jsop:[""],
keed:["h_086","00"],
mct: ["118"],
moko: ["h_254"],
mxgs:["h_068"],
neo:["433"],
omhd: [""],
pako:["h_1133"],
shic:["h_839"],
sma:[""],
thnib: ["h_706","00"],
tkol:[""],
tmhp: ["h_452"],
tmvi: ["h_452","00"],
tppn:[""],
vagu: [""],
venu: [""],
xvsr:[""],
ymdd:[""],
zeaa: ["h_086","00"],

一些不成熟的建议:

1. 在我测试的很多失败番号中, 去掉默认添加的 00 就能获取到视频, 可以在第一次失败后, 再尝试一次, 能提高一些成功率, 可以将失败率降低 1/3 左右。
2. javbus番号下方的“樣品圖像”, 某些是直接引用的 dmm.co.jp 上的, 图片和视频存储地址是一样的(绝大数),可以直接截取, 这样会极大的提高成功率。 不能保证地址是一模一样, 但大多数一样, 个别不一样是由于图片上额外加了00, 而视频地址中却没有, 再结合第一点建议, 基本能通杀。 上方反馈的那些番号就是这样得到的。

目前有个别番号比较特殊

1. 一个番号对应多个地址, doks 对应 h_139doks 和 36doks00
2. bf的番号按照之前的规则是没法写的, 按照代码里的拼接规则相当于是在corp bf后面添加了1个0, 然后在数字前面又添加了1个0 。
3. thnib 这个番号在前面添加了 n_1445之后, 又把番号截断了1位添加的, 变成了n_1445thni, 少了最后的 b

感觉可以写成下面这种, 不分开, 直接写在一起。本身脚本内的代码最终也是把它们合在一起。

keed:["h_086keed00"],

// 多个
// h_139doks571   36doks00567
doks:["h_139doks","36doks00"],

// 末尾补零
bf:["bf00"],

// 末尾截断
// n_1445thni088
thnib:["n_1445thni"],

还有一种更特殊的

例如 keed-078, 前面加了h_086, 后面数字删0 视频地址 https:///cc3001.dmm.co.jp/litevideo/freepv/h/h_0/h_086keed78/h_086keed78_sm_w.mp4
但是 keed-077, 就是正常的 视频地址 https://cc3001.dmm.co.jp/litevideo/freepv/h/h_0/h_086keed00077/h_086keed00077_dmb_w.mp4

感谢反馈与支持。你反馈的问题确实是存在的，现有的静态规则无法完全处理，这个番号规则生成比较复杂。 之前我与另外一个脚本的作者合作写了一个更全规则的版本，最近比较忙还没来得及测试发布。 目前静态规则处理失效后会调用在线查询的方法去匹配，缺点是有点慢。

推荐个思路：在每次获取到正确预览地址后，保存数据（番号和预览地址）到脚本数据里，已有下次可直接调用，没有的再次匹配成功到地址后写入。
就像楼主@qxin i写的根据番号搜索脚本一样，现在不是有avInfo数据表，可以加个预览地址数据表，用来保存番号和获取的正确预览地址，
后期数据存储多了，可以写成远程JSON用来调用。（可以参考自动无缝翻页的形式，有远程数据和本地获取的数据互补）
前期用脚本来匹配到正确地址，后期就收获地址，不断壮大这个数据库，也省去了番号预览地址规则匹配时间。
因为DMM预览地址太变态，有些系列，光规则就四五条，你再去匹配（mhb_w.mp4=3000 kbps\dmb_w.mp4=1500 kbps\dm_w.mp4=1000 kbps\sm_w.mp4=300 kbps\sm_s.mp4\dmb_s.mp4\vrlite.mp4等）这些后缀，又有很多条，大大延长了加载时间，这还不说无码系列的。

推荐个思路：在每次获取到正确预览地址后，保存数据（番号和预览地址）到脚本数据里，已有下次可直接调用，没有的再次匹配成功到地址后写入。
就像楼主@qxin i写的根据番号搜索脚本一样，现在不是有avInfo数据表，可以加个预览地址数据表，用来保存番号和获取的正确预览地址，
后期数据存储多了，可以写成远程JSON用来调用。（可以参考自动无缝翻页的形式，有远程数据和本地获取的数据互补）
前期用脚本来匹配到正确地址，后期就收获地址，不断壮大这个数据库，也省去了番号预览地址规则匹配时间。
因为DMM预览地址太变态，有些系列，光规则就四五条，你再去匹配（mhb_w.mp4=3000 kbps\dmb_w.mp4=1500 kbps\dm_w.mp4=1000 kbps\sm_w.mp4=300 kbps\sm_s.mp4\dmb_s.mp4\vrlite.mp4等）这些后缀，又有很多条，大大延长了加载时间，这还不说无码系列的。

其实 javspyl.tk 这个接口的后端就是按你说的方式来实现的。
这个接口的作者给我提供了他的数据库，我也写了一个初步的版本，但目前还没有时间来测试和优化，所以没有发布出来，请多包涵。
感谢支持与建议。