そのため、スペースをバケット/ファイル URL にAWS変換します。+ただし、既に含ま+れているファイル名は としてエンコードされ%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
私は AWS 愛好家ですが、S3 の元のアーキテクトが+、URL のパスを ASCII 0x20 (「スペース」) と同等であるかのように解釈する必要があると判断したときに、非常に不幸な誤りを犯したことを認めなければなりません。
この+文字は、クエリ文字列の一部である場合にのみ、この意味を持ちます。パスでは、文字どおりに解釈されているはずです。
正しくエンコードおよび解釈された URL のパスでは、+は と同等%2Bです。
したがって、S3 が正しい URL を誤って処理する原因となる根本的な欠陥のため、質問に対する信頼できる答えはありません。
%2B例の URL がブラウザーで使用された場合、S3 はそれらがスペースであると想定するという事実を考えると、使用する URL を変換するのではなく、S3 との対話でそのまま使用することによって、おそらくあなたの関心が最もよく満たされるでしょう.. . 実際の経験から、これらの URL の元のソースが実際に S3 と対話し、一貫したエンコーディングで後で使用するためにそれらを保存せずに実際に変換したことが示唆されない限り%2B、その場合、それらが間違って提供されているという議論がなされる可能性がありますが、技術的な理由よりも政治的な理由で、とにかくそれらを変換する必要があるかもしれません。
しかし、すでに疑っているように見えますが、その答えは簡単ではありません。