逆向知乎x-zse-96签名：从JS断点到Python实现的完整爬虫实战

1. 项目概述：当爬虫遇上知乎的加密门禁

如果你用Python写过爬虫，特别是想从知乎上获取点数据，那你大概率见过这个场景：你信心满满地写好了 requests.get() ，模拟了 User-Agent ，甚至带上了登录后的 Cookie ，但服务器返回的却是一个冷冰冰的“请求参数异常，请升级客户端后重试”。问题往往就出在请求头里一个不起眼的字段： x-zse-96 。这个参数，就是知乎API大门前的一道动态加密锁，没有正确的“钥匙”（签名），你的请求连门都摸不到。

我刚开始接触这个参数时，也走了不少弯路。网上能找到的代码片段要么已经失效，要么语焉不详，只给个结果，不说过程。逆向分析这类前端加密，听起来很高深，像是安全专家的领域，但其实只要掌握了正确的“破案”思路，任何有耐心、懂点JavaScript的开发者都能搞定。今天，我就以一个实战者的身份，带你完整走一遍从浏览器断点调试，到最终用Python稳定生成 x-zse-96 参数的整个流程。这不是一篇理论教科书，而是一份我踩过无数坑后总结出的“保姆级”操作手册。无论你是爬虫新手，还是遇到过类似加密难题的老手，这篇文章都能给你提供一套清晰、可复现的解决方案。

2. 逆向前的准备：理解加密的战场

在动手“抠代码”之前，我们必须先搞清楚对手是谁，战场在哪。盲目地一头扎进JavaScript的海洋，只会被淹没。

2.1 知乎反爬机制的核心： x-zse-96 是什么？

简单来说， x-zse-96 是知乎对其部分API请求（尤其是搜索、用户动态、回答列表等）进行客户端签名验证的产物。它不是简单的随机数或时间戳，而是一个基于多个动态参数（包括你的请求路径、Cookie、特定请求头等）计算出来的加密字符串。

它的存在意义在于：

1. 防止未授权访问 ：确保请求来自“合法”的知乎客户端（浏览器或App），而非简单的脚本。
2. 增加逆向成本 ：签名算法放在前端JavaScript中，且会不定期更新，迫使爬虫开发者需要持续跟进分析。
3. 绑定会话 ：签名计算依赖 d_c0 这个Cookie，使得签名与你的登录会话强关联，无法在不同账户间通用。

当你看到一个完整的、携带 x-zse-96 的知乎请求头时，它通常长这样：

GET /api/v4/search_v3?t=general&q=Python HTTP/1.1
Host: www.zhihu.com
User-Agent: Mozilla/5.0...
x-api-version: 3.0.91
x-zse-93: 101_3_3.0
x-zse-96: 2.0_aBcDeFgHiJkLmNoPqRsTuVwXyZ012345
Cookie: d_c0="ABC123..."; other_cookies...

其中， x-zse-93 是一个固定的版本标识，而 x-zse-96 则是我们需要攻破的动态签名。

2.2 工具准备：你的“破案”工具箱

工欲善其事，必先利其器。逆向前端加密，你只需要浏览器和代码编辑器，但用好它们需要技巧。

• 浏览器（首选 Chrome/Edge） ：这是我们的主战场。开发者工具（F12）是核心。
  • Sources 面板 ：用于设置断点、查看和调试JavaScript代码。
  • Network 面板 ：用于抓包，观察正常请求携带了哪些参数。
  • Console 面板 ：用于在断点暂停时，查看和修改变量值，执行临时代码。
• 代码编辑器（VS Code / Sublime Text） ：用于保存和整理我们“抠”出来的JavaScript代码。
• Node.js 环境 ：用于在本地独立运行和测试我们抠出的加密函数，验证其正确性。
• Python 环境 ：最终的生产环境。需要安装 requests 和 execjs 库。

  pip install requests PyExecJS
  

  注意 ： PyExecJS 是一个桥接库，它允许Python执行JavaScript代码。其底层需要一个JavaScript运行时，在Windows上默认可能是 JScript （IE引擎），对ES6+语法支持很差。 强烈建议你确保系统已安装Node.js，并让 execjs 使用Node作为运行时 ，这样兼容性最好。

准备工作就绪，接下来我们进入正题，开始“现场勘查”。

