115链接转磁力全解析：以SHA1为指纹的反查机制与实操指南

在论坛或者资源分享群里，我经常看到有人发一串这样的链接：

115://115sha1localcompute.exe|16421491|1eff2afb2cdbbaaa8017d79b6980696cb

第一次见到的人普遍懵圈：前面是协议，中间有竖线，后面还有一串十六进制数，看着像网盘分享口令，又有点像某种加密串。更多人会问：这玩意儿能不能转成磁力链接，直接丢进 qBittorrent 或者 BitComet 下载？

先把结论说在前面：严格意义上的“一键转磁力”是不存在的，因为115链接和磁力链接背后是两种完全不同的哈希体系。但好消息是，通过“SHA1反查BT索引”这套流程，你有很大机会能从115链接定位到BT网络里同一份文件。这篇文章会把原理、工具、实操、避坑全走一遍，适合被各种115://链接困扰的普通用户，也适合经常批量处理网盘资源、想在BT网络里找同款文件的下载爱好者。

1. 先搞懂115://和磁力链接到底差在哪

在处理转换之前，最好先把两种链接的底细摸清楚。很多人在这一步没想明白，后面再怎么折腾都是白费功夫。

1.1 115链接的三段式结构

一个完整的115链接通常长这样：

115://115sha1localcompute.exe|16421491|1eff2afb2cdbbaaa8017d79b6980696cb

用竖线分成三段。第一段是文件名，第二段是文件大小，单位是字节，第三段是对文件内容计算出来的SHA1哈希值。

这里有个细节我要专门说一下：第一段那个115sha1localcompute.exe不是一个真正的软件名字，而是115网盘客户端在本地计算文件哈希时自动生成的临时文件名。你从客户端里复制下载链接时，如果源文件名没有被传递过来，系统就会用类似115sha1localcompute.exe、115sha1remotefile.bin这样的名字来占位。所以当你看到第一段是这种名字，可以理解成“这个链接只记录了哈希，没记录源文件名”。

115网盘为什么把SHA1哈希放进链接里？这跟网盘的“秒传”机制有关。同样的文件内容，无论谁上传，算出来的SHA1都一样，服务器只需要比对哈希就能知道文件是否已经存在，不用真的再存一份。于是SHA1就成了文件的内容指纹，很多第三方插件也干脆用115://文件名|大小|SHA1这种结构来做分享协议。第三段的40位十六进制字符，才是整个链接里最有价值的部分。

1.2 磁力链接里的BTIH是怎样算出来的

再来看磁力链接。标准磁力链接长这样：

magnet:?xt=urn:btih:B7C0F25C6A75DB2A47B2C0A01B9C1A9B7A7F7B4E&dn=文件名

btih是BitTorrent Info Hash的缩写，是一个20字节共160位的信息摘要。计算BTIH的时候，工具先读取种子文件（.torrent），从里面提取出“info字典”，然后对这个字典整体做SHA1。这个info字典里包含了文件名、文件大小、每个分块的大小以及所有分块的SHA1哈希等元数据。

关键在于：BTIH是对“种子元数据”做的SHA1，不是对“文件内容”做的SHA1。同一个视频文件，用它做的种子，只要种子里文件名不同、分块大小不同、或者分块顺序有变化，BTIH都会不一样。而115链接里的SHA1是对文件内容直接算出来的，两者从数学上就不能互相推导。

1.3 “115转磁力”的本质不是转换，是反查

网上那些“115链接转磁力”的工具，原理其实都是下面这样：先从115链接里提取出文件内容的SHA1，然后拿着这个指纹去BT索引库、DHT缓存、历史种子数据库里搜，看看有没有哪个种子正好包含这个文件。搜到了，就能得到对应的磁力链接；搜不到，说明BT网络里压根没有这个文件的完整种子，再怎么做格式转换也只是造出一个永远连不上的空壳。

想明白这一点很重要，它可以避免你被“一键转换”类的工具误导。真正的“转换”是一个反查匹配的过程，不是把SHA1换个格式这么简单。

2. 从115哈希到磁力链接的三条可行路径

上一章明白了原理，接下来是实操路线。根据我自己的实践，从115链接出发找到可用的磁力，基本就三条路。

