关于javascript:一文了解文件上传全过程18w字深度解析进阶必备

平时在写业务的时候经常会用的到的是 GET, POST申请去申请接口，GET 相干的接口会比拟容易根本不会出错，而对于 POST中罕用的表单提交，JSON提交也比拟容易，然而对于文件上传呢？大家可能对这个步骤会比拟胆怯，因为可能大家对它并不是怎么相熟，而浏览器 Network 对它也没有具体的进行记录，因而它成为了咱们心中的一根刺，咱们老是无奈确定，对于文件上传到底是我写的有问题呢？还是后端有问题，当然，咱们个别都比拟虚心，总是会在本人身上找起因，可是往往实事呢？可能就出在后端身上，可能是他承受写的有问题，导致你换了各种申请库去尝试，axios，request，fetch 等等。那么咱们如何防止这种状况呢？咱们本身要对这一块够相熟，能力不以猜的形式去写代码。如果你感觉我以上说的你有同感，那么你浏览完这篇文章你将播种自信，你将不会质疑本人，不会以猜的形式去写代码。

本文比拟长可能须要花点工夫去看，须要有急躁，我采纳自顶向下的形式，所有示例会先展现出你相熟的形式，再一层层往下, 先从申请端是怎么发送文件的，再到接收端是怎么解析文件的。

multipart/form-data 最后由《RFC 1867: Form-based File Upload in HTML》文档提出。

Since file-upload is a feature that will benefit many applications, this proposes an extension to HTML to allow information providers to express file upload requests uniformly, and a MIME compatible representation for file upload responses.

因为文件上传性能将使许多应用程序受害，因而倡议对 HTML 进行扩大，以容许信息提供者对立表白文件上传申请，并提供文件上传响应的 MIME 兼容示意。

总结就是原先的标准不满足啦，我要裁减标准了。

The encoding type application/x-www-form-urlencoded is inefficient for sending large quantities of binary data or text containing non-ASCII characters. Thus, a new media type,multipart/form-data, is proposed as a way of efficiently sending the values associated with a filled-out form from client to server.

1867 文档中也写了为什么要新增一个类型，而不应用旧有的 application/x-www-form-urlencoded：因为此类型不适宜用于传输大型二进制数据或者蕴含非 ASCII 字符的数据。平时咱们应用这个类型都是把表单数据应用 url 编码后传送给后端，二进制文件当然没方法一起编码进去了。所以multipart/form-data 就诞生了，专门用于无效的传输文件。

兴许你有疑难？那能够用 application/json吗?

其实我认为，无论你用什么都能够传，只不过会要综合思考一些因素的话，multipart/form-data更好。例如咱们晓得了文件是以二进制的模式存在，application/json 是以文本模式进行传输，那么某种意义上咱们的确能够将文件转成例如文本模式的 Base64 模式。然而呢，你转成这样的模式，后端也须要依照你这样传输的模式，做非凡的解析。并且文本在传输过程中是相比二进制效率低的，那么对于咱们动辄几十 M 几百 M 的文件来说是速度是更慢的。

以上为什么文件传输要用 multipart/form-data 我还能够举个例子，例如你在中国，你想要去美洲，咱们的multipart/form-data 相当于是抉择飞机，而 application/json 相当于高铁，然而呢？中国和美洲之间没有高铁啊，你执意要坐高铁去，你能够花低廉的代价（后端额定解析你的文本）造高铁去美洲，然而你有更加便宜的形式坐飞机（应用multipart/form-data）去美洲（去传输文件）。你图啥？（如果你有钱有工夫，道歉，打搅了，老子给你赔罪）

摘自《RFC 1867: Form-based File Upload in HTML》6.Example

Content-type: multipart/form-data, boundary=AaB03x

--AaB03x
content-disposition: form-data; name="field1"
Joe Blow
--AaB03x
content-disposition: form-data; name="pics"; filename="file1.txt"
Content-Type: text/plain

... contents of file1.txt ...
--AaB03x--

