解密Google时间戳：EI与VED参数的技术解析
EI时间戳
从根本上说，这个想法是你可以使用EI时间戳来近似估算页面被访问的时间。例如，如果你找到这样的URL：
|
|
你可以提取EI值cDPwZt7ID-fB0PEP5rHJ6A0，然后通过转换找到时间戳Sun 22 Sep 2024 09:10:40 (UTC-6:00)，你可以看到这与我执行的搜索时间非常相似。
虽然我从未声称这是页面被访问的准确时间戳，但我相信它可以提供关于此的重要信息。
计算EI时间
对于任何想知道EI时间如何计算的人，让我们从上面取一个EI值：
cDPwZt7ID-fB0PEP5rHJ6A0
这是URL安全的Base64，所以我们首先需要将"-“转换为”+"，"_“转换为”/"。
现在我们有：cDPwZt7ID+fB0PEP5rHJ6A0
这通过Base64解码得到字节：70 33 f0 66 de c8 0f e7 c1 d0 f1 0f e6 b1 c9 e8 0d
我们实际上不需要所有这些字节，因为EI参数中除了时间戳还有更多内容。
我们只需要前4个字节：70 33 f0 66
这可以读取为32位小端序整数值：1727017840
这只是一个常规的UNIX时间戳（自1970年1月1日以来的秒数）：22 Sep 2024 15:10:40 (UTC)
VED值
我还将介绍Google的另一个查询字符串参数，因为它与时间戳相关，即VED参数。
我不负责解码这个值或弄清楚关于它的任何信息，我会引导你到Ryan Benson出色的unfurl工具和博客获取更多信息。
为了概述它，就像EI值一样，VED值是查询字符串中的一个参数，包含几个信息片段。
如果我们回头看之前的URL，我们可以找到ved值：
|
|
所以，专注于VED值：0ahUKEwjewI7n6taIAxXnIDQIHeZYEt0Q4dUDCBg
第一步是删除第一个字符，它指的是VED的版本。这给我们留下：ahUKEwjewI7n6taIAxXnIDQIHeZYEt0Q4dUDCBg
这是一个base64值，可以转换为十六进制：6a 15 0a 13 08 de c0 8e e7 ea d6 88 03 15 e7 20 34 08 1d e6 58 12 dd 10 e1 d5 03 08 18
*注意，由于base64是URL安全的，你可能需要切换使用的一些字符。
例如，base64字符串中出现的任何"_“需要替换为”+"，"-“需要替换为”/"。
一旦你有了base64解码，你可以发现它是一个需要进一步解码的protbuf blob：
其中一个值可以看到是1727017840255070，这是自1970年1月1日以来的微秒数。
这计算出来是2024-09-22 3:10:40 PM (UTC)，减去我的时区6小时，得到09:10:40，这与EI时间戳值相同。
它们意味着什么？
好的，很酷。所以现在我们知道了它在哪里以及如何计算出来，它意味着什么。
我将通过加载一个全新的浏览器窗口并访问www.google.com开始。
我在正好10:08:00点击了Google URL。
然后我等待了1分钟，在正好10:09:00执行了搜索。
加载的URL是：
|
|
在正好10:10:00，我点击了结果第2页的链接。
加载的URL是：
|
|
现在这些就够了。让我们来计算这些。
第1页（在10:09:00加载）
- EI =
4EDwZpP9D7zA0PEPk8O3mAw=2024-09-22 10:08:00 (UTC -6:00) - VED =
ahUKEwiT7bfP99aIAxU8IDQIHZPhDcMQ4dUDCBg=2024-09-22 10:08:00 PM (UTC-6)
第2页（在10:10:00加载）
- EI =
HEHwZqzpE8Xm0PEPvoOl-Qg=2024-09-22 10:09:00 (UTC -6:00) - VED =
ahUKEwis54ns99aIAxVFMzQIHb5BKY8Q8tMDegQIBRAE=2024-09-22 10:09:00 (UTC-6:00)
你会注意到，对于两个页面，EI和VED时间戳中显示的时间正好比页面实际被访问的时间早1分钟。
这既是预期的，也完全合理。
深入分析
现在让我们后退一步，在10:57:00重新加载初始Google页面。
我可以使用页面检查器工具查看页面背后的HTML代码。在这里我找到一个名为"ei"的隐藏字段，值为XEzwZtH3CMWO0PEP5PWvyAI
我还可以看到许多带有"data-ved"属性的字段，它们都有类似的值。
EI字段中的值可以计算为2024-09-22 10:57:00 (UTC -6:00)。
data-ved字段中的值可以计算为2024-09-22 10:57:00 (UTC-6)。
当我最终在11:02:00提交搜索时，我被带到的URL是：
|
|
注意URL中的EI和VED值等于初始页面中的EI和VED值（减去最后几个字符）。
我不会在这里计算这些，因为我们已经知道它们是什么。
然而，我会查看这个新加载页面的HTML，特别再次查找EI和data-VED字段。
- EI =
2024-09-22 11:02:00 (UTC -6:00) - VED =
2024-09-22 11:02:00 (UTC -6:00)
在11:18:00，我访问了第2页，这带我到了URL：
|
|
这里，EI匹配，大部分VED匹配。同样，最后几个字符不同，但版本字符也不同。无论如何，日期计算出来是相同的。
结论
本质上，当页面加载时，页面加载的时间被嵌入到页面本身。当下一个页面加载时，时间戳作为URL的一部分传递。
这意味着从查询字符串中的EI或VED值解析的时间戳是上一个页面加载的时间，不应误认为是这个页面加载的时间。
但它仍然可能有用。
如果你不需要秒级精确的时间戳，那么这个数据通常足够好，因为你可以通常假设页面在显示的时间戳之后不久被访问。
但这里有一个巨大的警告。
如果我打开一个几天没用的页面并再次开始使用它呢？如果我上次使用页面是几周或几个月前呢？在这些情况下，时间戳可能比我实际访问该页面的时间早几个月。
总结
与许多事情一样，这个时间戳不是Google为了我们的利益而放在那里的。对Google来说，知道你在离开前在页面上花费了多长时间可能很有用。但这并不真正使它对我们有用。
我们正在用我们拥有的东西做到最好，虽然我仍然认为它可能是一个相当有价值的工件，但当被问及它有多准确时，唯一的答案是"视情况而定"。