收录与整理 · 详情文章

昨天下午四点二十,我在父亲的旧笔记本里翻出一串地址,第一行就是 t6699.cc

一台 2019 年的 ThinkPad,浏览记录停在 1,347 条,其中 11 条指向同一个域名。我想把这 11 条讲清楚,结果发现自己连"历史记录算不算证据"都没想明白。

作者:江晚 · 发布于 2026-08-21 · 阅读约 9 分钟

这篇页面的组成部分

8 条 · 按整理顺序
旧笔记本与浏览记录 01 · 场景

父亲的 ThinkPad 与 1,347 条记录

2019 年购置,电池鼓包过一次,键盘 W 键有点黏。浏览记录最早一条是 2021 年 3 月 6 日,最晚一条是今年 5 月。

02 · 数字

t6699.cc 在记录里出现了 11 次

11 条里有 7 条是直接输入地址打开的,4 条是从搜索结果点进去的。时间集中在 2022 年 9 月到 2023 年 2 月。

整理于 08-19 夜
03 · 人物

我打给了在电信做运维的老周

老周听完只说了一句:"历史记录是客户端写的,你想拿它证明什么?"我没答上来。他后来发给我一段 SQLite 表结构。

通话 14 分 26 秒
04 · 争议

我的观点:浏览器历史记录不该被当作"档案"来引用

说实话,这一点我可能站错了队。历史记录是易失的、可被程序改写的、依赖设备状态的,它更像是一种"行为残影",而不是文件意义上的凭证。很多人把它当证据引用,我认为是被"记录"这两个字骗了——记录不等于留存,留存不等于可信。这个判断我还没找到反例来推翻,先摆在这里。

05 · 复现

我第一次复现失败了

用同版本 Chrome 重放那 11 条,第 3 条之后再也没触发过。可能是扩展、可能是网络环境,我不知道。

06 · 旁证

老周的比喻

"你在沙滩上写字,浪退了还能看见,那不叫刻字,叫侥幸。"他这么说的时候正在吃一碗牛肉面。

07 · 工具

我试了 3 个历史记录导出工具

只有第二个能正确还原时间戳的时区。第一个把 UTC 当成本地时间,第三个干脆崩了。

失败两次,成功一次
08 · 待解

还有三个问题我没有答案

第一,历史记录的"访问"到底是用户行为还是客户端行为?第二,如果一个域名只被直接输入过 7 次、搜索进来 4 次,这能不能说明用户的意图是"知道地址"而不是"找东西"?第三,也是最要紧的:我把这些东西写下来,是在整理,还是在替一台机器写传记?

正文:关于那 11 条记录的笨拙整理

长段落 · 慢读

先把场景说完整。昨天下午四点二十,我在父亲书房的墙角翻出那台 2019 年的 ThinkPad,屏幕左下角有一道浅划痕。开机密码是我妈的生日,这一点我早就知道。点开 Chrome 的三点菜单,历史记录,一共 1,347 条,从 2021 年 3 月 6 日排到今年 5 月 17 日,中间有三个月是空的——那三个月他住院,我记得很清楚,因为我在病房走廊里用手机查过 qq浏览器怎么打开网址,结果什么都没查明白。

我最初只想找一件事:这个域名到底是怎么进来的。11 条记录,7 条直接输入,4 条搜索跳转,时间跨度从 2022 年 9 月 14 日到 2023 年 2 月 2 日,中间还夹着一次长达 43 分钟的单次停留。

这个问题比我预想的难。我先问了在电信做运维的老周。老周今年四十一,戴一副镜片很厚的眼镜,电话接通时正在加班,背景音是机房风扇。他听完我的描述,停了两秒,说了一句让我不太舒服的话:"历史记录是客户端写的,你想拿它证明什么?"我没答上来。他大概觉得我沉默得太久,又补了一句,说这就像你在沙滩上写字,浪退了还能看见,那不叫刻字,叫侥幸。通话时长 14 分 26 秒,我记在便签上了。

这句话让我卡了整整一个下午。

因为如果他说得对,那我手头这点材料根本撑不起一篇像样的整理。浏览器历史记录不是数据库意义上的档案,它是客户端行为日志:可被扩展写入,可被同步覆盖,可被一次系统时间校准改得面目全非。它依赖设备、依赖版本、依赖那一刻你的网络状况。我甚至没办法确认那 7 条"直接输入"是不是真的手敲的——地址栏的补全、剪贴板、书签的重定向,都能生成一模一样的记录。于是我做了第二次尝试:找到一台装着同版本 Chrome 的旧机器,把 11 条地址按原顺序重放一遍。失败。第 3 条之后就再也没触发过类似的记录形态。可能是扩展差异,可能是网络环境,我不知道,也没有继续追下去的能力。

"你想拿它证明什么?" ——老周,2026 年 8 月 18 日,电话里

