HTTP 头提取实战:把原始请求拆成请求头解析表

调试接口的时候,我经常拿到一坨原始 HTTP 文本。可能是同事丢过来的 curl -v 输出,可能是从 Charles 或 Fiddler 复制的抓包,也可能是浏览器 DevTools 网络面板里整段贴出来的内容。里面请求行、请求头、请求体、计时日志全糊在一起,而我只想看清楚到底带了哪些头部、每个头的值是什么。手工一行行抠出来又慢又容易看漏,所以我把这件事交给 HTTP 头提取器来做。

头部提取到底在解决什么问题

一个 HTTP 头的结构其实很规整:头部名,一个冒号,然后是值。比如 Content-Type: application/json 里,冒号左边是名 Content-Type,右边是值 application/json。难点不在单行,而在于真实素材里这些规整的行被淹没了:前面有请求方法和路径,后面跟着一长串响应体,中间还夹着 * 开头的连接日志和时间戳。

提取的核心逻辑就是扫描每一行,识别出符合 Name: value 形状的行,按第一个冒号把名和值切开,其余的全部丢掉。这样一段几十行的原始 dump,最后只剩下十几行干净的头部键值,排成一张可以直接复核的表。

一个真实的输入输出例子

假设我从终端复制了下面这段 curl -v 片段:

> GET /api/orders HTTP/2
> Host: api.example.com
> Authorization: Bearer eyJhbGciOiJIUzI1NiJ9
> Accept: application/json
* Connection state changed
< HTTP/2 200
< Content-Type: application/json; charset=utf-8
< Cache-Control: no-store
< X-Request-Id: 8f3a-22c1

把整段贴进去,提取器只认带冒号的头部行,> GET ... 这种请求行和 * Connection ... 这种日志行都会被剥掉。按冒号拆完得到的表大致是:

| 头部名 | 值 | |---|---| | Host | api.example.com | | Authorization | Bearer eyJhbGciOiJIUzI1NiJ9 | | Accept | application/json | | Content-Type | application/json; charset=utf-8 | | Cache-Control | no-store | | X-Request-Id | 8f3a-22c1 |

注意 Content-Type: application/json; charset=utf-8 这一行,值里还带着一个冒号(其实是分号后面的内容),提取时只按第一个冒号切,所以名是 Content-Type,值完整保留了 application/json; charset=utf-8,不会被二次切坏。这一点在处理 Date、Authorization 这类值里本身含冒号的头部时尤其重要。

按名取值,而不是肉眼找

整理成表之后,真正高频的需求是按名取值。我想确认这次请求到底带没带 Authorization,或者想核对 Cache-Control 是不是 no-store,在表里搜一下头部名就能定位,比在原始文本里 Ctrl+F 翻滚动条靠谱得多。如果一个请求里同一个头出现了两次,或者你同时贴了好几个请求,去重之后能立刻看出哪些头部是重复的、哪些值有冲突。

残缺行也留着,方便回源头修

日志现实里很脏。常见的坏行有三种:没有冒号的行(根本不是头部)、值折行被截断的 Cache-Control、还有头部名是空的。提取器不会偷偷把这些行扔掉,而是连同原因一起列出来,告诉你第几行有问题。我自己排查折行 bug 时就靠这个:看到某个头的值莫名其妙短了一截,顺着行号回原文,往往就是日志工具把长头部从中间断开了。

整理完直接交付

复核完不一定要手动再抄一遍。结果可以切换成 CSV、JSON、Markdown、SQL IN 或 TypeScript union 等格式导出。我习惯导成 Markdown 表贴进工单或文档,如果是要塞进 wiki 或周报,顺手用 CSV 转 Markdown 表格再排一道版也很顺。整个流程,粘贴、解析、按冒号拆名取值、去重、导出,全部在浏览器本地完成,带 token 的请求头不会发到任何服务器,这对调试线上接口时手里那串 Authorization 来说是底线要求。

下次再对着一屏糊在一起的原始请求发愁,先别一行行抠,贴进去让它拆成表,你要找的那个头部值通常一眼就在。

Made by Toolora · Updated 2026-06-13