前端图片上传压缩技巧详解 (前端上传图片到服务器如何压缩)
随着互联网的不断发展和普及，图片作为一种重要的信息载体，已经成为我们日常生活和各行各业中不可或缺的一部分。随之而来的问题是，如何快速、高效地上传大量的图片，并且保证用户体验的同时还能减少服务器压力和网络传输的成本。本文将讲解一些前端图片上传和压缩的技巧，希望对广大开发者和站长有所帮助。
一、图片上传的基本原理
在介绍具体的图片上传和压缩技巧之前，我们需要了解一些图片上传的基本原理。
图片上传一般采用HTTP的POST方式，即用户在页面中选择了要上传的图片，然后通过Ajax形式，将图片的二进制数据传输给服务器，服务器再将其保存到磁盘中，并记录相应的位置和属性信息。上传图片的大小和数量对于服务器的压力和网络传输的成本有很大的影响，因此需要在上传之前对图片进行压缩处理，以减小图片的大小和在传输过程中的带宽占用。常见的图片压缩算法有JPEG、PNG和GIF等。
二、图片上传和压缩的技巧
1、利用canvas进行图片压缩
canvas是HTML5的一项新技术，可以将图片生成为一张画布（Canvas），而且可以在画布上进行各种像素级别的操作，如图片裁剪、调整大小、滤镜处理、添加文字等。利用canvas进行图片压缩的原理是先将图片绘制到画布上，然后根据画布的大小进行调整，最后将画布转化为对应大小的图片，即可达到压缩图片的目的。
2、利用FileReader进行文件读取
利用HTML5的FileReader API，可以将本地文件读取为二进制数据或文本信息，然后在前端进行预处理或上传。利用FileReader进行图片压缩的原理是先将图片转化为二进制格式，然后通过FileReader将其读取为一个字符串，最后再利用canvas进行图片压缩。
3、采用图片压缩库
为了更加方便和高效地进行图片压缩，我们可以使用一些已有的图片压缩库，如Jsdelivr上的compressor.js、tui-image-editor等。这些图片压缩库一般包含了许多实用的图片处理工具，如图片缩放、压缩、裁剪、滤镜等。
4、利用webp格式进行图片压缩
WebP是由Google公司创建的一种图片压缩格式，它可以比JPEG格式更小的文件大小，保持更好的图片质量。通过使用WebP格式的图片，可以减少在图片传输和存储过程中的网络传输成本和服务器压力。
三、
本文介绍了一些前端图片上传和压缩的技巧，包括利用canvas进行图片压缩、利用FileReader进行文件读取、使用图片压缩库和利用webp格式进行图片压缩等。通过这些技巧，我们可以更加高效、优化地进行图片上传和处理，减少服务器压力和网络传输成本。这些技巧不仅适用于开发者和站长，也可以帮助其他人更好地利用图片传达信息和美化页面。
相关问题拓展阅读：
js压缩图片 到固定像素以内，500k为例
本文旨在探究js压缩图片的两种方式：
改变图片长宽
，
改变图片质量
，和结合了以上两者的
最终方案
。
首先，阅读本文需要知道canvas的两个方法
这两个方法具体的说明可以在MDN上查看，关于图片压缩，也有很多现成的博客可以直接用。但是那些博客都有个问题，并没有关心之后图片的压缩质量。
我试着用一个现成的例子去跑了一下，一个1.7M的图片压缩到了23k，堪称像素级毁灭性破坏。
假如一张大图可能包含着很多文字等关键信息，必须上传之后使用方能清晰辨认。所以要压缩之后质量尽可能接近500k的。500k像素以内，就是若一张图宽度为1024，则高度不能超过500。因为图片有其他的信息，也是要占大小的。即不得大于
1024*500
。
所以激答，根据需求，上传图片不能超过500k的情况下尽可能保留图片的清晰度。当然如果可以的情况下用上面提到的 canvas.toDataURL 设置压缩程度为0.9，0.8试试看，图片质量可以接受，大小会有大幅度的缩小。
如果不压缩，靠调整图片长宽去控制上传大小呢？
原理很简单，就是靠不断地缩小限定的更大宽高，直到最终长宽的积小于规定的大小。
这种方法有可能最后得出的图片的大小会略大于规定大小，原因上文也提到过了，如果想使用这种方法，可自行再调整一下。
上面的方法有个问题，就是改变了图片的原始长宽。如果一个图的长宽足够大，压缩图片质量，糊一点但是内容看得清也是ok的嘛。所以，跟上面同理，我们可以不断调整图片的质量设定直到大小合适，那么，如何在图片上传之前知道图片的大小呢？
首先，需要知道的一点是，压缩之后拿到的base64字符串会转成blob对象，然后传给服务端。
可以查阅文档，blob对象有个属性是size
这个size就是上传之后实际的文件大小。
参照上面的思路，可以每次改变 canvas.toDataURL(‘image/’ + fileType, level); level的值，去调整压缩图片质量，然后用blob对象的size去验证是否满足500k以内的需求。
关于 canvas.toDataURL 的level到底是怎么计算的，MDN文档里也没说，写了个循环一次减少0.1的level压缩了几个图片
用加减乘除算了一下，没找到规律，数学不好放弃了（这个东西好像也不是能观察出来的，看结果跟初始大小没啥关系）。
这里要注意的是，有可能遇到超大图片闷早，0.1的level可能不足以压缩到500k，所以小于0.1的时候，改变level递减的差值继续压缩下去
在开始接收到图片的时候给一个loading增加用户的耐心好了，loading万岁~
其实单纯的压缩质量遇到稍大的图片，会导致页面高频计算，然后页面基本就用不了了- -。有尝试过用iphone的一个屏幕截图（10M左右），压的时候稍过一会，整个手机都在发烫，只能杀进程。
所以，若对长度没有特殊的限制，可以做一个缩放，去加快压缩的进度蚂铅雀，提高能压缩的图片大小上限。
页面到了ios上还是不行- -，可以看到最后图片level为0.001，最长边为764。
问题还是循环次数还是过多，计算频率太高。从图中可看出，对于大图来说，初始设定的level和图片尺寸过于宽松，可以优化一下初始level和尺寸。
有的时候还会遇到一张图片无论如何也压不到500k，就是上一次和这次的压缩后大小没有变化，这种情况需要抛错，不让循环继续。
大图片的等待时间稍长，可以给用户先预览一个base64的图片增加等待耐心，方法名为 getImgBase64 ,这里都一并给出了
解决的隐患：上面这个方案会出现我需要一个500k的照片，压到了520k之后，再压了一次。有时候这最后的一次会特别夸张，直接将图片弄到了几十k。
参考了：
这个库里面有个方法 compressAccurately ,这个方法可以比较精准地压缩。偷偷翻了一下源码。
其实上一个方案的痛点就在于，如何在每一个压缩循环里处理尺寸和压缩比例。
总结
如有纰漏，欢迎指正
关于前端上传图片到服务器如何压缩的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
