电子邮件格式说明_第1页
电子邮件格式说明_第2页
电子邮件格式说明_第3页
电子邮件格式说明_第4页
电子邮件格式说明_第5页
已阅读5页,还剩3页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

邮件格式说明邮件格式说明11概括..............................................................................................................................................22主体结构.....................................................................................................................................22.1邮件头................................................................................................................................21)长字段的断行.......................................................................................................22)字段主要结构.............................................................................................................33)邮件头结构协议.........................................................................................................34)重要参数字段.............................................................................................................42.2Content-type字段Multipart种类说明..........................................................................52.3Content-type字段Message种类说明...........................................................................6邮件格式说明MutipleInternetMailExtensionsRefertoInternetOfficialProtocolStandardsRFC822概括网络间传达的电子邮件需要公共认可的格式,以便于客户端邮箱软件辨别拆解此间的信息。邮件自己是由ASCII字符构成,整体上分为邮件头邮件体两部分,此间同意字符编码、附件、压缩等等多样化的格式。本文档参照网络官方协议标准中,恳求标注的邮件有关条款,总结了邮件结构及其各部分的格式说明,给出部分字符编码的有关解说。RFC(Requireforcomment)是InternetOfficialProtocolStandards标准所供给的网络协议标准系列。主体结构邮件结构包含邮件头、邮件体(可无),邮件体其实是一行行的ASCII字符构成的简单序列,它和邮件头是靠一个空行(该行只有一个回车换行符CRLF)来划分开的。2.1邮件头长字段的断行邮件头由很多头字段(headerfields)构成,这些字段包含字段名(fieldname)和字段值(fieldbody);字段值(fieldbody)能够切割成多行表述,叫做“可折叠”。断行的规则是:在一行的线性空格处,可用CRLF(回车换行)以后起码跟一个LWSP-char(空格或TAB),把本来的单行变成多行表示。RFC协议中介绍尽量把折叠的断行搁置在特定的空格分开处,比方,地点字段里的多个邮件地点,折叠时尽量在各地点之间,及逗号以后断行。字段主要结构包含字段名(Fieldname),冒号(colon),字段值(Fieldbody),结束符(CRLF);有些字段属于结构化字段,比方日期(Date),邮件地点(Address),有着特定的表示格式,用于系统辨别。而其余字段比方”Subject”“Comments”都被看作简单的字符串办理。字段表示:field-name":"[field-body]CRLF字段值(Fieldbody)可断行(见1)),内容所有都是ASCII码,元素包含句号,引用字符串,特别token,或一般文本。字段的含义拜见后文附录。邮件头结构协议邮件头字段不是一定依据特定的次序安排,只是是注意要把邮件体放在邮件头以后。邮件协议中介绍的做法是在搁置邮件字段时,邮件依据以下次序安排:”Return-Path”,“Received”,“Date”,“From”,“Subject”,“Sender”,“To”,“cc”,等等。邮件协议中规定邮件由字段和邮件体正文构成,两部分之间由一个空行(该行只有包含CRLF)分开,也就是说,在遇到的第一个空行以后所有的内容都被看作邮件体。?转发-Forwarding一些系统同意接受者转发信息,保存原有的邮件头,仅增添些新的字段,这些字段以”Resent-”为前缀。及前缀”Resent-”的字段表示接受者转发的原信息。?路径字段-TraceField路径信息用来追踪信息的发送者,”via”“with”等是记录变量。“Return-Path”:该字段由信息的最后发送者增添,是对于信息原始根源的地址和回朔路径。Reply-To字段是有信息源增添用来直接答复(地点?),而Return-Path是一个到信息原始根源的回朔路径。“Received”:由每此中继服务站增添,用于帮助追踪传输中出现的错误。字段内容包含,发送、接收的主机和接收时间。参数via用于记录信息发送后经过的物理站点,”with”指示了使用的邮件、连结的协议。参数id用于表记邮件。参数for用于记录发送者的散发的目的地点。?信息源的字段-OriginatorField“From/Resent-From”:与sender一定起码存在一个。“Sender/ResentSender-”“Reply-To/Resent-ReplyTo-”当自动生成答复信息的地点列表时,应该注意:假如没有”Sender”,将会使用”From”.接收者在答复信息时,邮件sender中的信息不会被自动使用。假如”Reply-To”字段存在,将使用该字段信息,而不是”From”字段。假如有”From”而没有”Reply-To”,将使用”From”。?接收者字段-ReceiverField“To/Resent-To”“Cc/ResentCc-”“Bcc/Resent-Bcc”参照字段“Message-ID/Resent-MessageID-”“In-Reply-To”“Reference”“Keywords”重要参数字段“MIME-Version”:所使用的网络邮件格式标准版本“Content-ype”邮件内容数据的种类,包含种类表记(type)和子种类表记(subtype),前者类型表记(type)声了然数据的种类,后者子种类表记

