Подтвердить что ты не робот

Секундомер как разделитель запросов URL

Хотя для веб-серверов настоятельно рекомендуется (источник W3C, через Википедию) поддерживать точку с запятой в качестве разделителя элементов URL-запросов (в дополнение к амперсанду), в целом этого не наблюдается.

Например, сравнить

http://www.google.com/search?q=nemo & oe = utf-8

http://www.google.com/search?q=nemo ; ОЕ = UTF-8

Результаты. (В последнем случае точка с запятой рассматривается или использовалась во время написания этого текста как обычный строковый символ, как если бы URL был: http://www.google.com/search?q=nemo% 3B oe = utf-8)

Хотя первая библиотека разбора URL, которую я попробовал, ведет себя хорошо:

>>> from urlparse import urlparse, query_qs
>>> url = 'http://www.google.com/search?q=nemo;oe=utf-8'
>>> parse_qs(urlparse(url).query)
{'q': ['nemo'], 'oe': ['utf-8']}

Каково текущее состояние принятия точки с запятой в качестве разделителя, и каковы потенциальные проблемы или некоторые интересные заметки? (с точки зрения сервера и клиента)

4b9b3361

ОТВЕТЫ

Ответ 1

Рекомендация W3C от 1999 года устарела. Текущее состояние, согласно 2014 W3C Рекомендация, заключается в том, что точка с запятой теперь незаконна в качестве разделителя параметров:

Чтобы декодировать полезную нагрузку приложения /x -www-form-urlencoded, следует использовать следующий алгоритм. [...] Результатом этого алгоритма является отсортированный список пар имя-значение. [...]

  • Пусть строки являются результатом строгого разделения полезной нагрузки строки на символы U + 0026 AMPERSAND (&).

Другими словами, ?foo=bar;baz означает, что параметр foo будет иметь значение bar;baz; в то время как ?foo=bar;baz=sna должно приводить к foo bar;baz=sna (хотя технически незаконно, так как второй = должен быть экранирован до %3D).

Ответ 2

Пока ваш HTTP-сервер и ваше серверное приложение принимают точки с запятой как разделители, вам должно быть хорошо идти. Я не вижу недостатков. Как вы сказали, спецификация W3C на вашей стороне:

Мы рекомендуем, чтобы разработчики HTTP-сервера и, в частности, разработчики CGI поддерживали использование ";" вместо "&" чтобы спасти авторов от бегства "&" символов таким образом.

Ответ 3

Я согласен с Бобом Аманом. Спецификация W3C предназначена для упрощения использования гиперссылок с привязкой с URL-адресами, которые выглядят как формы запросов GET (например, http://www.host.com/?x=1&y=2). В этом контексте амперсанд конфликтует с системой для ссылок на символьные сущности, которые начинаются с амперсанда (например, "). Поэтому W3C рекомендует веб-серверам разрешать использование точки с запятой в качестве разделителя полей вместо амперсанда, чтобы упростить запись этих URL-адресов. Но это решение требует, чтобы авторы помнили, что амперсанд должен быть заменен чем-то и что ; является равноправным полевым разделителем, хотя веб-браузеры универсально используют амперсанды в URL-адресе при отправке форм. Это, возможно, сложнее, если вспомнить, как заменить амперсанд на & в этих ссылках, как это было бы сделано в другом месте документа.

Хуже того, пока все веб-серверы не будут использовать точки с запятой в качестве разделителей полей, авторы URL-адресов могут использовать этот ярлык только для некоторых хостов и должны использовать & для других. Они также должны будут изменить свой код позже, если данный хост перестает допускать разделители с запятой. Это, безусловно, сложнее, чем просто использовать &, который будет работать на каждом сервере навсегда. Это, в свою очередь, устраняет любые стимулы для веб-серверов, позволяющих использовать точки с запятой в качестве разделителей полей. Зачем беспокоиться, когда все уже меняют амперсанд на & вместо ;?

Ответ 4

Короче говоря, HTML - большой беспорядок (из-за его снисходительности), и использование точек с запятой помогает упростить это МНОГО. Я полагаю, что когда я учитываю обнаруженные мной сложности, использование амперсандов в качестве разделителя делает весь процесс примерно в три раза сложнее, чем использование точек с запятой вместо разделителей!

Я программист .NET, и, насколько мне известно,.NET по своей природе не разрешает ';' разделители, поэтому я написал свои собственные методы синтаксического анализа и обработки, потому что я увидел огромное значение в использовании точек с запятой, а не в уже проблемной системе использования амперсандов в качестве разделителей. К сожалению, очень уважаемые люди (как @Bob Aman в другом ответе) не видят ценности в том, почему использование точки с запятой намного лучше и намного проще, чем использование амперсандов. Итак, теперь я поделюсь несколькими моментами, чтобы убедить других уважаемых разработчиков, которые еще не осознают ценность использования точек с запятой:

Использование строки запроса типа "? A = 1 & b = 2" на HTML-странице нецелесообразно (без предварительного кодирования HTML), но в большинстве случаев это работает. Это, однако, только из-за того, что большинство браузеров являются толерантными, и этот допуск может привести к трудно обнаруживаемым ошибкам, когда, например, значение пары "ключ-значение" публикуется в URL-адресе HTML-страницы без надлежащей кодировки (непосредственно как "? a = 1 & b = 2 'в источнике HTML). Строка QueryString типа "? Who = me+ & +you" также проблематична.

Мы, люди, можем иметь предубеждения и можем не соглашаться с нашими предубеждениями в течение всего дня, поэтому признание наших предубеждений очень важно. Например, я согласен, что я просто думаю отделить от ';' выглядит "чище". Я согласен с тем, что мое "чистое" мнение является чисто предвзятым. И другой разработчик может иметь одинаково противоположный и одинаково действительный уклон. Так что мой уклон по этому одному пункту не более правильный, чем противоположный уклон.

Но, учитывая беспристрастную поддержку точки с запятой, которая делает жизнь каждого человека в долгосрочной перспективе, не может быть правильно оспорена, если принять во внимание всю картину. Короче говоря, использование точек с запятой делает жизнь проще для всех, за одним исключением: небольшое препятствие для привыкания к чему-то новому. Это все. Всегда сложнее что-либо изменить. Но трудность внесения изменений меркнет по сравнению с продолжающейся трудностью продолжения использования & amp;.

С помощью; как разделитель QueryString делает его намного проще. Сепараторы с амперсандом более чем в два раза сложнее правильно кодировать, чем при использовании точек с запятой. (Я думаю) большинство реализаций не кодируются должным образом, поэтому большинство реализаций не вдвое сложнее. Но тогда отслеживание и исправление ошибок приводит к снижению производительности. Здесь я указываю на 2 отдельных этапа кодирования, необходимых для правильного кодирования QueryString, когда & это разделитель:

  • Шаг 1. URL кодирует как ключи, так и значения строки запроса.
  • Шаг 2. Объедините ключи и значения, такие как 'a = 1 & b = 2', после того как они закодированы с URL-адреса с шага 1.
  • Шаг 3. Затем HTML кодирует всю строку QueryString в исходном HTML-коде страницы.

Поэтому для правильного (безошибочного) кодирования URL нужно сделать специальное кодирование дважды, и не только, но это два разных, разных типа кодирования. Первый - это кодировка URL, а второй - кодировка HTML (для исходного кода HTML). Если что-то из этого неверно, то я могу найти вам ошибку. Но шаг 3 отличается для XML. Для XML вместо этого требуется кодировка символов XML (которая практически идентична). Я хочу сказать, что последняя кодировка зависит от контекста URL, будь то на веб-странице HTML или в документации XML.

Теперь с гораздо более простыми разделителями точек с запятой, процесс выглядит так:

  • 1: URL кодирует ключи и значения,
  • 2: объединить значения вместе. (Без кодировки для шага 3.)

Я думаю, что большинство веб-разработчиков пропускают шаг 3, потому что браузеры очень снисходительны. Но это приводит к ошибкам и дополнительным сложностям, когда выискивают эти ошибки или пользователи не могут что-либо делать, если таких ошибок не было, или пишут отчеты об ошибках и т.д.

Еще одна сложность в реальном использовании заключается в написании разметки документации XML в моем исходном коде как на С#, так и на VB.NET. С & Должен быть закодирован, это реальный тормоз, в буквальном смысле, на мою производительность. Этот дополнительный шаг 3 также затрудняет чтение исходного кода. Таким образом, этот трудный для чтения дефицит применяется не только к HTML и XML, но также и к другим приложениям, таким как код С# и VB.NET, потому что их документация использует документацию XML. Таким образом, сложность кодирования шага № 3 распространяется и на другие приложения.

Итак, в итоге, используя; разделитель прост, потому что (правильный) процесс при использовании точки с запятой - это то, как обычно ожидает один процесс: только один шаг кодирования должен быть выполнен.

Возможно, это не было слишком запутанным. Но вся путаница или трудность связана с использованием символа разделения, который должен кодироваться в формате HTML. Таким образом, & виновник И точка с запятой снимает все это осложнение.

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