3. 现场勘查：在浏览器中定位加密现场

逆向的第一步，永远是观察。我们需要找到一个携带 x-zse-96 的正常请求，并定位生成它的代码位置。

3.1 抓包与观察：找到目标请求

1. 打开浏览器，访问 zhihu.com 并登录你的账号。
2. 按 F12 打开开发者工具，切换到 Network（网络） 面板。
3. 勾选 Preserve log（保留日志） ，防止页面跳转时请求记录被清空。
4. 在知乎首页的搜索框里，输入一个关键词（比如“Python”）并搜索。
5. 在网络面板中，仔细筛选请求。你会看到一系列以 search_v3 、 search 开头的请求。点击其中一个，查看它的 Headers（标头） 。
6. 在 Request Headers（请求头） 部分，你应该能看到 x-zse-93 和 x-zse-96 这两个字段。记下这个请求的 URL（请求地址） 和完整的 Headers 。这是我们分析的起点。

3.2 全局搜索与断点：锁定加密函数

知道参数在哪出现还不够，我们需要找到生成它的代码。

1. 在开发者工具中，切换到 Sources（源代码） 面板。
2. 按 Ctrl + Shift + F （Windows/Linux）或 Cmd + Opt + F （Mac），打开全局搜索框。
3. 输入 x-zse-96 进行搜索。通常结果不会太多，可能只有2-5个匹配项。
4. 这些匹配项，很可能就是设置这个请求头的地方。 在每一处匹配的行号上点击，设置断点（Breakpoint） 。断点处会出现一个蓝色箭头。
5. 设置好断点后，回到知乎页面， 再次进行一次搜索操作 ，或者刷新页面。
6. 此时，浏览器的JavaScript执行流会在你设置的断点处暂停。页面会卡住，开发者工具会自动聚焦到Sources面板，并高亮暂停的那一行代码。

第一次实操心得 ：这里有个小技巧，如果设置了多个断点但代码没有暂停，可能是因为你设置的断点位置在函数定义处，而非函数执行处。确保你是在类似 headers['x-zse-96'] = value 这样的赋值语句上打的断点。如果还不确定，可以尝试在 x-zse-96 出现的附近，找找类似 set 、 assign 这样的函数调用打上断点。

4. 抽丝剥茧：逆向分析签名生成逻辑

代码暂停后，真正的侦探工作开始了。我们需要在“案发现场”收集所有线索。

4.1 解读调用栈与变量：找到源头

当代码在断点处暂停时，关注右侧的几个关键面板：

• Call Stack（调用堆栈） ：这里显示了当前暂停的函数是被谁调用的，一层层回溯上去。你不需要理解整个链条，但可以点击堆栈中上一层的函数，看看它从哪里调用了当前函数，这有助于你理解上下文。
• Scope（作用域） ：这里显示了当前作用域下的所有变量及其值。这是 最重要的信息来源 。
• Console（控制台） ：你可以在这里输入JavaScript表达式，实时查看或计算变量的值。

现在，看暂停的那行代码。它很可能长这样：

l.set("x-zse-96", "2.0_" + O);
// 或者
d.headers["x-zse-96"] = "2.0_" + signature;

这里的 O 或 signature 就是计算出来的签名值。我们的目标是找到 O 是怎么来的。

1. 悬停查看 ：将鼠标悬停在变量 O 上，开发者工具会显示它的当前值（一长串字符）。
2. 控制台打印 ：在Console面板里，直接输入 O 并回车，可以更清晰地看到它的值。同时，也输入 O.constructor.name 看看它是什么类型（通常是 String ）。
3. 回溯计算过程 ：在Call Stack中，点击当前函数的上层调用者，逐步往回看。你会看到类似这样的代码模式：

   var O = u()(f()(s));
   // 或者
   var signature = encrypt(md5(inputString));
   

   这里的 s 就是加密的原始输入， f() 是第一步处理（通常是哈希）， u() 是第二步加密。 我们的核心目标就是找到 s 、 f 和 u 。

4.2 拆解原始输入 s

在Console里输入 s ，查看它的值。你会发现它是一个由加号 + 连接的长字符串，格式基本固定为：

101_3_3.0+/api/v4/search_v3?...+d_c0_cookie值+[x-zst-81_header值]