2.1 路径A：用SHA1反查BT索引库

这是最常用、也最值得优先尝试的一条路。

很多BT索引站在抓取种子时，不只是记录种子里的BTIH，还会把每个文件的文件名、大小、甚至文件的SHA1一并解析出来存到检索系统里。所以你在搜索框里直接输入文件内容的40位SHA1，是有机会命中匹配项的。

具体步骤是：

1. 从115链接中提取出40位十六进制SHA1，例如1eff2afb2cdbbaaa8017d79b6980696cb；
2. 打开一个支持哈希检索的BT索引站，把SHA1粘贴到搜索框；
3. 看结果列表里有没有文件名、文件大小与手中资源基本一致的目标；
4. 点进详情查看种子文件列表，确认包含目标文件；
5. 复制该种子的磁力链接，准备使用。

注意事项：不同索引站的字段设计不同，有的只支持BTIH，不支持内容SHA1搜索。如果一个站搜不到，别立刻下结论，换两三个站再试。搜索时建议先用小写字母，因为不少后台数据库默认存小写。

2.2 路径B：走离线下载中转验证

如果你的网络环境对BT不友好，比如没公网IP、NAT类型受限、经常拉不到对端，那反查成功后直接下载可能很痛苦。这时候可以走网盘的离线下载服务做中转。

操作如下：先把反查到的磁力链接丢进115网盘的“离线下载”，等云端任务真正开始跑，说明服务商种子库里有这份资源，云服务器能连上做种者。之后把离线下载得到的文件存到自己网盘，再从网盘客户端本地下载。这个流程虽然多了一步，但下载速度和完整性都有保证。

需要提醒的是，这条路径严格来说叫“磁力转115”，不是“115转磁力”。如果你手里只有115链接，没有磁力，那就不能反过来用离线下载反推。不过它可以用来做验证：当你怀疑某个磁力是否就是某115链接指向的文件时，让离线任务下载完成后，转存一份到网盘，再把网盘里这个文件的SHA1提取出来与115链接里的SHA1做比对，结果一目了然。

2.3 路径C：格式硬转的“占位链接”用法

还有一种工具会把SHA1直接按BTIH的规则转成磁力链接，比如把40位十六进制SHA1转成32位Base32，或者原封不动拼成magnet:?xt=urn:btih:<sha1>。

严格讲，这种磁力链接在绝大多数情况下是没有对端资源的，因为BTIH与文件SHA1并不是同一个东西。但我会把它当作一个“占位链接”来用：以链接形式把SHA1记录下来，方便在支持磁力搜索的站点里快速识别；或者某些特殊资源站刚好把文件SHA1当作BTIH发布，这时候反而能命中。所以路径C不适合作为首选，但也不毫无用处。

3. 实操：解析、反查、锁定一份磁力

原理讲得再多，也得落到手上有代码、有操作。下面我用一个演示链接走一遍完整流程，你可以把链接换成自己拿到的真实内容。

3.1 手工拆解一个115链接

拿这条演示数据来说：

115://115sha1localcompute.exe|16421491|1eff2afb2cdbbaaa8017d79b6980696cb

手工拆开：

只要第三段是40位十六进制，它就是一个可用于反查的SHA1指纹。

实操提示：如果从聊天软件复制链接，容易被自动换行或表情符号截断，导致只剩两三段。复制后先粘贴到纯文本编辑器里检查一下完整性。

3.2 用Python脚本批量解析，格式乱也不怕

一次只有一两条链接，手工拆就够了。但如果你手里是一整个资源帖，动辄几十条115链接，就必须脚本化处理。下面这段代码能兼容两种常见写法：“文件名|大小|SHA1”和“文件名|SHA1|大小”。

import re def parse_115_link(text): text = text.strip() if not text.startswith("115://"): text = "115://" + text body = text[len("115://"):] parts = body.split("|") if len(parts) != 3: return None sha1 = None size = None name = None for p in parts: p = p.strip() if re.fullmatch(r"[0-9a-fA-F]{40}", p): sha1 = p.lower() elif re.fullmatch(r"\d+", p): size = int(p) else: name = p if sha1 is None or size is None or name is None: return None return {"name": name, "size": size, "sha1": sha1}

