【国家标准(GB)】 信息技术 因特网中文规范 电子邮件传送格式

ICS_35.240.20
中华人民共和国国家标准
GB/T18304—2001
信息技术
因特网中文规范
电子邮件传送格式
Information technology-Chinese specification of internetcharacter transfer format for email2001-01-02发布
2001-08-01实施
国家质量技术蓝督局
GB/T18304—2001
iiKAoNhiKAca
本标准规定了以GB13000为基础在因特网电子邮件中传输中文字符和其他文种字符的消息格式。
本标准文本主要包括定义，通用电子邮件传输格式、GB13000电子邮件传输格式和附录几个部分。由于目前因特网电子邮件只有RFC规范，没有相应的国际标准和国家标准，因此在本文本中等同参考了与通用电子邮件传输格式相关的内容。附录中收录了与GB13000相关的变体格式UTF-7、UTF-8以及编码方式Base-64的内容，同时给出了基于GB13000中文传输的实现参考模型。本标准由中华人民共和国信息产业部提出。本标准由全国信息技术标准化技术委员会归口。本标准起草单位：中国电子技术标准化研究所、北京四通新世纪信息技术有限公司、信息产业部数据通信技术研究所、中国科学院软件研究所、清华大学。本标准主要起草人：李韵琴、胡万进、陈淑仪、吴健、冯吉祥、陶文星、陈壮。I
1范围
中华人民共和国国家标准
信息技术因特网中文规范
电子邮件传送格式
InformationtechnologyChinesespecificationofinternet character transfer format for emailGB/T18304—2001
本标准规定了在因特网电子邮件中使用的中文字符信息和其他文种字符的信息传送格式。本标准适用于因特网电子邮件系统以及相关的应用领域。2引用标准
下列标准所包含的条文，通过在本标准中引用而构成为本标准的条文。本标准出版时，所示版本均为有效。所有标准都会被修订，使用本标准的各方应探讨使用下列标准最新版本的可能性。GB/T1988—1998信息技术信息交换用七位编码字符集（eqVISO646：1991）GB2312—1980信息交换用汉字编码字符集基本集GB13000.1一1993信息技术通用多八位编码字符集第一部分：体系结构与基本多文种平面(idtISO/IEC10646-1：1993）
GB/T15273.1—1994信息处理八位单字节编码图形字符集第一部分：拉丁字母一(idt ISo 8859-1:1987)
RFC821
RFC822
RFC2045
RFC2046
RFC2047
RFC2048
RFC2049
RFC1641
3定义
因特网文本消息格式标准（StandardfortheFormatofARPAInternettextmessages）简单邮件传送协议（SimpleMailTransferProtocol）多用途因特网邮件扩展第1部分（MultipurposeInternetMailExtensionsPart1）多用途因特网邮件扩展第2部分（MultipurpaseInternetMailExtensionsPart2）多用途因特网邮件扩展第3部分（MultipurposeInternetMailExtensionsPart3）多用途因特网邮件扩展第4部分（MultipurposeInternetMailExtensionsPart4）多用途因特网邮件扩展第5部分（MultipurposeInternetMailExtensionsPart5）在多用途因特网邮件扩展中使用Unicode（UsingUnicodewithMIME）本标准采用下列定义。
3.1纯文本plaintext
由字符、换行控制符和换页控制符等组成的文本。它不提供也不允许格式化命令、字体属性指示、处理指令、解释指令或内容编排等控制功能。3.2消息message
由信封和内容组成的能够在网络上传送的一个信息单位。信封包含提供传送和投递的必要信息，内容由要投递给接收方的对象组成。所涉及的部分只包括消息内容的格式和某些语义以及信封的非技术国家质量技术监督局2001-01-02批准2001-08-01实施
GB/T18304—2001
iiKAoNiKAca-
规范信息。消息由消息头字段（信封）和正文（内容，可选）组成。正文与消息头之间通过一个空行分开。3.3字段field
在没有特指的情况下，字段是指消息中的有逻辑字符串区域。一个字段可以分为多个子字段，每个子字段也可以是一个有逻辑字符串。3.4消息头header
在没有特指的时候，消息头是指电子邮件消息的信封部分。每一个消息头字段可以看成是一个单个的有逻辑的字符行，包括字段名和字段内容。为了方便，字段内容部分可以分成多行表示，称为“折叠”。消息头中主要有完成传送、投递和扩展的字符类型以及编码等信息。3.5正文body
在没有特指的时候，正文指消息的内容部分。正文是要投递给对方的对象，包括文本、图像、音频、视频和应用程序等。
3.6字符集characterset
在MIME里所用的字符集是指一种将八位二进制字节串转换为可识别的字符串的方法。注意，这里并不需要在其他方面进行绝对明确的转换，即不是所有的字符都可以通过给定的学符集进行表述，以及一个字符集可能会提供不止一种将一个八位二进制字节串表示成一个特定字符串的方法。它不仅包括将单个字符直接映射成单个八位二进制字节的规则（如GB/T1988和GB/T15273.1)，而且在MIME里还包括多字节编码字符集和交换技术等。3.7多用途因特网电子邮件扩展MIMEMIME，即多用途因特网电子邮件扩展（MultipurposeInternetMailExtensions），是对RFC822以及RFC934和RFC2049所定义的因特网文本消息格式标准进行的扩展。它对消息格式进行了重新定义，允许：（1)用字符集而不只是GB/T1988来表示的文本形式的消息内容；（2)有很多不同格式的可扩展的非文本形式的消息内容；(3)多组分消息内容；（4)用字符集而不只是GB/T1988来表示的文本形式的消息头信息。与MIME有关的是RFC2045、RFC2046、RFC2047、RFC2048和RFC2049。3.8charset
charset是电子邮件MIME消息头的Content-Type字段里用来指定“text/plain”数据类型的关键参数。它给出了消息中所使用的字符集名称。3.9中文字符Chinesecharacter
在GB13000.1一1993中收录并编码的所有汉字、汉语符号、少数民族文字及符号。4总要求
4.1电子邮件格式
4.1.1因特网文本消息格式标准
因特网文本消息格式标准（StandardfortheformatofARPAInternettextmessages）等同RFC822。
简单邮件传送协议（SimpleMailTransferProtocol）等同RFC-821。4.1.2多用途因特网邮件扩展格式本部分引用RFC2045中与非GB/T1988代码及其传送有关的内容，其他部分等同参考RFC2045、RFC2046、RFC2047、RFC2048和RFC2049RFC822只定义了因特网上GB/T1988代码邮件消息的标准传送格式。传送非GB/T1988代码文本（其中包括中文）或其他多媒体数据，应采用多用途因特网邮件扩展（MIME）对RFC822进行扩充所定义的标准格式。这些消息头字段标准格式的正式定义如下：entity-headers:-[content CRLF[encoding CRLF]
GB/T18304—2001bZxz.net
[idCRLF]
[descriptionCRLF
*(MIME-extension-field CRLF)MIME-message-headers:=entity-headersfields
versionCRLF
；本定义中所隐含的消息头字段顺序应忽略MIME-part-headers :-entity-headers[fields]
；任何不以\content-\开头的字段都可能因没有意义；而忽略，本定义中所隐含的消息头字段顺序应忽略其各种特定的MIME消息头字段语法如下：MIME-Version消息头字段
用来声明因特网消息正文格式所采用的版本，并且任何按RFC2045文档编排的消息都必须包括如下消息头字段：
MIME-Version,l.0
MIME-Version字段的正式BNF定义如下：version：-\MIME-Version\\.\1DIGIT\.\1*DIGITContent-Type消息头字段
用来指明在含有MIME项的正文中数据的性质，给出媒体类型和子类型标识符，以及提供某些媒体类型所需要的辅助信息，以便正在接收的用户代理程序能选择一个合适的代理或机制去向用户表示这些数据，或者用一个合适的方式处理这些数据。Content-Type消息头字段的值称为媒体类型，分为顶层媒体类型（声明数据的通用类型）、子类型（指明与通用类型对应的具体格式）和参数（媒体子类型的修饰部分)，其定义如下：
content,-\Content-Type\\\type\J\subtype*(\,\parameter)
媒体类型和子类型的匹配与大小写无关type：=discrete-type/composite-typediscrete-type：-\text\J\image\/\audio\J\video\/\application\/extension-tokencomposite-type：=\message\/\multipart\/extension-tokenextension-token;-ietf-token/x-tokenietf-token：一<由标准途径RFC定义的并在IANA注册的扩充标记>x-token：=<字符\x-\或\x-\后接任何中间没有空格的标记>subtype：=extension-token/iana-tokeniana-token：=<公开定义的扩充标记。该标记必须按RFC2048指定在IANA注册>parameter：attribute\value
attribute:token
;属性的匹配与大小写无关
value:=token/quoted-string
这里，
GB/T18304—2001
iiKAoNiKAca-
token：=1*<任何除SPACE，CTLs和tspecials的GB/T1988字符>tspecials=\(\\)\\<\\>\/\@\/\,\\，\\\\\>
；在参数值里使用时必须以引用串的形式出现a）类型、子类型和参数名均与大小写无关。参数值通常与大小写相关，但有时也有意使用与大小写无关的形式。参数的排列顺序不分先后。b）参数依赖于媒体类型和子类型，是一个可选项，大多数参数都与一个具体的子类型相关。MIME实现程序可以忽略任何无法识别名称的参数。c）初始的五种表示单一媒体组分的标准顶层媒体类型为：(1）text一一文本信息子类型\plain”用来特指不包含任何格式化命令和指令的纯文本。（2）image一图像数据需要用一种显示设备去查看其信息。定义的初始子类型有JPEG和GIF等。
(3)audio-
(4)video-
音频数据需要用一种音频输出设备去“显示”其内容。视频数据是移动的图像，需要通过专用的硬件和软件去播放。初始的子类型是有“mpeg”等。
(5）application一一应用类数据典型情况是非中断性二进制数据和能被某个应用程序处理的信息。子类型“octet-stream”用于非中断性二进制数据的情况，“PostScript”子类型用于传送PostScript材料。
初始的两种表示多种组合媒体的标准顶层媒体类型为：（1）multipart一一由多种无关数据类型组成的数据。(2）message—一已封装过的消息。d）在使用\text\媒体类型发送纯文本信息时，使用\charset\参数可以指明\text\子类型正文文本的字符集，尤其是在包括有表示通用纯文本的子类型\text/plain\的时候。有关Charset参数的说明如下：
Charset参数是Content-Type字段里用来指定\text/plain数据类型的关键参数，给出消息中使用的字符集名称，其形式可有如下两种：Content-type:text/plaingcharset=charset_nameContent-type:text/plain;charset=\charset_nameCharset参数的值与大小写无关。Charset参数不出现时的默认字符集是GB/T1988。任何将来出现的\text\子类型标准规范都必须指出是否同样使用\charset\参数以及可能要限定的参数。附加的字符集可以通过IANA登记注册。Content-Transfer-Encoding消息头字段在简单邮件传送协议里，限制邮件消息为7位的GB/T1988代码数据，每个文本行的长度（包括CR、LF)不超过1000个字符。因此，有必要定义一种将各种媒体数据编码成这种7位短行格式的机制。这种编码机制在MIME里由Content-Transfer-Encoding消息头字段来指明。Content-Transfer-Encoding字段提供两条信息：指明正文采用了何种编码转换方式以及对应地必须采用何种解码操作才能恢复数据成原样；指出编码结果的范围是什么。Content-Transfer-Encoding消息头字段的取值为一个指定编码类型的单个标记，其正式语法格式和编码类型如下：encoding：-\Content-Transfer-Encoding\\.\mechanismmechanism：=-\7bit\/\8bit\/\binary\/4
GB/T18304—2001
\quoted-printable\/\base64\ietf-token/x-token
这些值都与大小写无关。编码类型“7bit”要求正文采用7位的文本邮件表示方式。如果ContentTransfer-Encoding消息头字段没有出现，那么其默认取值是假定\Content-Transfer-Encoding：7bit\。如果有必要，实现机制可以定义私有的\Content-Transfer-Encoding\值，但是必须使用\x-token来指明是非标准状态，例如\Content-Transfer-Encoding：x-my-new-encoding\。在Content-Transfer-Encoding消息字段的赋值中，有一种是“base64”。这种编码方法可是用一种编码形式(不一定要可读)来表示任意字节串。详细内容见提示的附录A。4.2UCS字符集传送格式
本标准规定以GB13000作为因特网电子邮件中中文字符信息的传送格式。根据4.1.2对因特网电子邮件中有关文本传送格式的扩充定义，本节定义GB13000作为因特网电子邮件中新的基本学符集，用于传送多八位编码的字符。所涉及内容主要包括GB13000字符集编码格式和charset字段名称两部分。目前GB13000只定义了BMP平面中的字符，随着GB13000新版本的颁布，本标准也将作相应的修订和增补。
4.2.1UCS字符集编码格式
定义GB13000作为因特网MIME允许的基本字符集之一，即在电子邮件消息中使用GB13000（目前为GB13000.1)作为charset字段的赋值之一。在因特网MIME消息头中，按如下两种形式声明电子邮件文本的字符集为GB13000.1：Content-Type:text/plain,charsetucs-charset-nameContent-Transfer-Encoding:en cod ing-type或
Content-Type;text/plain;charset=\ucs-charset-name\Content-Transfer-Encoding:en cod ing-type这里只给出了在电子邮件中传送GB13000字符代码的特定头信息段。其中ucs-charset-name是标识GB13000字符集的charset名称，其具体内容在4.2.2和4.2.3中说明；encoding-type是传送GB13000字符代码的具体编码类型，可以采用base64或其他编码方式。有关base64编码的内容，参阅本标准提示的附录A。
4.2.2charset赋值规则
所有为MIME注册使用的GB13000变体和版本均使用符合以下统一形式的MIMEcharset名称：
charsetSID-version[-variant]其中SID是字符集标准标识号，即国际标准ISO/IEC10646(GB13000)。versiom是字符集标准的“版本号”，对ISO/IEC10646（GB13000）而言，其构成形式为releaseL-form，release是ISO/IEC10646（GB13000）的发行号，目前只有1”（表示ISO/IEC10646.1-1993），form是ISO/IEC10646(GB13000)的编码形式，目前已经颁布的有UCS2和UCS4两种形式。variant表示字符集标准的变体形式，目前有UTF7和UTF8两种，当然也可以不采用变体，而直接使用标准的原始编码。方括号内的参数都是可选的。
4.2.3charset赋值列表
根据4.2.2中的定义，下面列出了GB13000.1—1993（IS0/IEC10646.1—1993)的charset参数名称：
ISO/IEC-10646-1-UCS2
ISO/IEC-10646-1-UCS2-UTF7
GB/T18304—2001
ISO/IEC-10646-1-UCS2-UTF8
ISO/IEC-10646-1-UCS4
ISO/IEC-10646-1-UCS4-UTF7
ISO/IEC-10646-1-UCS4-UTF8
本标准的charset参数的赋值列表，将随着信息技术发展，逐步增补。iiKAoNiKAca-
GB/T18304—2001
附录A
（提示的附录）
UTF-7 与UTF-8
由于ISO/IEC10646（GB13000)标准编码空间十分庞大，传统的内码体系几乎无法表示整个ISOIEC10646(GB13000)字符集，而且，目前绝大多数的软件、硬件体系和输入/输出设备以及因特网的邮件几乎完全基于ISO/IEC646(GB/T1988）。因此，在实现时就必须考虑兼容性、继承性问题。采用UCS编码的变体是解决这一问题的途径之一。本附录列出了UCS编码在具体应用实现中的两种变体形式UTF-7和UTF-8的编码规则，与UCS的映射关系及应用情况。
A1 UTF-7
UTF-7是主要针对目前基于RFC822的因特网电子邮件系统只能支持7位ISO/IEC646（GB/T1988)码传送的现状而提出的一个UCS编码的变体形式。UTF-7采用带换档字符的一个或多个7位ISO/IEC646（GB/T1988）字节串表示UCS字符串，以便在只支持7位传送的邮件系统中传送UCS字符。
UTF-7将UCS字符集分为三个子集，D集，O集和B集。D集是可直接编码的字符集，包括：字母A～Z、a～z、数字0～9和以下特殊字符（‘十和‘=被忽略，见表A1)：
表A1D集字符
GB/T1988和UCS值（十进制）
O集是可选直接编码的字符集，包括下列字符(“\\”和“～”被忽略，见表A2)：表A2O集字符
GB/T1988和UCS值（十进制）
GB/T18304—2001
表A2（完）
GB/T1988和UCS值（十进制）
iiKAoNiKAca-
GB/T1988字符集中的\”和“～”不包括在内，因为这两个字符在应用中有不同的含义。B集是需要按Base-64编码规则编码的字符集(Base-64参见附录B）。用UTF-7编码字符串表示UCS字符的转换规则如下：规则1（直接编码）：在上面定义的D集中的UCS字符按照GB/T1988直接编码、O集中的UCS字符可以选择性的直接编码，同样地，它们中的许多字符禁止在头域中出现，或者不能正确地通过某些邮件网关。
规则2（转换编码）：任何UCS字符序列都可以使用B集中的一列字符编码和一个前导变换字符“+”（GB/1988值为43），字符“十”后的八进制数被解释为64基字符，直到出现一个非64基字符，包括控制字符如回车和换行。因此，一个UCS字符变换序列通常在一行的行尾结束，作为一个例外，如果一个序更以字符“_”（GB/T1988值为45)结束，则这个字符被忽略，其他结尾字符不能忽略正常处理。作为一个特例，“十-”作为“十”的编码。规则3：制表符（0x09）、回车（0x0d）和换行（0x0a）字符可以用它们的GB/T1988直接表示。注意，MIME内容转换编码按规则使用这些字符，这些用法不遵守RFC822的限制。利用这三个规则，一个UCS字符变为1行平均22/3个7位的GB/T1988码字符串。例如：字符串“HiMon你好！，其UCS编码为004800690020004D006F006D0020转换为UTF-7串为：HiMon+。
UTF-8是由X/Open联合I18N工作组提出的一种与UNX系统兼容的文件系统安全的UCS转换格式，并在ISO/IEC10646.1(GB13000.1)附录R中推荐。UTF-8采用1～6个八位字节来表示BMP中的一个字符。第一个八位字节从左到右有几个“1”就表示这个学符古占几个八位学节，第二个八位字节及以后的八位字节，每一个以“1打头，作为一个八位字节的标识，以“0”区分标识和后面的“有效位”。所有的“有效位”串接起来表示一个字符真正有意义的“位”。表示原GB/T1988128字符的UTF格式为一个八位字节，以\0”为先导。表A3是UTF-8编码方案。
3UTF-8编码方案
有效位
最小值(Hex）
00000000
00000080
00000800
00010000
00200000
04000000
最大值(Hex)
0000007F
000007FF
0000FFFF
001FFFFF
03FFFFFF
7FFFFFFF
0xxxxxxx
110xxxxx10xxxxxx
二进制的位序列
1110xXXx 10xXXXXX 10xXXXXX
11110xxx10xxxxxx10xxxxxx10xxxxxx111110xx10xxxxxx10xxxxxx10xxxxxx10xxxxxx1111110x10xxxxxx10xxxxxx10xxxxxx10xxxxxx10xxxxxx其中的x位连接起来就组成了UCS码。若只表示BMP(即UCS-2)，则只需三个八位字节。8
GB/T18304—2001
UTF-8的特点是兼容现有的基于ISO/IEC646（GB/T1988）字符的软、硬件平台，以及UCS码的转换算法，是目前使用比较广泛的一种UCS的变体形式。对于UTF-16，可以用两个UTF-8编码表示。附录B
(提示的附录）
Base-64字符
Base-64内容传送编码（Content-Transfer-Encoding）是一种用不可读的编码表示任意8位序列的编码形式，其编码和解码算法十分简单。Base-64的编码算法是将24位一组的输入位串转换成4个输出的编码字符。编码过程从左到右，24位输入串被分解为4个6位的位组，每个位组的值为0～63，然后，从表B1中取出相应的编码字符，放入输出串中。
编码输出流所表示的行不超过76个字符。所有断行或出现在表B1以外的字符都将被编码软件忽略。在解码时，表B1以外的字符、行中断以及其空白都表示传送出错，并给出警告或出错消息。表B1Base-64字符
有关Base-64的详细内容参见RFC2045。值
附录C
(提示的附录）
有关Unicode的charset赋值列表编码
(pad)=
考虑到等同于ISO/IEC10646/BMP的工业标准Unicode目前有一定的用户，以及Unicode已经发布的版本，特列出如下有关Unicode的charset参数名称的别名：csUnicode
Unicode-1-l
Unicode-1-1-UTF-7
csUNICODE11
CSUNICODE11UTF7
D1总体结构
GB/T18304—2001
附录D
(提示的附录）
实现参考模型
iKAoiKAca-
本标准所给出的实现参考模型，其总体结构如下图所示。其中，虚线框内的部分为本标准所规定的因特网电子邮件中文消息传送格式。1SO/[EC10646平台
IS02022扩展平台
映射转换
[SO/IEC10648纯文本信息
交体转换
发送电子邮件
ISO/IEC10646台
ISO2022扩屉平台
映射转换
ISO/IEC10646纯文木信息
变件转换
因特网电子邮件系统
接收电子邮件
在电子邮件发送过程中，对于在ISO2022(GB2311)扩展平台上使用的本地字符集的纯文本信息，通过映射转换的方法转换为ISO/IEC10646（GB13000）字符集的纯文本信息；对于在ISO/IEC10646（GB13000）平台上，直接使用ISO/IEC10646（GB13000）字符集的纯文本信息。对于ISO/IEC10646（GB13000）字符集的纯文本信息，通过可选的变体转换（如UTF7，UTF等），最后对其进行编码，在电子邮件的相应部分中，对所使用的字符集、变体形式和编码类型进行标记，然后向因特网电子邮件系统发送电子邮件。
在电子邮件接收过程中，对于从因特网电子邮件系统接收到的电子邮件，首先按照标记的编码类型，对于其中的纯文本信息进行解码，如果字符集字段有变体转换，进行相应的转换，将其转换为ISO/EC10646（GB13000)字符集的纯文本信息，对于ISO2022扩展平台，通过映射转换，将其转换为本地字符集，以便进行处理。
D2关键代码段
本标准所给出的实现参考模型的关键代码段采用C/C+十伪代码形式，使用SOCKET通信接口，分为发送和接收两部分，其中的斜体部分需要按照实际情况作必要的修改。发送部分：
char *SendMessage-
HELoyour_hostrn\，
\MAILFRoM：yourMaiBor@your_hostrn\，10
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。