我们来拆解一下每个部分：

1. 101_3_3.0 ：这是一个固定前缀，对应请求头里的 x-zse-93 。不同时期的知乎版本这个值可能不同（如 101_3_2.0 ），需要以你抓包时的值为准。
2. /api/v4/search_v3?... ：这是你请求的API路径和完整的查询字符串（Query String）。 关键点 ：这里的查询参数必须是 URL编码后 的格式，并且要和浏览器实际发出的请求完全一致。浏览器通常会帮你编码好，但我们在Python里构造时，必须手动确保一致性。
3. d_c0 ：这是你知乎登录会话的一个关键Cookie值。它通常在首次访问知乎时，由服务器通过 Set-Cookie 响应头返回。你可以在Network面板中，找到对 www.zhihu.com 域的第一个请求，在Response Headers里找到 set-cookie: d_c0=... 。这个值很长，且包含引号。在拼接 s 时，需要去掉外层的引号，只取引号内的值。
4. x-zst-81 ：这是另一个请求头字段，在某些版本中可以为空字符串。为了保险起见，建议从你成功请求的Headers里复制它的值。

第二次实操心得 ： s 的拼接顺序和分隔符（加号 + ） 绝对不能错 。一个常见的坑是， d_c0 的值本身可能包含加号，但它是作为整体字符串参与拼接的，不需要额外处理。确保你在Console里打印出的 s 和代码中用于计算的 s 完全一致。你可以手动在Console里按照这个格式拼接一个字符串，和变量 s 的值对比，这是验证你理解是否正确的最好方法。

4.3 分析第一步处理 f() ：识别哈希函数

找到 f() 函数的定义。在Sources面板，通常可以点击这个函数名跳转到定义，或者根据上下文找到它。

f() 函数内部可能包含一些位运算和魔数（Magic Number）。对于前端常见的哈希，大概率是 MD5 。如何验证？

1. 在Console里，计算 f()('test') 的值。
2. 打开一个在线MD5计算网站，或者用你熟悉的编程语言计算字符串 'test' 的MD5值（32位小写十六进制）。
3. 对比两者结果。如果一致，那么 f() 就是MD5函数。

为什么是MD5？ MD5算法是公开的，前端实现体积小、速度快，且对于这种签名场景，虽然MD5本身已不抗碰撞，但作为签名算法的一个步骤（后面还有加密），其速度和确定性依然是够用的选择。确认了 f() 是MD5，我们甚至可以用Python的 hashlib 库来替代，减少对抠出JS代码的依赖。但为了完整性，我们通常还是把整个流程的JS代码都抠出来。

4.4 分析第二步加密 u() ：核心逆向难点

这是整个逆向过程中最具挑战的部分。 u() 函数（或者叫 encrypt 、 sign 等）是知乎自定义的加密算法。你需要进入这个函数内部。

1. “抠”代码 ：这不是简单的复制粘贴。你需要把这个函数，以及它内部调用的所有 依赖函数和变量 ，都完整地提取出来。知乎前端代码通常经过Webpack等工具打包，函数和变量名可能被压缩（如 a , b , c ），但逻辑是完整的。
2. 注意模块化 ：你可能会看到 var r = n(10261) 或 var ty = tr.n(tg) 这样的语句。这表示函数来自某个模块。你需要找到这个模块的定义（通常是一个很大的IIFE——立即执行函数表达式），并把相关的代码块一起抠出来。
3. 识别关键操作 ： u() 函数内部可能包含AES、DES，或者自定义的位运算、Base64变种等。你需要通过变量名（如 CryptoJS 、 encrypt 、 mode 、 padding ）和运算模式（如 substr 、 charCodeAt 、 ^ （异或）、 & （与））来初步判断。

一个关键技巧 ：在Console里，对中间变量进行打印。例如，在 u() 函数内部打上断点，查看传入的参数（即 f()(s) 的结果，一个MD5字符串）经过每一步处理后的变化。这能帮你理解算法的每一步在做什么。

5. 环境补全：让抠出的JS代码在Node中运行

费尽九牛二虎之力，你终于把 f() 、 u() 以及它们的依赖函数都抠到了一个本地JS文件里，比如叫 zhihu_sign.js 。迫不及待地在Node环境下运行 node zhihu_sign.js ，结果大概率会看到：

