BT9G LABS / DHT 深度解析 #04

InfoHash 深度解析：BitTorrent v1、v2、Magnet、BTIH 与 BTMH

理解 BitTorrent 内容标识如何计算，以及 v1 SHA-1、v2 SHA-256、BTIH 与 BTMH 在 Magnet 链接中的关系。

BT9G Labs发布于 2026-09-163 分钟阅读

BT9G Labs / DHT Deep Dive #04. 从内容身份边界出发，解释 v1 与 v2 Torrent 如何生成哈希，以及搜索索引应如何正确处理两代标识。

InfoHash 深度解析：BitTorrent v1、v2、Magnet、BTIH 与 BTMH

快速摘要

主题: InfoHash 深度解析：BitTorrent v1、v2、Magnet、BTIH 与 BTMH
核心关键词: InfoHash, BitTorrent v1, BitTorrent v2, BTIH, BTMH
适合读者: 后端工程师、协议研究者、搜索工程师以及 BitTorrent 实现者
目标: 用足够准确的协议与系统视角解释原理，并能直接支持真实的采集、索引和搜索架构设计。

系统视图

.torrentinfo dictionaryHash FunctionInfoHashMagnet URI

.torrent → info dictionary; info dictionary → Hash Function; Hash Function → InfoHash; InfoHash → Magnet URI

info dictionary 才是身份边界

在 BitTorrent 中，Torrent 的内容身份并不是对整个 .torrent 文件随便做一次哈希。v1 的 InfoHash 是对 bencoded info dictionary 的编码结果执行 SHA-1；因此注释、创建者、Tracker 列表等 info 之外的字段发生变化时，v1 InfoHash 可以保持不变。

索引器如果重新序列化 info 结构再计算哈希，必须极其谨慎。尤其是解析后重编码可能改变原始字节序列，进而得到不同的哈希。最安全的做法是保留用于身份校验的原始字节边界。

v1 与 BTIH

经典 BitTorrent v1 使用 20 字节 SHA-1 InfoHash。在 Magnet URI 中，这种标识通常通过 xt=urn:btih:... 表示，可以是十六进制或 Base32 编码。大量 DHT、Tracker 与现有索引生态都围绕这个 160-bit 标识构建。

数据库层应把“原始二进制哈希”和“展示编码”分开。十六进制大小写差异不应该制造两个资源记录，用户输入的 Base32 也应规范化到同一个 canonical key。

v2、SHA-256 与 BTMH

BitTorrent v2 在 BEP 52 中引入 SHA-256 和 Merkle tree 等设计，内容身份不再完全等同于传统 v1 的 20 字节哈希。Magnet 表示通常使用 multihash 形式的 urn:btmh:。此外还存在同时兼容 v1 与 v2 的 hybrid torrent。

因此现代搜索系统不能把“InfoHash 永远就是 40 个十六进制字符”写死在所有数据模型中。更稳妥的设计是显式保存协议版本、哈希算法、原始摘要以及可用于 URL/搜索的规范化表示。

对索引系统意味着什么

内容身份是去重、Metadata 校验、详情页路由和跨来源合并的基础。v1、v2 和 hybrid 数据必须采用明确规则，不能简单把不同 namespace 的字符串塞进同一列后靠长度猜类型。

对于 BT9G 一类系统，最好让 canonical content identity 与“从哪里发现”“哪些 Tracker 出现过”“最近有哪些 Peer 活跃”解耦。这样同一内容可以聚合多种网络来源，同时不污染真正的身份字段。

实现示意

import hashlib

def v1_infohash(raw_bencoded_info: bytes) -> bytes:
    return hashlib.sha1(raw_bencoded_info).digest()

def v2_infohash(raw_bencoded_info: bytes) -> bytes:
    return hashlib.sha256(raw_bencoded_info).digest()

BT9G Labs 工程笔记

对 BT9G 一类索引系统而言，最重要的不是单纯追求事件数量，而是把内容身份、网络观察、采集状态和搜索文档拆成清晰的数据层。所有来自 DHT 或 Peer 的字段都应该保留来源与时间戳，并通过阶段化指标区分发现、连接、协商、Metadata 获取、校验、入库和索引等环节。这样才能在规模扩大后定位真实瓶颈，而不是把所有失败都归因于“网络不稳定”。

常见误区

对整个 .torrent 文件直接计算 v1 InfoHash。
把十六进制大小写差异当成不同资源。
假设所有 InfoHash 都固定为 20 字节 SHA-1。
没有为 v2 和 hybrid torrent 预留数据模型。

参考资料

下一篇: BEP 5 DHT 报文详解：ping、find_node、get_peers 与 announce_peer →

本文用于解释公开的 BitTorrent 协议与工程实现思路，不代表任何被观察到的 Swarm 一定可用、有效或被授权传播。