如何在线解码 Base64（以及结果意味着什么）

您有一串看似随机的字母和数字，可能以一个或两个等号结尾，您需要知道它的意思。这几乎肯定是 Base64，对其进行解码会显示原始文本或数据。以下是如何解码 Base64、结果告诉您什么，以及导致解码器失败的两种变体。

如何解码它

解码 Base64 是即时的：将编码的字符串粘贴到解码器中，解码器将其转换回原始文本。 Base64 是完全可逆的，它是一种编码，而不是加密，因此不需要密钥，任何人都可以在一秒钟内解码任何 Base64 字符串。如果结果是可读文本，那么您就得到了答案。如果结果看起来像二进制垃圾，则原始数据不是文本，它可能是图像、文件或随后进行 Base64 编码的加密数据，在这种情况下，解码后的字节不应该作为文本读取。

为什么需要解码 Base64

Base64 出现在您可能需要检查的许多地方。 JWT 身份验证令牌的标头和有效负载采用 Base64 编码，对它们进行解码可揭示内部的声明。 HTTP 基本身份验证凭据是授权标头中的 Base64。数据 URL 嵌入 Base64 编码的图像。电子邮件源显示 Base64 编码的附件。配置文件和 API 响应有时会携带 Base64 数据。当您调试其中任何一个时，解码可以让您看到实际存在的内容，而不是一堆编码字符。

Unicode 陷阱

如果解码后的文本在应该有重音符号或非英语字符的地方出现乱码，则问题出在 Unicode 处理上。 Base64 对字节进行编码，文本必须首先通过 UTF-8 等编码转换为字节。假设纯 ASCII 的解码器会破坏重音字母、表情符号和非拉丁文字。正确的解码器将字节解释为 UTF-8，因此“café”和“こんにちは”可以正确解码。如果您看到 mojibake、乱码，则编码器或解码器对 Unicode 步骤处理不当。

URL安全变体

如果解码器拒绝您的字符串或产生错误的输出，则可能是 Base64url（URL 安全变体）。标准 Base64 使用 + 和 / 字符，但这些字符会导致 URL 出现问题，因此 Base64url 将 + 替换为 -，将 / 替换为 _，并且经常删除 = 填充。 JWT 使用此变体。严格的标准解码器可能会因 - 和 _ 或缺少填充而阻塞。解决方法是将 - 转换回 +，将 _ 转换回 /，并在解码之前恢复填充，或者使用自动处理这两种变体的工具。

请记住：解码不是解密

重要的一点。解码 Base64 可以揭示编码的内容，不需要密钥，这意味着 Base64 不提供任何安全性。如果你能解码它，其他人也能。这就是为什么您永远不应该将密码或秘密存储为 Base64，认为它们是隐藏的；它们很容易阅读。解码 JWT 有效负载会向您显示声明，但不会验证令牌，这需要使用密钥检查签名，这是一个单独的步骤。 Base64 是关于表示，而不是保护。