我正在尝试在 HTTP 服务器上实现 RFC 2388 以支持多部分 POST。
我正在专门查看内容处置的“名称”参数的规范。
RFC 2388 第 3 节规定：
最初采用非 ASCII 字符集的字段名称可能会被编码
使用标准方法在“name”参数的值内
RFC 2047 中描述。
我“听说”当前没有 UA 支持表单控件名称上的 RFC2047。他们只会以原始编码发送文本。 （即，如果表单控件的名称是使用 UTF-8 的日语，它将发送带有 UTF-8 日语文本的多部分 POST 请求）
然而，为了“忠实”地相信这一问题有一天会得到解决。我更喜欢坚持 RFC。
但问题来自 RFC 2047 本身。第 5(3) 条规定：
- “编码字”不得出现在“地址规范”的任何部分中。
- “编码字”不得出现在“引用字符串”内。
- “编码字”不得在“已接收”标头字段中使用。
- MIME 参数中不得使用“编码字”
Content-Type 或 Content-Disposition 字段，或任何结构化的
字段主体，“评论”或“短语”内除外。
冲突在于第四个要点。鉴于“名称”参数是“内容处置”字段的一部分。我发现自己不知道规范希望我们实现者做什么。
无论什么在“现实”中有效/无效。我想问是否有人也认为这是一个冲突。
我发现自己也在问为什么 RFC 2388 仍然引用 RFC 2047 作为“名称”参数，但仅在几段之后就引用 RFC 2231 作为“文件名”参数的编码规范。鉴于 RFC 2047 不能用于“参数值”，这就是创建 RFC 2231 的原因。如果 RFC 2388 尚未更新，则“name”参数将使用 RFC 2231。
底线是，我应该还是不应该为了实现 RFC 2388 的功能而费心实施 RFC 2047？我是否还应该为“文件名”参数使用 RFC 2231？有谁知道 RFC 2231 目前是否被任何 UA 使用来上传非 ASCII 文件名？
我真的不认为这是一个冲突。请注意 RFC 2047
描述...允许在文件的各个部分中对非 ASCII 文本进行编码的技术RFC 822 消息头，以不太可能混淆现有消息处理软件的方式。
RFC 2388 并不试图导入 RFC 2047 的所有假设/上下文，而只是导入编码方法。因为此处编码的“部分”实际上是顶级“multipart/form-data”部分的子级，所以我认为尝试将有关邮件消息头的 RFC 2047 规则应用于这些部分是没有意义的。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
