如果您更仔细地阅读 RFC 7233，附录 A参考RFC 2046 第 5.1 节，了解 HTTP 正文中 MIME 数据的实际格式：
当 206（部分内容）响应消息包含多个范围的内容时，它们将作为多部分消息正文（[RFC2046]，第 5.1 节）中的正文部分传输，媒体类型为“multipart/byteranges”。
RFC 2046 第 5.1 节定义了“多部分”媒体类型的正式定义以及如何格式化和解析其边界。
要回答您的问题，以下是 RFC 2046 的正式语法：
边界分隔符必须出现在行首，即
在 CRLF 之后，并且初始 CRLF 被认为是附加的
到边界分隔线而不是前面的部分
部分。边界后面可以跟零个或多个字符
线性空白。然后由另一个 CRLF 和
下一部分的标题字段，或两个 CRLF，在这种情况下
下一部分没有标题字段。如果没有 Content-Type
字段存在，它被假定为“消息/rfc822”
否则为“multipart/digest”和“text/plain”。
注意：边界分隔线之前的 CRLF 在概念上是
附着在边界上，这样就可以有一个部分
不以 CRLF（换行符）结尾。必须的身体部位
被认为以换行符结尾，因此，必须有两个 CRLF
在边界分隔线之前，其中第一个是
前面的身体部分，第二个是身体的一部分
封装边界。
...
最后一个正文部分之后的边界分隔线是
可区分的分隔符，指示没有其他正文部分
将遵循。这样的分隔线与前面的相同
分隔线，在后面加上两个连字符
边界参数值。
--gc0pJq0M:08jU534c0p--
对实施者的注意：边界字符串比较必须比较
边界值与每个候选行的开头。一个准确的
不需要匹配整个候选行；就足够了
边界完全出现在 CRLF 之后。
...
“multipart”媒体类型的唯一强制性全局参数是
边界参数，由 1 到 70 个字符组成
已知通过邮件网关非常健壮的字符集，以及
不以空格结尾。（如果边界分隔线出现在
以空格结尾，必须假定空格是
由网关添加，必须删除。）正式规定
通过以下 BNF：
边界 := 0*69 bcharsnospace
bchars := bcharsnospace / " "
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
“+”/“_”/“”/“-”/“.” /
“/”/“:”/“=”/“？”
总体而言，“多部分”实体的主体可以指定为
如下：
dash-boundary := "--" 边界
; 取自值的边界
; 的边界参数
; 内容类型字段。
multipart-body := [序言 CRLF]
破折号边界传输填充 CRLF
身体部分 *封装
封闭分隔符传输填充
[CRLF 结语]
传输填充 := *LWSP-char
; 作曲家不得生成
; 非零长度传输
; 填充，但接收者必须
; 能够处理填充
; 由消息传输添加。
封装 := 分隔符传输填充
CRLF 身体部位
delimiter := CRLF 破折号边界
close-delimiter := 分隔符“--”
序言：=丢弃文本
结语：=丢弃文本
丢弃文本 := *(*text CRLF) *text
; 可以忽略或丢弃。
body-part := MIME-part-headers [CRLF *OCTET]
; 正文部分中的行不得开始
; 具有指定的虚线边界和
; 分隔符不得出现在任何地方
; 在身体部位。请注意，
; 身体部位的语义不同于
; 消息的语义，如
; 文中描述。
OCTET := <任何 0-255 字节值>
新部分开头的每个定界符都由 CRLF 终止，并且紧接在定界符之前的任何 CRLF 都被解析为边界的一部分，而不是前一部分的数据。但是，最终结束边界的末尾没有 CRLF，除非存在结语（这在电子邮件中很少使用，而且我从未见过它在 HTTP 中使用，因为无法确定结语何时结束除非存在有效的Content-Length标头，它不应该与 MIME 等自终止内容类型一起使用）。