Content-Type里的boundary参数是什么：多部分表单请求怎么分段

如果你在请求头里看到 Content-Type: multipart/form-data; boundary=something，这里的 boundary 不是媒体类型，也不是字符编码，它是给这次请求里各段内容起的一个分隔标记名。

按 MDN 的 Content-Type 说明，对于多部分实体，必须使用 boundary 指令。它用于封装信息多个部分的边界。也就是说，multipart/form-data 表示“这个请求由多段组成”，boundary 则告诉接收方“每段之间用哪串字符隔开”。

所以读这个头要分两层：斜杠前的 multipart 和斜杠后的 form-data 说明这是多段表单数据；分号后面的 boundary=... 给出分隔用的字符串。两者缺一不可，只有 multipart/form-data 而没有 boundary，接收方就不知道从哪里切段。

本文只讲这个参数的语法要求和分段标记怎么读，不讲文件上传代码，也不涉及其他主题。下面所有请求样例都是自建的练习数据，用于说明格式，不是对某个真实站点的抓包记录。

boundary 的值不是随便写什么都行。按 MDN 的说明，该指令由 1 至 70 个字符组成，这些字符选自一套已知能通过电子邮件网关的、非常健壮的字符集，并且不以空白字符结束。

这句话给出三条可核对的限制：

1. 长度在 1 到 70 个字符之间，不能为空，也不能超长。

2. 字符来自一套“健壮”的字符集，目的是让这串标记能安全穿过邮件网关这类中间环节。

3. 结尾不能是空白字符，比如空格、制表符。

资料没有逐字列出这套字符集包含哪些字符，也没有给出生成规则。所以本文不替你补一份“允许字符清单”，只说明这三条限制本身。实际写练习样例时，用字母、数字和连字符这类常见字符即可，避免在结尾留空格。

一个自建示例（练习数据，不是真实请求）：把 boundary 写成 boundary=demoBoundary123，这串值以数字结尾，不以空白结尾，长度也在范围内。

boundary 的值本身只是名字，真正出现在请求体里的分隔标记要在它前面加两个破折号。按 MDN 的说明，通常情况下，开头的边界前会加上两个破折号，而末尾边界的后面也会加上两个破折号。

这句话可以拆成两种标记：

- 段与段之间的分隔行：两个破折号加 boundary 值，例如 --demoBoundary123。

- 整个请求体的结束行：两个破折号加 boundary 值，再加两个破折号，例如 --demoBoundary123--。

所以读请求体时，先看请求头里 boundary 写的是什么，再在请求体里找“两个破折号加这串值”的行。找到的行就是分段点；末尾那行多出两个破折号，表示后面没有更多段了。

一个容易混淆的点：请求头里写的是 boundary=demoBoundary123，请求体里出现的是 --demoBoundary123，两者不是写错了，而是头里给名字、体里用加破折号的形式引用这个名字。boundary 值本身也可以包含连字符，例如 MDN 示例里的 boundary 值就是一长串连字符加数字；无论值里有多少连字符，请求体里都要在它前面再加两个破折号。

下面是一份自建的练习请求，用于说明各段的位置关系。它不是对某个真实站点的记录，字段名和值都是练习数据。

POST /exercise/submit HTTP/1.1
Content-Type: multipart/form-data; boundary=demoBoundary123

--demoBoundary123
Content-Disposition: form-data; name="note"

练习文本
--demoBoundary123
Content-Disposition: form-data; name="label"

示例标签
--demoBoundary123--

按这个样例，读的顺序是：

1. 先看请求头那一行，拿到 boundary 的值 demoBoundary123。

2. 在请求体里找 --demoBoundary123 这一行，它把第一段和第二段分开。

3. 每一段内部先写该段的头部（例如 Content-Disposition），空一行后写这一段的内容。

4. 最后一行是 --demoBoundary123--，两个破折号收尾，表示请求体到此结束。

这个样例里有两段内容，所以出现了两次中间分隔行，加一次结尾行。段数增加，中间分隔行就相应增加，结尾行始终只有一行。

分段标记只负责“切开”，切开之后每一段自己还有固定结构。按 MDN 示例，每一段先出现 Content-Disposition: form-data; name="字段名"，如果是文件，还会带 filename 参数和该段的 Content-Type。

把 MDN 示例的结构抽象出来，一段大致是：

--demoBoundary123
Content-Disposition: form-data; name="note"

练习文本

这里有三层：第一行是分隔标记；分隔标记之后是该段的头部，说明这段对应哪个字段；头部之后是一个空行，用来把段头和内容隔开；空行之后才是这段的实际内容。

读的时候要抓住空行这个分界。段头里的 name 告诉你这段填的是哪个字段，空行之后的内容才是这个字段的值。资料示例中，文件那一段还多一个 Content-Type: text/plain，说明该段内容的类型；普通文本段没有这一行。

需要说明的是，资料没有规定段头字段的排列顺序，也没有给出每段内容长度的限制。本文不补这些内容。

拿到一份 multipart/form-data 请求，可以按下面三处核对，任何一处对不上，就说明分段标记没读对：

1. 请求头里的 boundary 值和请求体里的分隔行是否一致。头里写 demoBoundary123，体里却出现另一串字符，说明两者不匹配。

2. 中间分隔行是否都以两个破折号开头。少了破折号，那一行就不符合资料描述的“开头边界前加两个破折号”的写法。

3. 结尾行是否以两个破折号收尾。没有结尾行，就不符合资料描述的“末尾边界后加两个破折号”的写法。

这三项是编辑整理的核对顺序，不是官方检测流程。资料只说明了 boundary 的组成和破折号的加法规矩，没有给出一份“错误码清单”，也没有说明接收方遇到格式偏差时会怎么处理，所以本文不列具体报错信息，也不推断解析后果。

一个自建示例（练习数据）：如果你把结尾行误写成 --demoBoundary123（少了后面两个破折号），按上面的第 3 项核对就能发现它和中间分隔行长得一样，无法区分“还有下一段”和“到此结束”。

关于 boundary，资料能支持的范围是：它是 multipart 实体必须带的指令，由 1 至 70 个字符组成，字符选自一套健壮字符集，不以空白结尾；请求体里开头边界前加两个破折号，末尾边界后再加两个破折号。

资料没有写的内容包括：boundary 的具体生成算法、字符集的完整清单、各段头部字段的排列规则、内容长度上限，以及不同服务器对格式偏差的容忍程度。这些本文都不补，也不编造数值。

还有一点要分清：本文讲的是请求体怎么分段，不涉及用代码构造或发送这类请求，也不涉及文件上传的实现。如果你要动手练习，建议只在练习目录里新建文本文件，例如 exercise/ 下的自建请求样例，不要拿正在使用的表单或接口直接改。

参考资料：MDN 的 Content-Type 说明页，见下方 source。