有两个文件,文件名分别为 [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 的那部分。
总结,( ) !这种字符为url编码的保留字符。 捷径里的url编码不会对这些进行编码,但是捷径里的http请求需要对这些字符编码的url。假如对这些字符没有编码,请求不会报错,而是会截断url。
1
Dreax 2 天前 via iPhone
把右括号 URLencode 试试 或者把文件名从 path 改到 query 里
|
2
PTLin OP @Dreax 原来是捷径自带的 url 编码 不会处理!()这种保留字符,而捷径的 http 请求需要编码保留字符的 url 。没用自带的 url 编码搞了下请求成功了,真坑,多亏兄弟提了一句。
|
3
edwardzcn98 2 天前
个人觉得不能算 bug 吧,我在手机上复现了一下,结果一样。
习惯上应该是对各参数编码再拼接到 base URL 后,ShortCut 里的 Unicode 对“http://”开头协议这一段做了保留处理,而不是像 python urllib.parse.quote 给你变成“http%3A//”。 |
4
PTLin OP @edwardzcn98 个人感觉还是不妥,我的逻辑是:我通过拼接得到 url 后,你还给我提供了 url 编码,很明显就实在告诉我编码后的 url 可以正确发起请求,但是时候编码后 url 发起请求竟然会把 url 截断,这个我认为是不符合这种低代码平台的编程习惯和逻辑的。
为此我不得不在服务器端对文件名进行编码,因为捷径没提供 url 解码,我还要提供接口解码,最后才能得到预期的行为。 |
5
everfly 1 天前
这个可能是快捷指令的 url 请求方式处理不当导致,你试试看换成用 safari 获取内容呢?看看打开的连接是不是被截断的。
|
6
PTLin OP @everfly safari 肯定没问题。
这个快捷指令的做法就相当于 web 端你把一个字符串传给 fetch ,fetch 检测到 url 不符合自己的规范,但是没抱错,自己把 url 截断给你发出请求了。 |