非官方中文译本声明：本页为 IETF RFC 2231《MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations》 的中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布，受 BCP 78 与 IETF 信托法律条款约束；本译本保留原文编号与结构，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc2231。

RFC 2231：MIME 参数扩展

标准跟踪 · N. Freed（Innosoft）、K. Moore（University of Tennessee）· 1997 年 11 月 · 类别：Standards Track（标准跟踪）· 取代 RFC 2184，更新 RFC 2045、RFC 2047、RFC 2183 · ISSN: 2070-1721

本备忘录的状态

本备忘录为互联网社区规定了互联网标准跟踪协议，并请求进行讨论以及提出改进建议。有关本协议的标准化状态与现状，请参考当前版本的《互联网官方协议标准》(STD 1)。本备忘录的分发不受限制。

Copyright (C) The Internet Society (1997)。保留所有权利。

目录

1. 摘要

本备忘录定义了 RFC 2045 媒体类型与 RFC 2183 处置参数值机制的扩展，以提供：

  1. 一种以 US-ASCII 之外的字符集指定参数值的手段；
  2. 指定在显示该值时所用语言的能力；
  3. 用于长参数值的续行机制，以避免报文头换行所带来的问题。

本备忘录还定义了 RFC 2047 中编码字的扩展，以允许同时指定用于显示的语言与字符集。

2. 引言

多用途互联网邮件扩展，即 MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2048, RFC-2049]，定义了一种允许以下内容的报文格式：

  1. 采用 US-ASCII 之外字符集的文本报文主体；
  2. 非文本报文主体；
  3. 多部分报文主体；
  4. 采用 US-ASCII 之外字符集的文本报文头信息。

MIME 现已广泛部署，并被包括互联网电子邮件在内的多种互联网协议所使用。然而，MIME 的成功也带来了对原始协议规范所未能提供的附加机制的需求。

具体而言，现有的 MIME 机制提供了具名的媒体类型（content-type 字段）参数以及具名的处置（content-disposition 字段）参数。一个 MIME 媒体类型可以为其所有子类型指定任意数量的关联参数，而任何特定子类型也可以为其自身用途指定额外的参数。一个 MIME 处置值可以指定任意数量的关联参数，其中最重要的可能就是附件处置的 filename 参数。

这些参数名与参数值最终会出现在互联网电子邮件的 content-type 与 content-disposition 报文头字段中。这天然带来了三个关键限制：

  1. 互联网电子邮件报文头字段按照 RFC 822 的换行规则进行折叠。这使得长参数值成为问题。
  2. MIME 报文头，如同它们经常出现于其中的 RFC 822 报文头一样，被限制在 7 位 US-ASCII 之内，而 RFC 2047 的编码字机制对参数值是不可用的。这使得在不指定某种私有的逐参数编码的情况下，不可能拥有 US-ASCII 之外字符集的参数值。
  3. 近来已经明确，字符集信息对于正确显示某些类别的信息是不够的——语言信息同样需要 [RFC-2130]。例如，对残障用户的支持可能需要将文本字符串朗读出来。要正确地做到这一点，需要知道文本所用语言。某些参数值可能需要显示，因此需要允许包含语言信息。

该列表中的最后一个问题对于 RFC 2047 所定义的编码字而言同样是个问题，因为编码字主要就是为显示目的而设计的。

本备忘录定义了解决所有这些限制的扩展。所有这些扩展都以与现有 MIME 实现在句法层面完全兼容的方式实现。此外，这些扩展的设计力求对 MIME 的现有用法产生尽可能小的影响。

重要提示：这些机制在实际使用时往往显得有些笨重。因此，不应轻率地使用这些机制；它们应保留给确实存在真实需求的场合。

2.1. 需求符号说明

本备忘录偶尔会使用以大写字母出现的术语。当术语 "MUST（必须）"、"SHOULD（应该）"、"MUST NOT（不得）"、"SHOULD NOT（不应该）" 与 "MAY（可以）" 以大写出现时，它们被用来指示本规范的特定要求。关于这些术语含义的讨论见 [RFC-2119]。

