我已将亚马逊s3与我在WP引擎上的托管帐户集成。一切都很好，除非涉及到带有+字符的文件。
例如，在以下情况下，文件命名为： test + 2.pdf http://support.mcsolutions.com/wp-content/uploads/2011/11/test+2.pdf =不起作用。
以下网址是亚马逊网址。请注意，+ charcter已编码。有没有办法防止/改变这个？ http://mcsolutionswpe.s3.amazonaws.com/mcsupport/wp-content/uploads/2011/11/test%2b2.pdf
其他网址正常： 亚马逊 - ＆gt; http://mcsolutionswpe.s3.amazonaws.com/mcsupport/wp-content/uploads/2011/11/test2.pdf 网站 - ＆gt; http://support.mcsolutions.com/wp-content/uploads/2011/11/test2.pdf
答案 0 :(得分：2)
如果我理解你的问题，那么不，没有办法真正改变这一点。
原因似乎是许多年前在S3上做出的一个不幸的设计决定 - 当然，现在无法修复，因为它会破坏太多其他东西 - 这涉及S3使用不正确的URL变体-escaping（包括但不限于“百分比编码”）在URL的路径部分，其中发送对象的密钥。
在查询字符串（?之后但在片段之前的URL的可选部分（如果存在，以#开头）中，+字符被视为等同于{ {1}}，（ASCII Dec 32，Hex 0x20）。
...但是在URL的路径中，不应该是这种情况。
...但在S3的实施中，它是。
所以[SPACE]实际上并不意味着+，这意味着+ ...因此，[SPACE]也不能代表+ .. 。这意味着需要使用不同的表达式来传达+ - 该值为+，网址是%2B的值（ASCII Dec 43，Hex 0x2B）。
当您上传文件时，+会被您正在使用的代码（假设它理解这个怪癖，显然是这样）转换为S3期望的格式（+）。 。所以必须使用%2B进行请求，以便下载文件时。
奇怪的是，但毫不奇怪，如果您将文件存储在S3中并在路径中留有空格，您实际上可以使用%2B或空格甚至+来请求它们以及所有这三个应该实际获取文件...所以如果看到路径中的%20是你想要的，你可以通过用空格来保存它来解决问题，尽管这种解决方法应该被描述为“破解”，如果有变通方法的话。这种策略不适用于生成预先签名的+ URL的库，除非它们专门设计为忽略S3的标准行为并按照您的意愿行事，而是......但对于公共链接，它本质上应该是当量。