(subtype)为这类数据种类指定了特定的格式。比方content-type:image/xyz;说明数据种类是图像型(image)的,图像数据格式是xyz。种类表记(type)与子种类表记(subtype)由斜杠”/”来切割。种类以后是参数会合parameter。邮件的数据种类分为七种,分别是:文本(Text)、多文档(mulipart)、信息(Message)、图像(Image)、音频(audio)、视频(Video)、应用(Application)。文本(Text)—文字类信息,其基本的子类表记是”Plain”,即没有格式的文本。除了需要支持指定的字符集,获取文本信息不需要特别的软件。文簿本类用于多信息文本,在其上应用文字办理软件能够美化文本的外观,但文本的内容及涵义无需任何软件。所以子种类包含任何可读得文字办理格式。多文档(mulipart)—包含拥有独立数据种类的多个部分。此中定义了4个最原始的子种类:mixed(基本种类),alternative(拥有可供选择的多个格式),parallel(同时阅览的部分),digest(都是信息型的多部内容).信息(Message)–未封装的信息。该种类的信息体自己部分或所有都是RFC822格式。基簿本类是”rfc822”。”partial”表示局部信息,同意邮件传输中可分块进行。”External-body”表示扩展大邮件。图形(Image)–需要有现实设施。子类主假如两种应用宽泛的图形格式:jpeg,gif。声频(audio)–基簿本类”basic”,需要声频输出设施。视频(Video)–基簿本雷”mpeg”,需要视频显示设施。应用(Application)–其余种类数据,没法分析的二进制数据。基簿本类”octet-stream”,用于不行分析的二进制数据状况,为用户供给将信息写入文件的方法。”PostScript”表示传输脚本文档。Content-type种类默以为Content-type:text/plain;charset=us-ascii。假如content-type没有明确拟订,那么系统会默以为该种类。当碰到未知的种类时,将会把未知种类看作”application/octet-stream”对待。Content-Transfer-Encoding头字段很多邮件内容是以最原始的格式传输的,8位字符或二进制数据,但对于有些协议这类格式数据就不可以正确传输了。比如RFC821限制messages一定为7位US-ASCII数据,并且每行不可以超出1000个字符。所以,有必需定义体制来把数据编码成7位短行格式。编码的目的就是用网络能够传输的方式来表达邮件内容。Content-Transfer-Encoding实质上就是在种类数据的当地表述和用7位邮件传输协议转变的表述之间的一种映照,比方协议RFC821(SMTP)。该字段的值就是指定编码种类的一种表记。其值以下:“7bit”,”8bit”,-“printablequoted”,“base64”,“-binarytoken”,“x表记不划分大小写,假如没有明确指定,该字段的默认值是”7bit”。若值是”8bit”,”7bit”或”binary”时,表示没有做任何编码。(持续翻译)2.2Content-type字段Multipart种类说明所有带前缀”Content-”的字段对正文都定义有含义,而其余得头字段一般都被邮件体部分忽视。协议中指出,在multipart的状况下,即多个不一样的数据会合归并在同一邮件体内,此时头字段中”multipart”参数值一定存在。这时邮件体必然存在一个或多个子部分,每一个子部分都会由界限(boundary)封装,并且最后一个子部分后边一定跟一个结尾界限。每一部分都会由界限开始,而后包含着邮件子体的头信息(header),空行,而后是邮件正文。假如没有填写content-type的头字段,那就是示意相应的邮件体时US-ASCII的一般text/plain文本。Boundary在作为界限值封装邮件时,其使用方法是值前加两个”-”。在一些特别状况下,这类用法也不必定合用。封装部分的结尾,boundary和前面的使用格式同样的状况下,后边再加两个”-”的形式表示。Content-type字段参数的语法是把boundaries的值包含在引号之中。也能够没有引号,但又引号是最保险的。有一些非法字符会出此刻boundary值中,如果不加引号会惹起错误。注意封装界限一定内行的开始,后边是回车换行CRLF,开头的CRLF会被看作界限的一部分,而不是上一块内容的一部分。界限后边跟一个CRLF和下一部分的邮件头字段,或许,两个CRLF,这类状况下不会有细一部分的邮件头。在界限之间(子部分头一个boundary和上一部分结尾boundary之间或许正文第一个界限以前邮件头以后),会有一些可增添额外信息的空白空间,这些空间邮件分析时会掠过。Multipart子种类的简要介绍:Mixed:表示个子部间相互独立,需要以特定的次序摆列。Alternative:每一子部分的是同样信息的不一样版本,各部分排序,最优的排在最后,但优先使用。Digest:将子部分默认成message来办理。Parallel:同时显示多个子部2.3Content-type字段Message种类说明在发送邮件时,该种类会屡次使用来封装子mail邮件。往常的子种类是message/rfc822,该种类下没有一定增添的参数。额外的子种类”partial”和”External-body”,需要必需的参数。编码方面,该种类只同意”7bit”“8bit”或”binary”。message的头字段往常是US_ASCII的,message体内能够依据其自己的content-transfer-encoding字段值进行编码。1)message/rfc822该种类是rfc822协议的message。但不用和最外层的rfc822message那样有from,subje

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论