node-red的http-request组件调研三方接口请求参数为form-data解决方案

一、问题描述

node-red的http-request组件可以请求三方接口，但是如果该接口输入参数格式是form-data，则会传参失败。

二、解决方案

1、网上很多方案是用function构建一个form-data格式请求参数，测试下来均无效。

// 设置 form-data 格式的 payload
msg.payload = {
    "id": "6",
    "token": "XXXXXXXXXXXXXXXXXXXXXX",
    "snids": "34|35|36",
    "playmode": "1",
    "jiange": "1",
    "fileids": "16",
    "len": "0"
};

// 设置 headers
msg.headers = {};
msg.headers["Content-Type"] = "multipart/form-data";

return msg;

2、最终修改为如下成功传参并返回结果。

// 构造请求体
msg.payload = {
    id: '6',
    token: 'XXXXXXXXXXXXXXXXXXXXXX',
    snids: '34|35|36',
    playmode: '1',
    jiange: '1',
    fileids: '16',
    len: '0'
};
// 设置请求头
msg.headers = {
    'Content-Type': 'application/x-www-form-urlencoded'
};
return msg;

三、对比说明

HTTP 请求中（尤其是表单提交 POST 或 PUT），application/x-www-form-urlencoded 和 multipart/form-data 是两种主要的 Content-Type。以下是它们的核心区别：

application/x-www-form-urlencoded

1. 编码规则：

• 数据被编码为 key=value 对，用 & 连接（如 name=John+Doe&email=john%40example.com）。
• 空格转为 +，特殊字符（如 @, !, 中文字符）转为 %XX 形式的百分号编码。

2. 优势：

• 简单通用，所有服务器都支持。
• 适合小型文本数据（如登录表单）。

3. 劣势：

• 编码后数据体积显著增大（如 @ 变成 %40）。
• 无法直接传输二进制数据（如文件）。

multipart/form-data

1. 编码规则：

• 数据被分成多个 Part（部分），每部分用随机生成的 boundary 分隔（如
  ------WebKitFormBoundary7MA4YWxkTrZu0gW）
• 每个 Part 包含独立的 Content-Disposition 头部（指定字段名）、Content-Type（如文件类型），后跟原始数据。

2. 优势：

• 支持文件上传（二进制数据保持原样，无额外编码开销）。
• 适合传输大型数据（如图片、视频）。

3. 劣势：

• 数据结构复杂，处理稍慢。
• 请求体积略大（因包含边界标记和头部信息）。