Если я правильно понимаю ваш вопрос, то нет, нет никакого способа, чтобы действительно изменить это.
Причина, по-видимому, является неудачным дизайнерским решением, принятым на S3 много лет назад, что, конечно же, не может быть исправлено, потому что оно сломает слишком много других вещей, что связано с S3, используя неправильный вариант URL-экранирование (которое включает, но не ограничивается «процентным кодированием») в части пути URL-адреса, где отправляется ключ объекта.
В строке запроса (необязательная часть URL после ? но до фрагмента, если он присутствует, который начинается с #), то + символа считаются эквивалентным [SPACE], (ASCII Dec 32, Hex-0x20).
... но на пути к URL-адресу это не так.
... но в реализации S3, это.
Так + на самом деле не означает +, это означает [SPACE] ... и поэтому + не может также означать + ... что означает, что другое выражение требуется передать + - и это значение %2B , скрытое с помощью URL значение + (ASCII Dec 43, Hex 0x2B).
При загрузке файлов, то + преобразуется в код, который вы используете (если он понимает эту странность, так как, видимо, это делает) в формат S3 ожидает (%2B) ... и поэтому он должен быть запрошен используя %2B, поэтому при загрузке файлов.
Как ни странно, но не удивительно, если вы храните файл в S3 с пробелом в пути, вы можете запросить его с + или пробелом или даже %20 и все три из них фактически должны извлечь файл .. так что если просмотр + в пути - это то, что вы хотите, вы можете сортировать работу по проблеме, сохраняя ее вместо пробела, хотя это обходное решение заслуживает того, чтобы быть описанным как «взломанный», если это когда-либо обходное решение. Эта тактика не будет работать с библиотеками, которые генерируют предварительно подписанные URL-адреса GET, если они специально не предназначены для игнорирования стандартного поведения S3 и делают то, что вы хотите, но ... но для общедоступных ссылок оно должно быть по существу эквивалентным.