四库一平台数据采集实战思路：看懂接口加密，理顺详情验证与自动化对接

一、先把页面摸清楚，再考虑怎么采集

采集四库一平台的企业数据，最容易走的弯路，就是打开列表页后立刻写循环，觉得把页码不断加一就能完成任务。真正跑起来才发现，列表响应看不懂，企业详情还有验证，偶尔成功的请求换个环境又失败。问题往往出在几个环节同时变化，却没有逐项确认。

比较稳妥的起点，是先用浏览器完成一次正常查询：进入数据服务，打开企业列表，设置查询条件，再点击一家企业查看详情。把这条操作路径走通，才能分清哪些请求负责获取业务数据，哪些只是加载脚本、图片或统计资源，也方便判断验证究竟出现在哪一步。

使用Chrome时，按F12打开开发者工具，进入Network面板，筛选Fetch/XHR请求。先清空记录，再执行一次翻页或查询，观察新增请求的地址、请求方法、查询参数和响应内容。如果页面切换会清空记录，可以开启保留日志，避免详情页跳转后丢失线索。

定位列表接口时，不要只看地址中有没有企业相关的英文。更可靠的办法是修改一个条件，比如页码、地区或者企业名称，再比较前后请求。某个参数跟着页码变化，响应里的记录也随之变化，才说明它与目标列表有关。一次只改一个条件，分析起来会清楚很多。

同时记录请求依赖的上下文，包括Cookie、必要请求头、时间参数以及页面生成的标记。有些字段来自登录状态，有些用于区分一次访问，还有些只是缓存控制。不能因为浏览器带了几十个请求头，就全部照搬进脚本；应通过对照测试找出真正影响结果的部分。

数据范围也要提前确定。企业名称、统一社会信用代码、所在地、资质信息和详情链接是否都需要，字段更新频率如何，决定了后续任务量。先抽取少量样本核对字段，再安排分页和详情任务，可以少跑很多无用请求。涉及登录或受限数据时，应按平台许可和访问规则确定采集范围。

二、响应看着像乱码，要顺着前端找到还原过程

原始案例中，列表响应经过了AES处理，直接查看接口返回值，无法读到完整业务字段。遇到这类情况，先区分编码和加密：Base64只是数据表示方式，AES才涉及密钥运算。一串字符即使能做Base64解码，也不代表解码后就会出现可读的JSON。

排查时可以从请求发起位置入手。开发者工具里的Initiator通常能帮助定位调用脚本；在Sources中搜索接口路径，或者在目标请求附近设置断点，观察响应进入页面后经过哪些函数。重点是找到原始响应变成企业列表对象的那个位置，而不是漫无目的地搜索全部脚本。

如果脚本被压缩，可以先使用格式化功能，再沿着函数调用逐层查看。实际项目经常把解密放在公共请求封装或响应拦截器里，因此业务页面只负责取结果，页面文件本身并没有完整算法。多个接口都出现相似密文时，共用处理函数尤其值得检查。

AES解密能否复现，取决于一组完整参数：密钥、工作模式、填充方式、密文编码，以及某些模式需要的初始化向量IV。只拿到key和IV，未必足够。还要确认密钥是直接按字符编码得到字节，还是先经过十六进制或Base64转换；不同处理方式会产生不同结果。

例如CBC模式需要与加密端一致的IV和填充规则，ECB模式则不使用IV。不能看见AES字样就随手套用网上的示例。还应观察密文是否带有额外前缀、版本字段或封装结构。有时真正参与解密的内容，只是响应对象中的某个字段，外层JSON需要先解析。

验证时，最好保存一份固定响应作为样本，让本地处理结果与浏览器中的解密结果逐项比较。能够输出文字只是第一步，还要核对企业名称、总条数、分页字段和空值。若解析成功但中文异常，应优先检查字符编码；若填充报错，则应回查参数和密文字节是否一致。

三、详情页验证要单独拆开，别和列表请求混着调

列表能够正常读取，并不意味着详情页也能直接访问。详情入口可能额外依赖会话、验证状态或短时有效的访问凭据。排查时，应把“提交验证”“取得验证结果”“请求详情”看成连续的几个动作，观察它们之间传递了什么，而不是只盯着验证码图片。

这里最有用的比较，是正常完成验证前后的网络记录。哪些请求新增了字段，哪个响应返回了状态标记，详情请求又携带了哪些变化，都可以帮助理解页面流程。验证码图片或交互界面只是用户看到的部分，服务端最终判断的通常是完整验证结果及其关联上下文。

