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

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

不是有 base64url 吗?

字符串分割可不是处理 url 的好方法

码表长度是 2 的整数次方当然有加成啊，这意味着不需要进行大整数运算。

base64 发明的时候 http 还没被发明出来

因为 base64 广泛啊，multipart 里就能用它。而且 64 是 2 整数次方能方便编解码，重新对二进制位分隔就好了。而且其他的 binary-to-text 编码也有，base58 ，base62 base85 base91 等。你说 base32 ，咋不直接用 base16 ，就直接是十六进制咯。最后，base64url 也是事实上的规范。

base62 解码写起来很麻烦的，代码量要比 base64 多。你写过一次，就知道为什么没有流行起来了。

总最简原则来讲，base64 还是方便不少。

base64: 3 字节的东西编码进 4 字节
hex(base16): 2 字节的东西编码进 4 字节
bit 数是固定的，编码解码位运算很方便

base36 ？你告诉我是几字节到几字节？
占几个 bit 固定不固定？如果不固定，可变长时怎么标记位数？如果固定，那 base 一定是 2 的某个次方，比如 16/32/64/128

@drymonfidelia 本来位运算就比除法快一个数量级。

更何况为了速度，base64 都上 SSE/AVX2/AVX512 向量指令集了。

在编码方面，速度就是这么重要。

挺奇怪的，又不是没有 url 编码，啥东西 url 编码之后拼在 url 也不会有问题啊，而且 base64 一开始设计也不是给 http 用的，只是刚好能用在 http 上