邮件附件.docVIP

邮件附件 MIME（RFC2045～RFC2049）并没有提出在邮件中附带文件的方法，提出这种方法的是RFC2183，这个文件提出一个新的MIME头段Content-Disposition，可用来说明邮件中所包含数据的处理方式。 Content-Disposition的语法是 Content-Disposition: type *(; param) 其中type指定所含数据的处理方式，必须是inline或者attachment。param是一些可选的参数。 这个头段象其它MIME头段一样，可用在邮件的邮件头说明邮件正文数据的处理方式，也可以放在分块邮件的某一块中说明块内数据的处理方式。 当type为inline时，所说明的数据为在线显示方式，邮件用户程序在接收到邮件后应该将这种数据和邮件其它内容一起显示出来，而不是另外作为一个文件处理。 当type为attachment时所说明的数据将被作为附件处理，邮件用户程序应该询问用户是否保存附件以及保存到什么地方。这种类型需要如下几个可选的参数： filename：附件的文件名。这是邮件发送方建议的文件名，接收方保存附件时可作为参考。文件名中不应该包含磁盘目录路径，若出现这种路径，接收方应该忽略它。 creation-date：附件中文件的创建日期。参数值必须使用RFC822规定的日期时间格式，并且必须使用数字表示的时区。 modification-date：附件中文件最后一次被修改的日期时间，格式同上。 read-date：附件中文件最后一次被阅读的日期时间，格式同上。 size：附件中文件的大致大小，以字节为单位。 参数filename的参数值可能需要使用非ASCII字符（例如，中文文件名），可以采用RFC2047的编码文本方法（见本章第五节），也可以采用RFC2184提出的方法。 RFC2184提出的方法主要是为了对参数值中的非ASCII字符进行编码转换，同时也提出了处理长串参数值的方法。 当参数值很长时，可以采用RFC822中的头段折叠的办法，但这种方法使用起来有一些限制，例如，必须有空格以便在空格处换行，但参数值中未必有空格。为此，RFC2184提出如下语法，假设有参数param： param=very long string value 其参数值是很长的一串字符，则可将之分成若干段，分别表示为 param*0=1st line; param*1=2nd line; param*2=3rd line 即，将很长的参数分成若干段，每段仍保留“; param=value”的形式，但是在参数名和等号之间插入一个星号“*”和一个数字，数字表示分段编号，编号从0数起。按照MIME语法，每一段相当于一个参数，并不违反原来的语法。邮件接收系统要复原这些参数段，只需将同样参数名的各行按行号排列，将等号右边的字符串连接起来就可恢复原来的参数值。 对于参数值中的非ASCII字符，采用的是URI那种转义的方法，即，将一个8位的编码用对应的两个16进制字符表示（A～F用大写字母），前面加上百分号。但是用这样的方法必须说明字符编码，因此，使用如下语法： param *= charset language encoded-string 其中param是参数名，参数名和等号之间插入一个星号“*”，表示参数值是经过编码转换的文字，等号之后charset的是字符编码名称，例如iso-8859-1、GB2312等，然后是一个单引号，后面的是关于所用语言的解释信息，接着又是一个单引号，最后是转换之后的字符串。 例如，参数 filename=互联网技术.doc 按上述方法转换之后成为 filename*=GB2312hz%BB%A5%C1%AA%CD%F8%BC%BC%CA%F5.doc 注意其中的ASCII字符是不转换的。 作为邮件附件的数据，除了用Content-Disposition说明其为附件数据之外，还必须用MIME头段Content-type和Content-transfer-encoding说明数据类型和传送编码。 例5：带有附件的电子邮件： From: someone someone@126.com To: others others@163.com Date: Sat, 16 Feb 2008 15:02:24 +0800 Subject: =?gb2312?B?z+DGrA==?= Content-Type: multipart/mixed; boundary=_004_29815604740571203145344048JavaMailcoremailbj12