贴一个enhancement：识别无前缀的网盘链接

[zxk2099]

常常会遇到因为各种原因不能发链接的地方，所以希望可以增加一个识别网盘链接后缀的功能，仅提供后边的部分就自动识别补全的链接。

这是我在2.0.5的基础上自己实现了一份：https://github.com/zxk2099/linkAI/blob/main/panai.js，添加的部分已用added注释出来了，可以直接搜到，逻辑是用正则匹配后缀。因为我不是专门做程序的，专门fork一份给自己使用也没有必要，所以希望能在正式版里有一个更全面的类似的功能。

[52fisher]

感谢，已拜读所提供的方案。其实之前有用户提出过类似的issueissues 51
目前的自动推导方案其实是不太完美的
比如：百度网盘 1JR-omArnoiiHZF85RksZDQ?pwd=upgw 1Plb_4feyJCAcZcCkKCBqFA?pwd=8888
正常识别
以下网盘（未支持）也会被错误的推导为百度网盘：https://1024terabox.com/s/1OrzYplkLgAW4UNdu0YzP9g
另如：
蓝奏云的唯一标识符 有七位的 https://pan.lanzoui.com/b174576
有九位的 https://www.lanzouw.com/b073c7g4f
有十一位的 https://pan.lanzous.com/iZRzRlb126b
这个位数太多 我觉得错误的可能性太多了

我在最近的更新中加入了这个功能，作为实验性功能，设置了开关

尝试支持百度、迅雷和夸克等网盘

[zxk2099]

我觉得可以考虑两个方向，一个是主流模式，一个是兼容模式；前者只考虑相同情况下的最主流情况，后者就把所有可能性都列出来让用户自己选。

比如蓝奏云和123都是12位的A-z0-9，蓝奏云的出现频率高于123盘，所以同12位正则就直接识别为蓝奏云。主流模式就是满足最多数人遇到的最多数情况就够了，同样23位A-z0-9，在百度和terabox之间做一个选择必然是前者。

关于蓝奏云7位9位，我个人测试了一下，貌似分享链接长短与文件最早上传的时间有关，18、19年的生成是7位，24、25年是12位，蓝奏云又不具备百度盘一样可以分享大文件置换本地硬盘空间的特点，久远资源积累还是相对弱势，所以主流模式完全可以去掉对7位的识别。

兼容模式我想了一种方案就是类似于edge浏览器选中后自动弹出的上下文菜单一样，选中后直接匹配所有正则，弹出所有符合的网盘，然后根据网盘规模排序，让用户自己选择。没法完美匹配，多这一步也没啥，即使加上这一步，也要比完全自己手动复制、手动输入前缀再粘贴要快得多。

像我写的很粗糙的代码，还有我其他脚本里也有判断url的正则，实际用下来从来没有遇到过问题，普通人一般不会有需要大量识别的场景，就算大量识别也不会轻易遇到边界情况。相同的正则结构决定了用正则不可能完美匹配出不同的网盘，但是就算不能完美识别，在大多数情况OK就已经很好了，这是我的一点想法

[52fisher]

比如蓝奏云和123都是12位的A-z0-9，蓝奏云的出现频率高于123盘，所以同12位正则就直接识别为蓝奏云。主流模式就是满足最多数人遇到的最多数情况就够了，同样23位A-z0-9，在百度和terabox之间做一个选择必然是前者。

目前更新的方向还是考虑的这种模式

关于蓝奏云7位9位，我个人测试了一下，貌似分享链接长短与文件最早上传的时间有关，18、19年的生成是7位，24、25年是12位，蓝奏云又不具备百度盘一样可以分享大文件置换本地硬盘空间的特点，久远资源积累还是相对弱势，所以主流模式完全可以去掉对7位的识别。

其实这个真的不好说，因为很多分享站还是会在以前产生的短链上进行分享，不能只考虑其中一些情况

兼容模式我想了一种方案就是类似于edge浏览器选中后自动弹出的上下文菜单一样，选中后直接匹配所有正则，弹出所有符合的网盘，然后根据网盘规模排序，让用户自己选择。没法完美匹配，多这一步也没啥，即使加上这一步，也要比完全自己手动复制、手动输入前缀再粘贴要快得多。

这种暂时不考虑，本身通过host判断要遍历一遍，未找到匹配对象会在父元素中再找一遍，还没找到就开始看是否开启了自动推导补全，开启后又要重新遍历一遍，要根据网盘规模排序，还得去给这些网盘指派权重，这个真有些不好说……在老司机里面他会觉得网赚网盘的权重更高，在一些资源分享的人眼里觉得百度、阿里这种权重高。有些人（这种人还不少）喜欢直接ctrl+a，然后等脚本自动识别，这种资源消耗就比较大，还是会有一些性能的问题的。

像我写的很粗糙的代码，还有我其他脚本里也有判断url的正则，实际用下来从来没有遇到过问题，普通人一般不会有需要大量识别的场景，就算大量识别也不会轻易遇到边界情况。相同的正则结构决定了用正则不可能完美匹配出不同的网盘，但是就算不能完美识别，在大多数情况OK就已经很好了，这是我的一点想法

我们自己fork再改的代码，基本上都是符合自身的情况的，用户基数大了，边界情况就会很多的。有些我们觉得不可能会发生的问题，在他们那里就会经常发生。这种权重问题不好解决，要么就参考隔壁网盘识别那种，能自行配置增删，但是那个性能真的爆炸，遇到一些网站甚至会内存溢出。比如你的fix函数里面，看起来好像没有指派权重，其实你把百度网盘的识别放到第一个，已经说明在你的观点中，百度网盘是你最常用的网盘，优先级是最高的，如果后面再遇到同样的大小写数字混合23位的，肯定会优先识别为百度网盘，基本上不会有人把不常用的放到逻辑的第一位来处理。我觉得这对我来说任务量也很大，本身这个脚本的定位就是云盘识别，自动推导补全也只是锦上添花的功能，不能本末倒置