Вопрос по query-string, url, http, urlencode, uri – HTTP-запрос и сомнение в кодировке URI [закрыто]

2

Недавно я исследовал строки HTTP-запросов, задаваясь вопросом о возможностях интерфейса доступа к веб-сервисам.API, И это кажется очень заниженным.

по фактуRFC 3986 (унифицированный идентификатор ресурса (URI): общий синтаксис) Безразлично»Не говоря уже о формате фрагмента строки запроса и заканчивается определением, какие символы разрешены и как кодировать другие символы. (Я вернусь к этому позже.)

Единственной вещью, которую я нашел, была спецификация HTML о том, как формы искажаются в строку запроса (HTML 4.01; 17.13.4 Типы содержимого формы, application / x-www-form-urlencoded). Алгоритм HTML 5 кажется достаточно близким (4.10.22.5 Данные формы в кодировке URL).

Это может показаться нормальным. В конце концов, почему кто-то хочет установить формат строки запроса для всех остальных. Зачем? Но есть ли другие (кроме HTML) хорошо установленные стандарты? Кто-нибудь еще использует другой формат?

Дополнительный вопрос здесь касается [] в именах полей формы. PHP использует это, чтобы гарантировать, что все вхождения поля все присутствуют в$_GET суперглобальная переменная. (В противном случае присутствует только последнее вхождение.)

Но изRFC 3986 кажется, что ни[ ни] разрешены в строке запроса. Тем не менее, мои эксперименты с различными браузерами показали, что ни один браузер не кодирует эти символы, и они есть в URI просто так ...

Это практика реальной жизни? Или я проверяю это неправильно? Я тестировал с PHP 5.3.17 на IIS 7. Используя Internet Explorer, Firefox и Chrome. Тогда я сравнил то, что в$_SERVER['QUERY_STRING'] а также .$_GET

Другой вопрос - реальная поддержка разделения точек с запятой.

Спецификация HTML 4.01 (Б.2.2 Амперсанды в значениях атрибутов URI) рекомендует HTTP-серверам принимать точку с запятой (;) в качестве разделителя параметров (в отличие от амперсанда)&).

Любой сервер поддерживает это? Кто-нибудь использует это? Стоит ли беспокоиться об этом (при рассмотрении разрешенных форматов строки запроса для веб-службы)?

Тогда как насчет поддержки не-ASCII символов?

Спецификация HTML 4.01 (B.2.1 Не-ASCII-символы в значениях атрибутов URI) четко повторяет то, что URI, описывающий RFC, указано в первую очередь: не-ASCII символы не допускаются в URI. Тем не менее спецификация учитывает существующую практику (использования недопустимых URI) и рекомендует преобразовывать такие символы в кодировку UTF-8, а затем обрабатывать каждый байт стандартным шестнадцатеричным кодированием URI.

Из моих тестов кажется, что, например, Chrome и Firefox делают это. Но Internet Explorer не сделал и просто отправил этих персонажей, как они были. PHP частично справился с этим.$_SERVER['QUERY_STRING'] а также$_GET содержал эти символы. Но$_SERVER['REQUEST_URI'] содержащиеся? вместо.

Существуют ли какие-либо стандарты или практики, как подходить к таким случаям?

И еще один связанный с этим вопрос: как тогда авторы должны публиковать (по URI) ресурсы с именами, содержащими не-ASCII (например, национальные) символы? Учитывая все различные стороны (HTML-код, запрос отправки браузером, сохранение файла браузером на диск, запрос на получение и обработку сервером и сервер, сохраняющий файл), кажется почти невозможным, чтобы он работал последовательно. Или, по крайней мере, мне так и не удалось.

Когда дело доходит до веб-страниц, яЯ уже привык к этому и всегда заменяю национальные символы соответствующими латинскими базовыми символами. Но когда дело доходит до внешних файлов (PDF-файлы, изображения, ...) это как-то «чувствует себя неправильно » чтобы «понижаем» имена. Особенно, если ожидается, что пользователи сохранят эти файлы на диске. Как решить эту проблему?

У меня есть новые (отдельные) вопросы:stackoverflow.com/questions/12928077/http-query-string-format,stackoverflow.com/questions/12928173/http-query-string-and,stackoverflow.com/questions/12928215/...,stackoverflow.com/questions/12928295/national-characters-in-uri а такжеstackoverflow.com/questions/12928368/..., Так что этот вопрос сейчас должен быть закрыт. Adam Badura
Ваш вопрос содержит не менее 5-6 отдельных вопросов. Пожалуйста, рассмотрите возможность разделения этого вопроса на несколько вопросов, на которые можно ответить отдельно. Прямо сейчас мне нужно предоставить эссе, чтобы дать исчерпывающий ответ. Это нене подходит этому сайтус Q &Формат. jsalonen
Если вам необходимо передать определенные символы в запросах к вашему веб-сервису, вам следует рассмотреть другие способы реализации API веб-сервиса, такие как XML / SOAP или JSON / JSONP, которые так же широко используются, как и REST. Stan

Ваш Ответ

2   ответа
1

На самом деле RFC 3986 (универсальный идентификатор ресурса (URI): общий синтаксис) неничего не скажешь о формате фрагмента строки запроса

Да, это так, в разделе 3.4:

query       = *( pchar / "/" / "?" )

pchar определяется в разделе 3.3:

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

и заканчивается определением, какие символы разрешены и как кодировать другие символы.

Именно так. Это определяет формат фрагмента строки запроса.

Но из RFC 3986 кажется, что ни [, ни] не допускаются в строке запроса.

Официально да. Но не все браузеры делают это, и это нарушает их поведение. Все официальные спецификации, которые я видел (и 3986 не единственный в игре), говорят, что эти символы должны быть закодированы в процентах.

Тогда как насчет поддержки не-ASCII символов?

Символы, не входящие в ASCII, не допускаются в URI. Они должны быть закодированы в кодировке и в процентах. Фактическая используемая кодировка зависит от сервера, нет спецификации, которая позволяла бы URI указывать используемую кодировку. Различные спецификации рекомендуют UTF-8, но не требуют UTF-8, а некоторые сторонние серверы действительно не используют UTF-8.

IRI spec (RFC 3987), который заменяет спецификации URL / URI, поддерживает полную кодировку Unicode, но IRI все еще относительно новы, и многие серверы еще не поддерживают их. Однако RFC определяет алгоритмы для преобразования IRI в URI и наоборот.

Если вы сомневаетесь, процентное кодирование всего, в чем вы не уверены. Серверы обязаны поддерживать их декодирование, когда они присутствуют, перед тем как обрабатывать декодированные данные по мере необходимости.

1

Вы проверили спецификацию HTTP (RFC2616)?

Взгляните на эти части:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.2http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2

Практический совет будет использоватьBase64 кодировать поля, которые, как вы ожидаете, содержат рискованные символы, а затем декодировать их на своем бэкэнде.

Btw. Ваш вопрос действительно длинный. Это уменьшает вероятность того, что кто-то будет копаться в этом.

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