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