概要

本文主要針對在使用node作為服務端接口時，前端上傳上傳文件至node作為中轉(zhuǎn)，再次上傳至oss/cdn的場景。以及針對在這個過程中，需要對同一個文件進行不同形式之間轉(zhuǎn)換的問題。

Blob、File、Buffer與stream

在解答上述問題之前，我們要先了解一下Blob、File、Buffer與stream這四者分別是什么。以及這四者的關(guān)系是什么樣的。

Blob

Blob 對象表示一個不可變、原始數(shù)據(jù)的類文件對象。

這是MDN對Blob的說明。簡而言之，所有的“數(shù)據(jù)”都可以用blob的格式進行存儲，而且不一定是 JavaScript 原生格式的數(shù)據(jù)。包括但不僅限于文本、二進制、文檔流等。而通過Blob的實例方法（Blob.prototype.arrayBuffer()、Blob.prototype.stream()），我們還可以將blob轉(zhuǎn)換為Buffer和ReadableStream。

File

File接口基于 Blob，繼承了 blob 的功能并將其擴展以支持用戶系統(tǒng)上的文件。接口提供有關(guān)文件的信息，并允許網(wǎng)頁中的 JavaScript 訪問其內(nèi)容，且可以用在任意的 Blob 類型的 context 中。

需要注意的一點是，F(xiàn)ile并沒有任何定義方法，而是只從Blob繼承了slice方法。

Buffer

Buffer是數(shù)據(jù)以二進制形式臨時存放在內(nèi)存中的物理映射。在Nodejs中，Buffer類是用于直接處理二進制數(shù)據(jù)的全局類型。它可以以多種方式構(gòu)建。

stream

Node.js 中有四種基本的流類型：

• Writable: 可以寫入數(shù)據(jù)的流（例如， fs.createWriteStream()）。
• Readable：可以從中讀取數(shù)據(jù)的流（例如， fs.createReadStream()）。
• Duplex: 兩者都是Readable和的流Writable（例如， net.Socket）。
• Transform：Duplex可以在寫入和讀取數(shù)據(jù)時修改或轉(zhuǎn)換數(shù)據(jù)的流（例如，zlib.createDeflate()）。

開發(fā)前的規(guī)劃

在我們進行文件上傳的過程中，經(jīng)歷了兩個階段：

1. 獲取前端上傳的文件
2. 處理文件后，調(diào)用內(nèi)部服務上傳至cdn

其實這樣看來的話，這是很簡單的兩個階段，我們只需要拿到前端的文件后傳遞給另外一個接口就可以了，可是在這個過程中，有幾個我們不得忽視的問題：

1. 我們的node服務中獲取到的前端上傳的文件到底是什么格式？
2. 我們進行上傳oss/cdn的接口，需要我們上傳的文件格式又是什么樣的？
3. 文件名稱如何保持不變/如何進行混淆？
4. 如何完成文件格式的校驗或過濾？

只有在考慮清楚了以上這些內(nèi)容的處理之后，才應該來考慮我們接口本身的業(yè)務邏輯的完善與開發(fā)。

開發(fā)中的問題

由于一些內(nèi)部原因，Node端的開發(fā)經(jīng)歷了從koa2到express的重構(gòu)。所以針對兩個框架的文件處理，我也都有幸（bushi）全都經(jīng)歷了一次。

node上傳格式

由于上傳至oss的第三方接口可以在前端調(diào)用，也可以在node中進行調(diào)用，所以在Postman中可以模仿上傳過程，由此可以看到第三方接口真正需要我們傳入的其實是一個ReadStream格式的文件。
所以我們的目標也很簡單，那就是無論我們獲取到什么格式的文件，都轉(zhuǎn)換成為ReadStream格式即可。

image.png

koa2

不同于在koa中使用koa-bodyparser模塊來完成post請求的處理；在koa2中，使用koa-body模塊不僅可以完成對于post請求的處理，同時也能夠處理文件類型的上傳。

在這種情況下我們只需要通過ctx.request.files即可訪問前端上傳給我們的文件實例，同時我們可以看到我們獲取到的是一個WriteStream格式的文件。通過size、name、type等屬性，即可獲取相應的屬性，用于進行文件格式的校驗與判斷。

當我直接使用fs.createReadStream方法將它轉(zhuǎn)換為我們所需要的格式時，問題也隨之而來：

由于上傳后的文件經(jīng)過了koa的處理，所以我們得到的WriteStream的path發(fā)生了一些變化，他變成了內(nèi)存中的一個地址導致我們轉(zhuǎn)化之后的文件名稱也發(fā)生了變化，變成了一個內(nèi)存中的地址串。

很顯然，這是我們不想要看到的，因為這對于我們來說是不可控的。為了解決這個問題，我嘗試了兩種解決方式均有效，大家可以自行選擇。

1. 使用koa-body的配置參數(shù)，進行地址轉(zhuǎn)存。

app.use(body({
    multipart: true,
    formidable:{
        // 上傳存放的路勁
        uploadDir: path.join(__dirname,'./temp'),
        // 保持后綴名\
        keepExtensions: true,
        onError(err){
           console.log(err)
        }
    }
})); 

2. 使用fs將文件轉(zhuǎn)存至本地，上傳完成后再進行刪除

import * as fs from 'fs';

