rfcrfc2046.txt

本程序为在linux下实现FTP传输文件的实现

适的转换机制进行编码。
4. 1. 2 字符集参数
“text/plain”数据的Content-Type域指定了一个重要的参数－字符集。下面是一个例子：

Content-type: text/plain; charset=iso-8859-1

不像一些其他参数值，字符集参数值是不区分大小写的。默认的字符集是US－ASCII。
“text”未来子类型的规范必须指定是否利用“charset”参数，是否限制它的值。对于“text”
中“text/plain”之外的其他子类型，“charset”参数的语义应该和在“text/plain”定义的一样，
例如，主体完全由给定的字符集中的字符组成。特别的，未来“text”子类型的定义者应该
密切关注多字节字符集的含义。
“text”的子类型的字符集参数给出了字符集的名称，就像RFC 2045中定义的“character 
set”一样。前面详细定义的换行规范必须严格遵守，不符合这些规范的字符集不能使用在
MIME“text”子类型中。
最初确定的字符集名称列表可以在这一节最后看到。额外的字符集应当通过IANA注
册。
其他的媒体类型选择采用这里定义的字符集参数，除了CRLF/换行限制。因此，所有遵守
RFC2045中“character set”常规定义的字符集都可以注册供MIME使用。
注意，如果指定的字符集包括8比特字符使用在主体中，为了通过一些邮件传输协议（如
SMTP【RFC821】）传输主体，需要内容/编码转换域和相应的数据编码。
默认的字符集US－ASCII在以前是很混乱和模糊的。不仅在定义中有含糊，而且在应
用中有很多变种。为了消除这种二义性，强烈推荐用户在Content-Type报头域中明确指定
字符集参数。"US-ASCII"不表示一个任意的7比特字符集，但是指定主体中的所有字节必须
根据"US-ASCII"字符集翻译。ISO 646 [ISO-646]面向应用版本通常不同于US－ASCII。字
符集名称“US-ASCII”明确引用定义在ANSI X3.4-1986 [US- ASCII]中的字符集。ISO646
新的国际参考版（IRV）和US-ASCII是一样的。字符集名称“ASCII”保留但禁止用于任何
目的。
注：RFC821明确规定了“ASCII”，并参考了较早的美国标准版。指定媒体类型和字符
集的一个目的是允许接收者毫无二义性的解释数据。假定不是“strict ASCII”作为默认字符
集，将冒改变正在传输的消息语义的危险。这也意味着包含依据ISO其他版本（非US-ASCII
和1991 IRV版）编码的字符的消息必须使用相应的字符集规范来和MIME保持一致。
完整的US-ASCII字符集列在ANSI X3.4- 1986。值得注意的是，除了合成的CRLF代表
换行，包括DEL在内的控制字符没有详细的意义。下面的两个字符在广泛使用中有实际意义：
FF经常表示“在新页的开头开始后续的文本”；TAB或HT经常表示“把光标后移，移动的列
数是8的倍数”。除了这些惯例，任何对控制字符的使用必须是下面两种情形之一：
（1）	由于非“plan”的文本子类型明确分配了一些附加意义，或者
（2）	发送者和接受者之间有一个私人的协定，这种协定是令人泄气的应该用文档中的其
他功能代替。
注：在US-ASCII之外有许多庞大的字符集。大量部分或全部重叠的字符集并不是一件好事
情。可以广泛使用的但是可以表示时间上所有语言的单一的字符集是首选的。不幸的是，几
个委员会还将继续使用多种字符集。因此，在本文当中定义了一小部分标准字符集。
定义的字符集是：
（1）	US-ASCII――定义在ANSI X3.4-1986 [US-ASCII]。
（2）	ISO-8859-X――ISO646字符集已经被8859代替，8859成为Internet邮件指定的字
符集。本文档出版时，“X”的合理的值是从1到10。
范围在128－159之间的字符在ISO-8859-X中没有指定意义。ISO-8859-X中值在128以下
的字符和它们在US-ASCII中有一样的意思。
ISO8859第六部分（拉丁/阿拉伯字母）和第8部分（拉丁/西伯来字母）包括了从右至
左和从左至右两种字符，但是没有定义一种规范的次序来表示双方向文本。"ISO-8859-6" 和 
"ISO-8859-8"字符集指定使用形象的方法【RFC-1556】。
所有这些字符集都是纯7比特或8比特集，没有“shift”和“escape”功能。“shift”和
“escape”序列的含义也没有在这些字符集中定义。
上面定义的字符集在MIME中都是没有争议的。本文档没有认可特殊的非US-ASCII
字符集，并且承认字符集未来的发展是未知的。
注意，使用的任何非US-ASCII字符集必须在Content-Type域中具体指定。
上面定义的字符集之外的、没有正式发行和IANA注册的字符集，或者私人约定的字符集，
这种情况下字符集名称必须以“X－”开始。
实现者不要定义新的字符集除非绝对需要。
“charset”参数主要定义用于文本数据，在这节中进行了描述。但是，有可能非文本数据也
希望指定字符集属性值，这种情况下应该使用相同的句法和属性值。
一般来说，合成软件应该总是使用“最低级的通用命名”字符集。例如，如果一个主体只包
括US-ASCII字符，应该标记成US-ASCII字符集，而不是ISO-8859-1。更普遍的情况，如
果一个字符集是另一个字符集的子集，而主体只包含子集中的字符，那么应该标记那个子集。
这将增加接受方正确看到结果的可能性。
4. 1. 3.  Plain(纯文本)子类型
      最简单、最重要的“text(文本)”子类型是“plain(纯文本)”。这表明纯文
  本不包含任何的命令格式或符号。纯文本是有意被保持原样的显示，就是说，正确
  的显示纯文本不需要进行命令格式、字体属性、特殊符号、处理结构、目录或段落
  标志的处理。缺省的使用格式“text/plain;charset=us-ascii”常用于因特网实践
  中现有的电子邮件。在RFC 822中由关于这个子类型的详细的定义。
     在这个文件中并没有其他的文本子类型的定义。     
