让我们以multipart/form-data taken from w3.com：
Content-Type: multipart/form-data; boundary=AaB03x
--AaB03x
Content-Disposition: form-data; name="submit-name"
Larry
--AaB03x
Content-Disposition: form-data; name="files"; filename="file1.txt"
Content-Type: text/plain
... contents of file1.txt ...
--AaB03x--
这很简单，但是假设您正在编写实现此功能的代码并从头开始创建这样的请求。我们假设file1.txt是由用户创建的，我们无法控制其内容。
如果文本文件file1.txt包含字符串--AaB03x怎么办？您可能会随机生成边界AaB03x，但我们假设"million monkeys entering a million web forms"场景。
是否有标准方式处理这种不可能但仍然可能的情况？
text/plain（甚至可能是image/jpeg或application/octet-stream之类的内容）应该以某种方式“编码”或“转义”内的某些信息？
或者开发人员是否应该始终搜索文件的内容以获取边界，然后反复继续选择一个新的随机生成的边界，直到在文件中找不到所选的字符串？
答案 0 :(得分：10)
HTTP委托MIME RFC在此处定义multipart/类型。规则列于RFC 2046 section 5.1。
RFC只是声明边界不得出现：
边界 分隔符不得出现在任何封装的部分内 单独行或作为任何行的前缀。这意味着它是 组成代理能够选择和指定一个至关重要的 唯一的边界参数值，不包含边界 封闭多部分的参数值作为前缀。
和
注意：因为边界分隔符不得出现在身体部位 被封装后，用户代理必须谨慎选择 唯一的边界参数值。中的边界参数值 上面的例子可能是设计的算法的结果 产生边界分隔符的概率非常低 存在于要封装的数据中而不必预先扫描 数据。替代算法可能导致更“可读”的边界 具有旧用户代理的收件人的分隔符，但需要 更多关注边界定界符的可能性 出现在封装部分的某一行的开头。该 最简单的边界定界线可能是“---”， 带有“-----”的闭合边界定界线。
大多数MIME软件只是生成一个随机边界，使得边界中出现边界的概率在统计上不太可能;例如碰撞可能会发生，但这种情况发生的概率很低，不可行。计算机UUID values依赖于同样的原则;如果你在一年内产生几万亿UUID，那么产生两个相同UUID值的概率与被陨石击中的人大致相同，两者都有170亿的机会。
请注意，您通常将二进制数据编码为某种形式的ASCII安全编码，例如base64，这是一种不包含破折号的编码，消除了二进制数据包含边界的可能性。
因此，处理这种可能性的标准方法是简单地使可能性几乎不可能。如果您有更大的机会将电子邮件存储在被陨石击中，为什么还要担心MIME边界？