base64 编码图片一般会使体积变大多少？

[rv54ntjwfm3ug8]

客户要求把用户上传的 8~9MB 照片全部 base64 保存进数据库防止被传马，API 直接返回 base64 ，给他解释 base64 会让图片变大他理解不了

[3dwelcome]

说出来你们可能不信，base64 增大的那 33%，只要用目前较强力的压缩算法，比如 7z ，又可以把增大的部分给压回去。

所以 base64+7z, 可能最终对比原图 JPG 大小，也就大个 5%。

[IvanLi127]

还不趁机加价加工期

[sneezry]

这都是什么可爱客户

[Quarter]

mongo ？

[play78]

这种方式有个客户刚好用上，最后问，为什么每次请求都那么慢。
是因为普通的文件服务器，图片能在浏览器缓存，而数据库查询出来的图片，做缓存很麻烦，要写代码做。

[gam2046]

@3dwelcome #21 7z 以后还是 blob 数据，那么既然如此，为何还要走 base64 -> 7z 这条路，直接图片本身 blob 入库。最后结果是一样，而且这么兜了一圈以后，base64 浪费一遍 CPU 资源，zip/unzip 又费一次 CPU 。

[cheng6563]

存储体积会涨 36%，但是，内存占用可能会翻个好几倍

[Askiz]

@aptx4689 这能做到吗？

[markgor]

之前有遇到过一个搞.NET PC 端的，他们就是把图片传入 sqlserver 的，但没有 base64 ，直接传 blob 。
我觉得直接把图片传入数据库中好处是：不用理会路径。
坏处是：当 sqlserver 为远程时容易把 sqlserver 的带宽打满导致响应不了其他请求。


其实配置下静态目录和执行权限，安全系数不会比存数据库低吧，而且就算存数据库为什么要 base64 呢？

[markgor]

话说这让我联想起 9 年前，和客户吃饭时客户专门带上懂电脑的朋友，试探性的问了我一句如果被 DDOS 了怎么办。
我那时候回复是只能硬抗，要么上设备清洗要么加大带宽。
然后他似笑非笑的说为什么不把 DNS 改为 127.0.0.1
当时我很无语，随后问他那拔网线不是更快......

[Cusmate]

@markgor 这位改 dns 解析思路异于常人，卖服务的怎么就没想到这个点子呢。

[aylmer]

直接上 oss 就解决的事，为什么要弄得这么麻烦呢

[en20]

经典客户不懂装懂,你还是顺着他意思吧

[wupher]

他愿意为此掏钱就照做吧，不过建议明确注明此项技术方案是甲方要求，由此引发的相关问题不担责即可。

[marcojbk]

这不是好事吗，硬件要求又提高不少，买硬件的回扣你能多挣不少呢

[caisanli]

我以前搞过一次 做一个新闻页 需要上传图片 领导不给文件服务资源 我就把图片转 base64 存数据库🤣

[mutalisk]

@3dwelcome 压回去不又变成二进制流了么，很多都是不可见字符。本来做 base64 的目的不就是都是可见的字符么，便于 json 传输或者终端打印。既然要压，那干嘛不直接用原来的图片字节流呢。

[PopRain]

@Cusmate 他可能认为攻击是基于域名而不是 IP 地址，改一下让他们自己攻击自己

[shanyue]

33%，可以根据这个工具 https://devtool.tech/base64 ，看一下编码的过程，为什么是 33% 一目了然。

[debuggeeker]

其实如果不是需要原图的话，可以保存 2 份，保存一次原图，制作一次采样图片，也保存到 oss 中，这种图片肯定不放数据库的，都是第三方储存桶。客户需要图片，就把图片地址丢给他，原图和采样都给，然他自己拿。采样工具可以 GitHub 看 Luban