4. 1. 4.Unrecognized（未被承认的）子类型
      Unrecognized（未被承认的）子类型被当作“plain”纯文本子类
   型，只要MIME知道怎样处理字符集。如果它的字符集是未被承认的，就被当作
   “application/octet-stream”处理。
4.  2.  Image Media Type（ 图象类型）
      “image”（图像）类型的主体部分包含一幅图像，它的子类型命名这幅特殊图像
   的格式。这些命名不区分大小写。初始的子类型是JPEG格式的“jpeg”类型，它
   使用JFIF编码[JPEG]。
       这里列出的“image”图像子类型即不是唯一的，也不是详细的，如果想要了
   解更多的在IANA注册过的子类型，可参考RFC 2048。
       Unrecognized（未被承认的）图像子类型一般被当作“application/octet
    -stream”处理。当它们没有被标注为安全而只是普通的图像浏览应用时，执行器
   可能随意的选择可用的图像子类型代替，如果那个子类型可用的话。
   注意：用这种方法把应用程序支持的大部分的危险的图像子类型处理成普通目的
   图像浏览应用可能会遗留下来一些安全性问题。
4.  3.  Audio Media Type（音频类型）
      "audio"（音频）类型的主体部分包含音频数据。虽然目前还没有一致的理想的
  音频格式用于电脑，但有一些压缩格式能提供共同操作的能力。[Page 11]
     最初的子类型"basic"（基本的）通过提供一个绝对的最小公分母音频格式
  满足这种需要。在以后的文件中可能定义更丰富的格式，它具有更高品质和更低
  带宽的音频。
     "audio/basic" 子类型采用单道8bit ISDN mu-law[PCM]编码，采样频率为8000
   Hz.
     未被承认的音频子类型有时被当作"application/octet-stream"类型处理。执行
  器可能随意的选择一个可用的音频子类型，选择的这个子类型不是确定的一个，可有
  多个选择，来满足应用程序的多方面的需要，只要该应用是可行的。
4.  4.  Video Media Type（视频类型）
      "video"（视频）类型的主体部分是一个随时间变化的运动图像，可能带有颜色和
  同步的声音。术语"video"（视频）这里是从最一般的角度来说的，而不是特指某一个
  技术或格式。也不排除动态图像编码。"mpeg"子类型指的是一种用MPEG标准编码的视频
  类型。
      应该注意虽然这个文档不提倡在单一的主体部分有多种媒体类型的混合，事实
  上已经有许多所谓的有同步描述的视频格式， "video"（视频）类型支持这种格式。
      未被承认的视频子类型有时被当作"application/octet-stream"类型处理。执行
  器可能随意的选择一个可用的视频子类型，选择的这个子类型不是确定的一个，可有
  多个选择，来满足应用程序的多方面的需要，只要该应用是可行的。
4.  5.  Application Media Type（ 应用类型）
      "application"（应用）类型用于不连续的、离散的数据，这些数据不适合其他的
   类型，但作为一种数据必须被应用程序处理。这种信息必须被应用程序在用户看见和
   使用前处理。 "application"（应用）类型的其他的用途包括文件传输、电子数据表、
   有时序的电子邮件数据和计算语法。（后者，特别地，能引起安全性问题，故被实现
  者重视，在"application/PostScript"类型中有关这方面详细的讨论。） [Page 12]
     例如，一个会议的时间安排可能定义一个标准的关于被提议的会议日期信息的
  描述，一个聪明的用户代理会使用这些信息管理一个用户的对话，然后可能发送关于
  那个对话的额外的材料，更一般地，已经开发出几个活性的消息语言，它们可用来编
  写一些特殊的程序被发送到一个远程接口位置并且自动地在接受者环境中运行。
     那样的程序可能被定义为"application"类型。这个文档定义了两个子类型：
   octet-stream,（8bit流） and PostScript（标记）.
   "application"（应用）的子类型不是应用的名字和它的一部分名字，在这个应用中
  数据是已定义的。这不是意味着，然而，任何一个应用程序的名字会作为一个
  "application"的子类型。   