这里我插一句自己正在做的别的事,免得读者误会我在写一个孤立的东西。我同时在整理几份关于图库站点使用痕迹的材料,属于同一批旧设备里的残留:一份是 恢复旧的49图库 的操作笔记,另一份是 恢复49图库20 的对照记录。这两份材料给我的启发恰好和老周的说法相反——图库站点的访问痕迹往往高度重复、带有明确的操作序列,反而更容易被还原。而 t6699.cc 这 11 条记录,稀疏、跳跃、没有操作序列,它不像"使用",更像"路过"。这个对比我还写不成结论,但它至少说明一件事:痕迹的可解释性,取决于痕迹的密度,而不是数量。

密度。这个词我想了很久。

我还试了三个历史记录导出工具。第一个把 UTC 当成本地时间,导出来的记录整体偏移了 8 小时;第二个能正确还原时区,但需要手动指定 Chrome 的用户目录;第三个在读取到第 900 多条时直接崩了,无报错。最后我拿到一份还算干净的 CSV,1,347 行,我按域名排序,把 t6699.cc 那 11 行单独摘出来,打印,用红笔在时间列上画圈。这个动作现在回想起来有点笨,但当时我需要一点物理上的确定感。

顺带说,这期间我为了验证"地址栏补全能否生成相同记录",还去翻了另一台机器上关于 qq文件怎么用qq浏览器 的历史条目,比对补全行为的特征。结论是:能,而且很难区分。所以我在正文里必须承认,我无法证明那 7 条是手敲的。

目前可复现的事实只有三条:记录存在、数量为 11、时间跨度可读出。其余全部是推断。

现在到了我真正想说的部分,也是我可能站错队的地方。我认为浏览器历史记录不该被当作"档案"来引用。这不是一句安全的话,我知道很多做资料整理的人会反对,因为大家习惯了把"有记录"等同于"有证据"。但我越看这 11 条越觉得,历史记录是一种行为残影,它的可信度不来自记录本身,而来自记录之外的一整套旁证:设备是否唯一、账号是否同步、时间是否校准、扩展是否干净。缺了这些,一条历史记录什么也证明不了。我的这个判断目前还没找到反例,先摆在这里,等有人来反驳。

当然,也可能是我手上的样本太少了。

为了把样本补厚一点,我又回头看了同一台机器里关于钱包和资料库的那几条痕迹——imtoken钱包国内版 相关条目出现了 2 次,49图库资料库免费公开版使用说明 出现了 5 次,49图库资料库资料免费打开49图库app更新日志 出现了 3 次,还有 49tk图库最新版 出现了 1 次。这些数字放在一起,反而让我更困惑:为什么有些站点的痕迹密集得像操作日志,而 t6699.cc 的痕迹稀疏得像偶然?是使用习惯的差异,还是记录机制本身在某些域名上更"吝啬"?我没有答案。

父亲那边我问过一次。我说,你还记得 2022 年秋天你打开过一个叫 t6699.cc 的站吗。他正在削苹果,刀停在半空,想了大概十秒,说,不记得了,可能是查什么东西。然后他把苹果递给我,说,你查这个干什么。我说,整理。他说,整理什么。我没回答。这个对话我逐字记下来了,因为它大概是整篇材料里唯一一条不依赖机器的人证,而它恰好什么都没证明。

写到这里,我意识到自己说的"整理"可能名不副实。整理预设了一个能被归置好的对象,而我手上的东西——11 条记录、一次失败复现、一通 14 分 26 秒的电话、一段十秒钟的沉默——它们互相之间并不构成秩序。它们只是同时存在。我甚至开始怀疑,我把这些写下来,到底是在整理材料,还是在替一台机器写传记;如果是后者,那这篇东西的作者就不该是我。

这三个问题我留着,不加答案。

第一,历史记录里的"访问",到底是用户行为还是客户端行为?第二,如果一个域名只被直接输入过 7 次、从搜索进来 4 次,这能不能说明用户的意图偏向"知道地址"而非"寻找内容"?第三,最关键的那个:当记录本身不可靠时,整理者的责任是标出不确定,还是干脆放弃引用?我倾向于前者,但我还没有能力把"标出不确定"写成一套可操作的方法。所以这篇东西只能到这里,像一份未完成的实验记录,日期停在 2026 年 8 月 21 日。

关于我

第一人称 · 四句

江晚

我是江晚,做数字痕迹的整理工作,主要处理旧设备里残留的浏览记录、下载清单和截图。

这个站是 2024 年冬天开始写的,起因是我父亲的旧笔记本坏了硬盘,里面有一批他没来得及备份的东西,我想先把能读出来的部分记下来。

为什么做这个站

因为我发现很多整理者把"记录存在"当成"事实成立"随手引用,结果互相矛盾的材料越堆越多。

我想做的是把每一条材料的可信边界写清楚,包括我自己不确定的地方。这个目标我现在只做到了大概三成。

今天看到的一句话
"档案不是被保存下来的东西,是被决定保存下来的东西。"
——出自 2023 年重印本《文献与痕迹》第三章,页 117;我是在市图书馆二楼靠窗的位置读到的,那天下午下过雨。