Greasy Fork

我来反馈一下这条蓝奏云链接：https://anxiaoxun.lanzoui.com/b01ui329e，密码：pot
按道理来说，我输入一次密码，密码就被脚本自动保存了对吧，但是这条链接始终是密码不正确。

应该是因为密码是三位的吧，一般蓝奏云密码都是四位的。

应该是因为密码是三位的吧，一般蓝奏云密码都是四位的。

是的，因为密码的长度边界比较难界定，所以默认匹配的是4位密码。

虽然匹配数位较少的密码出错的可能性比较低，但是目前的密码匹配逻辑是先从前后的兄弟元素，以及只向上查找。找不到密码时就会全文查找，所以稳定起见还是按照默认的4位来匹配比较安全。

4位以下的需要添加特殊支持，如果你的这个链接来源的网站都固定3位，提交一下来源网址

如果只是个例，那就麻烦你自己手动输入一下密码吧

应该是因为密码是三位的吧，一般蓝奏云密码都是四位的。

举个例子

例如一些论坛的链接，可能会出现把密码包含在超链接中，密码匹配逻辑，默认优先从超链接中的文本去匹配。

如果这个时候超链接里包含了6位密码中的其中4个字符，还有2个不是超链接的文本，是跟在后面的普通文本字符。

例如：!https://anxiaoxun.lanzoui.com/b01ui329e，密码：pots56

这个时候就会匹配出错，只能匹配到下面的 pots，56无法匹配。

当然，这个问题技术上肯定可以解决的。可以分别提取超链接中的文本，以及超链接的上下文，再进行一个综合的分析。

但是这样的操作，始终无法确定密码的边界，万一56不是有用的数字呢？把两个密码一起带过去试？

这例子了有遇到过，不管怎样，这个脚本并不盈利，而这类例子出现的概率较低，重复输入的需求不高，逻辑越复杂，出问题的概率越高，问题的处理成本越高，我个人精力有限。

所以密码位数低于4位、异类字符访问码、超长的访问码，单独写一个密码提取规则，这样效率高一些，也可以收集到一些为以后密码提取算法的样本。

有不少后起之秀的脚本参考了我的密码提取逻辑，但是万变不离其宗，他们并没有针对这个密码提取算法做优化，反而集中精力在云提取密码上。

这只是我偶然发现的特殊链接罢了，提交网址就没必要了。