ReferenceError: window is not defined

或者

TypeError: Cannot read properties of undefined (reading 'userAgent')

这是因为浏览器提供了完整的BOM（浏览器对象模型）和DOM环境，而Node.js环境是纯净的，没有 window 、 document 、 navigator 这些对象。被抠出的前端代码往往包含对这些浏览器环境的检测或依赖。

5.1 补环境的基本原理

我们的目标不是搭建一个完整的浏览器，而是“欺骗”这段JS代码，让它以为自己运行在浏览器中。我们通过创建一些全局对象并设置必要的属性来实现。

核心策略：使用Proxy进行懒补全

与其绞尽脑汁去想代码需要哪些属性，不如让代码自己“告诉”我们。我们可以用 Proxy 对象来代理 window 或 navigator ，当代码尝试访问某个属性时，我们再动态地提供它。

5.2 一个实用的补环境代码模板

将以下代码放在你抠出的JS代码的最前面。

// ========== 补环境代码开始 ==========
// 1. 创建全局 window 对象，如果不存在的话
if (typeof globalThis.window === 'undefined') {
    const window = {};
    // 2. 代理 navigator 对象
    const navigatorFake = {
        userAgent: 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36',
        webdriver: false, // 非常重要！很多反爬会检测这个是否为true
        language: 'zh-CN',
        platform: 'Win32',
        appVersion: '5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36',
    };
    // 使用Proxy，当访问不存在的属性时返回undefined而不是报错
    window.navigator = new Proxy(navigatorFake, {
        get(target, prop) {
            // 如果属性存在，则返回；否则返回undefined
            if (prop in target) {
                return target[prop];
            }
            // 可以在这里打印出被访问但未定义的属性，便于后续补充
            // console.log(`[Navigator Proxy] Accessed property: ${prop.toString()}`);
            return undefined;
        }
    });

    // 3. 补充其他可能用到的浏览器对象
    window.location = {
        protocol: 'https:',
        host: 'www.zhihu.com',
        hostname: 'www.zhihu.com',
        href: 'https://www.zhihu.com/',
    };
    window.document = {};
    // 4. 将window挂载到globalThis（Node的全局对象）
    globalThis.window = window;
}
// 如果代码中直接使用了 `navigator`，也将其指向我们创建的代理
if (typeof globalThis.navigator === 'undefined') {
    globalThis.navigator = globalThis.window.navigator;
}
// ========== 补环境代码结束 ==========

// 接下来是你抠出来的知乎加密核心函数...
// function f(s) { ... }
// function u(s) { ... }
// ... 其他依赖函数

// 最后，封装一个方便调用的函数
function get_xzse_96(d_c0, api_path, x_zst_81) {
    // 拼接原始字符串 s，注意顺序和分隔符
    const s = `101_3_3.0+${api_path}+${d_c0}+${x_zst_81 || ''}`;
    // 第一步：MD5哈希 (f函数)
    const step1 = f(s);
    // 第二步：自定义加密 (u函数)
    const signature = u(step1);
    // 最终格式：2.0_ + 签名
    return `2.0_${signature}`;
}

// 导出函数，供Node.js测试或Python的execjs调用
if (typeof module !== 'undefined' && module.exports) {
    module.exports = { get_xzse_96 };
}

5.3 调试与迭代补全

1. 运行你的 zhihu_sign.js 。
2. 如果报错，仔细阅读错误信息。例如，如果报错 ReferenceError: document is not defined ，并且错误堆栈指向你抠出的某行代码，说明那段代码里用到了 document 对象。
3. 根据错误信息，在补环境代码中补充相应的对象或属性。例如，如果只是简单判断 document 是否存在，你可以像上面一样定义一个空对象 window.document = {} 。如果代码调用了 document.createElement 等方法，你可能需要模拟得更细致，但通常加密逻辑不会用到复杂的DOM操作，空对象或简单模拟足以绕过检测。
4. 重复步骤1-3，直到代码能成功运行 get_xzse_96 函数，并且计算出的结果与你在浏览器断点处看到的 x-zse-96 值 完全一致 。

