https://github.com/n0099/open-tbm/issues/24

这样说的话，主流 base64 不适合你这个用例，没必要上，谁逼你上的直接干他。坑你的人是主张在 url 里放乱七八糟东西的人，而不是 base64 。

base64 我记得好像是 3 位一组 3 位一组，然后不够的用=号补齐。用 62 的话，相似的设计，需要单独一个字符专门用来当补齐符号用。

因为 3 * 8 = 4 * 6

而 2 ^ 6 = 64 所以挑了 64 个字符

挺怪的.

避免除法，
你有 1G 数据流，直接当做一个整数，那是很麻烦的
而且可以流式处理，不用等到所有数据都接受到了才编码

菜就多练，URL 传递 Base64 就用 Base64URL ，硬传不就等于自己给自己挖坑吗？用的哪个语言？没有便捷的库？

> 被 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 导致参数丢失

每次跟这些不按标准喜欢自己拼接字符串的煞笔对接都气死我了

手拼 URL 不检查不转换参数偏要怪 base64 使用了不兼容 URL 的字符……那你手拼 SQL 直接传裸参试试。

先不说 base64 ，你拼 URL 的时候不用 encodeURIComponent()再包裹一遍吗？被坑了几次都还没这个意识吗？