fix: 修复URL query 被逗号拆分导致目标页参数不完整的问题

[dos1in]

问题描述

H5 页面调用：

wx.miniProgram.navigateTo({
url: '/pages/detail?data=' + JSON.stringify(data)
})

在 RN 下会进入 web-view 的消息处理，再调用 RN 路由的 navigateTo。

RN 路由解析 URL 时走：

packages/api-proxy/src/platform/api/route/index.ios.js (line 46)

const { path, queryObj } = parseUrl(options.url, true)

noDecode=true 等于不做 decodeURIComponent，但后续仍会走 parseQuery 拆 query。

在 packages/utils/src/url.js (line 100) 原逻辑：

const queryArgs = query.split(/[,&]/g)

它会同时按 & 和 , 拆参数。

之前传入的 JSON.stringify(data) 生成的 JSON 里就会包含逗号，比如：

?data={"a":1,"b":2}

会被拆成：

data={"a":1
"b":2}

导致目标页拿到的 query.data 在 JSON.parse(query.data) 时报错。

---

修复方案

当前修复方式是noDecode=true的情况下不应再把,当 query 分隔符。

另外补充了该问题场景下的相应的测试用例。

[hiyuki]

emm....parseQuery传递noDecode只是为了和微信处理行为保持一致，但是拼接参数时本身也应该encode的吧，否则像传递子url的场景比如：redirectUrl=https://didi.com?a=1&b=2，这种情况下还会基于&把参数给拆错，但我们不可能也不按照&来拆分参数。

但是说实话我也不记得为什么parseQuery会同时按 & 和 , 拆参数，看上去很奇怪，感觉可以直接改为只按照&拆分

[dos1in]

& 和 , 拆参数，看上去很奇怪，感觉

是的，没理解这么拆分的理由，以为有什么特别的考虑，所以按最小改动来调整了。

[hiyuki]

哦我确认了这块逻辑应该是参考loader-utils中的parseQuery编写的，可能是为了兼容webpack内部的某些request格式？
以及也确认了w3c规范中query string标准就是使用&来进行分隔参数的，可以直接把分隔符改为单&，但是建议业务拼接参数时还是统一经过encode

[dos1in]

utils中的parseQuery编写的，可能是为了兼容webpack内部的某些request格式？
以及也确认了w3c规范中query string标准就是使用&来进行分隔参数的，可以直接把分隔符改为单&，但是建议业务拼接参数时还是统一经过encode

好的，我看着调整下