如果表单数据边界包含在附件中怎么办？

让我们看下面的例子multipart/form-data 取自 w3.com http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2:

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随机，但我们假设“百万只猴子进入一百万个网络表单” http://en.wikipedia.org/wiki/Infinite_monkey_theorem设想。

有没有standard如何处理这种不太可能但仍然可能发生的情况？

应该text/plain（或者甚至可能是类似的东西image/jpeg or application/octet-stream）被“编码”或以某种方式“转义”中的某些信息？

或者开发人员是否应该始终在文件内容中搜索边界，然后重复选择新的随机生成的边界，直到在文件中找不到所选字符串？

HTTP 委托给 MIME RFC 来定义multipart/在这里输入。规则规定在RFC 2046 第 5.1 节 https://www.rfc-editor.org/rfc/rfc2046#section-5.1.

RFC 简单地规定边界不得出现：

边界 分隔符不得出现在任何封装部分内 行本身或作为任何行的前缀。这意味着它是 至关重要的是，组成代理能够选择并指定一个 不包含边界的唯一边界参数值 封闭多部分的参数值作为前缀。

and

注意：因为边界分隔符不能出现在正文部分中 被封装后，用户代理必须谨慎选择 唯一的边界参数值。中的边界参数值 上面的例子可能是一个算法的结果 产生边界定界符的概率非常低 存在于要封装的数据中，而无需预先扫描 数据。替代算法可能会产生更“可读”的边界 具有旧用户代理的收件人的分隔符，但需要 更多地关注边界定界符可能 出现在封装部分中某行的开头。这 最简单的边界分隔线可能是类似“---”， 结束边界分隔线为“-----”。

大多数 MIME 软件只是生成一个随机边界，使得该边界出现在部件中的概率为统计上不太可能;例如碰撞可能会发生，但发生的可能性很低，以至于不可行。电脑UUID 值 http://en.wikipedia.org/wiki/Universally_unique_identifier依赖相同的原则；如果您在一年内生成几万亿个 UUID，则生成两个相同 UUID 值的概率与某人被陨石击中的概率大致相同，两者的概率均为 170 亿分之一。

请注意，您通常将二进制数据编码为某种形式的 ASCII 安全编码，例如 base64，这是一种不包含破折号的编码，从而消除了二进制数据包含边界的可能性。

因此，处理这种可能性的标准方法就是简单地让这种可能性变得几乎不可能。如果存储电子邮件的计算机更有可能被陨石击中，为什么还要担心 MIME 边界呢？