[转]HTTP MIME编码

一般www_urlencode 因为有些不安全的字符所以需要编码

RFC 1738指明了统一资源定位(URLs)中的字符应该是US-ASCII字符集的子集。这是受HTML的限制,另一方面,允许在文档中使用所有ISO-8859-1(ISO-Latin)字符集。这将意味着在HTML FORM里POST的数据(或作为查询字串的一部分),所有HTML编码必须被编码。

ISO-8859-1 (ISO-Latin)字符集

在下表中,包含了完整的ISO-8859-1 (ISO-Latin)字符集,表格提供了每个字符范围(10进制),描述,实际值,十六进制值,HTML结果。某个范围中的字符是否安全。

Character range(decimal)TypeValuesSafe/Unsafe
0-31ASCII Control CharactersThese characters are not printableUnsafe
32-47Reserved Characters'' ''!?#$%&''()*+,-./Unsafe
48-57ASCII Characters and Numbers0-9Safe
58-64Reserved Characters:;<=>?@Unsafe
65-90ASCII CharactersA-ZSafe
91-96Reserved Characters[/]^_`Unsafe
97-122ASCII Charactersa-zSafe
123-126Reserved Characters{|}~Unsafe
127Control Characters'' '' Unsafe
128-255Non-ASCII Characters'' '' Unsafe

所有不安全的ASCII字符都需要编码,例如,范围(32-47, 58-64, 91-96, 123-126)。
下表描述了这些字符为什么不安全。   

CharacterUnsafe ReasonCharacter Encode
"<"Delimiters around URLs in free text%3C
>Delimiters around URLs in free text%3E
.Delimits URLs in some systems%22
#It is used in the World Wide Web and in other systems to delimit a URL from a fragment/anchor identifier that might follow it. %23
{Gateways and other transport agents are known to sometimes modify such characters %7B
}Gateways and other transport agents are known to sometimes modify such characters%7D
|Gateways and other transport agents are known to sometimes modify such characters%7C
/Gateways and other transport agents are known to sometimes modify such characters%5C
^Gateways and other transport agents are known to sometimes modify such characters%5E
~Gateways and other transport agents are known to sometimes modify such characters%7E
[Gateways and other transport agents are known to sometimes modify such characters%5B
]Gateways and other transport agents are known to sometimes modify such characters%5D
`Gateways and other transport agents are known to sometimes modify such characters%60
+Indicates a space (spaces cannot be used in a URL)%20
/Separates directories and subdirectories%2F
?Separates the actual URL and the parameters%3F
&Separator between parameters specified in the URL%26

如何实现

字符的URL编码是将字符转换到8位16进制并在前面加上''%''前缀。例如,US-ASCII字符集中空格是10进制
的32或16进制的20,因此,URL编码是%20。

文章出处:http://hi.baidu.com/java_ruby/blog/item/38170c17ffa037014b90a76b.html

MIME协议(中文版)》,DOC格式,大小89KB。 内容预览: MIME结构 一、 RFC822协议 RFC822 文档定义了邮件内容的主体结构和各种邮件头字段的详细细节,但是,它没有定义邮件体的格式,RFC822文档定义的邮件体部分通常都只能用于表述一段普通的文本,而无法表达出图片、声音等二进制数据。另外,SMTP服务器在接收邮件内容时,当接收到只有一个“.”字符的单独行时,就会认为邮件内容已经结束,如果一封邮件正文中正好有内容仅为一个“.”字符的单独行,SMTP服务器就会丢弃掉该行后面的内容,从而导致信息丢失。 由于 Internet的迅猛发展,人们已不满足于电子邮件仅仅是用来交换文本信息,而希望使用电子邮件来交换更为丰富多彩的多媒体信息,例如,在邮件中嵌入图片、声音、动画和附件。但是,由于图片和声音等内容是非ASCII码的二进制数据,而RFC822邮件格式只适合用来表达纯文本的邮件内容,所以,要使用 RFC822邮件格式发送这些非ASCII码的二进制数据时,必须先采用某种编码方式将它们“编码”成可打印的ASCII字符后再作为RFC822邮件格式的内容。邮件阅读程序在读取到这种经过编码处理的邮件后,再按照相应的解码方式解码出原始的二进制数据,这样就可以借助RFC822邮件格式来传递多媒体数据了。这种做法需要解决以下两个技术问题: (1) 邮件阅读程序如何知道邮件中嵌入的原始二进制数据所采用的编码方式; (2) 邮件阅读程序如何知道每个嵌入的图像或其他资源在整个邮件内容中的起止位置。 针对这个问题,人们后来专门为此定义了MIME(Multipurpose Internet Mail Extension,多用途Internet邮件扩展)协议。 二、 RFC822结构
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值