为什么最流行的编码算法是刚好带两个符号破坏兼容性的 base64，而不是能够无视大小写的 base36、不带符号的 base62？这两个符号不仅严重影响兼容性使标准码表的 base64 不能直接拼在 url 中，还没有增加多少信息密度

# base64 的编码结果并不是二进制，码表长度是 2 的整数次方没有任何的加成。
# 被 base64 坑了好几次，按=截断 key=value 数据的时候忘记指定 maxsplit=1 导致=后面的数据丢掉。

@lisongeee 这里比较坑的点是 url 可能被 encoding 多次。
举例：A 服务返回一个 json ，里面有一个 url B 服务调用 A 服务，返回给客户端，这时候是否要

base64 里有给 url 准备的编码方式，golang 里叫 URLEncoding ，标准的是 StdEncoding

会不会是你直接拿=去分割 url 的做法本身就不合理呢

我把内容一字不漏的复制给了 claude ，得出了和楼上各位差不多的回答。

k/v 解析只需要处理到第一个分隔符,
有 bug 改就完了。

@drymonfidelia 这个还真不是 base64 的锅，完全是你的个人技术问题，图片传输也用 base64,data:image/png;base64,这种多符号的你不是丢失的更多信息？

1. base64 应用广泛
2. 处理 url 需要 encode/decode

延续 40 楼的发言：
Base64 最早是在 1993 年由 IETF （互联网工程任务组）定义的。当时，它作为 MIME （多用途互联网邮件扩展）协议的一部分被提出。
在那之前，互联网主要用于电子邮件和文件传输，但 WWW （ World Wide Web ）还处于非常早期的阶段。Base64 并不是专门为 WWW 发明的，但它恰好在 WWW 开始普及之际被标准化。这种巧合使得 Base64 成为 WWW 生态系统中的一个重要工具，为网页中的二进制数据传输提供了可靠的解决方案。

有没有可能就是单纯的 base64 比 url 诞生的早？

既然都说的二进制，总应该知道 6 个 bit 就是 64 吧？ 62 不能完整表示 6 个 bit 啊，36 表示 5 个 bit 又浪费了几个字符
这些编码本来就早于 url 诞生的，你应该问的是为什么 url 标准不考虑兼容 base64

base64 的重要思想是将 bytes 以可视、非控制字符表示，是 bytes 类型转无控制字符的 string 类型的最简单实现，压根就和 url 没什么关系