开发者工具 · Base64 编码器和解码器
为什么粘贴的 Base64 无法解码：换行、换行和智能引号
· 为什么它很重要
base64 编码
Base64 在运输过程中很少中断；它在剪贴板中破裂。这篇文章对产生无效字符和长度错误的复制粘贴错误进行了分类，以及如何快速发现每一个错误。
在终端中有效但在浏览器中失败的密钥 - 一个不可见的字符和两个小时的搜索
工程师从终端复制 API 密钥以在脚本中进行测试。该密钥在终端中工作正常，但在粘贴到浏览器工具中时因无效字符而失败。两个小时后，在搜索代码、配置和文档后，他们发现了一个看不见的字符。键末尾的换行符（通过 echo 添加或从终端提示行复制）成为破坏 Base64 解码器的额外字符。钥匙是正确的；剪贴板不是。 Base64 数据在以电子方式传输、校验和和验证时是可靠的。它几乎只在手动复制和粘贴过程中中断。
终端中的换行、命令输出中的尾随换行符、富文本编辑器中的智能引号替换以及不同应用程序之间复制粘贴的隐藏 Unicode 字符都会引入看似 Base64 已损坏的错误，而实际问题在于其复制方式。这篇文章列出了最常见的故障，并展示了如何快速发现和修复每个故障。 Base64 字母表由大小写字母、数字、加号、斜杠和填充字符（等号）组成。 RFC 4648 是特定的：标准 Base64 字符串仅包含这些字符以及可选的空格（如果换行）。
来自终端、电子邮件客户端和 PEM 格式的换行 - 为什么 76 列中断对于某些解码器来说很好，而对于其他解码器来说却是致命的
许多工具可以容忍偏差：它们接受使用破折号和下划线而不是加号和斜杠的 URL 安全变体，或者忽略换行符。遵循 RFC 的严格解码器会拒绝任何超出预期字符集的内容，并因无效字符错误而失败。错误消息通常会指出有问题的字符或指出该字符串根本无法解码。当从电子邮件、终端、聊天历史记录或格式化文档粘贴 Base64 时，不可见字符或字符替换经常会出现并导致解码失败。数据本身没问题；剪贴板传输损坏了它。
换行是粘贴 Base64 失败的最常见原因，也是最容易修复的原因。终端工具将输出换行为每行 76 个字符，有时为 80 个字符，插入换行符并继续下一行。许多编码器（包括一些 Base64 编码库）将其输出包装在相同的 76 字符边界处，以与 MIME 电子邮件兼容。当您从终端复制包装的 Base64 字符串时，换行符就会出现。
来自 echo 和剪贴板工具的尾随换行符 - 成为额外字符的额外字节
一些解码器自动接受和忽略换行符。其他人则将它们视为无效字符而拒绝。修复方法是删除所有换行符和空格。如果 Base64 字符串在终端中跨多行换行，请选择所有行，将它们复制到编辑器中并删除所有换行符。
复制生成的单行字符串并将其粘贴到解码器中。这是粘贴失败时要尝试的第一件事。来自 echo 和剪贴板实用程序的尾随换行符是另一个常见的罪魁祸首。命令 echo $API_KEY 打印密钥，后跟换行符，这是命令标准行为。如果直接复制该输出，换行符将包含在副本中。某些终端在复制时会添加额外的换行符，而某些剪贴板管理器会保留或复制换行符。症状与换行相同：字符串末尾出现不属于 Base64 的额外字符。
智能引号、不间断空格和零宽度字符 — 富文本编辑器如何重写纯文本
修复方法同样简单：在尝试解码之前修剪编辑器中粘贴字符串的末端。删除前导和尾随空格以及任何看起来像换行符的字符。如果字符串足够短，您可以再次手动输入，但对于长键，仔细的手动修剪会更快。智能引号、不间断空格和其他 Unicode 替换都是微妙的陷阱。 Word 等富文本编辑器会自动将直引号转换为弯引号，将三个连字符转换为长破折号，并将某些空格序列转换为不间断空格。如果有人将 Base64 字符串粘贴到文档中，然后您将其从格式化文档复制到工具中，这些替换就会随之而来。
直双引号 (") 变成一对左右卷曲引号，两者都不是有效的 Base64。不间断空格 (U+00A0) 看起来与常规空格相同，但具有不同的字符代码，并且不会被所有解析器识别为空格。解决方案是首先粘贴到纯文本编辑器中，该编辑器会丢弃所有格式。如果从 Word 文档或格式化聊天中粘贴，请首先粘贴到纯文本编辑器或 HTML 文本区域中，然后检查对于奇数字符，然后从纯文本版本复制以在您的工具中使用。
截断和填充损失 — 长度模 4 检查告诉您字符丢失
在复制或粘贴过程中截断字符串时会发生截断。非常长的 Base64 字符串可能会超出某些系统上的剪贴板限制，或者由于应用程序错误而无法复制。结果是一个较短且不完整的字符串。应用填充后，Base64 字符串的长度必须是四的倍数。如果长度不是四的倍数，则会被截断或损坏。错误消息通常指出字符串长度无效或缺少字符。修复需要知道最初复制的内容。
如果您可以再次检查来源，请仔细复制一遍。否则，截断将无法恢复。填充损失是一个相关问题：带有等号的 Base64 填充有时会被删除以节省几个字节。有些应用程序省略填充，有些则需要填充。如果字符串最初被填充并且填充丢失，请将其添加回来。 Base64 字符串应具有 0、1 或 2 尾随等号，以便总长度为四的倍数。如果没有且长度不是四的倍数，则填充可能已丢失。
工作示例：修复包装和截断的字符串 - 逐步清理它直到解码
一个工作示例逐步展示了这些修复。假设复制的 API 密钥在编辑器中显示如下：VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0Cg==。从识别问题开始。尾随的 Cg== 是奇数； Cg 是换行符（十六进制 0A）的 base64，额外的 == 表明添加了某些内容。删除尾随的 Cg== 并尝试仅 VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0。这仍然是不对的；长度为 37 个字符，而不是四的倍数。再次修剪：VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0（35字符，仍然错误）。检查原始来源。正确的字符串是 VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0 （32 字符），并具有适当的填充：VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0。添加它：VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0=。
在解码器中测试。这解码为 这并不是一个真正的秘密。在每个步骤中，使用 Base64 编码器和解码器测试当前字符串，修复已识别的问题并再次测试，直到解码。解码器无法修复 Base64 字节本身内部的损坏。如果字节实际上在传输、传输或存储过程中被损坏，Base64 本身无法检测到。 RFC规定了有效字符；该集合之外的任何字符都是解码器要捕获的工作。任何字节损坏（例如 0 在 Base64 字符中间变成 1）都会产生完全不同的字符代码，并且仅由 Base64 无法检测到。
这不包括 - 编码字节内部的损坏，Base64 本身无法检测到
校验和或数字签名用于检测这种损坏，并且必须在 Base64 编码之前对原始二进制数据进行计算。如果您解码 Base64 字符串并且结果是垃圾或与您的预期不同，则损坏发生在编码之前或传输期间，而不是复制粘贴步骤期间。这在实践中很少见。大多数失败都是像上面这样的复制粘贴问题。调试 Base64 复制粘贴故障的系统方法是按顺序测试每个潜在问题。首先，删除所有空格和换行符。然后修剪前导和尾随空格以及任何杂散字符。
然后检查长度模四并根据需要添加填充。将每个版本粘贴到 Base64 编码器和解码器中并查看它是否解码。如果长度检查失败，则询问字符串是否被截断并从原始来源检索它。如果字母表检查失败并且您看到不寻常的字符，请查找智能引号或 Unicode 替换并将其替换为 ASCII 等效项。使用在线工具按名称显示无效字符，以便您识别并删除它们。 Base64 编码器和解码器对每个无效字符执行此操作，准确说明哪个字符不在字母表中。
要点：在指责数据之前检查长度和字母表 — Base64 编码器和解码器如何为您提供一个快速的本地位置来测试每次修复
使用该反馈来修复每个字符并继续，直到字符串解码。预防比调试更容易。当您知道再次需要 Base64 字符串时，请以保留格式的方式复制它。不要将其粘贴到富文本文档中。将其存储在纯文本文件或不进行替换的指定文本区域中。如果有人在格式化消息中向您发送 Base64 字符串，请要求他们以代码格式或纯文本形式重新发送。如果必须从格式化源进行复制，请先粘贴到纯文本编辑器中，并在使用之前验证字符串。
获得字符串后，请在依赖它之前立即在 Base64 编码器和解码器中对其进行测试。如果失败，您可以在仍然可以访问源的情况下索要一份新副本。如果等到字符串变旧或源消失，修复截断或损坏就变得不可能。 Base64 编码器和解码器为您提供了一个快速的本地位置，可以在提交使用之前测试任何字符串。尽早测试并经常测试，以便立即发现复制粘贴故障。