为什么最流行的编码算法是刚好带两个符号破坏兼容性的 base64，而不是能够无视大小写的 base36、不带符号的 base62？这两个符号不仅严重影响兼容性使标准码表的 base64 不能直接拼在 url 中，还没有增加多少信息密度
drymonfidelia · 111 天前 · 5909 次点击这是一个创建于 111 天前的主题，其中的信息可能已经有所发展或是发生改变。
base64 的编码结果并不是二进制，码表长度是 2 的整数次方没有任何的加成。
被 base64 坑了好几次，按=截断 key=value 数据的时候忘记指定 maxsplit=1 导致=后面的数据丢掉。
49 条回复 • 2024-09-02 11:50:16 +08:00
 |
1
MoYi123 111 天前
不是有 base64url 吗?
|
 |
2
drymonfidelia OP @MoYi123 我说了 **标准码表** 啊，我是想讨论兼容性这么差的编码算法为什么会流行起来
|
|
3
MoYi123 111 天前  1
@drymonfidelia 因为 n % 64 == n & (63), 而 base62 和 base36 不行, 就这么简单.
|
 |
4
vvhy 111 天前 3
字符串分割可不是处理 url 的好方法
|
 |
5
Trim21 111 天前
码表长度是 2 的整数次方当然有加成啊，这意味着不需要进行大整数运算。
|
 |
6
masterclock 111 天前 3
base64 发明的时候 http 还没被发明出来
|
 |
7
bczhc 111 天前
因为 base64 广泛啊，multipart 里就能用它。而且 64 是 2 整数次方能方便编解码，重新对二进制位分隔就好了。而且其他的 binary-to-text 编码也有，base58 ，base62 base85 base91 等。你说 base32 ，咋不直接用 base16 ，就直接是十六进制咯。最后，base64url 也是事实上的规范。
|
|
8
drymonfidelia OP @Trim21 多用几位一起编码不会带来明显的性能损失吧，和兼容性比起来两个符号的问题显得更大
|
 |
9
tool2dx 111 天前
base62 解码写起来很麻烦的，代码量要比 base64 多。你写过一次，就知道为什么没有流行起来了。
总最简原则来讲，base64 还是方便不少。 |
 |
10
sagaxu 111 天前
base64: 3 字节的东西编码进 4 字节
hex(base16): 2 字节的东西编码进 4 字节 bit 数是固定的，编码解码位运算很方便 base36 ？你告诉我是几字节到几字节？ 占几个 bit 固定不固定？如果不固定，可变长时怎么标记位数？如果固定，那 base 一定是 2 的某个次方，比如 16/32/64/128 |
 |
11
ipwx 111 天前
|
|
12
ipwx 111 天前 1
另外看楼主的背景是前端或者后端。
如果楼主会写 C ，大概才能理解为啥 64 位一定比 62 位快很多了。 |
|
13
Trim21 111 天前
@drymonfidelia #8 你首先要理解 baseXX 的意义，是把原始数据作为一个大整数然后进行进制转换。
base62 ，base63 跟 base65 可能差不多，但是 base64 有独特的性质。64=2^6 ，byte 的 255=2^8 意味着每 3 字节的原始数据一定能编码为 4 字节的 base64 。 所以 base64 可以每 4byte 进行处理，用现成的 uint32 就行。换成 base62 你就要处理一个不定长的 big int ，因为 62 不是 2 的幂，没有 base64 这样的性质。 |
 |
14
proxytoworld 111 天前 2
挺奇怪的，又不是没有 url 编码，啥东西 url 编码之后拼在 url 也不会有问题啊，而且 base64 一开始设计也不是给 http 用的，只是刚好能用在 http 上
|
|
15
proxytoworld 111 天前
没看懂影响兼容性，url 编码解码不费 cpu ，又不是 api 改参数了。
|
 |
17
IvanLi127 111 天前 2
这样说的话，主流 base64 不适合你这个用例，没必要上，谁逼你上的直接干他。坑你的人是主张在 url 里放乱七八糟东西的人，而不是 base64 。
|
 |
18
Y25tIGxpdmlk 111 天前
base64 我记得好像是 3 位一组 3 位一组，然后不够的用=号补齐。用 62 的话，相似的设计，需要单独一个字符专门用来当补齐符号用。
|
 |
19
wy315700 111 天前
因为 3 * 8 = 4 * 6
而 2 ^ 6 = 64 所以挑了 64 个字符 |
 |
20
knva 111 天前
挺怪的.
|
 |
21
liuidetmks 111 天前
避免除法，
你有 1G 数据流，直接当做一个整数，那是很麻烦的 而且可以流式处理，不用等到所有数据都接受到了才编码 |
 |
22
CEBBCAT 111 天前 1
菜就多练，URL 传递 Base64 就用 Base64URL ，硬传不就等于自己给自己挖坑吗？用的哪个语言？没有便捷的库？
|
 |
