项目上也用到很多上传文件的地方,七牛云,阿里云OSS,讯飞web api上传都接触过,所以在这里做一个记录,总结一下前端上传的几种方式。
- 上传基本概念
- 常见前端上传场景
- 自家后端服务上传浅析
- 阿里云OSS上传浅析
- 七牛云上传浅析
- 几种上传服务的对比
- 思考
上传基本概念
File
- File对象可以通过
<input>
,DataTransfer, 或者HTMLCanvasElement.mozGetAsFile()
new File(bits, name[, options])
此处的bits是一个数组,数组元素可以由ArrayBuffer,ArrayBufferView,Blob或者DOMString组成;fileName指明文件名称或者文件路径;options里的type属性指明MIME类型,lastModified属性指明上次修改时间,默认是Date.now();
FormData
- 键值对形式的表单,可被XMLHttpRequest.send()直接发送
- 编码格式指定为
multipart/form-data
也需要用FormData组装数据 其实就是http的request header指定了{Content-Type: 'multipart/form-data'}
- append(key,value)向FormData中添加数据,存在覆盖不存在新建
Blob对象
可以参考我的另一个记录:blob Url那些事儿
常见前端上传场景
- 原生File对象。使用场景:本地上传的图片,音频,视频等文件,没有经过任何其他处理。
- 转换后的Blob对象。使用场景:图片canvas合成后的base64转换为Blob对象;音频通过麦克风录音算法生成的Uint8Array转换成Blob对象。
- 字节数组。使用场景:音频通过麦克风录音算法生成arrayBuffer再转换成Uint8Array。
tips:
- 七牛云 qiniu-js 和 阿里云OSS ali-oss支持Blob对象的上传方式。
- 讯飞web api文件分片上传使用字节数组的方式。
- 看似File对象和Blob对象是2种上传方式,但其实是1种上传方式,因为File对象继承自Blob对象,可以把上述两种上传统一理解成上传Blob对象。
自家后端上传服务浅析
const formData = new FormData(); // 由于服务端编码格式为multipart/form-data,所以需要构造一个FormData对象 const file = new File([blobObj], fileName, { type: blobObj.type }); // 传入blob对象创建一个File实例 formData.append('file', file);// formData实例增加file对象 const options = { method: 'post', url: 'https://foo.bar.com/baz', headers: { 'Content-Type': 'multipart/form-data' }, // 上传相关 data: formData, // 上传相关 }; axios.request(options).then(()=>{}).catch(()=>{});
阿里云OSS上传浅析
ali-oss是一个Node环境和Browser环境皆可用的对象存储服务package。
import OSS from 'ali-oss'; const token = apiNode.generateOssToken({ type }) // 调用nodejs端接口,根据类型生成某个bucket有效的token this.client = new OSS(token); const blobObj = new Blob([u8arr], { type: mime }); this.client .put(fileName, blobObj) // 这里我们传入的值blob对象,ali-oss仅支持浏览器端的Blob对象 .then((data) => { if (data && data.name) { return data.name; // OSS返回的文件名 } }) .catch(() => {});
可以再伪代码基础上用document.cookie设置token的有效时长;上传重试等等护航功能。
关键是ali-oss SDK的put方法,它主要用来向bucket添加一个object。
.put(name, file[,options])
- name String类型的文件名
- {String|Buffer|ReadStream|File(only support Browser)|Blob(only support Browser)} object local path, content buffer or ReadStream content instance use in Node, Blob and html5 File
七牛云上传浅析
qiniu-js是一个基于七牛API开发的前端SDK。
import * as qiniu from 'qiniu-js'; const putExtra = { fname: '', params: {}, mimeType: null };// fname文件原文件名,params自定义变量,mimeType数组,限制文件上传类型 const config = { useCdnDomain: true, // 表示是否使用 cdn 加速域名 disableStatisticsReport: false, // 是否禁用日志报告,为布尔值,默认为 false retryCount: 5, // 上传自动重试次数(整体重试次数,而不是某个分片的重试次数);默认 3 次(即上传失败后最多重试两次);目前仅在上传过程中产生 599 内部错误时生效,但是未来很可能会扩展为支持更多的情况 region: qiniu.region.z0, // 选择上传域名区域;当为 null 或 undefined 时,自动分析上传域名区域 }; const token = apiNode.generateOssToken({ type }) // 调用nodejs端接口,根据类型生成某个bucket有效的token this.observable = qiniu.upload(obj.file, obj.fileName, token, putExtra, config); this.observable.subscribe({ next: (res) => { this.emit('progress', Math.ceil(res.total.percent)); }, error: (err) => { this.clear(); this.emit('error', err, obj.imgName); }, complete: (res) => { this.clear(); this.emit('complete', res.hash, obj.imgName); }, });
关键是qiniu-js SDK的upload方法,它是上传的核心。
qiniu.upload(file: blob, key: string, token: string, putExtra: object, config: object): observablefile: Blob 对象,上传的文件key: 文件资源名token: 上传验证信息,前端通过接口请求后端获得config: 包括cdn加速,日志报告,上传区域名,上传自动重试次数,分片上传的请求并发数,MD5校验等等putExtra: 自定义的一些内容
其次就是这个上传成功后的返回的observable对象,在其中可以做一些上传后的处理。
这个方法本身是一个observable对象,有subscribe方法,主要有next和error,complete三个事件。
next: 接收上传进度信息,res是一个带有 total 字段的 object,包含loaded、total、percent三个属性,提供上传进度信息。error:上传错误后触发;自动重试本身并不会触发该错误,而当重试次数到达上限后则可以触发。当不是 xhr 请求错误时,会把当前错误产生原因直接抛出,诸如 JSON 解析异常等;当产生 xhr 请求错误时,参数 err 为一个包含 code、message、isRequestError 三个属性的 objectcomplete: 接收上传完成后的后端返回信息,具体返回结构取决于后端sdk的配置
与自家服务端和ali-oss不同的是,qiniu-js提供了除成功和失败额外的next事件,可以实时监测到上传的进度,用户感知上传进度是起码的用户体验。
几种上传服务的对比
- 除自家上传服务通过原有的cookie做验证以外,ali-oss和qiniu-js都需要token,而且出于安全的考虑,这个token必须从服务端获取,一般来说都有nodejs,java,go,python等等语言的服务端实现
- 上传的文件类型都支持Blob对象
- ali-oss支持多类型,多平台,从文件类型方面来讲是个不错的选择
- qiniu-js的上传提供了进度的next事件,别具一格
- 从功能复杂性来说和文档友好度来说,ali-oss更胜一筹
- 抛开大公司自己有上传服务,小公司单纯从上传方面做技术选型的话,个人建议使用ali-oss
思考
- 前后端分离的模式下,一个完整功能的实现,前端往往会强依赖后端,注意是强依赖
- 个人认为前后端分离的分离,最好是仅仅从项目架构上做分离,而不是将组织架构做前后端的分离
- 想使得自己获得更大成长空间的程序员,尽量不要限定自己是前端,后端,从全栈的角度去提升自己,没有机会就创造机会,没有时间就挤出时间
- 若是身处前后端协作的团队,享受前后端组织架构分工带来的利好,但也不能因此麻木,尽可能多的走出知识舒适区,不要害怕浪费时间,不要害怕工作中用不到,学习另一端会反哺你对当前端的理解