Я энтузиаст AWS, я должен признать, что первоначальные архитекторы S3 сделали крайне досадную ошибку, когда решили, что +
в пути URL-адреса следует интерпретировать так, как если бы он был эквивалентен ASCII 0x20 («пробел»).
Символ +
имеет это значение только тогда, когда является частью строки запроса. В пути это следовало интерпретировать буквально.
В пути правильно закодированного и интерпретированного URL-адреса +
эквивалентно %2B
.
Таким образом, на этот вопрос нет надежного ответа из-за фундаментального недостатка, из-за которого S3 неправильно обрабатывает правильные URL-адреса.
Учитывая тот факт, что если бы URL-адрес примера использовался браузером, S3 предположил бы, что это были пробелы, ваши интересы, вероятно, будут лучше всего удовлетворены, если не преобразовывать URL-адрес для использования %2B
, а использовать его как есть при взаимодействии с S3. .. если практический опыт не показывает, что исходный источник этих URL-адресов действительно взаимодействовал с S3 и действительно преобразовал их в %2B
, не сохраняя их для последующего использования с согласованной кодировкой; в этом случае можно привести аргумент, что они предоставляются вам неверно, но вам, возможно, все равно придется их преобразовать по причинам, которые могут быть скорее политическими, чем техническими.
Но, как вы, кажется, уже подозреваете, ответ не так однозначен.
person
Michael - sqlbot
schedule
21.04.2016
$_SERVER['QUERY_STRING']
или$_SERVER['REQUEST_URI']
- person Dolbik   schedule 20.04.2016JSON
вместе сPOST
запросом - person   schedule 20.04.2016urldecode()
имя файла из строки запроса, то все, что он выводит, будет соответствовать имени файла. Он преобразует%2B
в+
и+
в пробел. - person Rasclatt   schedule 20.04.2016Pul0419_32_a+b.zip
? Откуда мне это знать? - person   schedule 20.04.2016a b
получен какa b
, аa+b
получен какa+b
. Это проблема. Я отправляюPOST
запрос с данными какJSON
. Пример ввода: `{file_path: s3-us-west -2.amazonaws.com/pts/ds/MXF/TEST/a b.mxf} - person   schedule 20.04.2016