AdGuard浏览器扩展MV3版本中URI编码参数移除问题解析

在AdGuard浏览器扩展从MV2向MV3架构迁移的过程中，开发团队发现了一个关于$removeparam过滤规则的特殊问题。该问题涉及URI编码参数的处理机制，值得Web开发者和广告过滤技术爱好者深入了解。

问题现象

当用户尝试使用以下过滤规则时：

||reddit.com^$removeparam=%24deep_link 
||reddit.com^$removeparam=%243p

在MV2版本的扩展中能够正常工作的规则，在MV3版本中却无法正确移除URL中的$deep_link和$3p参数。这些参数在URL中实际是以URI编码形式%24deep_link和%243p存在的，其中%24是美元符号$的编码表示。

技术背景

1. URI编码机制：在URL中，某些特殊字符需要被编码为百分号加十六进制数的形式。美元符号$的编码就是%24。

2. MV3架构变化：Manifest V3对浏览器扩展的许多核心功能进行了重构，包括请求修改的处理方式。这种架构变化可能导致某些边缘情况的行为差异。

3. 参数移除逻辑：AdGuard的$removeparam规则需要正确处理原始参数名和编码后参数名的匹配关系。

问题本质

核心问题在于MV3版本中参数移除逻辑对URI编码参数的处理不够完善。具体表现为：

• 规则中明确指定了编码形式的参数名(%24deep_link)
• 但实际URL匹配时可能需要进行双重处理：
  1. 对规则中的参数名进行解码
  2. 对URL中的参数名进行解码
  3. 然后进行匹配比较

解决方案思路

要解决这个问题，需要改进参数匹配逻辑，使其能够：

1. 正确处理URI编码的参数名
2. 保持与MV2版本的行为一致性
3. 不引入额外的性能开销

理想情况下，参数移除功能应该对以下所有形式的规则都能正确工作：

• 原始参数名：$removeparam=deep_link
• 部分编码：$removeparam=%24deep_link
• 完全编码：$removeparam=%24deep%5flink

对用户的影响

普通用户可能会注意到：

• 某些跟踪参数没有被正确移除
• 过滤效果在不同版本扩展中存在差异
• 需要等待扩展更新才能完全解决问题

开发者建议

对于规则编写者，在过渡期间可以：

1. 同时添加编码和非编码版本的规则
2. 关注扩展更新日志
3. 测试规则在不同版本中的效果

这个问题已被标记为修复状态，并计划在AdGuard v5.1-mv3版本中解决，体现了开发团队对兼容性问题的重视和快速响应能力。