3. 参数值续行

长的 MIME 媒体类型或处置参数值与报文头换行约定不能很好地配合。具体而言，正确的报文头换行依赖于存在允许出现线性空白（LWSP）的位置，而这样的位置在参数值中可能不存在，即便存在也可能无法被识别为空白，因为执行换行的代理未必掌握参数值语法的具体知识。其结果是，长的参数值可能会被不正确的换行实现所截断或以其他方式损坏。

因此，需要一种机制将参数值拆分为更适于换行的较小单元。任何此类机制都必须与现有的 MIME 处理程序兼容。这意味着：

  1. 该机制不得改变 MIME 媒体类型与处置行的语法；且
  2. 该机制不得依赖于参数顺序，因为 MIME 声明参数是不区分顺序的。注意，尽管 MIME 确实禁止在传输过程中修改 MIME 报文头，但在进行用户代理级处理时，参数仍有可能被重新排序。

那么，显而易见的解决方案是使用多个参数来容纳单个参数值，并使用某种有区别的名称来指示正在这样做。而这里所规范的正是这个显而易见的方案：采用星号（"*"）后接一个十进制计数的方式，来指示正在使用多个参数来封装单个参数值。计数从 0 开始，并针对参数值的每个后续分段加 1。使用十进制数值，不允许有前导零，也不允许序列中出现缺口。

原始参数值是通过将各个分段按序拼接而恢复的。例如，content-type 字段

Content-Type: message/external-body; access-type=URL;
 URL*0="ftp://";
 URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"

在语义上等同于

Content-Type: message/external-body; access-type=URL;
  URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"

注意，参数值两侧的引号是值语法的一部分；它们本身并非值的一部分。此外，明确允许续行字段中引号与无引号形式混合出现。

4. 参数值的字符集与语言信息

某些参数值可能需用字符集或语言信息加以限定。显然，需要一个有区别的参数名来标识此类信息何时出现，同时为值中的信息规定特定的语法。此外，还需要一种轻量级的编码机制，以容纳参数值中的 8 位信息。

星号（"*"）被复用于提供指示器，表明语言与字符集信息存在且正在使用编码。单个撇号（"'"）用于在参数值开头处分隔字符集与语言信息。百分号（"%"）用作编码标志，这与 RFC 2047 一致。

具体而言，参数名末尾的星号充当指示器，表明字符集与语言信息可能出现在参数值的开头。参数值字符串中使用单个撇号来分隔字符集、语言与实际值信息，并使用百分号来标记以十六进制编码的八位组。例如：

Content-Type: application/x-stuff;
 title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A

注意，将字符集字段或语言字段留空是完全允许的。还应注意，即便其中一个字段值被省略，单个撇号分隔符也必须存在。当字符集、语言或两者均与手头的参数值无关时，即采用此做法。这不得用于指示默认的字符集或语言——参数字段定义不得指定默认的字符集或语言。

4.1. 字符集、语言与参数续行的组合

字符集与语言信息可以与参数续行机制组合使用。例如：

Content-Type: application/x-stuff
 title*0*=us-ascii'en'This%20is%20even%20more%20
 title*1*=%2A%2A%2Afun%2A%2A%2A%20
 title*2="isn't it!"

注意：

  1. 语言与字符集信息仅出现在给定参数值的开头。
  2. 续行并不提供在同一参数值中使用多于一种字符集或语言的能力。
  3. 使用多个续行所呈现的值可以包含编码段与未编码段的混合。
  4. 如果给出了语言与字符集信息，则续行的第一个分段必须为编码形式。
  5. 如果续行参数值的第一个分段为编码形式，则即便字段留空，语言与字符集字段分隔符也必须存在。

5. 编码字中的语言说明

