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