application/x-www-form-urlencoded字符串是一种编码类型 当URL地址里包含非西欧字符的字符串时 系统会将这些字符转换成application/x-www-form-urlencoded字符串
表单里提交时也是如此 当包含非西欧字符的字符串时 系统也会将这些字符转换成application/x-www-form-urlencoded字符串
然而 在向服务器发送大量的文本 包含非ASCII字符的文本或二进制数据时 这种编码方式效率低 这个时候 就要使用另一种
编码类型 multipart/form-data 比如在 在做上传的时候 表单的 enctype 属性一般会设置成 multipart/form-data
网页中的表单使用POST方法提交时 数据内容的类型是 application/x-www-form-urlencoded 这种类型会
1.字符"a"-"z" "A"-"Z" "0"-"9" "." "-" "*" 和"_" 都不会被编码
2.将空格转换为加号 (+)
3.将非文本内容转换成"%xy"的形式 xy是两位16进制的数值
4.在每个 name=value 对之间放置 & 符号
不同操作系统间的差异性
差异性能引起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