能够简略解释一些，首先是申请类型，而后是一个 boundary（宰割符），这个货色是干啥的呢？其实看名字就晓得，分隔符，过后宰割作用，因为可能有多文件多字段，每个字段文件之间，咱们无奈精确地去判断这个文件哪里到哪里为截止状态。因而须要有分隔符来进行划分。而后再接下来就是申明内容的形容是 form-data 类型，字段名字是啥，如果是文件的话，得晓得文件名是啥，还有这个文件的类型是啥，这个也很好了解，我上传一个文件，我总得通知后端，我传的是个啥，是图片？还是一个 txt 文本？这些信息必定得通知人家，他人才好去进行判断，前面咱们也会讲到如果这些没有申明的时候，会产生什么？

好了讲完了这些前置常识，咱们接下来要进入咱们的主题了。面对 File, formData,Blob,Base64,ArrayBuffer, 到底怎么做？还有文件上传不仅仅是前端的事。服务端也能够文件上传（例如咱们利用某云，把动态资源上传到 OSS 对象存储）。服务端和客户端也有各种类型，Buffer，Stream，Base64…. 头秃，怎么搞？不急，就是因为上传文件不单单是前端的事，所以我将以下上传文件的一方称为 申请端 ，承受文件一方称为 接管方。我会以申请端各种上传形式，接收端是怎么解析咱们的文件以及咱们最终的杀手锏调试工具 -wireshark 来进行解说。以下是解说的纲要，咱们先从浏览器端上传文件，再到服务端上传文件，而后咱们再来解析文件是如何被解析的。

首先咱们先写下最简略的一个表单提交形式。

<form action="http://localhost:7787/files" method="POST">
    <input name="file" type="file" id="file">
    <input type="submit" value="提交">
</form>

咱们抉择文件后上传，发现后端返回了文件不存在。

不必焦急，相熟的同学可能立马晓得是啥起因了。嘘，晓得了也听我缓缓叨叨。

咱们关上控制台，因为表单提交会进行网页跳转，因而咱们勾选preserve log 来进行日志追踪。

咱们能够发现其实 FormData 中 file 字段显示的是文件名，并没有将真正的内容进行传输。再看申请头。

发现是申请头和预期不符，也印证了 application/x-www-form-urlencoded 无奈进行文件上传。

咱们加上申请头，再次申请。

<form action="http://localhost:7787/files" enctype="multipart/form-data" method="POST">
  <input name="file" type="file" id="file">
  <input type="submit" value="提交">
</form>

发现文件上传胜利，简略的表单上传就是像以上一样简略。然而你得熟记文件上传的格局以及类型。

formData 的形式我轻易写了以下几种形式。

<input type="file" id="file">
<button id="submit"> 上传 </button>
<script src="https://cdn.bootcss.com/axios/0.19.2/axios.min.js"></script>
<script> submit.onclick = () => {const file = document.getElementById('file').files[0];
    var form = new FormData();
    form.append('file', file);
  
    // type 1
    axios.post('http://localhost:7787/files', form).then(res => {console.log(res.data);
    })
    // type 2
    fetch('http://localhost:7787/files', {
        method: 'POST',
        body: form
    }).then(res => res.json()).tehn(res => {console.log(res)});
    // type3
    var xhr = new XMLHttpRequest();
    xhr.open('POST', 'http://localhost:7787/files', true);
    xhr.onload = function () {console.log(xhr.responseText);
    };
    xhr.send(form);
} </script>

以上几种形式都是能够的。然而呢，申请库这么多，我轻易在 npm 上一搜就有几百个申请相干的库。

因而，把握申请库的写法并不是咱们的指标，指标只有一个还是把握文件上传的申请头和申请内容。

Blob 对象示意一个不可变、原始数据的类文件对象。Blob 示意的不肯定是 JavaScript 原生格局的数据。File 接口基于Blob，继承了 blob 的性能并将其扩大使其反对用户零碎上的文件。

因而如果咱们遇到 Blob 形式的文件上形式不必胆怯，能够用以下两种形式:

1. 间接应用 blob 上传

const json = {hello: "world"};
const blob = new Blob([JSON.stringify(json, null, 2)], {type: 'application/json'});
    
