Wenn ich Ihre Frage richtig verstanden habe, dann nein, es gibt keinen Weg, um wirklich das zu ändern.
Die Ursache scheint eine unglückliche Designentscheidung zu sein, die vor vielen Jahren auf S3 getroffen wurde - was natürlich nicht behoben werden kann, weil es zu viele andere Dinge kaputt machen würde - was S3 mit einer falschen Variante von URL-Escaping (einschließlich, aber nicht ausschließlich, "Prozent-Codierung") im Pfadteil der URL, an den der Schlüssel des Objekts gesendet wird.
In dem Query-String (der optionale Teil einer URL nach ? aber vor dem Fragmente, falls vorhanden, die mit # beginnt), der + Charakter als gleichwertig mit [SPACE], (ASCII Dezember 32, Hex 0x20).
... aber im Pfad einer URL sollte dies nicht der Fall sein.
... aber in S3-Implementierung ist es.
So hat + nicht wirklich + bedeutet, bedeutet es [SPACE] ... und daher + kann auch bedeuten, nicht + ... was bedeutet, dass ein anderer Ausdruck + zu vermitteln ist erforderlich - und dieser Wert ist %2B der URL-Escape-Wert + (ASCII Dez 43, Hex 0x2B).
Wenn Sie Ihre Dateien hochladen, wird die + durch den Code konvertiert, den Sie verwenden (vorausgesetzt, sie versteht diese Eigenart, wie es scheint) in das Format S3 erwartet (%2B) ... und so muss es angefordert werden mit %2B so, wenn Sie die Dateien herunterladen.
Seltsam, aber nicht überraschend, wenn Sie die Datei in S3 mit einem Raum, in dem Pfad zu speichern, können Sie verlangen, es tatsächlich mit einem + oder einem Raum oder sogar %20 und alle drei von ihnen sollte die Datei tatsächlich holen .. Wenn Sie die + im Pfad sehen, was Sie möchten, können Sie das Problem umgehen, indem Sie es stattdessen mit einem Leerzeichen speichern, obwohl diese Problemumgehung als "Hack" bezeichnet werden sollte, wenn es jemals eine Problemumgehung gab. Diese Taktik funktioniert nicht mit Bibliotheken, die vorzeichenbehaftete GET URLs generieren, es sei denn, sie sind speziell dafür ausgelegt, das Standardverhalten von S3 zu ignorieren und stattdessen das zu tun, was Sie wollen ... aber für öffentliche Links sollte es im Wesentlichen gleichwertig sein.