第三次实操心得 ：补环境是个耐心活。一个高效的方法是，在浏览器Sources面板里，在你抠出的代码段开头也加上类似的补环境代码，然后直接在浏览器控制台里运行测试。因为浏览器本身环境是完整的，你的补环境代码可能不会生效，但你可以通过 console.log 打印出代码实际访问了哪些环境属性，从而知道需要在Node中补充什么。

6. Python整合：调用JS函数并发起请求

当你的 zhihu_sign.js 在Node环境下能稳定输出正确的 x-zse-96 后，最后一步就是把它集成到Python爬虫中。

6.1 使用 execjs 调用JavaScript

execjs 库让我们可以在Python中执行JavaScript代码。

import requests
import execjs
import urllib.parse
import json

# 1. 读取我们抠出并补好环境的JS代码
with open('zhihu_sign.js', 'r', encoding='utf-8') as f:
    js_code = f.read()

# 2. 编译JS代码
# 指定使用Node.js作为运行时，兼容性更好
try:
    # 尝试获取Node运行时
    node_runtime = execjs.get('Node')
except:
    # 如果找不到Node，回退到默认运行时（不推荐）
    node_runtime = execjs.get()
    print("警告：未找到Node.js运行时，使用默认运行时，可能不支持某些ES6语法。")

ctx = node_runtime.compile(js_code)

# 3. 准备参数（这些需要从你浏览器的实际请求中获取）
# d_c0: 从Cookie中获取，去掉引号。例如：`"ABC123..."` -> `ABC123...`
d_c0 = "YOUR_D_C0_COOKIE_VALUE_WITHOUT_QUOTES"
# x-zst-81: 从请求头中获取，可能为空字符串
x_zst_81 = "YOUR_X_ZST_81_HEADER_VALUE_OR_EMPTY_STRING"

# 4. 构造API路径和参数（必须与浏览器请求完全一致）
api_path = "/api/v4/search_v3"
# 查询参数，注意顺序和编码
query_params = {
    "t": "general",
    "q": "Python爬虫",  # 搜索关键词
    "correction": "1",
    "offset": "0",
    "limit": "20",
    "lc_idx": "0",
    "show_all_topics": "0",
    "search_source": "Normal",
    "flow": "0",
}
# 关键步骤：将参数字典转换为URL查询字符串
# 使用 urllib.parse.urlencode 并确保空格等字符被正确编码为%20，而不是+
# `quote_via=urllib.parse.quote` 确保编码方式与浏览器一致
encoded_query = urllib.parse.urlencode(query_params, quote_via=urllib.parse.quote)
full_path = f"{api_path}?{encoded_query}"
print(f"构造的API路径: {full_path}")

# 5. 调用JS函数生成 x-zse-96
try:
    xzse96 = ctx.call('get_xzse_96', d_c0, full_path, x_zst_81)
    print(f"成功生成 x-zse-96: {xzse96}")
except Exception as e:
    print(f"调用JS函数失败: {e}")
    # 可能是环境问题或JS代码错误，可以尝试在Node中直接运行测试
    exit(1)

# 6. 组装请求头
headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
    "x-api-version": "3.0.91",  # 重要！需从抓包中获取最新值
    "x-zse-93": "101_3_3.0",    # 与JS代码中拼接的版本号一致
    "x-zse-96": xzse96,          # 我们计算出的签名
    "x-requested-with": "fetch",
    "referer": "https://www.zhihu.com/search?type=content&q=Python",
    "cookie": f"d_c0={d_c0}",    # 关键cookie，注意格式
}
# 如果 x_zst_81 不为空，也加入请求头
if x_zst_81:
    headers["x-zst-81"] = x_zst_81

# 7. 发起请求
url = f"https://www.zhihu.com{full_path}"
print(f"请求URL: {url}")
response = requests.get(url, headers=headers, timeout=10)

print(f"状态码: {response.status_code}")
if response.status_code == 200:
    try:
        data = response.json()
        print("请求成功！")
        # 打印部分结果，例如搜索到的第一条内容
        if data.get('data'):
            first_item = data['data'][0]
            # 根据实际返回结构解析，这里只是示例
            if 'object' in first_item and 'content' in first_item['object']:
                print(f"第一条结果预览: {first_item['object']['content']['title'][:50]}...")
            else:
                print(f"返回数据格式: {json.dumps(data, indent=2, ensure_ascii=False)[:500]}...")
        else:
            print(f"返回数据: {data}")
    except json.JSONDecodeError:
        print("响应不是有效的JSON:", response.text[:200])