const file = ctx.request.files.file;
// 通過originalname獲取文件原名稱
const newName = file.originalname;
fs.writeFileSync(newName, file.path);
const newFile = fs.createReadStream(newName);
// 使用newFile進行文件上傳。。。
fs.rmSync(newName);

在處理文件名稱的過程中也可以手動的使用uuid來進行名稱的混淆。有人可能認為，為什么寧愿那么麻煩的獲取原來的名稱、再使用uuid重新生成新名稱，也不愿意直接使用內(nèi)存地址作為文件名稱呢？

很顯然，因為這個流程對于我們來說是可控的。

NestJS?express

由于一些公司內(nèi)部的歷史原因，導致在使用koa2的開發(fā)過程中，缺少了一些swagger相關(guān)的功能實現(xiàn)。不得不使用NestJS+express來重構(gòu)整個項目??????

而在NestJS中的上傳，則需要使用NestJS提供的攔截器UseInterceptors，同時也需要依賴FileInterceptor和UploadedFile來對于單文件上傳的處理。FileInterceptor是攔截器負責處理請求接口后的文件 再使用UploadedFile進行文件接收。

import {  UploadedFile, UseInterceptors, Body, Post, Query } from '@nestjs/common';
import {  FileInterceptor } from '@nestjs/platform-express';

@Post('/upload')
// "file" 表示 上傳文件的鍵名
@UseInterceptors(FileInterceptor('file'))
public async uploadFileUsingPOST(
  @Query() query: any,
  @Body() body: any,
  @UploadedFile() file,
) {
  // body為form/data中的其他非文件參數(shù)
  // query為請求中的Query參數(shù)
  console.log(file, body, query);
  return "上傳成功";
}

由于思維慣性的影響，對于文件的處理產(chǎn)生了先入為主的思想，下意識的認為接口中獲取到的前端上傳文件格式仍然為WriteStream，結(jié)果在處理過程中發(fā)現(xiàn)文件格式變成了Buffer形式的二進制。因此在這個過程中我們就有需要再次處理從Buffer到ReadStream的轉(zhuǎn)換。

而在這個過程中，我順便做了文件名稱的混淆，而我采取的方式也是一個較笨的方式，直接上代碼：

import { v4 } from 'uuid';
import * as fs from 'fs';

// 使用uuid作為文件名稱，并且保留文件后綴
const newName: string = `${v4()}.${file.originalname.split('.')[1]}`;
// 將文件寫入本地
fs.writeFileSync(newName, file.buffer);
// 使用本地文件生成ReadStream
const newFile = fs.createReadStream(newName);
// 生成請求使用的FormData
const formData = new FormData();
formData.append('files[]', newFile);

/**
  POST formData，完成文件上傳
*/
fs.rmSync(newName); // 上傳完成后，移除本地文件

文件格式校驗

在解決了文件上傳邏輯以及格式轉(zhuǎn)換的問題后，我們再回過頭來看一下是不是所有文件類型都允許上傳至我們的oss或cdn上呢？這過程中會不會混入一些我們“不喜歡”的文件。

這里簡單以NestJS的邏輯為例，簡單列舉一下代碼。

import {  UploadedFile, UseInterceptors, Body, Post, Query } from '@nestjs/common';
import {  FileInterceptor } from '@nestjs/platform-express';

@Post('/upload')
@UseInterceptors(FileInterceptor('file'))
public async uploadFileUsingPOST(
  @Query() query: any,
  @Body() body: any,
  @UploadedFile() file,
) {
  // 定義我們允許上傳的文件類型白名單      
  const filterType: string[] = ['image', 'video'];
  const { mimetype } = file;
  // 判斷當前上傳至接口的文件類型是否在白名單中，如果在則允許上傳，不在則返回錯誤信息
  if (filterType.findIndex((f: string) => mimetype.includes(f)) < 0) {
    return {
      result: -1,
      errMessage: "文件格式錯誤，僅支持上傳圖片、動圖或視頻",
      success: false
    };
  }
  return {
    result: 1,
    message: "上傳成功",
    success: true
  };
}

總結(jié)

其實單純就邏輯來講，這是一件很簡單的事情。無非就是我們獲取文件流后用node服務作為“中轉(zhuǎn)站”添加邏輯后再上傳至“終點”。只不過重點還是在于我上面列舉過的四個問題上：

1. 我們的node服務中獲取到的前端上傳的文件到底是什么格式？
2. 我們進行上傳oss/cdn的接口，需要我們上傳的文件格式又是什么樣的？
3. 文件名稱如何保持不變/如何進行混淆？
4. 如何完成文件格式的校驗或過濾？

而解決這四個問題的重點，其實也很簡單：

1. 弄清楚我們獲取到的類型與我們最終需要的類型到底是什么；
2. 學習好不同文件類型之間的關(guān)系與轉(zhuǎn)換方式；
3. 想明白我們最終要上傳的文件以一個什么樣的名字來進行上傳；
4. 做好文件類型的白名單控制
5. 杜絕慣性思維，了解清楚不同框架/技術(shù)棧之間到底有什么不同，再著手邏輯的開發(fā)。

參考文獻

Blob - Web API 接口參考 | MDN

File - Web API 接口參考 | MDN

Stream | Node.js v15.14.0 Documentation

Buffer | Node.js v15.14.0 Documentaion

NestJS - 攔截器

NestJS - 文件上傳