23
lisongeee 111 天前 4
> 被 base64 坑了好几次，按=截断 key=value 数据
看起来你的场景是在反序列化 url string 里的 search 参数，好奇为什么不用标准序列化对象？ https://developer.mozilla.org/en-US/docs/Web/API/URL 另外将 base64 编码到 url search 参数里的时候，也要调用标准序列化方法 此时 base64 里的 = 字符会变成 %3D ，如果按照这个标准序列化，你的分割不会出现错误 我猜测两边都是手动拼接/手动分割字符串去构造参数，而不是去使用标准序列化和反序列化方法 我们这边后端一个系统 解析/构造 url 的时候不按照标准走，产生如 hash 丢失，参数解码错误破坏整个 url 还有 飞书 的网页第三方登录，点击拒绝授权的时候，如果你的参数里面有 url ，url 里面有特殊字符，虽然你的按标准走的，但是煞笔飞书会手动解码两次后拼接，导致破坏整个 url 导致参数丢失 每次跟这些不按标准喜欢自己拼接字符串的煞笔对接都气死我了 |
 |
24
adoal 111 天前 2
手拼 URL 不检查不转换参数偏要怪 base64 使用了不兼容 URL 的字符……那你手拼 SQL 直接传裸参试试。
|
|
25
tool2dx 111 天前
@lisongeee RFC 标准有，就是 https://en.wikipedia.org/wiki/Base64 里的 base64url ，简单来说就是把'+'和'/'变成'-'和'_', 再把尾巴=去掉。
在国外项目挺常见的，比如 lets encrypt acme 协议提交的 url ，就必须这样编码。 |
|
26
lisongeee 111 天前
@tool2dx
你的回复和我的回复没有一点关系，你是不是回复错人了 --- 另外 base64 尾部的 = 只是为了让这个 base64 string 的长度是 4 的倍数 而现在的大多数解析器解析时都是支持忽略尾部 = 字符的，所以很多工具生成的 base64 都没有 = 字符 |
 |
28
DOLLOR 111 天前 2
先不说 base64 ，你拼 URL 的时候不用 encodeURIComponent()再包裹一遍吗？被坑了几次都还没这个意识吗？
|
 |
29
FengMubai 111 天前
base16(hex): 变为原来的 2 倍
base32: 1.6 倍 base64: 1.333 倍 base85: 1.25 倍 base85 里有反斜线, base64 已经很折中了 |
 |
30
BugCry 111 天前
网站可以发出来看一下吗，我保证不做 sql 注入
|
|
31
drymonfidelia OP |
|
32
drymonfidelia OP @drymonfidelia 然后 cookies 就是 key=value 编码的，如果直接按=截断就会出现这个问题
|
 |
33
zpfhbyx 111 天前
base64 urlsafe
|
 |
34
oamu 111 天前
稍微了解下位运算也不至于说出 “码表长度是 2 的整数次方没有任何的加成。” 这种话。
|
|
35
proxytoworld 111 天前
@drymonfidelia 你没对=做判断吗，=是最后出现的字符，而且最多两个，这分割没啥大问题啊
|
|
36
tool2dx 111 天前
|
 |
37
msg7086 111 天前 1
URL 不适合用 base64 所以有了 base64 的 url-safe 版本。
Cookie 不是问题吧，本来就是按等号分割成两部分，第二部分有没有等号不影响使用。 |
|
38
drymonfidelia OP |
 |
39
NoOneNoBody 111 天前 1
既然都说的二进制，总应该知道 6 个 bit 就是 64 吧？ 62 不能完整表示 6 个 bit 啊，36 表示 5 个 bit 又浪费了几个字符
这些编码本来就早于 url 诞生的，你应该问的是为什么 url 标准不考虑兼容 base64 base64 的重要思想是将 bytes 以可视、非控制字符表示，是 bytes 类型转无控制字符的 string 类型的最简单实现，压根就和 url 没什么关系 |
 |
40
cheng6563 111 天前
有没有可能就是单纯的 base64 比 url 诞生的早？
|
 |
41
GeekGao 111 天前
延续 40 楼的发言：
Base64 最早是在 1993 年由 IETF （互联网工程任务组）定义的。当时，它作为 MIME （多用途互联网邮件扩展）协议的一部分被提出。 在那之前，互联网主要用于电子邮件和文件传输，但 WWW （ World Wide Web ）还处于非常早期的阶段。Base64 并不是专门为 WWW 发明的，但它恰好在 WWW 开始普及之际被标准化。这种巧合使得 Base64 成为 WWW 生态系统中的一个重要工具，为网页中的二进制数据传输提供了可靠的解决方案。 |
 |
42
n18255447846 111 天前 1
1. base64 应用广泛
2. 处理 url 需要 encode/decode |
 |
43
Terminl 110 天前
@drymonfidelia 这个还真不是 base64 的锅，完全是你的个人技术问题，图片传输也用 base64,data:image/png;base64,这种多符号的你不是丢失的更多信息？
|
 |
44
iceheart 110 天前 via Android
k/v 解析只需要处理到第一个分隔符,
有 bug 改就完了。 |
 |
45
qiumaoyuan 110 天前
我把内容一字不漏的复制给了 claude ，得出了和楼上各位差不多的回答。
|
 |
46
ShuWei 110 天前
会不会是你直接拿=去分割 url 的做法本身就不合理呢
|
 |
47
yianing 109 天前
base64 里有给 url 准备的编码方式，golang 里叫 URLEncoding ，标准的是 StdEncoding
|
Select Language