else:
    print(f"请求失败: {response.status_code}")
    print(f"响应文本: {response.text[:500]}")  # 打印前500字符以便调试

6.2 关键细节与避坑指南

1. d_c0 Cookie的获取与更新 ：

   • d_c0 是登录态的核心，有有效期。过期后需要重新登录获取。
   • 获取方式：浏览器登录知乎后，在开发者工具的Application -> Cookies -> https://www.zhihu.com 下找到 d_c0 ，复制其 Value 。注意，Value通常被双引号包裹，在Python中使用时 需要去掉引号 。
   • 自动化思路：可以用 requests.session() 模拟登录流程来获取新的 d_c0 ，但这涉及到知乎的登录加密（另一套更复杂的机制），通常手动获取一次够用一段时间。

2. API路径与参数编码 ：

   • 一致性是关键 ： full_path 必须与浏览器中抓到的请求URL中问号 ? 后面的部分 完全一致 ，包括参数的顺序。 urllib.parse.urlencode 默认会对空格编码为 %20 ，而有些浏览器或库可能编码为 + 。使用 quote_via=urllib.parse.quote 参数可以强制使用 %20 ，这是更安全的做法。
   • 验证方法 ：将你Python代码中生成的 full_path 与浏览器Network面板里看到的请求URL进行字符串对比，确保一模一样。

3. 请求头完整性 ：

   • x-api-version 和 x-zse-93 这两个字段也可能随知乎前端更新而变化，务必从最新的抓包数据中复制。
   • referer 和 x-requested-with 虽然不是签名计算的一部分，但加上可以使得请求更像浏览器行为。

4. execjs 运行时选择 ：

   • 在Windows上， execjs 的默认运行时可能是 JScript （IE引擎），对ES6语法支持极差。确保你的系统安装了Node.js，并且 execjs.get(‘Node’) 能正确找到它。你也可以在代码中指定：

     import execjs
     execjs.eval（"process.version") # 测试Node是否可用
     ctx = execjs.get('Node').compile(js_code)
     

7. 进阶策略与长期维护

“抠代码+补环境”的方法在大多数情况下是稳定有效的，但它并非一劳永逸。知乎的加密逻辑可能会更新，反爬策略也会升级。以下是几种应对策略和进阶思路。

7.1 应对算法更新与复杂环境检测

如果某天发现脚本突然失效，返回403或参数错误：

1. 第一步：重新抓包对比 。检查最新的请求中， x-zse-93 、 x-api-version 的值是否变化，请求的URL格式是否有变。
2. 第二步：重新断点调试 。按照第3、4章的步骤，重新定位加密函数。算法核心可能从 u() 换成了另一个函数，但寻找 x-zse-96 赋值处的思路不变。
3. 第三步：应对增强的环境检测 。新的算法可能加入了更多浏览器指纹检测，如：
   • screen.width / screen.height
   • navigator.plugins 长度
   • Canvas 指纹
   • WebGL 渲染器信息 在补环境时，你需要用 Proxy 更精细地模拟这些属性。一个更激进但有效的方法是，在Node中直接定义一个全局的 window 为 Proxy ，并在其 get 陷阱里打印所有被访问的属性，从而知道需要补什么。

   const accessedProperties = new Set();
   globalThis.window = new Proxy({}, {
       get(target, prop) {
           accessedProperties.add(prop);
           // 返回一个默认值，比如空对象或函数
           if (typeof prop === 'symbol') return {};
           if (prop === 'then') return undefined; // 避免被当作Promise
           return function(){}; // 对于方法，返回一个空函数
       }
   });
   // 运行你的加密代码后...
   console.log([...accessedProperties].sort());
   

7.2 JSRPC方案：终极稳定之道

对于加密逻辑极其复杂、更新频繁，或者环境检测严苛到难以模拟的情况，可以考虑 JSRPC（JavaScript Remote Procedure Call） 方案。

核心思想 ：让加密代码始终在真实的浏览器环境中运行，Python只负责发送参数和接收结果。

实现方式 ：

