hcm cloud rest call from jersey с параметром запроса с пространством [дубликат]

Вам понадобится плагин для компилятора проектора. https://github.com/non/kind-projector

51
задан Richard JP Le Guen 26 March 2011 в 14:45
поделиться

5 ответов

Пространства просто заменяются на «% 20»:

http://www.example.com/my%20beautiful%20page

81
ответ дан Community 18 August 2018 в 17:37
поделиться
  • 1
    Отредактировал вопрос, чтобы указать незашифрованное пространство. – Richard JP Le Guen 26 March 2011 в 14:46
  • 2
    Итак ... их критика неточна? – Richard JP Le Guen 26 March 2011 в 14:46
  • 3
    @Richard JP Le Guen: Это зависит от того, как вы его интерпретируете: Синтаксически URI не должен содержать буквальное пространство и должен быть закодирован; семантически, %20 не является пространством (очевидно), но представляет собой пространство. – Gumbo 26 March 2011 в 14:50
  • 4
    Я, это лучшая интерпретация, которую я могу придумать. – Richard JP Le Guen 26 March 2011 в 14:53
  • 5
    И +1000000 для цитирования источника. Этот вопрос касался не технологий, а скорее доверия и дезинформации, но все равно за 2 минуты осталось 3 других необоснованных, неопроверенных и недоказанных ответа, которые так же легко могли быть личными. Спасибо. – Richard JP Le Guen 26 March 2011 в 14:56
  • 6
    Нажатие на ссылку дает 400 страниц. Я думаю, что вам не хватает 20 после второго %. – ArtOfWarfare 8 October 2013 в 16:22
81
ответ дан Community 7 September 2018 в 02:09
поделиться
82
ответ дан Community 30 October 2018 в 06:28
поделиться

Они действительно дураки. Если вы посмотрите на RFC 3986 Приложение A, вы увидите, что «пространство» просто не упоминается нигде в грамматике для определения URL-адреса. Поскольку это не упоминается нигде в грамматике, единственный способ кодировать пространство - это процентное кодирование (%20).

На самом деле RFC даже утверждает, что пробелы являются разделителями и их следует игнорировать:

В некоторых случаях может потребоваться добавить дополнительные пробелы (пробелы, разрывы строк, вкладки и т. д.), чтобы разбить длинный URI на строки. Пробел должен игнорироваться при извлечении URI.

и

Для обеспечения надежности программное обеспечение, которое принимает пользовательский URI, должно попытаться распознать и удалить оба разделители и встроенные пробелы.

Любопытно, что использование + в качестве кодирования пространства не упоминается в RFC, хотя оно зарезервировано как суб-делиметр. Я подозреваю, что его использование либо просто конвенции, либо связано с другим RFC (возможно, HTTP).

15
ответ дан Gabe 18 August 2018 в 17:37
поделиться
  • 1
    Символ + не переводится в пробел (или наоборот) любой частью процесса HTTP-запроса в общем случае. Однако он преобразуется в пространство, когда встречается как значение параметра в приложении «application / x-www-form-urlencoded». строку запроса и часто предпочитаемую программным обеспечением браузера над %20, для краткости, когда такие строки запросов добавляются для запроса URI. Конечно, HTTP-сервер также может рассматривать обработку + как эквивалентную пробелу в путях URI, но это не указано стандартом. – Mark Reed 19 February 2013 в 06:55
  • 2
    Однако! Тот же стандарт на той же странице также упоминает: «Использование & lt; & gt; угловые скобки вокруг каждого URI особенно рекомендуется в качестве стиля разметки для ссылки, которая содержит встроенные пробелы. & quot; Так как насчет этого? – Brandon Kuczenski 5 May 2017 в 19:10

Информация есть, я думаю, частично прав:

Это неверно. URL может использовать пробелы. Ничто не определяет, что пространство заменяется знаком +.

Как вы отметили, URL-адрес НЕ может использовать пробелы. Запрос HTTP будет завинчен. Я не уверен, где определен +, хотя %20 является стандартным.

1
ответ дан orlp 18 August 2018 в 17:37
поделиться
Другие вопросы по тегам:

Похожие вопросы: