《上傳那些事兒之Nest與Koa》——文件格式怎麼了！

2022 年 10 月 27 日
筆記
node, 前端

轉載自：juejin – 馬睿不想說話

概要

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

Blob、File、Buffer與stream

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

Blob

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

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

File

File接口基於 Blob，繼承了 blob 的功能並將其擴展以支持用戶系統上的文件。接口提供有關文件的信息，並允許網頁中的 JavaScript 訪問其內容，且可以用在任意的 Blob 類型的 context 中。

需要注意的一點是，File並沒有任何定義方法，而是只從Blob繼承了slice方法。

Buffer

Buffer是數據以二進制形式臨時存放在內存中的物理映射。在Nodejs中，Buffer類是用於直接處理二進制數據的全局類型。它可以以多種方式構建。

stream

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

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

開發前的規劃

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

獲取前端上傳的文件
處理文件後，調用內部服務上傳至cdn

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

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

只有在考慮清楚了以上這些內容的處理之後，才應該來考慮我們接口本身的業務邏輯的完善與開發。

開發中的問題

由於一些內部原因，Node端的開發經歷了從koa2到express的重構。所以針對兩個框架的文件處理，我也都有幸（bushi）全都經歷了一次。

node上傳格式

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

koa2

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

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

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

由於上傳後的文件經過了koa的處理，所以我們得到的WriteStream的path發生了一些變化，他變成了內存中的一個地址導致我們轉化之後的文件名稱也發生了變化，變成了一個內存中的地址串。

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

1. 使用koa-body的配置參數，進行地址轉存。

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

2. 使用fs將文件轉存至本地，上傳完成後再進行刪除

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重新生成新名稱，也不願意直接使用內存地址作為文件名稱呢？

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

NestJS➕express

由於一些公司內部的歷史原因，導致在使用koa2的開發過程中，缺少了一些swagger相關的功能實現。不得不使用NestJS+express來重構整個項目😭😭😭

而在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中的其他非文件參數
  // query為請求中的Query參數
  console.log(file, body, query);
  return "上傳成功";
}

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

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

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); // 上傳完成後，移除本地文件

文件格式校驗

在解決了文件上傳邏輯以及格式轉換的問題後，我們再回過頭來看一下是不是所有文件類型都允許上傳至我們的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
  };
}

總結

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

我們的node服務中獲取到的前端上傳的文件到底是什麼格式？

我們進行上傳oss/cdn的接口，需要我們上傳的文件格式又是什麼樣的？

文件名稱如何保持不變/如何進行混淆？

如何完成文件格式的校驗或過濾？

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

弄清楚我們獲取到的類型與我們最終需要的類型到底是什麼；
學習好不同文件類型之間的關係與轉換方式；
想明白我們最終要上傳的文件以一個什麼樣的名字來進行上傳；
做好文件類型的白名單控制
杜絕慣性思維，了解清楚不同框架/技術棧之間到底有什麼不同，再着手邏輯的開發。

參考文獻

Blob – Web API 接口參考 | MDN

File – Web API 接口參考 | MDN

Stream | Node.js v15.14.0 Documentation

Buffer | Node.js v15.14.0 Documentaion

NestJS – 攔截器

NestJS – 文件上傳

Tags: node 前端