JWT 规范化:从日志和请求头里清洗出纯 token

我做过一件特别费眼睛的事:从一份几百行的接口日志里,把每个请求带的 JWT 捞出来,对照着排查哪个 token 过期了。问题是那些 token 长得各不一样,有的前面挂着 Bearer ,有的被引号包着,有的两端还有从表格复制带来的空格。肉眼根本对不齐,贴进解码器还会因为多一个空格而报错。后来我把这套清洗流程固定下来,核心就一件事:JWT 归一,把杂乱的字符串统一成纯粹的三段 token。

一个 JWT 到底应该长什么样

标准的 JWT 是三段用点号连接的 base64url 字符串:header.payload.signature。它本身不含 Bearer,不含引号,也不含空格。Bearer 是 HTTP 认证方案的标记,属于 Authorization 头的语法,不属于 token 本身。换句话说,Authorization: Bearer eyJ... 这一整行里,真正的 token 只是 Bearer 后面那一段。

很多人把整行直接拿去解码,工具要么报错,要么把 Bearer 也当成数据。规范化要做的,就是把这些外壳全部剥掉,只留下能被解析的纯三段结构。

为什么 Authorization 头里的 Bearer 要去掉

后端验证签名时,中间件会先按空格拆 Authorization 头,取第二段才是 token。但你在排查、做测试夹具、灌入数据库时,拿到的往往是从日志、请求头、客服工单里复制出来的原始行。如果不先把 Bearer 去掉:

贴进任何 JWT 解码器都会因为首字符不是 base64url 而失败;
做去重时,Bearer eyJabc 和 eyJabc 会被算成两条不同记录;
存进数据库后,后续比对永远对不上真实下发的 token。

所以去前缀不是可选项,是让 token 能进入后续流程的前提。

一个真实的输入输出例子

我常遇到的脏数据是这样一坨,混着前缀、引号和空格:

"Bearer  eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N3"
   eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoiTGlsZWkifQ.s8Q0p2c_tokenB_value
Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N3

跑一遍规范化,做了三件具体的事:去掉 Bearer 前缀、削掉每条两端的空格、剥掉包裹的引号,只留下纯三段 token,顺手把第一行和第三行这对重复合并:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N3
eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoiTGlsZWkifQ.s8Q0p2c_tokenB_value

注意第一行里 Bearer 和 token 之间有两个空格,引号也贴在外侧,这些都被一并清掉。剩下的每一行都是干净的 header.payload.signature,可以直接贴进解码器,也可以导出成 CSV、JSON 或 SQL IN 列表交给脚本。如果某条只剩两段、或者某段根本不是合法 base64url,工具不会硬凑,而是原样留着并标出原因,让干净的输出靠得住。

为什么这件事必须在本地做

JWT 的 payload 段是 base64url 编码,不是加密,任何人拿到都能解出里面的用户 id、过期时间甚至权限范围。把一批真实 token 上传到某个在线工具去清洗,等于把一摞还没过期的访问凭证交给了别人的服务器。

我用的工具是 JWT Token 规范化工具,解析、去 Bearer、去空格、去重、导出全部在浏览器当前标签页完成,token 一直留在本机,不发往任何服务器。这一点对处理生产环境凭证是底线,不是加分项。

配合用的几个小工具

清洗 JWT 很少是孤立的一步。如果你拿到的是一整行原始请求头,可以先用 HTTP 请求头提取工具把 Authorization 这类字段单独抽出来,再扔进规范化工具去前缀;如果你只想从大段文本里先把所有 token 捞出来,JWT Token 提取工具会按行带出每个匹配项和行号,方便回原文核对。

把这几步串成习惯之后,从日志到纯 token 列表的整个清洗,几分钟就能收尾,而且整段数据都没离开过我的机器。

Made by Toolora · Updated 2026-06-13