Base64 / URL / JWT 编码与解码

在浏览器中编码和解码 Base64 或 URL，并查看 JWT 的头部和载荷。

文本或 JWT

输出

使用方法

在“文本或 JWT”框中粘贴或输入内容：要编码的纯文本、要解码的 Base64 字符串或百分号编码字符串，或者要查看的 JWT。
点击“Base64 编码”或“Base64 解码”在文本和 Base64 之间转换，或点击“URL 编码”或“URL 解码”添加或去除百分号编码。结果或错误信息会显示在“输出”框中。
要查看令牌，请将其粘贴进来（带不带 Bearer 前缀均可），然后点击“解码 JWT”。头部和载荷会以缩进的 JSON 显示；载荷中如有 iat、nbf 和 exp 声明，会列在“JWT 时间声明”下，其中的数值会换算为 UTC 时间和您的本地时间。
点击“复制结果”即可复制输出。要还原编码，请将编码后的文本粘贴到“文本或 JWT”框中，然后点击对应的解码按钮。先解码再重新编码不一定能得到与原文完全相同的结果：URL 安全或不带填充的 Base64 重新编码后会变为标准字母表，并在需要时补上 = 填充；而“URL 解码”后保留下来的 + 会被“URL 编码”转换为 %2B。

常见问题

我粘贴的文本或令牌会被发送到别处吗？

不会。编码和解码通过 JavaScript 在您的浏览器中进行，您输入的内容不会发送到 LeedyBox。JWT 常被用作登录凭据，在过期或被撤销之前，任何持有它的人都可能用它通过身份验证，因此请像对待密码一样对待仍然有效的令牌，不要在截图或聊天中分享。

为什么“Base64 解码”提示数据不是有效的 UTF-8 文本？

“Base64 解码”会把解码后的字节显示为 UTF-8 文本；如果这些字节不是有效的 UTF-8，就会显示此错误并停止。PNG 或 JPEG 图像、大多数 PDF 和压缩数据都属于这种情况，以 Latin-1 或 Shift_JIS 等其他编码保存的文本也常常如此。本工具不会把解码后的字节保存为文件，因此请将它用于内容为文本的 Base64。像 data:image/png;base64,... 这样的 data URI 会被视为无效的 Base64，因为冒号、分号和逗号不是 Base64 字符。

能处理 URL 安全的 Base64 和缺少填充的值吗？

解码时可以。“Base64 解码”同时接受标准字母表（+ 和 /）和 URL 安全字母表（- 和 _），有无 = 填充均可，并会忽略空格和换行。“Base64 编码”输出使用标准字母表并带 = 填充；如需 JWT 中使用的 URL 安全形式，请将 + 替换为 -、/ 替换为 _，并删除末尾的 = 号。文本会按输入原样以 UTF-8 编码，因此末尾的空格或换行会改变结果，输入框中的换行按 LF 编码。

可以用“URL 编码”编码整个 URL 吗？

通常不建议。“URL 编码”的行为与 JavaScript 的 encodeURIComponent 相同：除 A–Z、a–z、0–9 和 - _ . ! ~ * ' ( ) 之外的所有字符都会被百分号编码，因此构成 URL 结构的 / ? & = : # 也会被编码。请只用于 URL 的单个部分，例如一个查询参数的值。空格会变成 %20，非 ASCII 字符会按其 UTF-8 字节编码，例如 é 会变成 %C3%A9。

为什么加号不会变成空格？“URL 解码”在什么情况下会报错？

“URL 解码”的行为与 JavaScript 的 decodeURIComponent 相同：它会解码 %XX 转义序列，并保留 + 不变，因为在通用的 URL 语法（RFC 3986）中，+ 并不表示空格。许多查询字符串采用的 HTML 表单数据格式（application/x-www-form-urlencoded）会把空格编码为 +，因此解码这类数据前，请先把每个 + 替换为空格；在这种格式中，真正的加号写作 %2B，仍能被正确解码。如果 % 后面不是两位十六进制数字（如 50% off），或者转义后的字节不是有效的 UTF-8（如 %E2%82），就会报错。

“解码 JWT”可以读取哪些令牌？

可以读取签名 JWT（JWS）所用的三段式紧凑格式 header.payload.signature，包括签名部分为空的无签名令牌。工具不会检查签名部分，因此能够解码并不能证明令牌是真实的。加密令牌（JWE）由五个部分组成，没有密钥就无法读取其载荷，因此会出现格式错误。如果头部或载荷无法从 Base64 解码为 JSON，或者载荷是字符串、数字等普通值而不是 JSON 对象，就会显示“JWT 解析错误”。头部或载荷中大于 9,007,199,254,740,991 的整数在浏览器解析 JSON 时可能被舍入，因此较长的数字 ID 显示出来的末几位可能不同。

exp、nbf 和 iat 时间如何显示？令牌何时会被标记为已过期？

这些值按照 JWT 标准（RFC 7519）的定义读取为以秒为单位的 Unix 时间，并以 UTC 和本地时间显示。“已过期”和“尚未生效”是在您点击“解码 JWT”的那一刻，将 exp 和 nbf 与设备时钟比较得出的，不预留任何时钟偏差，因此设备时钟不准时，显示的状态也会出错。服务器可能会容许少量偏差，通常不超过几分钟，因此在接近 exp 或 nbf 时间时，服务器的判断可能与这里显示的状态不同。以字符串形式写入的时间（如 "1700000000"）会被标为“不是有效的数字 Unix 时间戳”。