ios 快捷指令发现了个很邪门的 bug

[PTLin]

有两个文件，文件名分别为 [aaaaa111bbbbbbbbbaaaaa)] aaaa-aaaa xx Aaaaaaa_! _ 红红红红红_! (xxxx-xxxx ww Wwwwwww!)和 file1 ，在这个文件夹启动 http 服务器。

用这个发起请求 发现第一个文件请求错误，http 服务器错误如下 错误指出第一个文件用了 http://192.168.31.26:8000/%5Baaaaa111bbbbbbbbbaaaaa 来请求的文件，而不是正确的 url 。

随后我把获取 url 编码后的内容，换成了显示，发现是正确的 url

然后无意中我把这两个请求的 url 贴到了便签中 我发现请求的错误的 url 就是便签中对 url 高亮的那部分，也就是 ios 认为的是 url 的那部分，也就是说快捷指令中只会对一个 url 请求系统认为是 url 的那部分。

[Dreax]

把右括号 URLencode 试试 或者把文件名从 path 改到 query 里

[PTLin]

@Dreax 原来是捷径自带的 url 编码 不会处理!()这种保留字符，而捷径的 http 请求需要编码保留字符的 url 。没用自带的 url 编码搞了下请求成功了，真坑，多亏兄弟提了一句。

[edwardzcn98]

个人觉得不能算 bug 吧，我在手机上复现了一下，结果一样。

习惯上应该是对各参数编码再拼接到 base URL 后，ShortCut 里的 Unicode 对“http://”开头协议这一段做了保留处理，而不是像 python urllib.parse.quote 给你变成“http%3A//”。

[PTLin]

@edwardzcn98 个人感觉还是不妥，我的逻辑是：我通过拼接得到 url 后，你还给我提供了 url 编码，很明显就实在告诉我编码后的 url 可以正确发起请求，但是时候编码后 url 发起请求竟然会把 url 截断，这个我认为是不符合这种低代码平台的编程习惯和逻辑的。
为此我不得不在服务器端对文件名进行编码，因为捷径没提供 url 解码，我还要提供接口解码，最后才能得到预期的行为。

[everfly]

这个可能是快捷指令的 url 请求方式处理不当导致，你试试看换成用 safari 获取内容呢？看看打开的连接是不是被截断的。

[PTLin]

@everfly safari 肯定没问题。
这个快捷指令的做法就相当于 web 端你把一个字符串传给 fetch ，fetch 检测到 url 不符合自己的规范，但是没抱错，自己把 url 截断给你发出请求了。

[everfly]

@PTLin 这个问题在于虽然圆括号是 URL 标准里面允许的字符，但是不同的终端处理方式不同，可能导致不符合预期的行为。所以最好是把圆括号也 URL 编码了，但是捷径里似乎没有这么做，而最后请求的时候，用的是截断之后的 URL 。

[PTLin]

@everfly 我昨天测试发现了这点，已经改完了，准备给苹果提交个建议。