Python爬虫怎么分析API协议_通过抓包工具分析加密参数构造-Python教程-PHP中文网

抓包看不到请求体或参数被加密，是因为https未解密、工具未解析非标准格式请求，或前端使用混淆js/wasm加密；需配置抓包工具解密https、在devtools查request payload、比对签名原文构造细节、定位加密逻辑并统一环境与编码规范。

python爬虫怎么分析api协议_通过抓包工具分析加密参数构造

不是接口没发数据，是浏览器用了 fetch 或 XMLHttpRequest 发送了非标准格式的请求（比如 application/json 或二进制 blob），而某些抓包工具默认不解析或过滤掉了这类流量。

实操建议：

用 Charles 或 Fiddler 时，务必勾选「Capture HTTPS traffic」并安装根证书，否则所有 HTTPS 请求体都是空的
在 Chrome DevTools 的 Network 面板里，点开具体请求 → 切到 Headers 标签页看 Request Payload，不是 Form Data
如果 Payload 是乱码或 Base64，大概率是加密了；先别急着逆向，先确认它是否每次请求都变——如果 timestamp、nonce、sign 这类字段存在，说明是服务端要求的签名机制

常见现象是：抓到的 sign 值一模一样，但自己用 requests.post() 提交就失败。根本原因不是加密算法写错了，而是签名原文构造顺序/编码方式/时间戳精度和前端不一致。

实操建议：

前端 JS 里找 sign 相关函数（如 getSign、buildSignature），重点关注它拼接参数的顺序——Python 用 dict 构造参数时默认无序，必须用 collections.OrderedDict 或按 key 字母序排序
检查时间戳单位：Date.now() 是毫秒，int(time.time()) 是秒，差1000倍会导致签名失效
URL 编码要严格对应：JS 的 encodeURIComponent 不编码 ' '（空格）为 +，而是 %20；Python 的 urllib.parse.quote 默认也不转 +，但若传了 safe='' 就会转，得保持一致

不是所有加密都在明文 JS 里。遇到 .wasm 文件加载、或者 JS 变量名全是 _0xabc123 这种，说明做了混淆或把核心逻辑抽到了 WASM。

python-script-generator

快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。

下载

实操建议：

在 Chrome DevTools 的 Sources 面板里，按 Cmd+Shift+F（Mac）或 Ctrl+Shift+F（Win）全局搜 sign、encrypt、crypto、wasm，优先看 webpack 打包后的 bundle.js 里靠后的函数
如果发现 WebAssembly.instantiateStreaming 调用，右键该 .wasm 文件 → Save as 下来，用 wabt 工具链反编译：wasm-decompile xxx.wasm -o xxx.wat，再搜索关键词
别硬啃整个混淆代码——直接在疑似加密函数开头加 debugger;，刷新页面触发断点，看调用栈和入参，比读代码快得多

典型表现：本地 python test.py 输出的 sign 和浏览器一致，但放到 Linux 服务器上就错。问题往往出在环境差异导致的底层行为偏移。

实操建议：

检查 Python 版本：某些加密库（如 pycryptodome）在 3.8 和 3.12 上对 padding 的默认处理不同，AES.new(..., mode=AES.MODE_CBC) 必须显式传 iv，不能依赖默认值
系统时区影响 datetime 生成的时间字符串——浏览器用的是本地时区，服务器可能用 UTC，导致 timestamp 或 date 字段不一致
Linux 系统默认 locale 是 C，str.encode() 在某些场景下会忽略 Unicode 正规化，而浏览器 JS 的 TextEncoder 总是用 UTF-8 + NFC 规范，建议统一用 unicodedata.normalize('NFC', s).encode()