快捷指令和 Auto.js 怎么做加密：用哈希接口补上签名能力

如果你本地就是标准后端项目，MD5、SHA256、HMAC 这些东西直接本地算就行，根本没必要多绕一层 HTTP。

但有些场景不是这样。

比如快捷指令、Auto.js 这种环境，发请求很方便，拼参数也不难，偏偏目标网站或者接口多了一步签名校验。
这时候问题就来了：不是你不会算，而是你当前这个环境不适合补一套本地加密逻辑。

这个哈希接口更适合解决的，就是这种问题。

这个接口适合什么场景

接口文档：

• https://apizero.cn/marketplace/hash

接口入口：

• https://v1.apizero.cn/api/hash

它支持：

• MD5、SHA-1、SHA-256、SHA-384、SHA-512
• SHA3-256、SHA3-512、RIPEMD-160、Whirlpool
• CRC32、CRC32B、Adler-32
• HMAC 签名
• hex/base64输出

但这篇不想再把算法列表抄一遍。

这接口最合适的场景其实很具体：

• 你在快捷指令里抓某个网站内容，但它请求前要签名
• 你在 Auto.js 里调某个接口，但它的参数要先做哈希
• 你在机器人框架里能发 HTTP，但官方没给现成加密能力
• 你不是不会写，而是当前环境补本地加密不划算

所以重点不是“它支持多少算法”，而是：

当前环境能不能直接拿它补签名能力。

场景一：快捷指令抓网站内容，结果卡在签名上

这个场景最典型。

比如你在快捷指令里做一个内容获取流程：

1. 用户输入一个关键词
2. 快捷指令去请求某个网站或接口
3. 把返回结果整理后展示

前两步都很顺。
问题是第三方接口并不一定让你直接调。

有些站会要求：

• 某个参数先做 SHA256
• 某个 header 要带 HMAC 签名
• 请求体和时间戳拼接后再算摘要

这时候快捷指令最尴尬的地方就出来了：

• 请求你会发
• 参数你会拼
• 但真让你在里面补一套稳定的 SHA256 / HMAC，不一定顺手

这种时候最省事的做法，就是把哈希接口当成一个中间步骤：

流程

1. 先在快捷指令里拼好待加密文本
2. 请求哈希接口
3. 拿到签名结果
4. 再带着签名去请求目标网站

也就是说，你不是在快捷指令里“实现算法”，而是在快捷指令里“调用加密能力”。

一个真实一点的例子

假设某网站请求前要生成这样一个签名串：

timestamp=1715500000&path=/api/search&keyword=coffee

它要求你对这段文本做：

• algorithm=sha256
• encoding=hex

那你在快捷指令里就不用自己实现 SHA256，只需要先请求：

GET /api/hash?text=timestamp%3D1715500000%26path%3D%2Fapi%2Fsearch%26keyword%3Dcoffee&algorithm=sha256&encoding=hex HTTP/1.1 Host: v1.apizero.cn Accept: application/json

拿到结果后，把这个摘要塞回目标接口的sign参数里，再发正式请求。

这样写下来，快捷指令本身只负责流程，不负责加密实现。

场景二：Auto.js 请求接口，参数里偏偏要 HMAC

Auto.js 这边更常见的不是“单纯算个 MD5”，而是请求接口时要补 HMAC。

比如你在 Auto.js 里做一个自动化请求：

• 先登录
• 再拉数据
• 最后提交结果

其中某一步接口要求你带一个签名，比如：

• 把body + timestamp + nonce拼起来
• 用密钥做HMAC-SHA256
• 再把结果放进请求头

这时候如果官方没给现成签名函数，你就会卡在这个地方。

继续自己在 Auto.js 里补一整套 HMAC 逻辑，不是不能写，但很多时候没必要。
尤其你只是想把事情做通，而不是在脚本环境里再维护一套加密实现。

这个时候就很适合直接调哈希接口。

请求示例

GET /api/hash?text=body%3Dabc123%26timestamp%3D1715500000%26nonce%3Dxyz&algorithm=sha256&hmac_key=my_secret_key&encoding=base64 HTTP/1.1 Host: v1.apizero.cn Accept: application/json

返回结果拿到以后，直接回填到你后续请求头里，比如：

X-Sign: xxxxxxxxx

这样 Auto.js 只要会发 HTTP 请求，就够了。

这两种场景里，真正有用的是这几个参数

在这篇的使用场景里，真正要关心的其实只有四个东西：

• text：你要计算的原始文本
• algorithm：比如md5、sha256
• encoding：hex或base64
• hmac_key：如果要做 HMAC 才传

这个接口最实用的点就在这里：

• 普通哈希，不传hmac_key
• HMAC 签名，传hmac_key
• 想看得直观点，用hex
• 对方接口要求更紧凑结果，就用base64

机器人框架这类场景，也能顺手补上

之前我做某些机器人框架接网站接口时，也遇到过类似问题：

• 能发请求
• 能收消息
• 能做简单逻辑
• 但官方没现成加密能力

这种场景本质和快捷指令、Auto.js 一样：
缺的不是“会不会发请求”，缺的是请求前那一步签名。

所以这种哈希接口，本质上就是一个外接能力补丁。

这种场景下，代码就不用硬写 SDK 了

当你当前环境不方便本地做哈希/HMAC 时，怎么通过一个 HTTP 接口把能力补进去。

这个场景下，真正有价值的不是 SDK，而是调用思路：

1. 先拼待加密文本
2. 再请求哈希接口
3. 拿结果
4. 回填正式请求

够了。

小结

它更适合快捷指令、Auto.js、机器人框架这类环境：请求会发，参数会拼，但目标网站偏偏又多了一步签名或加密。