java 中的 URLEncoder 和 URLDecoder 类

/*
　　网页中的表单使用 POST

 

方法提交时，数据内容的类型是 application/x-www-

form-urlencoded，这种类型会：
　　1.字符"a"-"z"，"A"-"Z"，"0"-"9"，"."，"-"，"*"，和"_" 都不会被编码;
　　2.

 

将空格转换为加号 (+) ;

　　3.将非文本内容转换成"%xy"的形式,xy 是两位 16 进制的数值;
　　4.

 

在每个 name=value 

 

对之间放置 & 符号。

　　*/
　 　 URLEncoder 类 包 含 将 字 符 串 转 换 为 application/x-www-form-urlencoded 
MIME 格式的静态方法。
　　web 设计者面临的众多难题之一便是怎样处理不同操作系统间的差异性。这些差异
性能引起 URL 方面的问题：例如，一些操作系统允许文件名中含有空格符，有些又不允

“

许。大多数操作系统不会认为文件名中含有符号 #”会有什么特殊含义;但是在一个 URL

“

中，符号 #”表示该文件名已经结束，后面会紧跟一个 fragment(部分)标识符。其他的
特殊字符，非字母数字字符集，它们在 URL 或另一个操作系统上都有其特殊的含义，表
述着相似的问题。为了解决这些问题，我们在 URL 中使用的字符就必须是一个 ASCII 字
符集的固定字集中的元素，具体如下：
　　1.大写字母 A-Z
　　2.小写字母 a-z
　　3.

 

数字 0-9

　　4.

 

标点符 - _ . ! ~ * ' (  

和 ,)

　　诸如字符: / & ? @ # ; $ + =   

和 %也可以被使用，但是它们各有其特殊的用途，

如果一个文件名包括了这些字符( / & ? @ # ; $ + = %)，这些字符和所有其他字符就
应该被编码。
　　编码过程非常简单，任何字符只要不是 ASCII 码数字，字母，或者前面提到的标点

“

符，它们都将被转换成字节形式，每个字节都写成这种形式：一个 %”后面跟着两位 16

“

进制的数值。空格是一个特殊情况，因为它们太平常了。它除了被编码成 %20”以外，还

“

能编码为一个 +”。加号(+)本身被编码为%2B。当/ # = & 和?作为名字的一部分来使用
时，而不是作为 URL 部分之间的分隔符来使用时，它们都应该被编码。
　　WARNING 这种策略在存在大量字符集的异构环境中效果不甚理想。例如：在 U.S. 
Windows 系统中, é 

 

被编码为 %E9.   

在 U.S. Mac 中被编码为%8E。这种不确定性的存

在是现存的 URI 的一个明显的不足。所以在将来 URI 的规范当中应该通过国际资源标识
符(IRIs)进行改善。
　　类 URL 并不自动执行编码或解码工作。你能生成一个 URL 对象，它可以包括非法的
ASCII 和非 ASCII 字符和/或%xx。当用方法 getPath() 和 toExternalForm( ) 作为输出
方法时，这种字符和转移符不会自动编码或解码。你应对被用来生成一个 URL 对象的字
符串对象负责，确保所有字符都会被恰当地编码。