因此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
答案 0 :(得分：3)
AWS爱好者，我必须承认，当他们认为URL的路径中的+应该被解释为等同于ASCII 0x20时，S3的原始架构师犯了一个非常不幸的错误。 （＆＃34;空间＆＃34）。
+字符在查询字符串的一部分时仅包含此含义。在路径中，它should have been interpreted literally。
在正确编码和解释的网址的路径中，+相当于%2B。
这个问题没有可靠的答案，因为导致S3错误处理正确URL的根本缺陷。
鉴于如果浏览器使用示例网址，S3会认为这些是空格，您可能最好通过不转换网址来使用%2B来满足您的兴趣，而是将其用作 - 是在与S3的交互......除非实际经验表明这些URL的原始来源实际上已经与S3进行了交互并确实将它们转换为%2B而没有存储它们以供后续使用一致编码，在这种情况下可以说他们被错误地提供给你，但你可能不得不改变它们，原因可能是政治上的而不是技术性的。
但是，你似乎已经怀疑，答案并不简单。