【发布时间】：2012-11-18 21:53:44
【问题描述】：
我正在尝试在 HTTP 服务器上实现 RFC 2388 以支持多部分 POST。
我正在专门查看内容处置的“名称”参数的规范。
根据 RFC 2388 的第 3 节，它指出：
最初采用非 ASCII 字符集的字段名称可能会被编码 使用标准方法在“name”参数的值内 在 RFC 2047 中描述。
我“听说”目前没有 UA 在表单控件名称上支持 RFC2047。他们只会以原始编码发送文本。 （即，如果表单控件的名称是使用 UTF-8 的日语，它将发送多部分 POST 请求，其中包含 UTF-8 中的日语文本）
但是，为了“忠实”，这总有一天会得到解决。我更喜欢坚持 RFC。
不过，问题来自 RFC 2047 本身。根据第 5(3) 条规定：
- “编码字”不得出现在“地址规范”的任何部分。
- “编码词”不得出现在“引用字符串”中。
- 不得在 Received 标头字段中使用“编码字”。
- 不得在 MIME 的参数中使用“编码字” Content-Type 或 Content-Disposition 字段，或任何结构化的 字段正文，“评论”或“短语”内除外。
冲突在第 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 文件名？
【问题讨论】：
标签： java http webserver mime non-ascii-characters