1. 使用 selenium 或 playwright 启动一个无头浏览器（如Chrome）。
2. 在浏览器中打开知乎页面，并注入一个JavaScript脚本。这个脚本将计算 x-zse-96 的函数暴露给页面上下文（例如挂载到 window 对象上）。
3. Python端通过WebDriver的 execute_script 方法，调用这个暴露出来的函数，传入 d_c0 、 api_path 等参数，并获取返回的签名。
4. Python再用这个签名去发起真正的 requests 请求。

优点 ：

• 环境绝对真实 ：所有浏览器API、指纹都是真实的，无需模拟。
• 维护简单 ：即使知乎前端加密代码更新，只要页面能正常加载，你的注入脚本就能调用最新的加密函数。你只需要确保注入脚本能定位到正确的函数即可，无需重新“抠代码”。
• 稳定性高 ：避免了复杂的补环境工作。

缺点 ：

• 性能开销大 ：启动和维护浏览器实例消耗资源。
• 复杂度高 ：需要管理浏览器生命周期、处理页面加载、确保注入脚本执行成功。

这更适合于对稳定性要求极高、且不介意额外资源消耗的生产级爬虫项目。

7.3 移动端接口分析：另辟蹊径

有时，知乎App的接口其签名算法可能比Web端简单，或者使用的是另一套体系。你可以尝试抓包分析知乎App的请求。

• 工具 ：使用 Fiddler 、 Charles 等抓包工具，配置手机代理。
• 分析 ：观察App请求的Headers，寻找类似 x-zse-96 的签名参数。其生成逻辑可能放在App的本地代码（Android的SO库或iOS的二进制文件）中。
• 逆向 ：这属于更高级的逆向工程领域，可能需要使用 Frida （动态插桩）、 unidbg （模拟执行）等工具来Hook或模拟执行Native层的加密函数。这条路难度大，但一旦逆向成功，稳定性往往比Web端更高，因为App更新频率相对较低。

8. 总结与个人体会

逆向 x-zse-96 的过程，本质上是一场与前端工程师的“猫鼠游戏”。它考验的不仅仅是技术，更是耐心、观察力和系统性思维。我从最初的看到加密就发怵，到现在能相对从容地定位和分析，最大的体会是： 流程化和工具化 是关键。

我把整个逆向过程总结为以下标准化流程，每当遇到新的前端加密时，都会按这个步骤来：

1. 抓包定位 ：用浏览器开发者工具，找到携带目标参数的请求。
2. 搜索断点 ：全局搜索参数名，在可能的位置设置断点。
3. 追溯源头 ：在断点暂停时，利用调用栈和作用域面板，找到生成该参数的函数和原始输入。
4. 抠取代码 ：将关键函数及其依赖完整提取到本地文件。
5. 补全环境 ：在Node.js中，用Proxy等方法模拟浏览器环境，让代码能独立运行。
6. 验证输出 ：用已知正确的输入输出对，验证抠出的算法是否工作。
7. 集成调用 ：通过 execjs 或 JSRPC 将算法集成到Python中。

最后，分享几个我踩过的大坑：

• 不要相信记忆，要相信日志 ：所有从浏览器获取的参数（ d_c0 、 x-zst-81 、 api_path ），最好都打印出来，并与浏览器抓包的数据进行逐字符对比。一个空格、一个编码差异都可能导致签名错误。
• 版本号是活的 ： x-zse-93 、 x-api-version 这些字段，定期检查一下是否有变化。养成每次跑脚本前，先抓一次包确认的习惯。
• 准备降级方案 ：对于非常重要的数据获取任务，不要只依赖一种签名方法。可以同时维护 execjs 本地计算和 selenium JSRPC 两种方案。当一种失效时，能快速切换到另一种。
• 尊重规则 ：逆向技术是学习前端安全、理解网络协议的绝佳途径，但请务必将其用于合法合规的学习、测试和研究目的，遵守目标网站的 robots.txt 协议，控制请求频率，避免对对方服务器造成不必要的负担。

希望这篇超过五千字的详细拆解，能帮你彻底打通知乎 x-zse-96 参数逆向的任督二脉。这套方法论不仅适用于知乎，对于大多数前端加密参数（如某音的 X-Bogus 、某宝的 sign 等）的分析，其核心思路都是相通的。祝你爬虫之路顺利！