设为首页 - 加入收藏
广告 1000x90
您的当前位置:三五图库香港35图库大全 > 变换编码 > 正文

UTF-7 邮件安全的 Unicode 转换编码

来源:未知 编辑:admin 时间:2019-06-27

  本文为因特网社区提供信息。本文没有指定任何因特网标准。分发本文不受限制。

  Unicode标准,2.0版本, 以及ISO/IEC 10646-1联合定义了一种字符集,它包含了世界上大多数可书写的字符系统。(后文都直接用Unicode一词)。

  事实上,因特网邮件(STD 11, RFC 822)目前所支持的仅仅是7-bit的ASCII字符集。MIME(RFC 2045到2049)扩展了网络邮件以支持不同的媒体类型和字符集,也因此能够在邮件信息里支持Unicode了。虽然它确实提供了随着时间而增加的字符集注册的方法,但MIME既没有把Unicode定义为容许的字符集,也没有说明它要怎么编码。

  本文档描述了一种Unicode的转换编码,它只使用7-bit的ASCII字节,并且意图在文件由US-ASCII表中字符组成的限定条件下,对人来说是易读的。还说明了在MIME的内容中怎么使用这种转换编码(RFC 1641“在MIME中使用 Unicode”)。

  虽然存在着其他的Unicode转换格式,并且也足以在这样的环境下使用(最明显的就是UTF-8,还有UTF-2 or UTF-FSS),但他们都有一个缺点,就是他们使用了128-255这一范围对Unicode编码,超过了US-ASCII的范围。因此,在邮件环境中,8位字节必须要被编码。这要求让文本经历两次连续的编码,让US-ASCII范围以外的字符有一个显著的扩展,这使得非英文的使用者处于非常不利的地步。例如,使用UTF-8和MIME中的Quoted-Printable内容编码方式一起处理,让US-ASCII字符出现在一个字节里,但其 它的字符可能需要9个字节。

  UTF-7把Unicode字符编码为US-ASCII的字节,并且用替换序列编码超出范围(0-127)的字符。为了这个目的,US-ASCII 表里的一个字符就要保留作为替换字符使用。大多邮件网关和系统不能处理完整的US-ASCII字符集(例如那些基于EBCDIC的),所以UTF-7包含了在US-ASCII用于编码的预留,以便所有的邮件系统都能兼容。UTF-7应该一般用在7-bit传输的环境中,比如邮件。其他的环境中Unicode或者UTF-8还是

  16-bit字符集,Unicode,由Unicode标准,2.0版本所定义。这套字符集与国际标准组织的编码ISO/IEC 10646-1一致。 编码后形式为UCS-2;子集为300;实现等级为3,包含对10646+的前7个修正。

  注:Unicode 2.0 还进一步说明了这些字符在ISO标准组织以外的使用和交互。事实上,一个有效的10646序列就是一个有效的Unicode序列,反之也是;Unicode 协会提供对序列的解析,而ISO标准组织却一直没有。

  集合D:(直接字符)包含如下的字符(取自RFC 1521,附录B,在RFC 2045中不再出现了):

  大写字母A-Z,小写字母a-z,和10个数字0-9,和后面的9个特殊字符(注意:+和-遗漏了)

  集合O: (可选的直接字符) 包含如下的字符: (注意 \\ 和 ~ 遗漏了):

  基本原理:有两个字符 \\ 和 ~ 被遗漏了是因为在ASCII表中他们经常被重新定义变量值。

  基本原理: 衬垫字符 = 被排除了是因为UTF-7被设计用来在报头字段中使用,就如RFC 2047中的集合4。 因为RFC 2047编码中唯一易读的编码就是Q,(基于RFC 2045s Quoted Printable),所以=不适合使用(没有很多的转义序列)。这很不幸,但是却不可避免。其实,= 字符在UTF-7中也可以作为转义字符使用,如果不是使用+。

  一个UTF-7流用如下方式使用7-bit US-ASCII字节表示16-bit Unicode字符:

  规则1:(直接编码) 上面的集合D中的Unicode字符可以直接的编码为ASCII的等价物。集合O中的字符可以有随意的直接编码为ASCII的等价物,但要记得其中的很多的字符在报头字段是不合法的,或者不能正确的穿过邮件网关;

  规则2:(Unicode替换编码) 通过在前面加上转换字符+(US-ASCII字符十进制值为43),任何一个Unicode序列都可以使用集合B中的字符编码。+意味着后面的字节将被作为更改过的BASE64字母表中的元素解析,直到遇到一个不是字母表中的字符为止。这些字符中包含控制字符,比如回车和换行;因此,一个Unicode转换序列总是在一行上结束。作为一个特殊的情形,如果序列结束于一个-字符(US-ASCII值45),那么那个字符就要被关注;其他的结束字符不用关心,而且可以正常处理;

  注意:如果跟在转换字符后的第一个字符就是-,那么一个多余的必须被加上,以便结束转换序列,所以真正的-不是它关心的;

  基本原理:一个结束字符在如下的情形是必须的:在更改的base64序列的下一个字符是集合B中的部分,或者本身就是一个结束字符。通过界定编码的序列也可以增强可读性。作为特定情形,序列+-可以用来编码字符+。一个+字符之后立即跟着的字符若不是集合B的成员或者-,就是一个形式有误的序列;

  对Unicode使用更改的base64编码时候,可以首先转换Unicode的16bit的数量值为一个字节流。通过把成对中的一个当作单独的值以后,就会转换为字节对。奇数个字节的的文本是错误的形式,ISO1646 字符超过可设定地址范围的部分转换为字节对后也无法编码。基本原理:ISO/IEC 10646-1:1993(E)说明了当UCS2形式被字节流序列化时,哪个字节在前面。选定一种用来发送的规范格式,在一般网络应用中也是遵循的;基本原理:ISO 10646和Unicode标准中代码点定位的策略是一个同步一致的字

  然后,对字节流进行编码时使用了更改的base64编码算法(定义于RFC 2045),更改中去掉了衬垫字符=。在编码时候,增加了代替的0 bits以便衬垫base64编码字符的边界。在解码时,在更改的base64编码序列最后的一些bits,如果不能组成一个完整的 16-bit的Unicode字符,那么就会被丢弃。如果丢弃的bits不是0,那么这个编码序列就是有格式错误的。

  基本原理:在对更改的 Base64 进行编码时,不使用衬垫字符=,因为就象上文提及的,它与在 RFC 2047 中将它用做 Q 内容传输编码 的转义字符相冲突;

  规则3: 空格 (十进制 32),tab (十进制 9),回车(十进制 13),和换行(十进制 10)字符可以直接使用ASCII等价字符表示。事实上,应该注意到MIME传输编码也有使用这些字符的规则。如果使用并不遵循RFC 822的限制,必须要使用MIME编码而不是7bit或者8bit的一些编码,比如quoted-printable,binary,或者base64。

  鉴于给定的一组规则,Unicode字符可以经由规则1或者规则3编码,一个字符占用一字节;然后其他的Unicode字符用规则2编码,一个字符占用平均(2 + 2/3)个字节,加上一个转换开关字节用来进入更改的base64编码,加一个可选的转换跳出字节。

  UTF-7字符集对邮件传输是安全的,因此可以应用于MIME中任何内容的编码(除非出现了对行长度和行中断的强制约束)。特定的,7-bit的编码用于主体, Q内容编码用于报头的情况也可以使用。MIME字符集的标签是UTF-7,这一点对大于等于2.0版本的Unicode很重要。

  例子:这是一个MIME消息的片段,包含了一段用汉语表示日语词 nihongo 的 Unicode 序列:

  注意:为了和可能不支持Unicode与MIME的系统达到最好的互用性,在准备邮件传输正文的时候,行中断应该遵守网络惯例。这意味着行应该很短而且要使用SMTP的CRLF来标记结束。Unicode的行分隔符(十进制 2028)和段分隔符 (十进制 2029)应该被替换为SMTP的行中断。理想的情况,这应该由一个理解 Unicode的用户代理透明的处理。

本文链接:http://1763inn.com/bianhuanbianma/959.html
上一篇:简单好用的网页版在线公式编辑器
下一篇:没有了

相关推荐:

网友评论:

栏目分类

现金彩票 联系QQ:24498872301 邮箱:24498872301@qq.com

Copyright © 2002-2011 DEDECMS. 现金彩票 版权所有 Power by DedeCms

Top