34 条回复  ·  388 次点击
iceheart 小成 2024-8-31 08:09:59

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

k/v 解析只需要处理到第一个分隔符,
有 bug 改就完了。
qiumaoyuan 小成 2024-8-31 10:12:25

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

我把内容一字不漏的复制给了 claude ,得出了和楼上各位差不多的回答。
ShuWei 小成 2024-8-31 10:24:35

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

会不会是你直接拿=去分割 url 的做法本身就不合理呢
yianing 小成 2024-8-31 23:08:34

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

base64 里有给 url 准备的编码方式,golang 里叫 URLEncoding ,标准的是 StdEncoding
inza9hi 小成 2024-9-1 10:09:38

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

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