Base64 校验工具

如何校验 Base64 字符串

1. 把字符串粘贴到 要检查的 Base64。换行、PEM 外壳和 data: 前缀都可以保留；它们会作为发现项报告出来，其余部分照常分析。
2. 查看顶部的结论。每个问题都会列出位置，例如“位于第 3 行第 17 列（第 169 个字符）”。
3. 查看 你的输入（问题已高亮），出问题的字符会在原位标出。
4. 查看 它符合哪些 Base64 变体？，了解它作为标准、无填充、URL 安全、MIME 或 PEM Base64 是否有效，以及不符合时的原因。
5. 点击 修复 切换到 修复模式，清理字符串。

校验工具检查什么

• 字母表以外的字符，并显示其 Unicode 码位，这样不换行空格（U+00A0）或零宽空格（U+200B）这类看不见的字符也能现形。
• 混用字母表：同一个字符串中既有标准 Base64 的 + 和 /，又有 Base64URL 的 - 和 _。
• 中间出现 =，这几乎总是意味着两个编码值被拼接在了一起。
• 不可能的长度：去掉填充后，长度除以 4 余 1 是任何编码器都不可能产生的。说明少了或多了一个字符。
• 填充：缺失、过多，或与数据长度不符。
• 最后一个字符中 不规范的尾部位（RFC 4648 §3.5）。
• 空白和换行：空格和制表符、行宽，以及各行以 CRLF、LF 还是混合方式结尾。

详情 还会给出长度、长度 mod 4、填充状态、字母表、解码后大小和检测到的内容类型。高亮显示的输入副本仅限前 20,000 个字符，但分析总是覆盖整个字符串。

同一个字符串，不同的解码器

“有效”取决于谁来判断。下面五个字符串分别交给四种常见的解码器（Python 3.13、Node.js 24、WHATWG atob 和 GNU coreutils 9.7）：

最危险的是 Node 对拼接输入悄悄返回 Hello 的那一格，丢了一半数据却不报任何错。因此本工具会报告每一处偏差，包括你自己的解码器能容忍的那些。变体表格则会告诉你这个字符串满足哪种严格格式。

有效的字符串就一定是 Base64 吗？

abcd、test 和 1234 都是有效的 Base64，各自解码为三个看似随机的字节。所以工具还会回答 这真的是 Base64 吗？，给出 0 到 100 的评分和背后的理由，每条理由都标明是支持还是反对它是 Base64：

• 支持：填充正确，大小写字母和数字混合，字符多样性高，以 eyJ 开头（{" 的 Base64，JSON 和 JWT 的典型特征），或者解码后是已知的文件类型或可读文本；
• 反对：只有字母（可能是一个单词），只有十六进制数字（可能是 hex 字符串），只有数字（可能是一个数），字母大小写单一，或者字符串很短。

请把评分当作提示。它是一种启发式方法，短字符串在两个方向上都可能骗过它。

在代码中校验 Base64

最严格且实用的测试是往返转换：解码、重新编码，再比较。它能一次性拒绝空白、缺失的填充和不规范的结尾。

import base64

def is_canonical_base64(s):
    try:
        return base64.b64encode(base64.b64decode(s, validate=True)).decode() == s
    except ValueError:
        return False

在 Node.js 中，同样的思路是 Buffer.from(s, "base64").toString("base64") === s。像 ^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$ 这样的正则表达式可以检查字母表和长度，但它会接受 SGVsbG9= 和空字符串。对于 URL 安全的字符串，先转换，或者使用对应的字母表；见 Base64 与 Base64URL。各语言的具体错误信息汇总在 Base64 错误 中。

常见问题