RFC 2047 为 RFC 822 报文头注释、短语以及任何非结构化文本字段提供了对非 US-ASCII 字符集的支持。这是通过定义一个可出现在这些位置的编码字构造来实现的。鉴于这些是意在显示的字段，有时有必要将语言信息与编码字相关联，而不仅仅是字符集。本规范扩展了编码字的定义，以允许包含此类信息。做法很简单：在字符集说明之后附加一个星号，后接语言标签。例如：

From: =?US-ASCII*EN?Q?Keith_Moore?= <moore@cs.utk.edu>

6. IMAP4 对参数值的处理

IMAP4 [RFC-2060] 服务器在生成 BODY 与 BODYSTRUCTURE 获取属性时，应该对参数值续行进行解码。

7. 对 MIME ABNF 的修改

RFC 2045 中给出的 MIME 参数值 ABNF 为：

parameter := attribute "=" value

attribute := token
             ; Matching of attributes
             ; is ALWAYS case-insensitive.

本规范将此 ABNF 修改为：

parameter := regular-parameter / extended-parameter

regular-parameter := regular-parameter-name "=" value

regular-parameter-name := attribute [section]

attribute := 1*attribute-char

attribute-char := <any (US-ASCII) CHAR except SPACE, CTLs,
                  "*", "'", "%", or tspecials>

section := initial-section / other-sections

initial-section := "*0"

other-sections := "*" ("1" / "2" / "3" / "4" / "5" /
                       "6" / "7" / "8" / "9") *DIGIT)

extended-parameter := (extended-initial-name "="
                       extended-value) /
                      (extended-other-names "="
                       extended-other-values)

extended-initial-name := attribute [initial-section] "*"

extended-other-names := attribute other-sections "*"

extended-initial-value := [charset] "'" [language] "'"
                          extended-other-values

extended-other-values := *(ext-octet / attribute-char)

ext-octet := "%" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")

charset := <registered character set name>

language := <registered language tag [RFC-1766]>

RFC 2047 中为编码字给出的 ABNF 为：

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

本规范将此 ABNF 修改为：

encoded-word := "=?" charset ["*" language] "?" encoded-text "?="

8. 支持语言说明的字符集

将来，某些字符集很可能会提供内联语言标注的能力。此类能力本质上比此处所定义的更为灵活，因为它们允许在字符串中间进行语言切换。

如果并且当此类能力被开发出来时，应该优先使用它们，而非此处规定的语言标注能力。注意，此处定义的所有机制都允许省略语言标签，以便能够适应这种未来可能的用法。

9. 安全考量

本 RFC 不讨论安全问题，且被认为不会引发任何电子邮件中本已普遍存在、并在完全符合规范的 MIME 实现中已经存在的安全问题。

10. 参考文献

11. 作者地址

Ned Freed
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 91790
USA

电话：+1 626 919 3600
传真：+1 626 919 3614
电子邮件：ned.freed@innosoft.com

Keith Moore
Computer Science Dept.
University of Tennessee
107 Ayres Hall
Knoxville, TN 37996-1301
USA

电子邮件：moore@cs.utk.edu

12. 完整版权声明

Copyright (C) The Internet Society (1997)。保留所有权利。

本文件及其译本可以被复制并提供给他人，并且可以准备、复制、出版和分发全部或部分地评论或解释它、或协助其实现的衍生作品，不受任何种类的限制，前提是上述版权声明与本段文字包含在所有此类副本与衍生作品之中。然而，本文件本身不得以任何方式被修改，例如通过移除版权声明或对互联网协会或其他互联网组织的引用，除非是为了制定互联网标准之目的而需要这样做（在此情况下必须遵循互联网标准过程中定义的版权程序），或是为了将其翻译成英语之外的语言而需要这样做。

上文授予的有限许可是永久性的，且不会被互联网协会或其继承者或受让人撤销。

本文件及其中包含的信息是基于"按现状（AS IS）"基础提供的，互联网协会与互联网工程任务组声明放弃所有明示或暗示的担保，包括但不限于任何关于使用 herein 信息不会侵犯任何权利的担保，或任何关于适销性或特定用途适用性的暗示担保。