Параметры URL MediaWiki без значений

Часть query в URL, кажется, состоит из пар ключ-значение, разделенных & и связанных =.

Я привык всегда использовать функцию jQuery $.param() для URL-кодирования строк моего запроса, потому что я считаю, что это делает мой код более читабельным и поддерживаемым.

За последние пару дней я обнаружил, что звоню в MediaWiki API, но при очистке моего рабочего прототипа с жестко закодированными URL-адресами для использования $.param() я заметил, что некоторые MediaWiki API включают параметры запроса с ключами, но не со значениями!

api.php ? action=query & titles=Main%20page & redirects

Обратите внимание на часть &redirects, которая не имеет значения.

$.param() jQuery принимает объект, и поскольку объекты состоят только из пар ключ-значение, невозможно передать объект, в котором один член имеет ключ, но не имеет значения.

Это нормально, поэтому я решил, что могу просто передать какое-то значение, например null, undefined или 0, но похоже, что все они обрабатываются одинаково. Я нахожу это удивительным, и мне не удалось обнаружить что-либо в документации MediaWiki API О причинах этого.

Хорошо, в моем случае легко обойтись, создав строку URL-адреса вручную. Мой вопрос: «Является ли это причудой API MediaWiki? Или особенностью конструкции кодирования URL-адресов? Где мне следует прочитать, чтобы понять причины, лежащие в основе параметров, закодированных в URL-адресах, без связанных значений?


person hippietrail    schedule 18.06.2012    source источник
comment
Не читая документы, я бы предположил, что это просто означало, что redirects рассматривался как boolean со значением true, аналогично тому, как в большинстве языков вы могли писать if(redirects) вместо if(redirects==true)   -  person ChrisW    schedule 18.06.2012
comment
Да, я предполагаю то же самое, мне просто интересно, насколько обычно это делается таким образом, и откуда такая возможность, учитывая, что инструменты для создания URL-адресов, очевидно, игнорируют этот способ.   -  person hippietrail    schedule 18.06.2012


Ответы (3)


Скорее всего, они просто проверяют, определен ли параметр. Добавление redirects в строку запроса фактически означает, что «переменная перенаправления истинна». Таким образом, добавление redirects=0 по-прежнему определяет эту переменную, и MediaWiki API отмечает, что она определена (не заботясь о ее значении).

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

person Jeff Jenkins    schedule 18.06.2012

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

На странице «Строка запроса» в Википедии в разделе «Веб-формы» говорится:

  • Каждая пара "поле-значение" разделяется знаком равенства. Знак равенства может быть опущен, если значение является пустой строкой.

Строка запроса определена в разделе 3.4 RFC 3986, но на самом деле ключ Пары -значение не являются частью стандарта и упоминаются лишь кратко:

Однако, поскольку компоненты запроса часто используются для передачи идентифицирующей информации в виде пар «ключ = значение», а одно часто используемое значение является ссылкой на другой URI, иногда для удобства использования лучше избегать процентного кодирования этих символов. .

Как видите, ничего о наличии или отсутствии значений ключей.

Что касается jQuery, оказалось, что за последние 15 месяцев было подано два отчета об ошибках / запросов на добавление функций об этом поведении:

Были внесены различные предложения, касающиеся преобразования param: null и param: undefined в param или param=.

В конце концов, в следующий выпуск jQuery 1.8 было включено исправление, которое преобразует как null, так и undefined в param= - пустую строку.

Конечно, в этом есть какой-то смысл, но в случае с MediaWiki, который не упоминался в отчетах об ошибках / запросах функций, это совсем не помогает:

http://en.wikipedia.org/w/api.php?action=query&titles=Main%20page&redirects=

возвращается

<?xml version="1.0"?>
<api>
  <query>
    <redirects>
      <r from="Main page" to="Main Page" />
    </redirects>
    <pages>
      <page pageid="15580374" ns="0" title="Main Page" />
    </pages>
  </query>
</api>

Подводить итоги:

Стандарты не определяют, что здесь следует делать, оставляя это на усмотрение реализации. MediaWiki API сделал одно, jQuery сначала упустил его из виду, а затем, когда на это указали, сделал другое. Две стороны, кажется, не знают друг друга.

Пробел в спецификации привел к несовместимым интерпретациям ... но их несложно обойти.

person hippietrail    schedule 18.06.2012

Что ж, если вы создадите небольшой тестовый веб-сервер на python или ruby ​​или что-то в этом роде и запросите URL-адрес со строкой запроса, такой как ?something, обычно вы увидите, что параметры входят как something=nil (или аналогичный).

MediaWiki написан на PHP, поэтому с ним можно работать немного по-другому, но мне кажется, вы должны быть в безопасности, просто выполняя $.params( { redirects: null } ), и он просто не будет проверять значение, поскольку он ему не нужен. В качестве альтернативы просто создайте его самостоятельно, добавив правильную строку.

person rfunduk    schedule 18.06.2012
comment
Да, работать с этим действительно легко, но мне всегда нравится по-настоящему разбираться в вещах, поэтому я хочу знать, почему это так (-: Действительно, если мне всегда нужен &redirects в URL-адресе, я могу передать любое значение, включая null. Но для кого-то которые хотели перенаправить или не основывались на какой-либо переменной или логике, здесь скрывается небольшая ошибка.Например, кто-то, разрабатывающий библиотеку MediaWiki в jQuery, должен знать, как создавать свои URL-адреса без стандартной функции создания URL-адресов jQuery. - person hippietrail; 18.06.2012
comment
$.param( $.extend( obj, shouldRedirect ? { redirects: true } : {} ) ) резал бы это. Я думаю, дело в том, что MediaWiki делает это неправильно, полагаясь на значение по умолчанию null или undefined для параметра, являющегося частью спецификации, когда ничего не указано. Таким же образом x=&y=1 также действителен. - person rfunduk; 18.06.2012