你有没有注意到一个现象：现在越来越多的资源站不再提供“.torrent”种子文件，而是一串以“magnet:?”开头的神秘代码。这串代码短则几十个字符，长则上百个，复制到下载工具里就能开始下载——没有种子文件，没有中心服务器，甚至原来的资源站关站了它依然能用。
这背后到底藏着什么技术逻辑？磁力链接究竟是怎么被“生成”出来的？
一、磁力链接的本质：一串“内容指纹”
要理解磁力链接的生成，首先要理解一个关键概念：它和传统下载链接有着根本性的不同。
普通HTTP链接（如 http://example.com/file.mp4）是“位置链接”，它告诉你文件放在哪个服务器的哪个目录下。而磁力链接是“内容链接”——它不关心文件在哪里，只关心文件是什么。科普中国的定义说得很清楚：磁力链接“只是通过不同文件内容的Hash结果生成一个纯文本的‘数字指纹’，并用它来识别文件”。
这个“数字指纹”就是磁力链接的核心。只要文件内容一模一样，无论它存在谁的电脑上、叫什么名字、放在哪个文件夹里，算出来的指纹都是相同的。磁力链接本质上是一个统一资源名称，而非统一资源定位符。
二、生成的核心步骤：从文件到哈希值
磁力链接的生成过程，可以拆解为三个关键步骤。
第一步：构建info字典。 当你要分享一个文件时，BitTorrent客户端首先会扫描这个文件（或文件夹），提取出一组元数据：文件名、文件大小、分块大小以及每个数据块的SHA-1哈希值。这些信息被打包成一个结构化的数据块，称为“info字典”。分块的意义在于，下载时每个块都可以独立校验，确保传输过程中数据没有损坏。
第二步：对info字典进行Bencode编码。 info字典本身是一种数据结构，需要用BitTorrent协议规定的Bencode编码方式序列化为二进制字符串。Bencode是一种极简的编码格式，用数字加冒号表示字符串长度（如 4:name），用字母标记列表和字典的起止。
第三步：计算SHA-1哈希，得到info_hash。 对Bencode编码后的info字典做一次SHA-1运算，得到一个160位（20字节）的哈希值。这个值就是info_hash，它是整个磁力链接唯一的“身份证号”。BitTorrent协议中使用的哈希算法是SHA-1，输出固定为160位。
三、从info_hash到完整磁力链接
得到info_hash之后，还需要经过编码和组装，才能变成你看到的那串字符。
info_hash的原始形式是20字节的二进制数据，直接展示会包含大量不可读字符。因此需要将其编码为可读文本。最常见的方式是十六进制编码，将20字节转化为40个字符的字符串，例如 4D9FA761D69964B00DF0B3B0C9C1F968EA6C47D0。另一种方式是Base32编码，用字母A-Z和数字2-7表示，将20字节压缩为32个字符，例如 SCC2WWKVWVS7EZICVDG5KBK4R4TG2BEW。十六进制格式更常见，但部分动漫资源站偏好Base32格式。
最后，将编码后的哈希值组装成标准格式：
magnet:?xt=urn:btih:<info_hash>&dn=<文件名>&tr=<Tracker地址>
其中，xt 是唯一必需的参数，它包含哈希值本身；dn（显示名称）和 tr（Tracker服务器地址）都是可选参数。一个最简的磁力链接只需要 magnet:?xt=urn:btih: 加上哈希值就够了。
四、为什么不需要Tracker也能用？
传统BT下载依赖Tracker服务器来协调用户之间的连接——你下载前必须先连上Tracker，由它告诉你还有谁在下载同一个文件。Tracker一挂，种子就“死了”。
磁力链接的厉害之处在于，它通过DHT网络（分布式哈希表）解决了这个问题。DHT本质上是一个去中心化的“通讯录”，每个参与下载的节点都保存了一小部分“哪个文件在谁那里”的信息。当你使用磁力链接时，客户端会拿着info_hash向DHT网络中的其他节点发起查询，逐步找到持有该文件数据的用户节点。
这就是为什么2009年BTChina等站点倒下后，大量磁力链接依然能够正常下载——因为它们根本不依赖任何中心服务器。
五、总结
磁力链接的生成可以概括为一句话：对文件内容计算SHA-1哈希，将哈希值编码后组装成标准URI。它的技术根基由三层构成——SHA-1哈希算法确保文件的唯一标识，Bencode编码规范数据结构，DHT网络实现去中心化的资源发现。正是这三者的组合，让磁力链接成为了一种比传统种子文件更轻量、更健壮、更便于传播的文件分享方式。