8

我正在尝试在 HTTP 服务器上实现 RFC 2388 以支持多部分 POST。

我正在专门查看内容处置的“名称”参数的规范。

根据 RFC 2388 的第 3 节，它指出：

最初在非 ASCII 字符集中的字段名称可以使用 RFC 2047 中描述的标准方法在“名称”参数的值内编码。

我“听说”目前没有 UA 在表单控件名称上支持 RFC2047。他们只会以原始编码发送文本。（即，如果表单控件的名称是使用 UTF-8 的日语，它将发送带有 UTF-8 日语文本的多部分 POST 请求）

然而，为了“忠实”，这总有一天会得到解决。我更喜欢坚持 RFC。

不过，问题来自 RFC 2047 本身。根据第 5(3) 条规定：

  • “编码字”不得出现在“地址规范”的任何部分。
  • “编码字”不得出现在“引用字符串”中。
  • 'encoded-word' 不得在 Received 头字段中使用。
  • 'encoded-word' 不得用于 MIME Con​​tent-Type 或 Content-Disposition 字段的参数中，或任何结构化字段正文中，“comment”或“phrase”除外。

冲突在第 4 个要点。鉴于“名称”参数是“内容处置”字段的一部分。我发现自己迷失了规范希望我们实现者做什么。

无论什么在“现实”中有效/无效。我想问是否有人也认为这是一个冲突。

我发现自己也在问为什么 RFC 2388 仍然将 RFC 2047 称为“名称”参数，但仅在几段之后将 RFC 2231 称为“文件名”参数的编码规范。鉴于 RFC 2047 不能用于“参数值”，这就是显然创建 RFC 2231 的原因。RFC 2388 是否也没有更新，以便“名称”参数使用 RFC 2231。

底线是，我应该，还是不应该为了实现 RFC 2388 的功能而完全执行 RFC 2047？我是否也应该为“文件名”参数烦恼 RFC 2231？有人知道任何 UA 当前是否使用 RFC 2231 来上传非 ascii 文件名？

4

1 回答 1

2

我真的不认为这是冲突。请注意，RFC 2047

描述...允许在RFC 822 消息头的各个部分中对非 ASCII 文本进行编码的技术，其方式不太可能混淆现有的消息处理软件。

RFC 2388 并没有尝试导入 RFC 2047 的所有假设/上下文，只是编码方法。因为这里编码的“部分”实际上是顶级“multipart/form-data”部分的子级，所以我认为尝试将有关邮件标头的 RFC 2047 规则应用于这些部分是没有意义的。

于 2013-03-25T06:03:24.530 回答