Node和瀏覽器文件上傳全過程（進階必備）

前言

平常在寫業務的時候常常會用的到的是 GET, POST請求去請求接口，GET 相關的接口會比較容易基本不會出錯，而對於 POST中常用的 表單提交，JSON提交也比較容易，但是對於文件上傳呢？大家可能對這個步驟會比較害怕，因爲可能大家對它並不是怎麼熟悉，而瀏覽器Network對它也沒有詳細的進行記錄，因此它成爲了我們心中的一根刺，我們老是無法確定，關於文件上傳到底是我寫的有問題呢？還是後端有問題，當然，我們一般都比較謙虛， 總是會在自己身上找原因，可是往往實事呢？可能就出在後端身上，可能是他接受寫的有問題，導致你換了各種請求庫去嘗試，axios，request，fetch 等等。那麼我們如何避免這種情況呢？我們自身要對這一塊夠熟悉，才能不以猜的方式去寫代碼。如果你覺得我以上說的你有同感，那麼你閱讀完這篇文章你將收穫自信，你將不會質疑自己，不會以猜的方式去寫代碼。

本文比較長可能需要花點時間去看，需要有耐心，我採用自頂向下的方式，所有示例會先展現出你熟悉的方式，再一層層往下, 先從請求端是怎麼發送文件的，再到接收端是怎麼解析文件的。以下是講解的大綱，我們先從瀏覽器端上傳文件，再到服務端上傳文件，然後我們再來解析文件是如何被解析的。

前置知識

什麼是 multipart/form-data?

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兼容表示。

總結就是原先的規範不滿足啦，我要擴充規範了。

文件上傳爲什麼要用 multipart/form-data？

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）去美洲（去傳輸文件）。你圖啥？（如果你有錢有時間，抱歉，打擾了，老子給你道歉）

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來進行講解。

請求端

瀏覽端

File

首先我們先寫下最簡單的一個表單提交方式。

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

我們選擇文件後上傳，發現後端返回了文件不存在。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-adPzCkNp-1586163610222)(https://s3.qiufengh.com/blog/image-20200328191433694.png)]

不用着急，熟悉的同學可能立馬知道是啥原因了。噓，知道了也聽我慢慢叨叨。

我們打開控制檯，由於表單提交會進行網頁跳轉，因此我們勾選preserve log 來進行日誌追蹤。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-f26Mu4Vr-1586163610224)(https://s3.qiufengh.com/blog/image-20200328191807526.png)]

我們可以發現其實 FormData 中 file 字段顯示的是文件名，並沒有將真正的內容進行傳輸。再看請求頭。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-FhlQbAe6-1586163610227)(https://s3.qiufengh.com/blog/image-20200328192020599.png)]

發現是請求頭和預期不符，也印證了 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>

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-WKXm7ava-1586163610227)(https://s3.qiufengh.com/blog/image-20200328192539734.png)]

發現文件上傳成功，簡單的表單上傳就是像以上一樣簡單。但是你得熟記文件上傳的格式以及類型。

FormData

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>

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-JV1h7sLw-1586163610228)(https://s3.qiufengh.com/blog/image-20200328192539734.png)]

以上幾種方式都是可以的。但是呢，請求庫這麼多，我隨便在 npm 上一搜就有幾百個請求相關的庫。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-k6fOfx3p-1586163610229)(https://s3.qiufengh.com/blog/image-20200328194431932.png)]

因此，掌握請求庫的寫法並不是我們的目標，目標只有一個還是掌握文件上傳的請求頭和請求內容。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-jYPSng0r-1586163610230)(https://s3.qiufengh.com/blog/image-20200328194625420.png)]

Blob

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

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。

Base64

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 調試器。

Buffer

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,這個是我們後端的端口。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-9oqLszl3-1586163610231)(https://s3.qiufengh.com/blog/image-20200328234316233.png)]

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

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-eOPTtskp-1586163610232)(https://s3.qiufengh.com/blog/image-20200328234543643.png)]

我們來找到我們發送的這條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

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-RqblLz0K-1586163610232)(https://s3.qiufengh.com/blog/image-20200328235629308.png)]

就是利用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}\r\nContent-Disposition: form-data; name="file"; filename="1.png"\r\nContent-Type: image/jpeg\r\n\r\n`
);
// 寫入內容
const fileStream = fs.createReadStream(path.join(__dirname, '../1.png'));
fileStream.pipe(request, { end: false });
fileStream.on('end', function () {
    // 寫入尾部
    request.end('\r\n--' + boundaryKey + '--' + '\r\n');
});
request.on('response', function(res) {
    console.log(res.statusCode);
});

至此，已經實現服務端上傳文件的方式。

Stream、Base64

由於這兩塊就是和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 不存在，就會懵逼了，可能也不太清楚它到底做了什麼，文件流又是怎麼解析的。

我還是要說到規範…請求端是按照規範來構造請求…那麼我們接收端自然是按照規範來解析請求了。

Koa-body

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

那麼讓我們繼續深入，來看看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 抓到的包

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-0Qm3SYli-1586163610233)(https://s3.qiufengh.com/blog/image-20200329144355168.png)]

我用紅色進行了分割標記，對應的就是formidable所分割的片段 ，所以說這個包主要是將大段的 buffer 進行分割，然後循環處理。

這裏我還可以補充一下，可能你對以上表非常陌生。左側是二進制流，每1個代表1個字節，1字節=8位，上面的 2d 其實就是16進制的表示形式，用二進制表示就是 0010 1101，右側是ascii 碼用來可視化，但是 assii 分可顯和非可顯示。有部分是無法可視的。比如你所看到文件中有需要小點，就是不可見字符。

你可以對照，ascii表對照表來看。

我來總結一下formidable對於文件的處理流程。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-Pc48zncl-1586163610233)(https://s3.qiufengh.com/blog/formible-process.png)]

原生 Node

好了，我們已經知道了文件處理的流程，那麼我們自己來寫一個吧。

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('\r\n');
        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; // 有多\r\n\r\n
    const startBinary = body.toString().substring(start);
    const end = startBinary.indexOf("--" + boundary + "--") - 2; // 前面有多\r\n
     // 去除後面的分隔符
    const binary = startBinary.substring(0, end);
    const bufferData = Buffer.from(binary, "binary");
    fs.writeFile(fileName, bufferData, function(err) {
      res.end("sucess");
    });
    ;
  })
}

server.listen(7787)

總結

以上所有示例代碼倉庫: https://github.com/hua1995116/node-upload-demo

相信有了以上的介紹，你不再對文件上傳有所懼怕, 對文件上傳整個過程都會比較清晰了，還不懂。。。。找我。

再次回顧下我們的重點:

請求端出問題，瀏覽器端打開 network 查看格式是否正確（請求頭，請求體）, 如果數據不夠詳細，打開wireshark，對照我們的規範標準，看下格式（請求頭，請求體）。

接收端出問題，情況一就是請求端缺少信息，參考上面請求端出問題的情況，情況二請求體內容錯誤，如果說請求體內容是請求端自己構造的，那麼需要檢查請求體是否是正確的二進制流（例如上面的blob構造的時候，我一開始少了一個[]，導致內容主體錯誤）。

其實講這麼多就兩個字: 規範，所有的生態都是圍繞它而展開的。

參考

https://juejin.im/post/5c9f4885f265da308868dad1

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

https://segmentfault.com/a/1190000020654277

更多請關注