奇葩的后端分页要求 --后端大佬安排&前端小白实现

[qshu]

GET 参数 params 来获取指定页内容

/api/cont?limit=数量&continue=Base64 加密的 JSON 页数

大家有没有遇到过这样搞分页的，页码数 base64 加密？

[viakiba]

base64 只能称为编解码 不属于加密

[FrankFang128]

这不算奇葩，只能算脱裤子放屁——多此一举。

[qshu]

@viakiba 编码人类不能直接理解与加密有什么区别(-_-)

[imnpc]

页数 base64 ？我记得 get 传递 base64 会出问题来着？有些符号会变？

[yahon]

可以，但没必要。

[qshu]

@imnpc 大佬是这么要求的 出问题接着问他就把类似 "{"start":2}"这种字符串转 base64

[zjsxwc]

如果 base64 后包含符号 & ? + 等符号时，
你不就凉了 233333

[LancerComet]

如果是 JSON 的问题，可以 stringify 之后当字符串传，这种还挺多的

[Elethom]

这种后端留着过年？怕不是来搞笑的吧。

[qshu]

@zjsxwc 好像是唉，把这放在 URL 真的无语

[tomczhen]

为了防止遍历分页还是有把分页编码或者加密的需求的。

base64 中只有 / 和 + 字符，没有 & 和 ？，而且 web 上一般用 url safe base64，所以担心特殊字符的就算了。

[passerbytiny]

难道是反爬？

[gaoryrt]

@zjsxwc base64 编码之后合法字符包括 [A-Za-z/+=]
讲道理应该是没问题的。。。吧

[qshu]

@passerbytiny 反爬好像是有那么点效果的

[qshu]

@tomczhen
@gaoryrt 感谢，刚查了下，是没有影响的字符，才疏学浅了

[zjsxwc]

@gaoryrt

看了下普通数字是不会有特殊字符 0-9 总共就那么几个字母轮流替换

[Macolor21]

@qshu
编码就是编码，加密就是加密，不能混淆。那我们的编程语言的也对普通人不可理解，那算加密么？
另外这种风格我见国外的外部 api 也有用的，一般就是出于各种考虑和妥协的后果，不要见到什么不和自己的理念就吐槽，这种心态不太好。

[hanxiV2EX]

加密 url 参数也不是这样搞的呀，接过 sdk 的都应该知道是给参数加盐后求 sign

[fundon]

还不如 POST 数据一把梭

[vevlins]

反爬也不能用这种手段啊，太不优美。大佬都给你安排好了你还准备跟他肛一波不成？按照要求写呗

[Vegetable]

自以为是吧，不过 base64+urlencode 看起来的确不那么容易直接看出来，但是 f12 看一下，大家都会把 base64 过的字段解出来看一下的。所以这一步只是自己骗自己。

[MonoLogueChi]

base64 没问题啊，jwt 就是 base64 编码的，有那么多人在用，为什么楼上说凉凉之类的。这样用也没什么问题吧，只要能解决需求就好，在 get 参数里做 base64 编码也是很常见的操作

[code2019]

不应该是 POST 嘛

[Lax]

如果目的是反爬的话，单单把参数放 json 里在 base64 这一种措施真的是没什么用，大佬的方案里是不是还有其它关键参数？

[winglight2016]

@code2019 post 没法缓存，不适合列表页面

[kekxv]

也许是祖传的坑，一直没改

[xiangyuecn]

@viakiba base64 编码也算是一种加密！不信来一段试试：

5oiR5LiN5L+h5L2g6IO95LiA55y855yL5Ye65oiR5Yqg5a+G55qE5q2k5q615YaF5a65

在不知道解密算法的前提下，要得到明文是很困难的，哈哈😉

----------------


此后端分页要求在合理的场景下不算奇葩。也许是增加别有用心的人的利用难度而已，算是低成本高回报；加密算法也许哪天可以不用 base64 了，换成别的，或者算法一天一换。

另一个心里安慰：用户看不到 url 里面的页码。。。看起来蛮高大上😂

[yhxx]

类似 "{"start":2}"这种字符串也转 base64

不会因为 url 长度太长出现某些奇怪的问题吗？

[zsdroid]

md5 可还行

[an168bang521]

感觉这么做可以的，类似网页防用户复制和前端压缩混淆一样，防住一些初级小白和君子就好；
业务上没问题，增加爬取难度就行了，
真想爬你的页面，你再怎么加盐，加 sige，别人大不了直接绕过你那一套，直接拿你页面"下一页"的最终链接，还不是直接爬到；

[luopengfei14]

@zsdroid md5 不可逆，只能做校验吧 눈_눈

[mooncakejs]

关键在于 continue 的内容是前端 encode 的还是后端直接字符串返回的，如果是后者，这就是一个 cursor，前端不应该关心其内容。

[chendy]

脱裤子放屁行为
还反爬虫…随便开几个观察一下参数就知道怎么回事了好么…

[qshu]

@mooncakejs 作为分页的按钮来跳转，每次都需要 encode，跳转的话，翻下一页的话，还是需要自己转

[qshu]

@vevlins 有疑问，感觉这么做不大合适，才发出来看看大家意见和建议

[Youen]

和 OData 差不多啊。 编码一下也没啥， 反向代理会过滤一些带特殊字符的 URL

[yanguangs]

base64 可不是加密啊
我们的解决方式是 post 方式传 json,
因为之前的项目使用的 mogodb,所以参数是 skip limit,还是很奇怪

[qshu]

@xiangyuecn 同理解

[Jiangyf]

这边建议加盐再 Base64 处理传给后端呢

[pinews]

php:

function urlsafe_base64_encode ($data) {
return str_replace(array('+','/','='),array('-','_',''), base64_encode($data));
}

[bwangel]

base64 中就三个特殊点的字符，+ / =

可以搜索 URL Safe Base64，会将 + / 替换成 - _，同时不再尾部添加=表示补充的字节。