1、ICS 35.240.01 L 78 GB 中华人民共和国国家标准化指导性技术文件GB/Z 18812-2002 EDI对象的MIME封装MIME encapsulation of EDI objects 2002- 08-09发布2003 - 04 -01实施中华人民共和国发布国家质量监督检验检瘦总局050928068518 GB/Z 18812-2002 目次前言.引言.E1 范围2 规范性引用文件.3 EDI交换的类型.4 MIME中的相关头段.5 基于EDIFACT的EDI交换的MIME封装. 2 6 基于ANSIX12的EDI交换的MIME封装. 7 基于其他EDI体系的EDI交换的
2、MIME封装.3 8 电子邮件传输EDI对象的典型过程.4 9 安全问题.4参考文献6前言本指导性技术文件主要根据Internet工程任务组提出的RFC1767制定。本指导性技术文件由中国标准研究中心提出。本指导性技术文件由全国电子业务标准化技术委员会归口。本指导性技术文件起草单位:中国标准研究中心。本指导性技术文件主要起草人:魏宏、:X1J碧松、胡涵景、孙文峰。GB/Z 18812-2002 GB/Z 18812-2002 引电子数据交换(EDI)提供了一种在贸易伙伴间传输结构化数据的手段，其传统的增值网传输机制阻碍了EDI的推广和应用。Internet以其可靠、费用低廉、支持宽带和易接入等
3、优点，为EDI的传输开辟了一条新的途径，利用互联网的邮件传输体系对EDI对象进行传输是最为方便和可行的一种方法。为了进一步规范EDI对象在Internet上的传输，IETF专门制定了一系列RFC，包括从如何封装EDI对象到如何实现安全传输，是较为完整的一套在Internet上利用电子邮件传输EDI的解决方案。RFC 1767是其中之一。GB / Z 18812- 2002 EDI对象的MIME封装1 范围本指导性技术文件规定了在多用途Internet邮件扩展协议(MultipurposeInternet Mail Exten sions ，MIME)中封装EDI对象的格式。除非特别声明，本指导
4、性技术文件中的EDI对象指一个包括交换头和交换尾在内的完整的EDI交换。本指导性技术文件仅规定EDI对象在MIME环境中的封装，并不涉及该对象内部的语法和语义。iIITi!:行，本指亨咂嗡文件通过便捷的Internet电子邮件传2 规范性引用文件3 4 RFC 2045 RFC 822 在世界范a) b ) c) 界范围内得到广的子集标准属此MIME是一组基于展，增加定义了以下消息一一非US-ASCII字符集表述的文本型头段信息。RFC822所定义的是Internet上文本邮件的标准格式，而对多媒体格式并未作任何说明，即使是文本，也仅限定用户使用US-ASCII字符串，对非US-Ascn字符集
5、未加说明。MIME协议组在不产生任何不兼容性的基础上，通过引入相关头段，增加了解决传输多媒体格式的机制。具体头段如下:a) MIME版本头段:该段提供一个版本号，声明消息与何种版本的MIME一致，以便邮件处理器区别新旧版本生成的消息。版本号由两个数字组成，中间用小数点分隔，以便将来可能对消息格式的标准进行扩展。GB/Z 18812-2002 b) 内容类型头段:该段的目的是描述消息体中的数据，以便接收代理能够用适当的方法或机制将此数据提交给用户。该段的值被称为媒体类型。内容类型头段通过媒体类型和子类型标识符定义实体中的数据类型，对于某些特殊媒体可能需要给出一些附加的信息。这些附加信息以一组参数
6、的形式紧眼在类型标识符后面，)顺序不限。一般来说，媒体类型大致说明基本的数据类型，子类型说明数据类型的具体格式。参数是媒体子类型的修饰符，但并不会影响实体中内容的本质。参数值的设置取决于媒体类型和子类型，或者是可选的。大多数参数值只与某一特定的子类型有关。例如:参数CHARSET(字符集)适用于text(文本)类型中的任何子类型;参数boundary(界限)适用于Multipart(多部分)类型中的任何子类型;而参数MicAlg用于说明完整性控制值的算法。媒体类型分为两大类:discrete-type(离散类型)和composite-type(复合类型)。其中离散类型分为五种:text (文本
7、)、image(图像)、audio(声音)、vedio(视频)、application(应用)。复合类型分为两种:message(消息)、multipart(多部分)。上述的七种媒体类型基本涵盖了所有的媒体类型，如果用户自行扩展，需要将标记定义为以X打头，以免同将来标准的名称相冲突。建议用户只对子类型作扩展。对子类型名称定义的唯一语法限制是名称上不能冲突。c) 内容传送编码头段:该段既可说明应用于消息体的编码转换，也可说明转换的结果域。编码转换通常对数据进行处理，以便其能通过有数据或字符集限制的邮件传输系统。目前IETF定义了三种转化类型:本体(未作转化)、quoted-printable和b
8、ase64。当内容编码头段的值为7bit、8bit或binary时，表示本体转化，这些值仅作为指示符。quotedprintable和base64编码转化是将任意格式转化为基于7bit的数据格式，使得数据安全通过某些带有限制的传输协议。d) 内容标识头段和内容描述头段:在一些较高级的应用中，可能希望引用其他消息。内容标识头段提供这样的功能。与消息的唯一标识号(1D号)一样，内容标识头段必须是唯一的。而内容描述头段用于为消息体中的内容提供描述性信息。5 基于EDIFACT的EDI交换的MIME封装当对EDIFACT类型的EDI交换进行封装时，MIME中的相关信息定义如下:MIME类型:Appli
9、cation MIME子类型:EDIFACT 参数:CHARSET , MicAlg等内容传送编码头段:base64或者quoted-printable内容标识头段:用户视引用情况自行定义内容描述头段:用户自行说明其中MIME媒体类型选取Application，无论封装哪种类型的EDI交换，MIME媒体类型均使用Application。当对符合EDIFACT标准的EDI进行封装时，MIME媒体子类型定义为EDIFACT。参数此处都是可选型的，例如如果EDI报文中包括中文字符，则CHARSET定义为gb18030。大多数EDI数据都是文本型，但某些特殊字符(如分隔符)可能是非打印的ASCII字符
10、，或某些数据可能是纯二进制。对于包含这些数据的EDI对象，内容传送编码头段需要定义为base64或者quotedprintable 。2 内容标识头段和内容描述头段都是根据具体情况用户自行进行定义。下面给出一个MIME封装EDIFACT类型的EDI交换的实例:To: editestcyclonesoftware. com Subject: From: ediSendercyclonesoftware. com Date: Thu , 3 June 2000 11: 30: 29 Mime-Version : 1. 0 Content-Type :application/ED1FACT ;CHA
11、RSET=gb18030 Content-Transfer-Encoding: base64 Content-Description: Invoice Message 一一-ED1交换开始一一ED1交换一-ED1交换结束一6 基于ANSIX12的EDI交换的MIME封装当对ANSIX12类型的ED1交换进行封装时，MIME中的相关信息定义如下:MIME类型:Application MIME子类型:EDI-X12 参数:CHARSET ，MicAlg等内容传送编码头段:base64或者quoted-printable内容标识头段:用户视引用情况自行定义内容描述头段:用户自行说明其中除了MIME子
12、类型变为EDI-X12以外，其他头段的内容与第5章相同。下面给出一个MIME封装ANSIX12类型的ED1交换的实例:To :editestcyclonesoftware. com Subject: From :ediSendercyclonesoftware. com Date: Thu , 3 June 2000 11: 30: 29 Mime-Version : 1. 0 Content-Type :application/EDI-X12 Content-Transfer-Encoding: base64 Content-Description: Invoice Message 一-ED
13、1交换开始一ED1交换一一一ED1交换结束一一一7 基于其他EDI体系的EDI交换的MIME封装当对其他ED1体系的ED1交换进行封装时，MIME中的相关信息定义如下:MIME类型:Application MIME于类型:EDI-consent 参数:CHARSET ，MicAlg等内容传送编码头段:base64或者quoted-printable内容标识头段:用户视引用情况自行定义内容描述头段:用户自行说明GB/Z 18812-2002 3 GB/ Z 18812- 2002 8 其中MIME子类型变为EDI-consent，其他头段的内容与第5章相同。下面给出一个MIME封装其他EDI类型
14、的EDI交换的实例:To :editestcyclonesoftware. com Subject: From :ediSendercyclonesoftware. com Date:Thu , 3 June 2000 11:30:29 Mime-Version : .。Content-Type :application/ EDI-consent Content-Transfer-Encoding : base64 Content-Description: Invoice 一EDI交换开始一(EDI交换一一-EDI交换结束9 安全问题性等问题。本指导性技术文件规定了通过Internet邮件传输
15、敏感数据的方式和其他支持MIME对象封装的服务。对于敏感数据，有必要考虑安全服务.诸如鉴别、机密性、抗抵赖性等。本指导性技术文件本身并不提供任何安全机制。如果需要和适当的话，必须在传输过程中增加这样的机制，可以使用基于MIME的安全服务，或者使用基于EDI标准的安全服务。4 基于MIME的安全服务参见:RFC 2630和RFC2633(安全MIMECS/MIME)报文规范RFC 2015(PGP格式的安全MIME)GB/Z 18812-2002 基于EDI标准的安全服务参见:GB/T 14805.5-1999用于行政、商业和运输业电子数据交换的应用级语法规则(语法版本号:的第5部分:批式电子数
16、据交换安全规则(真实性、完整性和掘抗抵赖性) GB/T 14805.6-1999用于行政、商业和运输业电子数据交换的应用级语法规则(语法版本号:4)第6部分t安全鉴别和确认报文(报文类型为AUTACK)GB/T 14805.9-2001用于行政、商业和运输业电子数据交换的应用级语法规则(语法版本号:4)第9部分:安全密钥和证书管理报文(报文类型为KEYMAN)5 GB/Z 18812-2002 参考文献RFC 2630 安全MIME(S爪nME)报文规范RFC 2633安全MIME(S/MIME)报文规范第3版RFC 2015 PGP格式的安全MIMEGB/T 14805.5-1999 用于行
17、政、商业和运输业电子数据交换的应用级语法规则(语法版本号:4) 第5部分:批式电子数据交换安全规则(真实性、完整性和源抗抵赖性)GB/T 14805.6一1999用于行政、商业和运输业电子数据交换的应用级语法规则(语法版本号:的第6部分:安全鉴别和确认报文(报文类型为AUTACK)GB/T 14805. 9-2001 用于行政、商业和运输业电子数据交换的应用级语法规则(语法版本号:4) 第9部分:安全密钥和证书管理报文(报文类型为KEYMAN)6 NOON-NF N菌。中华人民共和国国家标准化指导性技术文件EDl对象的MIME封装GBIZ 18812一-2002 中国标准出版社出版北京复兴门外三里河北街16号邮政编码:100045电话:6852394668517548 中国标准出版社秦皇岛印刷厂印刷新华书店北京发行所发行各地新华书店经售，瞻印张3/4字数14手字2003年3月第一次印刷i开本880X12301/16 2003年3月第-版印数1-1500 JG 定价10.00铸书号:155066 1-19147 网址版权专有侵权必究举报电话:(010)68533533祷632 189 科目GB/Z 18812-2002
