先说我目前的做法是在前台新增商品照片时可以多个上传每个图片都会有一个 hidden input,里面放的是 base64
<input type="hidden" name="icon[]" value="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAacAAAJ7CAYAAABH+15RAAAKsGlDQ1BJQ0MgUHJvZmlsZQAASImVlgdUU1kexu976Y0...">
然后在后端 php 用 file_put_contents 将其下载到指定目录
foreach ($_POST['icon'] as $value) {
preg_match('/^(data:\s*image\/(\w+);base64,)/', $value, $result);
$typeThis = '.' . $result[2];
file_put_contents('../../images/product/cover-XXX'.$typeThis, base64_decode(str_replace($result[1], '', $value)));
只是这个字串长度真的让人呵呵然后如果上传十几MB的图片,就直接不给过(应该是base64字串太长的关系,好像跟SIZE有关)有没有其他的方式有一样的效果,但更乾淨的做法,可以不用那么长,上传多大的图片都可以?可以用同样的方式在后端抓取?
2 回答
holdtom
TA贡献1805条经验 获得超10个赞
首先谢邀,
对后端不够熟悉,我给一些偏前端的点吧:
- 在文件存储的技术选型上,优先推荐使用对象存储,各家云服务平台应该都有这个产品线。对象存储的好处,其一它存储是以文件为单位的,不依赖具体的服务器或路径(当然一些分类或处理用的路径还是可以自己新建的),这样你做负载均衡时也可以共享着用,而且如果突然有一天想单独管理,像我用过的阿里云OSS,有单独的客户端可以用,登陆上去完全可视化,和操作Windows差不太多;其二它不怕容量撑爆,我记得几年前做过个营销类型的页面,小游戏,需要用户传头像上去,上线当天直接把硬盘堆满了,整台临时下线去扩容……用对象存储的话,Money给够一切好说。。?
- 当然如果说服务器空间管够+单主机,选择直接存到主机上也没什么不对,但是非常不建议用Base64,因为用文件存是因为文件是二进制的,转成Base64后,二进制变成ASCII码,体积起码膨胀3倍(字符串占用二进制位数),不做压缩的话,这个数字非常之恐怖,进而会直接导致用户的图片卡在前端传不过来或者页面上的资源没法显示(其实就算传过来了,几十兆字符串存进数据库貌似也不太合适……当然我说的基础型的),所以不要为了表面上“能转成字符串存数据库”就贸然用这个方案,除非你的图片都是平均几k的小东西。
- 前端做法我个人建议压缩一下再传给后台。这里压缩的目的一是直观控制图片大小,二是做规格化预处理,把EXIF之类的东西先清一清,需要高质量的话可以输出原大小的PNG。当然如果用对象存储的话,可能还有机会用到一些附加工具在后台做二次处理。
- 不建议后端直接下载的方式。从用户体验角度来说,还是建议给用户一个更直观的反馈,同时也是提醒用户需要“主动”去完成操作,这样用户会按照习惯把图片上传完,再去做别的。如果是放在后台静默加载,没加载完用户关闭了页面,那前边不就白传了么?
- 2 回答
- 0 关注
- 488 浏览
添加回答
举报
0/150
提交
取消