以及它是否是一个与用户相关的参数。我担心它可能取决于地理数据 + 活跃登录用户数据的组合。这将使找到通用参数和仅一个基于城市的地理位置 GET 请求的所有希望破灭。
我联系了一位法国 SEO 同事来验证这个理
论并尝试找出“ uule ”参数的值，结果“太成功了”！他那边的“ uule ”参数值和我那边的“uule”参数值匹配。结果发现，“ uule ”参数 决策者电子邮件列表 实际上允许基于城市对查询进行地理定位。
因此，问题立即出现了：我们如何才能获得所有可能的 uule 值？我们是否要“全部删除”它们，还是尝试了解事物的工作原理（逆向工程），以便能够自己创建或 uule？实际上，两者都是。
这值得吗？让我刮一下吧！
因为我们已经有了包含所有需 您可以使用类似的方法将两 要查找位置的原始文件，所以我们只需要使用 casperjs 或 imacros 删除生成的 iframe 的 src。
虽然我个人喜欢用 imacros 进行简单的抓取或提交任务，但让我们面对现实吧：Casperjs 更适合那些确切知道自己在寻找什么的人。除此之外，到目前为止，我只成功使用 Casperjs（一个基于 phantomjs 的框架）抓取了由 ajax 驱动的 Adwords 界面（此外，
结果：一份用于地理定位的（长）参数列表
在本文首次发布（法语版）后，我们 巴西号码列表 与几位朋友进行了交谈，我们发现，根据 Google Adwords 中全球所有可用地点的 csv， 这个“ uule ”只是该地点“规范名称”的 base64 编码形式。如果我以法语为例：
然后，我的一个朋友尝试删除下一个字母（即在第一个例子中为“ f ”）并使用 base64 解码字符串的其余部分并且 bingo：你得到了该地方的“规范名称”：（Lezigne,Pays de la Loire,France）。
那么， w+CAIQICI与字符串其余部分 之间的中间字母是什么？很简单：uule 的意思是：w+CAIQICI = 我们想根据它的“规范名称”从某个地方获取 uulef = 这是一种基于未编码“规范名称”字符串长度的密钥
规范名称”的 base64 编码形式
我们看到，f仅取决于未编码的城市“规范名称”字符串的长度。这里有我们迄今为止使用抓取方法获得的所有密钥和长度：