这段代码的核心是：用正则识别“40位十六进制”为SHA1，识别“纯数字”为大小，剩余字段当文件名。所以就算三段顺序调换，也能正确解析。批量处理时，把多行链接喂给列表循环即可：

links = [ "115://115sha1localcompute.exe|16421491|1eff2afb2cdbbaaa8017d79b6980696cb", "115://cadence_16.6.iso|1234567890|aabbccddeeff00112233445566778899aabbccdd", ] for link in links: info = parse_115_link(link) if info: print(f"文件名: {info['name']}") print(f"大小: {info['size']} 字节") print(f"SHA1: {info['sha1']}") print("---")

跑完脚本，你会得到一份“文件名+大小+SHA1”的清单，这就是后面反查的原料。

3.3 用SHA1在BT索引库反查的标准步骤

拿到SHA1后，在浏览器里打开一个你常用的BT索引站，把1eff2afb2cdbbaaa8017d79b6980696cb粘进搜索框，回车。

正常情况下会出现几种可能性：

• 直接命中同名、同大小的结果，这是最理想的，点进去看种子文件列表，确认目标文件在列；
• 命中多个大小接近但文件名不同的结果，这时候就要用文件大小进一步过滤；
• 一个结果都没有，说明这个SHA1不在该站索引里，需要换站或换方案。

确认命中后，复制磁力链接时一定要看清楚xt=urn:btih:后面的哈希值。有些网站在详情页会把“SHA1”和“BTIH”同时列出来，两者如果不一样，要以btih参数里的值为准。

3.4 反查失败后的补救搜索技巧

反查失败是常态，尤其是比较冷门的资源。我的补救顺序是这样的：

1. 换搜索形式：试试Base32编码后的BTIH（第4.3节有转换方法），个别站点只索引Base32形式；
2. 换关键词：文件名去掉扩展名，或加上版本号、制作组等关键字再搜；
3. 改哈希大小写：部分老旧的索引系统对大小写不敏感，但有的敏感，建议小写、大写各试一次；
4. 换站点：BT索引站各有侧重，覆盖面差别很大；
5. 扩大范围：用“SHA1前16位”或“文件名”做模糊搜索，再手动比对文件列表。

到这里，线上反查基本走完。能命中最好，命不中就得考虑网盘端有没有其他办法，比如联系分享者要补链。

4. 拿到磁力之后：验证与完整性校验

反查得到磁力链接只是开始，真正的坑往往在下载阶段。下面按先后顺序讲清楚验证链路。

4.1 用文件大小做第一轮筛选

拿到磁力链接后，先看种子详情里的文件大小，与115链接里的大小做对比。115链接第二段16421491是单个文件的字节数。如果磁力里那个目标文件大小差出很多，比如标称15MB实际40MB，说明不是同一份文件，直接放弃。

不过要注意，有些种子是打包发布的，目标文件之外还有说明文档、汉化补丁、封面图等附加文件。你要比的是目标文件自己的大小，不是整个种子的总大小。

4.2 下载完成后用SHA1一锤定音

大小一致只能说“高度疑似”，要百分之百确定，还得靠下载完成后的哈希校验。

Windows下用PowerShell：

Get-FileHash -Algorithm SHA1 -Path D:\Downloads\yourfile.bin

Linux/macOS下更简单：

sha1sum yourfile.bin

把输出的40位十六进制结果与115链接第三段比对，完全一致，才能说明这次反查真正成功。我以前下过一个大体积安装包，下载工具显示100%完成，结果因为磁盘错误导致分区数据损坏，SHA1对不上，重新下一遍才恢复正常，所以这步不能省。

4.3 BTIH的十六进制与Base32换算

前面反复提到“40位十六进制”和“32位Base32”，这里把它讲透。

BTIH本质是20字节的数据，共160位。40位十六进制对应160位，每4位一个字符。32位Base32也是160位，但每个字符代表5位，所以32×5=160，正好。字符表是A-Z加2-7，长度32。

十六进制转Base32需要先把十六进制字符串还原成字节，再按5位分组重新编码，不能用字母一一对应。Python里用标准库就能做：

