因此AWS
将空格转换+
为存储桶/文件 URL。但是其中已经包含的文件名+
被编码为%2B
. 我很困惑如何处理这种情况。
当应用程序的输入 URL 是:
https://s3-us-west-2.amazonaws.com/mybucket/Pul0419_32_a+b.zip
我如何确定实际存在的文件Pul0419_32_a+b.zip
是Pul0419_32_a b.zip
因此AWS
将空格转换+
为存储桶/文件 URL。但是其中已经包含的文件名+
被编码为%2B
. 我很困惑如何处理这种情况。
当应用程序的输入 URL 是:
https://s3-us-west-2.amazonaws.com/mybucket/Pul0419_32_a+b.zip
我如何确定实际存在的文件Pul0419_32_a+b.zip
是Pul0419_32_a b.zip
我是 AWS 爱好者,我不得不承认,当 S3 的原始架构师决定+
在 URL 的路径中应该将其解释为等同于 ASCII 0x20(“空格”)时,他们犯了一个非常不幸的错误。
该+
字符仅在作为查询字符串的一部分时才具有此含义。在路径中,它应该按字面解释。
在正确编码和解释的 URL 的路径中,+
等价于%2B
.
因此,这个问题没有可靠的答案,因为导致 S3 无法正确处理正确 URL 的根本缺陷。
鉴于如果示例 URL 被浏览器使用,S3 会假设这些是空格,您的兴趣可能最好通过不转换 URL 来使用%2B
,而是在与 S3 的交互中按原样使用它。 . 除非实际经验表明这些 URL 的原始来源实际上已经与 S3 交互,并且确实将它们转换为%2B
没有存储它们以供后续使用一致的编码,在这种情况下,可以认为它们提供给您的参数是错误的,但是无论如何,您可能都必须对其进行改造,原因可能更多的是政治而非技术。
但是,正如您已经怀疑的那样,答案并不简单。