| 出版日期：1997-10-27 总期号：681 本年期号：41 |
|
 |
encode和decode
白爱民 本期推荐： 电子邮件的普及拉近了我们与世界的距离，但是针对传输电子邮件和发布新闻而设计的协议却仅能接收、发送可显示的ascii字符。我们怎样传输图像、声音、应用软件等大量的二进制文件呢？本文的介绍能给您满意的答案。 encode和decode即编码和解码。 encode是一种将二进制文件转换成可显示的ascii码文本文件格式的方法，而decode则是将转换成的ascii文件再还原为原来的二进制文件。 为什么要encode和decode 因为用于传送电子邮件和发布新闻的协议被设计成只能传送可显示的ascii字符而不能发送二进制文件。但在现实工作中常常需要在internet上通过internetmail和usenetnewsgroups将二进制文件发送出去。 二进制数据包括软件、图像、声音、影像等，它们使用了一个字节中所有256个可能的值。这256个值的某些值代表控制字符，它们或者对传输过程产生错误的控制作用，或者使数据内容不能正确的传送出去。 为了顺利发送二进制数据，发送前必须首先对该数据编码，使其成为一个可安全传输的字符集组成的文件。收件人收到编码文件后，通过解码再还原成原来的二进制文件。 encode和decode的方法 若干年来，出现了许多不同的方案，用来编码二进制文件，以便它们能够通过netmail和usenet安全成功的发送出去。这些方案有mime、uu－encoding、xx－encoding和binhexencoding等等。二进制文件经过encoding后，其内容看起来就象一些杂乱无章的字符放在一块，仅在文件的最开始部分有几行可读的句子。 无论采用那一种encode和decode方法，其基本原理都是一样：发送二进制文件的用户先对该文件进行编码，然后将编码转换后的文本文件传送出去。收件人运行decode程序解码收到的文本文件即可恢复获得原来的二进制文件。 当要传送的文件很大时还会出现更复杂的情况。某些e－mail和新闻发布系统对其传送的文件大小有限制，即只能传送小于某一长度的文件。为了解决这一问题，先要将文件划分为多个部分，分别进行编码，编码转换后产生多个文本文件。收件人必须收到所有划分的文本文件后，再进行解码、合并，然后才能获得原来的二进制文件。 编码发送和解码的方法并非只有一种，特别是我们将介绍的这四种方法，它们完全不同、相互不兼容但均可将二进制数据编码成为文本文件，这使问题变得有点复杂了，发送人和收件人都必须事先达成一致，即使同一种方法来进行编码解码工作。否则收件人无法还原得到原来的二进制数据。下面我来介绍这常用的四种方法： uu－encoding。这是历史上发明的第一个方法，它的原理很简单，但也产生过一些问题，在最初的文件编码转换中使用了空格字符，而许多邮件网关会将位于行末尾的空格字符剔除，其结果是使收件人获得的文件面目全非。后来引入了新的方法才解决了这一问题。 xx－encoding。此方法很少使用，它的出现是由于uu－encoding在使用初期时出了问题。但用该方法在使用不同字符集进行encoding时同样要避免使用空格字符。 base64。该方法是根据mime标准产生的，从而避免了使用上述两种方法会出现的问题。但是，在某些计算机中没有该方法所使用的部分字符。除了具有mime的其它优点外，这种方法还是一种最安全的方法。 binhex。可在macintosh系统环境下传送文件的方法。在macintosh机器中文件由两个部分组成：“datafork”和“resourcefork”。对文件编码转换时，首先它会再加上一个文件头部分，然后将这三个部分组成单一的一个数据流，再稍加压缩后才进行编码。 实际上，还有一些其它使用得不太广泛的编码／解码方法，如ship或btoa等，由于很难在实际工作中碰到，在此不作介绍。 采用何种方法进行encode和decode 首先是避免使用xx－encoding，它是一种陈旧的方法。而binhex必须使用于macintosh系统，它的解码程序使用并不很广泛，在其它系统中选择binhex通常是不明智的。的确，binhex声称它在编码时对文件进行了压缩，使得传输文件变得更小。但对已经压缩的文件，这就不算什么优点了。 值得一提的是，对文件进行压缩在文件传输中是很重要的。即不要试图发送一个未经压缩的文件，这会浪费宝贵的带宽。gif和jpeg图像已经是一个自压缩的格式。其它类型的数据在传输前应该总是先压缩成zip文件或其它类似的压缩格式。 因此只有uu－encoding和base64这两种方法了。其主要考虑点要放在所使用的电子邮件软件上。如果该软件是mime兼容的，提供“attach”按base64方法编码的文件的功能，那么就使用这种方法。对mime信息而言，base64是首选方法。 此外，可使用uu－encoding方法，它现在仍然是使用得最广泛的编码方法。由于越来越多的软件已成为mime兼容软件，uu－encoding方法将会被base64方法取而代这。但是只要有收件人使用老的软件系统，uu－encoding就有存在的可能性，uu－encoding方法是最安全的。 请注意，mime兼容仅指电子邮件软件能否处理而言。例如，如果你使用uuenview编码／解码软件将数据编码成base64格式，然后将编码数据“attach”在发送的信息中，则最终发送的信息已经不再是mime兼容的了。 该事实很重要，必须理解清楚。因此，如果你的电子邮件并不带有“attachment”功能，你又必须使用外部编码器时，最好使用uu－encoding方法。 文件的划分与否与划分大小标准 对所有方法来说还有另一个问题，即文件划分问题。对发件人和收件人来说，在一个单一邮件中发送任何东西是最容易的，你不会被如何对文件进行划分及再将它们合并起来所困扰。但是你必须确信发出的邮件在传输途中并未丢失内容。现在，对电子邮件来说，这已经不是什么很大的问题了。通常你能一次发送数兆字节的邮件。因此建议你先尝试送出一个完整的大文件，然后再询问你的收件人是否文件完整。如果未能收到完整文件，只有靠实验来找出可安全送出的最大文件长度。但是对新闻发布则完全不同，有许多网关仅允许发送小于某长度的新闻。通常一次仅能发送文件长度约为一千行。就是说大文件需按每千行一个部分来划分，再编码后才能成功传输出去。 必要的文件信息 当你发送文件时，应该让收件人在作解码前就知道他们得到的是什么。同样，大多数人下载编码文件后，在文件解码之前想知道的也是他们获得的究竟是什么。当他们发现他们下载的东西完全是没有用处时，他们会变得非常脑火。为了避免这种事情发生，发件人应先送一个小信息来说明该文件的内容、目的和功能等。不要只是说，你必须拥有这个文件，而要包括一些必须的文件说明信息。 对小于一千行的编码文件，你可将小信息文件附在编码文件开始。但对于较大的文件，你必须单独将信息文件发送出去。 主题行的构成 最后，我们必须面临的问题是如何为邮件建立一个适当主题。主题建立得好，收件人就能很容易地知道收到的是什么文件，对于划整为零的文件，收件人也能从主题得知，这是文件的第几个部分等等。 下面是主题的一个实例： uudeview0．5aforwindows－uudvw05a．zip（001／004） 首先在主题行的是对文件的一个简短描述，应少于40个字符；然后是一个连线“－”，后跟着编码前的文件名；最后在括号中是文件的第几部分和文件总共有几个部分组成。在这个例子中，收件人知道，他还应该在收到第2部分至第4部分后再对文件进行解码。象上例这个主题行中包括了所有必要的信息。 如果为四个部分的文件附加一个信息说明文件，通常应作为该文件的第零部分。该部分仅有文字描述，不包含有任何编码数据。对收件人而言，当看到所收到的邮件中有分成几个部分的文件，且有一个邮件的部分代号为“0”，则应先行阅读这第零部分，在这一部分中收件人能知道所收到的文件是什么内容，是否有必要对文件解码等等。 注意，如果编码文件只有一个部分，也同样应该将部分代号包括在主题上，且应为（001／001）。这样收件人就知道该邮件没有其它部分了。 小结 ·如果你的邮件或新闻是mime兼容的，可直接“attach”二进制文件时，使用base64方法。如果是使用外部编码器将编码数据包括在你发送的信息中时，采用uuencoding方法。 ·通常在邮件发送时并不必要将编码文件分成几个部分，但是如果是通过新闻组来发布新闻时，每个划分的文件部分应不超过1000行。除非文件的确太大，否则发送的部分不应超过100个。 ·发送文件时先压缩。 ·建立一个好的主题行，将所有必要的信息包括在内，以方便收件人和解码。某些软件如“uudeview”在合并文件时对主题行有特殊要求。 ·发送描述文件时先将部分代号设置为零。 |
||||||||||||||||