const form = new FormData();
form.append('file', blob, '1.json');
axios.post('http://localhost:7787/files', form);

2. 应用 File 对象，再进行一次包装（File 兼容性可能会差一些 https://caniuse.com/#search=File）

const json = {hello: "world"};
const blob = new Blob([JSON.stringify(json, null, 2)], {type: 'application/json'});
    
const file = new File([blob], '1.json');
form.append('file', file);
axios.post('http://localhost:7787/files', form)

ArrayBuffer 对象用来示意通用的、固定长度的原始二进制数据缓冲区。

尽管它用的比拟少，然而他是最贴近文件流的形式了。

在浏览器中，他每个字节以十进制的形式存在。我提前准备了一张图片。

const bufferArrary = [137,80,78,71,13,10,26,10,0,0,0,13,73,72,68,82,0,0,0,1,0,0,0,1,1,3,0,0,0,37,219,86,202,0,0,0,6,80,76,84,69,0,0,255,128,128,128,76,108,191,213,0,0,0,9,112,72,89,115,0,0,14,196,0,0,14,196,1,149,43,14,27,0,0,0,10,73,68,65,84,8,153,99,96,0,0,0,2,0,1,244,113,100,166,0,0,0,0,73,69,78,68,174,66,96,130];
const array = Uint8Array.from(bufferArrary);
const blob = new Blob([array], {type: 'image/png'});
const form = new FormData();
form.append('file', blob, '1.png');
axios.post('http://localhost:7787/files', form)

这里须要留神的是 new Blob([typedArray.buffer], {type: 'xxx'})，第一个参数是由一个数组包裹。外面是 typedArray 类型的 buffer。

const base64 = 'iVBORw0KGgoAAAANSUhEUgAAAAEAAAABAQMAAAAl21bKAAAABlBMVEUAAP+AgIBMbL/VAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAACklEQVQImWNgAAAAAgAB9HFkpgAAAABJRU5ErkJggg==';
const byteCharacters = atob(base64);
const byteNumbers = new Array(byteCharacters.length);
for (let i = 0; i < byteCharacters.length; i++) {byteNumbers[i] = byteCharacters.charCodeAt(i);
}
const array = Uint8Array.from(byteNumbers);
const blob = new Blob([array], {type: 'image/png'});
const form = new FormData();
form.append('file', blob, '1.png');
axios.post('http://localhost:7787/files', form);

对于 base64 的转化和原理能够看这两篇 base64 原理和

原来浏览器原生反对 JS Base64 编码解码

对于浏览器端的文件上传，能够归纳出一个套路，所有货色外围思路就是结构出 File 对象。而后察看申请 Content-Type，再看申请体是否有信息缺失。而以上这些二进制数据类型的转化能够看以下表。