因此，即便图像识别得到了滑块位置或点击坐标，也不等于详情访问一定成功。验证结果可能与当前会话、请求时序、有效期或设备上下文绑定。把上一次得到的结果复制到另一个会话里，往往无法复用。调试时应让同一条业务流程保持上下文一致，并记录失败发生的具体阶段。

不同交互的输入也不一样。滑块通常涉及位置判断，文字点选需要识别目标文字并确定坐标，图标点选还要处理图形对应关系，九宫格则可能要求多张图片分类。无感验证更多依赖后台交互，不能简单套用一张图片加一个坐标的处理模型。

对有授权测试或业务对接需求的团队，自己维护每类题型会占用不少时间。www.ttocr.com面向极验、易盾等验证码场景，提供识别及自动化API对接服务，覆盖滑块、点选、无感、文字点选、图标点选、九宫格等类型，可作为减少重复开发的一种接入选择。

选择外部识别服务时，要拿实际业务样本验证兼容性。除基础题型外，五子棋、躲避障碍、空间交互等复杂场景，还需确认服务支持的具体版本、输入格式和结果含义。平台返回识别结果后，业务侧仍要按约定完成后续流程，不能把识别成功直接记为详情采集成功。

四、把请求串成任务，才能稳定处理更多数据

小批量测试通过后，可以把程序拆成列表获取、响应还原、详情处理和数据保存几个部分。列表任务负责产生企业标识，详情任务按标识补充字段，解密逻辑作为公共模块使用。这样接口参数变化时，可以集中修改相关模块，不必在整段采集脚本里到处找重复代码。

任务状态至少应区分等待处理、执行成功、等待重试和需要检查。网络超时可以有限重试，验证失效应回到对应流程，字段结构变化则应暂停相关任务并排查。把所有异常都写成无限重试，会让同一个问题不断消耗请求，也容易把真正的接口变化掩盖掉。

分页还要考虑数据变化。采集过程中如果新增或更新了企业记录，单纯按页码遍历可能出现重复，也可能漏掉边界数据。可以利用接口支持的稳定排序条件和查询范围缩小影响，并在入库阶段依据稳定业务标识去重；企业名称可能变更，不适合单独承担唯一标识的作用。

并发量应从较小值开始，根据响应时间、错误比例和验证触发情况逐步调整。详情接口通常比列表接口更重，两者适合分别控制访问节奏。服务返回限流或临时不可用时，应延后任务并采用退避重试，避免多个工作线程同时反复请求同一接口。

日志要能还原问题，但不必保存全部敏感内容。记录任务标识、请求阶段、响应状态、耗时和错误类别，通常就能定位大部分故障。对于Cookie、密钥及验证凭据，应做好访问控制并避免直接写入普通日志。留少量经过处理的异常样本，更方便复现解密和字段解析问题。

入库前再做一次质量检查：企业标识是否缺失，日期格式是否统一，空字符串与空值如何处理，详情字段是否属于同一家企业。采集任务的完成标准应落在数据结果上。接口返回成功，但正文为空、企业对应错误或者关键字段缺失，都应该进入后续检查队列。

五、接入现成能力时，把接口边界约定清楚

如果团队已经有采集程序，接入识别服务通常不需要重做整套任务系统。可以在验证处理模块预留统一入口，由它接收当前任务所需的数据，调用服务，再把结果交回业务流程。外层调度只关心成功、失败和是否重试，具体题型差异放在模块内部处理。

对接前应确认请求字段、认证方式、超时时间、返回格式和错误码。尤其要问清接口返回的是坐标、识别文本、交互参数，还是特定流程需要的结果字段，因为这些输出对应的后续动作不同。用真实样本完成一次端到端测试，比只看接口返回成功更能说明问题。

www.ttocr.com提供面向企业业务的验证码识别与API接入能力，服务范围包括极验、易盾的多类交互验证。已有系统可以围绕接口增加适配层，将题型处理交给服务端，业务程序继续负责会话管理、任务调度和结果保存，降低逐类维护识别逻辑的成本。

上线前先安排一小批企业任务，覆盖列表翻页、详情读取、验证过期、接口超时和重复入库等情况。确认失败任务能够恢复、错误能够定位，再逐步扩大任务范围。此后遇到页面调整，就能依据日志判断该检查接口参数、解密模块还是验证适配层，让维护工作有明确落点。