import base64 def hex_to_btih_base32(hex_str): raw = bytes.fromhex(hex_str) return base64.b32encode(raw).decode() print(hex_to_btih_base32("1eff2afb2cdbbaaa8017d79b6980696cb"))

输出的是32个字符的Base32字符串，可以拼进磁力链接的xt=urn:btih:后面。再次强调，这种“格式转换”得到的磁力不能保证有源，它只是让你在那些只认Base32的站点里多一种搜索姿势。

5. 常见问题与排查技巧实录

这部分是实战踩坑总结，直接整理成表格，后面再补几个容易忽略的细节。

5.1 高频问题速查表

5.2 三个容易被忽略的实操细节

第一个细节是哈希的大小写。很多脚本解析时都统一转成小写，但某些索引站更吃大写，所以反查搜索时可以大小写各试一次，成本很低，回报率高。

第二个细节是分段下载。有些BT客户端默认不校验已完成分块，如果你之前下过残缺文件，可能被客户端当成有效分块跳过。建议下载前把保存目录里的同名旧文件清掉，别让旧分块污染新任务。

第三个细节是提取哈希时别连文件名一起搜索。有人图省事，把整个115://115sha1localcompute.exe|16421491|1eff...粘进搜索框，绝大多数搜索引擎会把它当成一段乱码，结果自然为空。真正有价值的就是最后那40位十六进制。

这些细节虽然小，但用好了能帮你省下大量折腾时间。

6. 关联工具与典型场景延伸

讲完核心流程，再补充几个用户搜索热词里的关联点，帮大家把这些知识串到真实使用场景里。

6.1 115云盘下载提速脚本的原理与风险

有关“115云盘下载提速脚本”的讨论一直很多。这类脚本通常以用户脚本形式存在，配合Tampermonkey运行在浏览器里。原理大致是：拦截115网页版的文件请求，把官方下载入口拆分为多线程分片拉取，或者切换到更快的加速节点，从而突破官方客户端的单线程限速。

使用流程一般是：

1. 浏览器安装Tampermonkey扩展；
2. 获取脚本源码，新建脚本并保存；
3. 打开115网页版并登录；
4. 在文件下载页点击“下载”或“离线获取”，观察脚本是否接管请求。

风险我必须讲清楚。这类脚本需要读取网页里的接口响应数据，等于能看到你的登录态和部分文件信息，来源不明时很可能顺手带走你的Cookie。如果你一定要用，建议在隔离的浏览器配置里登录，用完之后退出账号，并定期清理Cookie。从稳定性角度看，官方客户端始终是最可靠的选择，脚本只能算锦上添花。

6.2 大型软件资源“115链接转磁力”的实战建议

最后看一个热搜里“cadence 16.6 115”所代表的典型场景：大型EDA类软件的安装包，动辄几个GB甚至十几个GB，分享者为了防失效，往往只发115链接而不会直接发种子。作为下载者，拿到115链接后的建议是：

• 先把所有分卷的115链接批量解析，得到一份“分卷名+大小+SHA1”清单；
• 拿清单里的SHA1去BT索引库反查，优先找同版本、同分卷大小的种子；
• 若找到，先比对单个分卷大小，再用下载完成后的SHA1校验；
• 若找不到，就用完整文件名的关键词搜索，很多资源站给种子起了不同名字，但里面的分卷SHA1是一样的。

这里也提醒一下安装类大文件最容易踩的坑：分卷文件众多，哪怕只有一个分卷损坏，解压或安装都会失败。所以不管你是从115下载还是从BT下载，安装前一定要把每个分卷的SHA1都核对一遍，别省这点时间。

最后说说我的习惯。我做资源整理时，同一份文件手里往往同时有115链接和磁力链接，我会一直把文件内容的SHA1当作唯一的对照基准。115链接给SHA1，BT种子也给每个文件SHA1，两边一比对，是不是同一份文件马上见分晓。这比记文件名、比大小都可靠得多。再遇到“115://开头的链接怎么转磁力”这种问题，我的答案始终是：别执着于把SHA1硬塞进magnet链接里，而是把SHA1当作指纹去搜索、去匹配、去校验。你真正要找的不是“链接格式”，而是“同一份数据的另一个入口”。把这条思路理清，后续无论网盘资源怎么变，你都有办法绕回自己想下的文件。