图片起源 (https://shanyue.tech/post/binary-in-frontend/#%E6%95%B0%E6%8D%AE%E8%BE%93%E5%85%A5)

讲完了浏览器端，当初咱们来讲服务器端，和浏览器不同的是，服务端上传有两个难点。

1. 浏览器没有原生 formData，也不会想浏览器一样帮咱们转成二进制模式。

2. 服务端没有可视化的 Network 调试器。

Request

首先咱们通过最简略的示例来进行演示，而后一步一步深刻。置信文档能够查看 https://github.com/request/request#multipartform-data-multipart-form-uploads

// request-error.js
const fs = require('fs');
const path = require('path');
const request = require('request');
const stream = fs.readFileSync(path.join(__dirname, '../1.png'));
request.post({
    url: 'http://localhost:7787/files',
    formData: {file: stream,}
}, (err, res, body) => {console.log(body);
})

发现报了一个谬误，正像下面所说，浏览器端报错，能够用NetWork。那么服务端怎么办？这个时候咱们拿出咱们的利器 — wireshark

咱们关上 wireshark（如果没有或者不会的能够查看教程 https://blog.csdn.net/u013613428/article/details/53156957）

设置配置 tcp.port == 7787, 这个是咱们后端的端口。

运行上述文件 node request-error.js

咱们来找到咱们发送的这条 http 的申请报文。两头那堆乌七八糟的就是咱们的文件内容。

POST /files HTTP/1.1
host: localhost:7787
content-type: multipart/form-data; boundary=--------------------------437240798074408070374415
content-length: 305
Connection: close

----------------------------437240798074408070374415
Content-Disposition: form-data; name="file"
Content-Type: application/octet-stream

.PNG
.
...
IHDR.............%.V.....PLTE......Ll.....  pHYs..........+.....
IDAT..c`.......qd.....IEND.B`.
----------------------------437240798074408070374415--

能够看到上述报文。发现咱们的内容申请头 Content-Type: application/octet-stream有谬误, 咱们上传的是图片申请头应该是image/png，并且也少了 filename="1.png"。

咱们来思考一下，咱们方才用的是 fs.readFileSync(path.join(__dirname, '../1.png')) 这个函数返回的是 Buffer，Buffer 是什么样的呢？就是上面的模式，不会蕴含任何文件相干的信息，只有二进制流。

<Buffer 01 02>

所以我想到的是，须要指定文件名以及文件格式，幸好 request 也给咱们提供了这个选项。

key: {value:  fs.createReadStream('/dev/urandom'),
    options: {
      filename: 'topsecret.jpg',
      contentType: 'image/jpeg'
    }
}

能够指定options, 因而正确的代码应该如下(省略不重要的代码)

...
request.post({
    url: 'http://localhost:7787/files',
    formData: {
        file: {
            value: stream,
            options: {filename: '1.png'}
        },
    }
});

咱们通过抓包能够进行剖析到，文件上传的要点还是标准，大部分的问题，都能够通过标准模板来进行排查，是否结构出了标准的样子。

Form-data

咱们再深刻一些，来看看 request 的源码, 他是怎么实现 Node 端的数据传输的。

关上源码咱们很容易地就能够找到对于 formData 这块相干的内容 https://github.com/request/request/blob/3.0/request.js#L21

就是利用form-data，咱们先来看看 formData 的形式。

const path = require('path');
const FormData = require('form-data');
const fs = require('fs');
const http = require('http');
const form = new FormData();
form.append('file', fs.readFileSync(path.join(__dirname, '../1.png')), {
    filename: '1.png',
    contentType: 'image/jpeg',
});
const request = http.request({
    method: 'post',
    host: 'localhost',
    port: '7787',
    path: '/files',
    headers: form.getHeaders()});
form.pipe(request);
request.on('response', function(res) {console.log(res.statusCode);
});

原生 Node

看完 formData, 可能感觉这个封装还是太高层了，于是我打算对照标准手动来结构 multipart/form-data 申请形式来进行解说。咱们再来回顾一下标准。

Content-type: multipart/form-data, boundary=AaB03x

--AaB03x
content-disposition: form-data; name="field1"
Joe Blow
--AaB03x
content-disposition: form-data; name="pics"; filename="file1.txt"
Content-Type: text/plain

... contents of file1.txt ...
--AaB03x--

我模仿上方，我用原生 Node 写出了一个multipart/form-data 申请的形式。

次要分为 4 个局部

结构申请 header
结构内容 header
写入内容
写入完结分隔符

const path = require('path');
const fs = require('fs');
const http = require('http');
// 定义一个分隔符，要确保唯一性
const boundaryKey = '-------------------------461591080941622511336662';
const request = http.request({
    method: 'post',
    host: 'localhost',
    port: '7787',
    path: '/files',
    headers: {
        'Content-Type': 'multipart/form-data; boundary=' + boundaryKey, // 在申请头上加上分隔符
        'Connection': 'keep-alive'
    }
});
// 写入内容头部
request.write(`--${boundaryKey}rnContent-Disposition: form-data; name="file"; filename="1.png"rnContent-Type: image/jpegrnrn`
);
// 写入内容
const fileStream = fs.createReadStream(path.join(__dirname, '../1.png'));
fileStream.pipe(request, { end: false});
fileStream.on('end', function () {
    // 写入尾部
    request.end('rn--' + boundaryKey + '--' + 'rn');
});
request.on('response', function(res) {console.log(res.statusCode);
});

至此，曾经实现服务端上传文件的形式。

因为这两块就是和 Buffer 的转化，比较简单，我就不再反复形容了。能够作为留给大家的作业，感兴趣的能够给我这个示例代码仓库奉献这两个示例。

// base64 to buffer
const b64string = /* whatever */;
const buf = Buffer.from(b64string, 'base64');

// stream to buffer
function streamToBuffer(stream) {return new Promise((resolve, reject) => {const buffers = [];
    stream.on('error', reject);
    stream.on('data', (data) => buffers.push(data))
    stream.on('end', () => resolve(Buffer.concat(buffers))
  });
}

因为服务端没有像浏览器那样 formData 的原生对象，因而服务端外围思路为结构出文件上传的格局 (header,filename 等)，而后写入 buffer。而后千万别忘了用 wireshark 进行验证。

这一部分是针对 Node 端进行解说，对于那些 koa-body 等用惯了的同学，可能一样不太分明整个过程产生了什么？可能惟一比较清楚的是 ctx.request.files ??? 如果ctx.request.files 不存在，就会懵逼了，可能也不太分明它到底做了什么，文件流又是怎么解析的。

我还是要说到标准 … 申请端是依照标准来结构申请.. 那么咱们接收端天然是依照标准来解析申请了。

const koaBody = require('koa-body');

app.use(koaBody({ multipart: true}));

咱们来看看最罕用的 koa-body，它的应用形式非常简单，短短几行，就能让咱们享受到文件上传的简略与高兴（其余源码库一样的思路去寻找问题的根源）能够带着一个问题去浏览，为什么用了它就能解析出文件？

寻求问题的根源，咱们当然要关上 koa-body的源码，koa-body 源码很少只有 211 行，https://github.com/dlau/koa-body/blob/v4.1.1/index.js#L125 很容易地发现它其实是用了一个叫做 formidable 的库来解析 files 的。并且把解析好的 files 对象赋值到了 ctx.req.files。（所以说大家不要一味死记 ctx.request.files, 留神查看文档，因为明天用 koa-body是 ctx.request.files 今天换个库可能就是 ctx.request.body 了）

因而看完 koa-body咱们得出的论断是，koa-body的外围办法是formidable

那么让咱们持续深刻，来看看 formidable 做了什么，咱们首先来看它的目录构造。

.
├── lib
│   ├── file.js
│   ├── incoming_form.js
│   ├── index.js
│   ├── json_parser.js
│   ├── multipart_parser.js
│   ├── octet_parser.js
│   └── querystring_parser.js

看到这个目录，咱们大抵能够梳理出这样的关系。

index.js
|
incoming_form.js
|
type
?
|
1.json_parser
2.multipart_parser
3.octet_parser
4.querystring_parser

因为源码剖析比拟干燥。因而我只摘录比拟重要的片段。因为咱们是剖析文件上传，所以咱们只须要关怀 multipart_parser 这个文件。

https://github.com/node-formidable/formidable/blob/v1.2.1/lib/multipart_parser.js#L72

...
MultipartParser.prototype.write = function(buffer) {console.log(buffer);
  var self = this,
      i = 0,
      len = buffer.length,
      prevIndex = this.index,
      index = this.index,
      state = this.state,
...

咱们将它的 buffer 打印看看.

<Buffer 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 34 36 31 35 39 31 30 38 30 39 34 31 36 32 32 35 31 31 33 33 36 36 36 ... >
144
<Buffer 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 00 00 00 01 00 00 00 01 01 03 00 00 00 25 db 56 ca 00 00 00 06 50 4c 54 45 00 00 ff 80 80 80 4c 6c bf ... >
106
<Buffer 0d 0a 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 34 36 31 35 39 31 30 38 30 39 34 31 36 32 32 35 31 31 33 33 36 ... >

咱们来看 wireshark 抓到的包

我用红色进行了宰割标记，对应的就是 formidable 所宰割的片段，所以说这个包次要是将大段的 buffer 进行宰割，而后循环解决。

这里我还能够补充一下，可能你对以上表十分生疏。左侧是二进制流，每 1 个代表 1 个字节，1 字节 = 8 位，下面的 2d 其实就是 16 进制的示意模式，用二进制示意就是 0010 1101，右侧是 ascii 码用来可视化，然而 assii 分可显和非可显示。有局部是无奈可视的。比方你所看到文件中有须要小点，就是不可见字符。

你能够对照，ascii 表对照表来看。

我来总结一下 formidable 对于文件的解决流程。

好了，咱们曾经晓得了文件解决的流程，那么咱们本人来写一个吧。

const fs = require('fs');
const http = require('http');
const querystring = require('querystring');
const server = http.createServer((req, res) => {if (req.url === "/files" && req.method.toLowerCase() === "post") {parseFile(req, res)
  }
})
function parseFile(req, res) {req.setEncoding("binary");
  let body = "";
  let fileName = "";
  // 边界字符
  let boundary = req.headers['content-type']
    .split(';')[1]
    .replace("boundary=", "")
  
  req.on("data", function(chunk) {body += chunk;});
  req.on("end", function() {
    // 依照合成符切分
    const list = body.split(boundary);
    let contentType = '';
    let fileName = '';
    for (let i = 0; i < list.length; i++) {if (list[i].includes('Content-Disposition')) {const data = list[i].split('rn');
        for (let j = 0; j < data.length; j++) {
          // 从头部拆分出名字和类型
          if (data[j].includes('Content-Disposition')) {const info = data[j].split(':')[1].split(';');
            fileName = info[info.length - 1].split('=')[1].replace(/"/g,'');
            console.log(fileName);
          }
          if (data[j].includes('Content-Type')) {contentType = data[j];
            console.log(data[j].split(':')[1]);
          }
        }
      }
    }
    // 去除后面的申请头
    const start = body.toString().indexOf(contentType) + contentType.length + 4; // 有多 rnrn
    const startBinary = body.toString().substring(start);
    const end = startBinary.indexOf("--" + boundary + "--") - 2; // 后面有多 rn
     // 去除前面的分隔符
    const binary = startBinary.substring(0, end);
    const bufferData = Buffer.from(binary, "binary");
    fs.writeFile(fileName, bufferData, function(err) {res.end("sucess");
    });
    ;
  })
}

server.listen(7787)

置信有了以上的介绍，你不再对文件上传有所害怕, 对文件上传整个过程都会比拟清晰了，还不懂。。。。找我。

再次回顾下咱们的重点:

申请端出问题，浏览器端关上 network 查看格局是否正确（申请头，申请体）, 如果数据不够具体，关上 wireshark，对照咱们的标准规范，看下格局（申请头，申请体）。

接收端出问题，状况一就是申请端短少信息，参考下面申请端出问题的状况，状况二申请体内容谬误，如果说申请体内容是申请端本人结构的，那么须要查看申请体是否是正确的二进制流（例如下面的 blob 结构的时候，我一开始少了一个[]，导致内容主体谬误）。

其实讲这么多就两个字: 标准，所有的生态都是围绕它而开展的。更多请看我的博客。

shark-cleaner: 一个 Node Cli 实现的垃圾清理工具(深层清理开发垃圾)

Node + NAPI 实现 C++ 扩大 – LRU 淘汰算法

开发一个 Node 命令行小玩具全过程 – 高颜统计工具

如果我的文章有帮忙到你，心愿你也能帮忙我，欢送关注我的微信公众号 秋风的笔记 ，回复 好友 二次，可加微信并且退出交换群， 秋风的笔记 将始终陪伴你的左右。

https://juejin.im/post/6844903810079391757

https://my.oschina.net/bing309/blog/3132260

https://segmentfault.com/a/1190000020654277

关于javascript:一文了解文件上传全过程18w字深度解析进阶必备

前言

前置常识

什么是 multipart/form-data?

文件上传为什么要用 multipart/form-data？

multipart/form-data 标准是什么？

申请端

浏览端

File

FormData

Blob

ArrayBuffer

Base64

小结

服务端

Buffer

Request

Form-data

原生 Node

次要分为 4 个局部

Stream、Base64

小结

接收端

Koa-body

Formidable

原生 Node

总结

相干浏览

最初

参考