再探URL拼接的坑(续:NSURLComponents默认会对url做一次decode)

对于任意一个IT从业者来说，网络是最熟悉、最基本的技术点之一。但是往往最基本的技术也是最容易入坑的技术。我们在最新版的应用中就在URL的拼接上犯了一个幼稚的错误。

需求：针对所有的url，拼接一个全局的参数。例如，原URL为https://www.baidu.com, 则需要在上述url后面加一个固定的参数a=b。

开始拿到这个需求，感觉并没有什么困难，常见的url不就如下几种样式么：

https://www.baidu.com ---------------------------------noquery                         （1）
https://www.baidu.com/act/index.html----------------------noquery                      （2）
https://www.baidu.com/act/index.html?---------------------noquery but has ?            （3）
https://www.baidu.com/act/index.html?foo=bar---------------has query                   （4）
https://www.baidu.com/act/index.html?foo1=bar1&foo2=bar2-----has query                 （5）

开始入坑：

基于上面的理解，这种拼接大概有三种情况：

针对（1）（2），拼接: ?a=b

针对（3）      拼接：a=b

针对（4）（5）  拼接：&a=b

具体的实现就不细说了，也就是根据url中？的位置进行分割判断，最后拼接。

上线后出问题了，有一些页面反馈打不开了。经过排查发现，只要url中存在“#”这个符号，且h5或者h5后台有逻辑依赖了它，则会出问题。我们先看几种存在问题的url的样式：

https://www.baidu.com?/#&a=b
https://www.baidu.com#origkey=origval/originkey2=origval2?a=b
https://www.baidu.com?key=val#origkey:origval/originkey2:origval2&a=b

上述不同情况下url在加载过程中会有不同的问题，这个主要取决于#后面的部分如何使用。问题很显然，我们在拼接参数的时候没有充分考虑#的情况。

那么这个#到底是何方大神？到底在URL中的作用是什么？这个还要从URL的构成说起：

http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

如上URL，其基本构成

scheme: http
host:www.aspxfans.com
port:8080
path:/news/index.asp
query:boardID=5&ID=24618&page=1
fragment:name

可见，一般情况下，？后面的是a=b的样式是query，而#后面是fragment。（这句话有毛病，后面我们再说）

query是用于传递参数，一般为key-value的形式，而fragment的作用在这篇文章中有详细的介绍：

https://www.jianshu.com/p/2c07fbb52b45

一言以蔽之：fragment有很多取巧的特性。我们上述未考虑fragment的情况的参数拼接，实际上会破坏fragment的机制。导致跳转异常。

如何正确的给URL拼接参数：

答案是根据url的标准来。

如上分享，url的组成是固定的，原生给url拼接参数本身是为了在请求时把一对key-value带过去，所以，拼接的元素应该是query，而非其他。那么，如何正确的拼接参数到query呢？很多时候，我们会用上述的想法，在？#上做文章。但是url实在太灵活了。我们依据某些特征的分割总会有问题。比如我们用？来分割下面的url：

https://www.baidu.com/#?a=b

很遗憾，这里的a=b虽然看起来很像参数，应该属于query，但是实际上它却属于fragment。

所以，我们就不要自己动这种歪脑筋了。各种系统都有系统方法帮我们分解url，然后合成url。以OC为例，拼接query的代码如下：

NSURLComponents *components = [NSURLComponents componentsWithString:url];
NSString *query = components.query;
NSString *tmpQuery = @"a=b";
query = (query&&![query isEqualToString:@""])? [query stringByAppendingString:[NSString stringWithFormat:@"&%@",tmpQuery]] : tmpQuery;
components.query = query;
NSString *resulturl = components.URL.absoluteString;

以上使用了NSURLComponents类来分解原url，然后把新的参数拼接到query中，再生成新的url，简单明了！

完！

-------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------

人生在世，少立flag啊！

前面提到了我们使用NSURLComponents成功实现了按照url的标准添加了参数。业务上线两个版本，突然有业务反馈，他们的url被过度decode了。

问题的排查很艰辛：业务反馈重装App是没有问题的，只有升级的用户才有问题。我们排查从两个方面入手：第一、对比升级前后的差异，这部分浪费的时间太多；第二、排查显式的decode的地方。后来猛然想到我们新增上述参数是有条件的，是不是被这个参数搞的，随即将条件调整到满足添加参数的条件，成功复现问题。

坑爹的 NSURLComponents 会默认对url做一次decode！！！特此Mark！！！！

--------------------------------------------------------------------------------------------

问题的解决：

以上问题会让我们产生一个直觉：苹果真的这么愚蠢吗？设计出这么渣的API。但是事实是，苹果还有一个API不会decode url------------------percentEncodedQuery.当前还有与它对应的好几个兄弟。它可以保留被encode过的部分。以此替换前面的query就没有问题了。

教训：仔细看文档！！！！！！！！！！！！！！！！！！