怎么做URL encoding
URL encoding分为两个步骤：
- 获取字符对应的16进制数字。比如”:” UTF-8对应的10进制是58，16进制是3A，所以这一步”:”得到”3A”。
- 在Step1的结果前面加”%”，这一步得到”%3A”。
URL encoding的原则
谁生产Url，谁负责encode规则。原则上只encode查询参数的value部分，查询参数的key以及path避免特殊字符。
encode仅一次，decode仅一次。
保留字符必须encode
非保留字符不能encode
其它字符强烈建议encode
URL iOS开发中URL encode的方法编写
有三个函数或系统方法用于URL encode，CFURLCreateStringByAddingPercentEscapes(9.0废弃)，stringByAddingPercentEscapesUsingencode（9.0废弃），
stringByAddingPercentencodeWithAllowedCharacters（系统推荐）。该系统推荐方法默认使用了UTF8编码然后再根据我们指定允许的字符集完成percent编码。通常我们在拼接GET请求URL时使用URL encode。
核心代码
NSCharacterSet *allowedCharacterSet = [NSCharacterSet characterSetWithCharactersInString:@"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_.~"];
NSString *urlEncodingValue = [value stringByAddingPercentEncodingWithAllowedCharacters:allowedCharacterSet];
URL encode中的 + 与 空格
在使用过base64编码的童鞋多半会知道，基础base64衍生了web safe base64，更改了编码字符集，其中基本表中会出现+和/字符，这个一般会被浏览器理解成空格和路径分割符。所以为了让其工作正常，需要把索引表的最后两个字符+和/分别替换成点 . 和下划线 _ 。+号经过percent编码后为%20，而20正是空格的ASCII码，这大概是浏览器的设计者将+理解成空格的原因。
那么在URL encode中是不是需要针对性的指定许可字符集，对+号和空格做处理防止混淆呢。实际上我们在之前使用Unreserved Characters对内容做编码时，并没有允许+和/符号出现在内容项的编码结果中。
因此，正确的使用percent编码，当传入的参数字典中包含有+号和/字符也是可以放心的。在传入参数是base64的结果时，并不需要特别的将base64换成web safe base64。
由于不同scheme或协议对URI格式有不同的要求，RFC关于对哪些内容编码，采用何种过滤原则不做硬性规定。而将决定权延后到执行时由开发者根据需要决定。通常遵循以下原则：
1.不要对Unreserved Characters做percent encode编码。
2.除了保留字符和非保留字符外的所有字符，必须使用percent encode进行编码。
3.保留字符不用于URI分隔符，而是用于其它位置，比如query部分的value时，要对这时用到的保留字符做percent encode编码。
4.当两个URI的字符几乎对等，区别只在于一个对某些字符用的原有字符，另一个URI对这些字符做了percent encode时。绝大部分情况下，这两个URI应当被认为是不同的两个URI。因此，不应当对保留字在作为保留字的使用场景时使用percent encode编码。
不正确的URL encode可能导致的问题
有的iOS开发者拿到 GET请求URLString和参数字典后，先拼接参数，然后再对整个字符串做URL encode，造成不能区分某些字符是处于分割组件的作用，或者是作为组件的content。这是千万不可取的，可能发生如下问题：
- 1.如果没有正确过滤，比如http://www.baidu.com做编码后变成了http%3a%2f%2fwww.baidu.com%2findex.htm，将不能正常访问。 也就是说，为了支持对拼接后的字符串作URL encode, 必须对整个拼接后的字符串禁止对所有URI的保留字作编码，比如&字符，这就造成了问题2和3。
-
- 当构建参数传入{“name” : ”namepart1&namepart2”，“id” : “kk”}。此时拼接字符串编成了http://www.baidu.com?name=namepart1&namepart2&id=kk，那么如何解析得到"name"字段“namepart1&namepart2”的实际value值，以及id字段的值"kk"？
-
- 当构建参数传入{“name” : ”Mitty&isLogin=true”}。此时拼接字符串编成了http://www.baidu.com?name=Mitty&isLogin=true，如果isLogin真的是有意义的queryKey时，直接造成服务器接收了额外的参数。当然关于URL的攻击有很多，比如semantic attack, 这里不做讨论。
|