浏览器时间换算
浏览器历史库里存的是整数时间戳，基准与单位都和 Unix 时间不同，直接读会得到 1601 年或 1970 年附近的荒谬数值。Chromium 系（Chrome、Edge）使用自 1601-01-01 UTC 起的微秒数，Firefox 使用自 1970-01-01 UTC 起的微秒数。
基本信息
| Chromium 系 | visit_time 为自 1601-01-01 UTC 起的微秒数 |
|---|---|
| 换算常数 | 11644473600 秒，即 1601 与 1970 两个基准之间的差值 |
| Firefox | visit_date 为自 1970-01-01 UTC 起的微秒数 |
| 库文件位置 | Linux 在 ~/.config/google-chrome/Default/History |
| Windows 位置 | %LOCALAPPDATA%\Google\Chrome\User Data\Default\History |
| Firefox 库 | 配置目录下的 places.sqlite |
典型使用场景
- 还原浏览器访问行为的时间线
- 判断某域名首次与末次访问的时刻
- 与网络流量日志对照确认访问动作
- 分析下载记录并关联本地文件时间
- 排查书签与保存凭据的变更时点
最小示例
最小示例
cp ~/.config/google-chrome/Default/History /tmp/History # 先复制副本再查询
sqlite3 /tmp/History "SELECT datetime(visit_time/1000000-11644473600,'unixepoch') FROM visits LIMIT 3;"
sqlite3 /tmp/History "SELECT url, visit_count FROM urls ORDER BY last_visit_time DESC LIMIT 5;"
cp places.sqlite /tmp/places.sqlite # Firefox 同样先复制
sqlite3 /tmp/places.sqlite "SELECT datetime(visit_date/1000000,'unixepoch') FROM moz_historyvisits LIMIT 3;"
sqlite3 /tmp/places.sqlite "SELECT url, title FROM moz_places ORDER BY last_visit_date DESC LIMIT 5;"字段与解读
| 项目 | 含义 | 说明 |
|---|---|---|
| visit_time | Chromium 访问时刻 | 微秒，基准为 1601-01-01 UTC |
| visit_date | Firefox 访问时刻 | 微秒，基准为 1970-01-01 UTC |
| 11644473600 | 两个基准之间的秒数 | 换算 Chromium 时间时必须先减掉 |
| url | 访问地址 | 含查询参数时按脱敏规则处理 |
| visit_count | 累计访问次数 | 与时间戳配合判断活跃程度 |
| last_visit_time | 汇总的最后访问时间 | 需与 visits 表逐条记录配合校验 |
直接对原始 History 库执行查询会生成额外的日志文件，还可能被浏览器本身覆盖；先复制副本，若存在 -wal 与 -shm 文件要一并复制。
时间戳为 0 或异常小的条目一般表示该字段未写入，应作为无效值排除，而不是换算出一个虚假时间。
urls 表的 last_visit_time 只是汇总字段，要还原逐条访问序列应以 visits 表为准，两者不一致时以明细表为准并说明差异。
同一用户目录下常有多个配置文件（Default、Profile 1 等），不同浏览器也各存一份历史库，只查一个会漏掉其余浏览记录。
浏览器库通常处于被占用状态，边用边查可能读到不一致快照，也可能触发浏览器自身的修复逻辑改写数据。