跳到主要内容

5.1. 非 ASCII 字段名称和值

5.1. Non-ASCII Field Names and Values (非 ASCII 字段名称和值)​

通常, multipart body 中的 MIME header field 要求只由 US-ASCII 字符集中的 7 位数据组成. 虽然 [RFC2388] 建议按照 [RFC2047] 中的方法对非 ASCII 字段名称编码, 但这种做法似乎没有被广泛遵循.

本规范针对三种不同的工作流程状态提出三组建议.

5.1.1. Avoid Non-ASCII Field Names (避免非 ASCII 字段名称)​

为了与现有已部署软件获得最广泛的互操作性, 创建表单者 SHOULD 避免使用非 ASCII 字段名称. 这通常不会成为负担, 因为字段名称一般对用户不可见. 底层字段名称不需要与用户在屏幕上看到的内容一致.

如果无法避免非 ASCII 字段名称, 表单或应用创建者 SHOULD 统一使用 UTF-8. 这会尽量减少互操作性问题.

5.1.2. Interpreting Forms and Creating multipart/form-data Data (解释表单并创建 multipart/form-data 数据)​

本规范的某些应用会提供一个字符编码, 用于解释 multipart/form-data body. 具体而言, HTML 5 [W3C.REC-html5-20141028] 使用:

  • "charset" 字段的内容, 如果存在;
  • <form> 元素的 accept-charset 属性值, 如果存在;
  • 包含表单的文档字符编码, 如果它与 US-ASCII 兼容;
  • 否则使用 UTF-8.

将此值称为 form-charset. 任何文本, 无论是字段名称, 字段值, 还是使用 ASCII 范围外字符的 "text/plain" form data, MAY 直接以 form-charset 编码表示.

5.1.3. Parsing and Interpreting Form Data (解析和解释表单数据)​

虽然本规范为创建 multipart/form-data 提供指导, 但解析器和解释器应意识到各种实现差异. 例如, 文件系统在是否以及如何规范化 Unicode 名称方面有所不同. 表单元素与 form-data part 的匹配可能依赖更模糊的匹配. 特别是, 某些 multipart/form-data 生成器可能遵循 [RFC2388] 先前建议, 并使用 [RFC2047] 中描述的 "encoded-word" 方法对非 ASCII 值编码:

encoded-word = "=?" charset "?" encoding "?" encoded-text "?="

已知其他实现会遵循 [RFC2231], 发送未编码的 UTF-8, 甚至发送以 form-charset 编码的字符串.

因此, 在未提供 charset 字段值或 "text/plain" Content-Type header field 的 charset 参数时, 解释 multipart/form-data 即使来自符合规范的生成器, 也可能需要知道表单编码中使用的字符集.

最后于 更新