相似的编码格式，也需要明确边界

看起来像 Base64，不等于采用同一份协议

将二进制内容转成便于传输的文本，可以减少特殊字节在协议中的问题。但相似的编码名称并不保证字符集合、补齐规则和历史兼容约定完全相同。

技术路线首先要区分接受哪些形式，以及输出采用哪一种规范表达。这样不同模块不会各自尝试修补输入，形成难以追踪的多种版本。

标准形式与 URL 安全形式使用不同的字符映射，补位符是否必须保留也可能不同。某些系统还为兼容历史输入增加自己的接受规则，因此接口名相同并不能替代协议说明。

设计解码入口时，先写清允许的字符表、补位规则和空白策略。解码器的宽松能力可以用于特定兼容场景，但不应默认让所有形式互相混用。

先观察同一组字节的两种表达

import base64
raw = b"\xfb\xff"
standard = base64.b64encode(raw)
url_safe = base64.urlsafe_b64encode(raw)
assert standard == b"+/8="
assert url_safe == b"-_8="
assert base64.urlsafe_b64decode(url_safe) == raw

这里的差异来自字符映射，而不是内容被加密。任何知道规则的一方都可以恢复原始字节。若数据包含不应公开的内容，需要独立的保密机制，不能因为看起来不易阅读就直接放进公开链接。

解码输出也不一定是文本。图片、摘要和压缩内容都可以使用同样的包装，因此解码器应先返回字节，再由上层根据真实内容决定是否按 UTF-8 解释。

去掉补位符之前，先定义如何恢复

解码前可以根据输入长度估算输出容量，并检查计算是否越界。遍历过程中识别允许字符，积累足够信息后再生成输出字节，保持读取与写入的位置清晰。

兼容历史内容时，只接受已经明确记录的差异。宽容解析不应无限扩大，尤其不能因为常见样例都能成功，就把任意多余字符都自动忽略。

import re, base64
value = "-_8"
if not re.fullmatch(r"[A-Za-z0-9_-]*", value) or len(value) % 4 == 1:
    raise ValueError("非法编码形式")
padded = value + "=" * ((-len(value)) % 4)
raw = base64.b64decode(padded, altchars=b"-_", validate=True)
assert raw == b"\xfb\xff"

补位数量来自分组结构，不是任意补几个等号直到库不再报错。长度余一的输入无法形成有效的无补位形式，应在进入底层解码之前拒绝。

这个示例并没有同时接受已经包含补位符的输入。若协议要兼容两种形式，应该分别检查合法位置与数量，再统一恢复，而不是简单删除输入中所有等号。中间出现的补位符通常意味着格式问题。

需要唯一文本表示时，再检查规范形式

某些解码器可能接受多个文本表达并还原为相同字节。若文本本身将参与签名、唯一索引或缓存键，这种多重表示会制造额外复杂度。

可以在解码后按唯一规则重新编码，并与原输入比较，确认它就是期望的规范形式。这个检查应与是否允许省略补位等规则配套，否则会把已经明确允许的表达误判为错误。

规范化也应在签名验证之前有清楚约定。发送方签原始文本、接收方却验证规范化文本，双方计算的对象已经不同，失败不是摘要算法的问题，而是签名输入没有对齐。

把容量限制与格式判断一起放在边界

这类转换主要解决表示问题，不承担加密或身份校验。需要保护内容时，应由专门的安全层处理，避免把看不懂的文本误认为无法还原的数据。

验收要分别覆盖每一种支持形式，检查空输入、异常长度、非法字符和往返转换。把兼容边界写清楚，比在发生问题时反复添加替换规则更有长期价值。

编码后的长度通常可以用来估算解码结果的上限，所以不必等到分配大缓冲区后才发现输入超标。流式处理还要保留不完整分组，不能把任意网络分片都当作完整编码块分别解码。

测试应包括空内容、一个和两个字节的尾组、标准与 URL 安全字符差异、错误补位以及非法字符。再做字节层面的往返比较，而不是只比较屏幕上显示的字符串是否相似。

对于确实需要兼容的特殊形式，单独记录案例和原因。这样将来收紧规则时能够评估影响，也避免一次“顺便更严格”的改动让已有客户端突然无法读取历史内容。