2010-01-22 2 views
6

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

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

но RFC 1808 никогда не упоминает амперсанд (&) в качестве действительного параметра сепаратора (по крайней мере, как я читал). Он предлагает точку с запятой (;). Может быть, потому, что он был составлен в 1995 году? Имеет & заменен ;? Если кто-нибудь будет проверять, будет ли параметр NSString параметром strring также обрабатывать & как разделитель?

Что такое «правильный» путь, прежде чем мы вырываем большую дыру?

ответ

8

В соответствии с RFC 1808 (. 2,1 URL синтаксический Components) Правильный синтаксис выглядит следующим образом:

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

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

" В пределах пути и компонентов поиска, «/», «;», «?» Зарезервированы ».

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

http://server/path/query 

и запрос:

property1=value1&property2=value2 

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

«Форма данных представляет собой поток Name = пар значений, разделенных & характер.»

+0

очень полезно ... спасибо! трудно ** искать ** для этого материала в Интернете, потому что каждый URL-адрес friggin «попадает» так или иначе. – Meltemi

2

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

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

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

Смежные вопросы