4. 5. 1. Octet-Stream Subtype（8bit子节流子类型）
    Octet-Stream（8bit子节流）子类型的主体部分包括任意的二进制数据。当前的设置
的参数定义为:  
    (1)PYTE--普通的类型或二进制数据。这是有意作为人类可接受的信息形式而不是其他
的任何一个机械的处理。
   （2）PADDING--由二进制流组成的填补的比特数量是根据实际的内容产生附加的的8bit
子节数据。这在当总的比特数不是8的倍数时是有用的。
    这两个是可选的。
    另外的参数，"CONVERSIONS"，在RFC 1341 中定义，但是已经不用了。RFC 1431也定
义了"NAME"参数的用法。它表示一个用来写数据的文件的文件名。在后来的RFC文档中反对
在分开的内容中使用该头域。
   推荐的为一个执行接收"application/octet-stream"的实体的使用方法是简单的把数据
放到一个文件中，如使用Content-Transfer-Encoding（内容传输编码），或使用它作为一
个用户定义的进程的输入。          [Page 13]
   为了减少传输抵赖，它强烈建议执行中不用机械地路径搜索，在那里武断地命名一个程
序的参数作为输入。  
4. 5. 2. PostScript Subtype（标注类型）
   "application/postscript"的类型显示一个有标注的程序。通常允许两个不同的标注
语言；起始的标注1变量在[POSTSCRIPT]中描绘，另外一个标注变量在[POSTSCRIPT2]描绘。
   标注是一个Adobe体系公司的一个注册商标，MIME类型的使用
"application/postscript"意味着商标的所有的权利。
     标注语言定义提供了设施，为了内部的特殊的语言特征定义，用在程序中使用。这种
特殊语言的标号特征叫做标注文档结构规范或DSC。DSC是非常普通和充分的用于常规的信
息系统中。不管有没有要求，它被强烈的推荐使用，作为一个互用性的辅助。缺乏常规的习
惯性的结构的文档不能让人相信会在一个给定的环境下工作。同样地，一些系统可能设定最
坏的情况并拒绝处理无结构的文档。
   普通目的的执行标注细节是有严重的安全性隐患，实现者会气馁于发送一些带标注体
"off- the-shelf"的翻译。然而它通常是安全的，在发送标注给一个打印机时，在那里通过
一个典型的打印环境潜在的伤害是很大的，执行者应该考虑所有的下面个情况，在他们增加
交互式的显示标注体给他们的MIME读者的时候。 
   下面是这部分的一些概要，虽然可能不全，和在标注实体传输中的可能出现的问题。
   （1）PostScript语言危险的操作包括，但不是限制，"deletefile", "renamefile", 
"filenameforall", 和 "file"."File"只在一些费标准的输入输出应用中是危险的。执行可
能定义非标准的文件操作；这些可能产生对安全的危险。 "Filenameforall"文件搜索操作
通配符 ，在第一次出现时无危险的。                                        
          然而，这种操作潜在的暴露有用的信息，这种信息可能本身是敏感的。  
 消息发送者应该避免使用有潜在危险的文件操作符，既然这些操作符是十分可能引发安全
问题。消息接受和显示软件应该消除所有的安全隐患的文件操作符或采取特殊的方法。当
PostScript 解释器处理文件时，这些操作符应该被当作外部的代理。那样的话，使and/or
检查应该在到达解释语言本身之前完成。注意确保没有enabling full函数方法存在。        
           
    (2)  PostScript 语言给现有的标准的解释器提供工具或服务等。外部环境的改变，
通常保留在文件里，有时也会存于容易丢失的内存中。与解释器相关的操作和文件有潜在的
接口。然而，无限制地使用会导致拒绝服务。PostScript解释器的操作包括exitserver操
作和startjob操作。消息发送和接收软件不应该生成PostScript，而是让解释器来完成，
既然退出的能力可能是难以获得的，在PostScript安全执行时。消息发送和接收软件应该
完全不能有能力来保留PostScript环境的改变，通过排除或禁止"startjob" 和
"exitserver"操作。 如果这些操作不能排除或完全的禁止和他们相关联的密码，就应该设
置一个hard- to-guess值。 
    （3) PostScript 提供操作来设置system-wide和device-specific参数。这些参数设
置可能保留交叉的工作也可能对解释器正确操作造成危险。PostScript设置系统和设备
参数的操作包括，但不仅限于，    "setsystemparams" 和 "setdevparams"操作。消息发
送软件不应该产生依靠系统和设备参数设置能正确操作的PostScript。设置这些参数的能
力可能在安全的PostScript执行中被禁止。消息发送和显示软件有能力禁用系统和设备参