6

因此AWS将空格转换+为存储桶/文件 URL。但是其中已经包含的文件名+被编码为%2B. 我很困惑如何处理这种情况。

当应用程序的输入 URL 是:

https://s3-us-west-2.amazonaws.com/mybucket/Pul0419_32_a+b.zip

我如何确定实际存在的文件Pul0419_32_a+b.zipPul0419_32_a b.zip

4

1 回答 1

7

我是 AWS 爱好者,我不得不承认,当 S3 的原始架构师决定+在 URL 的路径中应该将其解释为等同于 ASCII 0x20(“空格”)时,他们犯了一个非常不幸的错误。

+字符仅在作为查询字符串的一部分时才具有此含义。在路径中,它应该按字面解释

在正确编码和解释的 URL 的路径中,+等价于%2B.

因此,这个问题没有可靠的答案,因为导致 S3 无法正确处理正确 URL 的根本缺陷。

鉴于如果示例 URL 被浏览器使用,S3 会假设这些是空格,您的兴趣可能最好通过不转换 URL 来使用%2B,而是在与 S3 的交互中按原样使用它。 . 除非实际经验表明这些 URL 的原始来源实际上已经与 S3 交互,并且确实将它们转换为%2B没有存储它们以供后续使用一致的编码,在这种情况下,可以认为它们提供给您的参数是错误的,但是无论如何,您可能都必须对其进行改造,原因可能更多的是政治而非技术。

但是,正如您已经怀疑的那样,答案并不简单。

于 2016-04-21T01:43:48.363 回答