Путаница в параметре NSURL с использованием ';' против '&' - PullRequest
Новая
       29

Путаница в параметре NSURL с использованием ';' против '&'

6 голосов
/ 23 января 2010

Я хотел бы использовать -[NSURL parameterString] для анализа параметров URL, который я передал. Это говорит, что URL должен соответствовать RFC 1808 , но теперь задается вопросом, делают ли наши?!? Мы используем что-то вроде:

http://server/path/query?property1=value1&property2=value2

, но RFC 1808 никогда не упоминает амперсанд ( & ) как допустимый разделитель параметров (по крайней мере, так, как я его читаю). Это предполагает точку с запятой (; ). Возможно, потому что он был разработан в 1995 году? & заменил ; ? Если так, то кто-нибудь проверит, будет ли параметр NSURL параметр String также обрабатывать & как разделитель?

Каков "правильный" способ, прежде чем мы выкопаем большую яму?

Ответы [ 2 ]

8 голосов
/ 23 января 2010

Согласно RFC 1808 (2.1. Синтаксические компоненты URL) правильный синтаксис следующий: 

<scheme>://<net_loc>/<path>;<params>?<query>#<fragment>

В нем говорится, что информация запроса отформатирована в соответствии с разделом 3.3 RFC 1738, в котором говорится:

"В компонентах path и searchpart" / ","; ","? "Зарезервированы."

Для меня вышеизложенное говорит, что в вашем URL путь (к вашему CGI): 

http://server/path/query

и запрос: 

property1=value1&property2=value2

Который не содержит никаких зарезервированных символов. Так что ты в порядке. Фактически использование «&» в качестве разделителя в строке запроса здесь происходит от спецификации CGI , а не от URL RFC:

"Данные формы - это поток пар имя = значение, разделенных символом &."

2 голосов
/ 23 января 2010

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

На самом деле строки запросов по сути не имеют определенного RFC-формата; Вы можете прекрасно поместить любую строку в них и получить их нетронутыми на стороне сервера. Однако стандарт HTML описывает способ создания строк запроса из содержимого формы, и этот формат application/x-www-form-urlencoded используется большинством серверных сценариев.

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

...