MIME扩展：Content-Disposition（翻译自RFC2183）

1. 介绍

MIME提供了将多个数据块封装到单个邮件中的标准格式，但那些文档没有解决表示形式的问题。它为邮件内容的交换提供了一个框架，但却将表示问题交给了用户代理的具体实现者。

显示多部分电子消息有两种常见方法，一种是显示为主文档和单独的附件列表；另一种是作为一个整体以内联方式展开显示各个部分。附件的显示通常被解释为要求收件人采取积极行动才可以展示的，而内联邮件在查看邮件时会自动显示附件。需要一种机制允许发送者给接受者传输这种直白的信息。Content-Disposition头提供了这种机制，允许邮件的每个部分添加一个指示它被期望的展示方式的标记。

以这种方式标记信息通常足以进行基本的消息格式设置，但在许多情况下需要一个更强大更灵活地方式。此类方式的定义不在本文范围，但此类方法可以通过别的Content-Disposition值和参数来设置，它们将在以后定义。

除了允许发送方指定邮件一个部分的表示方式外，还希望允许发送方指示一个默认的存储设置或文件名，可选的filename参数提供了这一点。此外，creation-date、modification-date、read-date参数允许在文件通过MIME电子邮件传输时保留这些文件属性。

1. Content-Disposition

Content-Disposition是一个可选的头域，如果邮件没有这个头域，用户代理可以使用它认为合适的任何表示方法。

为了避免不必要的复杂性，最好将一组可能的表示类型保持在较小的范围中，并且定明确。即便如此，不断发展的使用可能需要定义额外的表示类型或参数，因此表示类型集是可扩展的。

Content-Disposition头域用扩展的BNF被如下定义：

     disposition := "Content-Disposition" ":"

                    disposition-type

                    *(";" disposition-parm)

 

     disposition-type := "inline"

                       / "attachment"

                       / extension-token

                       ; values are not case-sensitive

 

     disposition-parm := filename-parm

                       / creation-date-parm

                       / modification-date-parm

                       / read-date-parm

                       / size-parm

                       / parameter

 

     filename-parm := "filename" "=" value

 

     creation-date-parm := "creation-date" "=" quoted-date-time

 

     modification-date-parm := "modification-date" "=" quoted-date-time

 

     read-date-parm := "read-date" "=" quoted-date-time

 

     size-parm := "size" "=" 1*DIGIT

 

     quoted-date-time := quoted-string

                      ; contents MUST be an RFC 822 `date-time'

                      ; numeric timezones (+HHMM or -HHMM) MUST be used

       2.1 inline

如果要在显示消息时自动显示，则这部分应标记为“inline”。根据multipart邮件的正常语义，内联部分应按它们出现的顺序呈现。

       2.2 attachment

实体可以被指定为attachment，表示它与邮件的主体分离，并且它的显示不是自动的，而是取决于用户的操作。用户代理可以将附件用图标表示，或者显示用户可以选择查看或存储的附件列表。

       2.3 Filename参数

如果实体被分离并存储在单独的文件中，发送方可能希望建议使用一个文件名，如果接收的用户代理将实体写入一个文件，那么建议的文件名应该作为实际文件名的基础。

值得注意的是，用户代理不能盲目地使用建议的文件名，建议的文件名应该被检查（有可能被更改）以确保它符合本地文件系统惯例，不会覆盖现有文件，也不会出现安全问题。

接收用户代理不应考虑filename参数中可能存在的任何目录路径信息，filename应该只被视为终端的文件名。目录路径的规范在未来可能作为一个独立的Content-Disposition参数被执行，但至少不在这个文件中提及。

文件名参数的存在并不强制实现将实体写入单独的文件，除非用户另有要求，否则实现将实体作为普通邮件流的一部分是完全可以接受的。因此，参数可以用于任何mime实体，甚至是“inline”实体。这些通常不会写入文件，但如果接收用户选择将部件写入文件，则可以使用参数提供的文件名。

       2.4 Creation Date参数

creation-date参数可用于指示创建文件的日期，参数值必须是一个带引号的字符串，引号内包含以【RFC-822】中date-time格式表示的文件创建日期。

       2.5 Modification-Date参数

modification-date参数可能被用来指明文件上次被修改的日期，这个参数的值的要求与creation-date一样。

       2.6 Read-Date参数

read-date参数可能被用来指明上次文件被读取的日期，参数的值要求与上两个参数一样。

       2.7 Size参数

size参数指明一个文件的大小（字节），它可以用来在尝试存储文件前预先分配空间，或者确定是否存在足够的空间。

       2.8 说明

用户代理应该忽略无法识别的参数，无法识别的表示类型应该被视为attachment。

除非参数定义中另有说明，否则Content-Disposition参数对所有disposition都有效。甚至，如果表示类型本身无法识别，其参数依旧被视为有效。

如果在multipart部分上使用Content-Disposition，则它应用在了这个部分整体上，而不是单个的子部分，在显示multipart部分时应尊重子部分的disposition，如果使用inline则多部分应该被正常显示，但是如果是attachment则要求用户执行操作才能显示。一旦用户选择显示多部分，应咨询各个子部分配置，以确定如何显示子部分。

在一个邮件的主体中使用Content-Disposition头是被允许的。