我正在尝试在HTTP服务器上实现RFC 2388以支持多部分POST。
我正在专门针对content-disposition的“name”参数查看规范。
根据RFC 2388的第3部分，它声明：
最初在非ASCII字符集中的字段名称可以被编码 使用标准方法在“name”参数的值内 在RFC 2047中描述。
我已'听说'UA目前在表单控件名称上不支持RFC2047。他们只需以原始编码发送文本。 （即如果表单控件的名称是使用UTF-8的日语，它将发送带有UTF-8的日文文本的多部分POST请求）
然而，为了“忠实”，这有一天会得到解决。我更喜欢坚持使用RFC。
但问题来自RFC 2047本身。根据第5（3）条规定：
- '编码字'不得出现在'addr-spec'的任何部分。
- “编码字”绝不能出现在“引用字符串”中。
- “已编码的单词”不得在“已接收的标题”字段中使用。
- 不得在MIME的参数中使用'encoded-word' Content-Type或Content-Disposition字段，或任何结构化字段 除了'评论'或'短语'之外的字段正文。
冲突发生在第4点。鉴于'name'参数是“content-disposition”字段的一部分。我发现自己已经失去了规范要求我们实施者做什么。
无论什么在“现实”中起作用/不起作用。我想问一下是否有人发现这也是冲突。
我发现自己也在问为什么RFC 2388仍然将RFC 2047称为“name”参数，但稍后只有几段后面将RFC 2231称为“filename”参数的编码规范。鉴于RFC 2047不能用于“参数值”，这就是显然创建RFC 2231的原因。 RFC 2388是否也未更新，因此“name”参数使用RFC 2231。
底线是，我应该，还是应该为实现RFC 2388的功能而无法实施RFC 2047 AT ALL？我是否还应该为RFC 2231打扰'filename'参数？有没有人知道任何UAs目前是否使用RFC 2231来上传非ascii文件名？
答案 0 :(得分：2)
我并不认为这是冲突。请注意RFC 2047
描述了允许在 RFC 822消息头的各个部分中编码非ASCII文本的技术，其方式不太可能混淆现有的消息处理软件。
RFC 2388并未尝试导入RFC 2047的所有假设/上下文，而只是导入编码方法。因为这里编码的“部分”实际上是顶级“multipart / form-data”部分的子代，所以我认为尝试将RFC 2047的规则应用于这些部分的邮件消息头是不合理的。