Parámetro de NSURL Confusión de cadena con el uso de ';' vs '&'

Question

Me gustaría usar -[NSURL parameterString] para analizar los parámetros de una URL que me han pasado. Dice que la URL debe ajustarse al RFC 1808, pero ahora se pregunta si la hacemos?!? Utilizamos algo como:

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

pero RFC 1808 nunca menciona el signo (&) como separador de parámetro válido (al menos la forma en que lo leí). Sugiere el punto y coma (;). Tal vez porque fue redactado en 1995? Ha reemplazado el & el ;? Si es así, ¿alguien verifica si parameterString de NSURL también analizará con & como delimitador?

¿Cuál es la forma "correcta" antes de cavar un agujero grande?

Answer 1

De acuerdo con RFC 1808 (. 2.1 URL sintáctica Componentes) sintaxis correcta es la siguiente:

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

Dice información de consulta se formatea según la sección 3.3 del RFC 1738 que nos dice:

" Dentro de los componentes path y searchpart, "/", ";", "?" Están reservados. "

Para mí lo anterior dice que en su URL de la ruta (a su CGI) es:

http://server/path/query 

y la consulta es:

property1=value1&property2=value2 

que no contiene ningún carácter reservado. Entonces estás bien.De hecho, el uso de la "&" como separador en la cadena de consulta que aquí se deriva de la CGI specification y no el RFC URL:

"Los datos del formulario es una corriente de pares nombre = valor separadas por el carácter &."

Answer 2

RFC1808 no define el formato interno de la cadena de consulta. Creo que el punto y coma 1808 está hablando de información adicional de un tipo diferente (en rutas), que en la práctica nunca se usa. Por lo que puedo ver, la interfaz NSURL no incluye ningún método que se ocupe de analizar/dividir los contenidos de la cadena de consulta en sí, por lo que esto no interesa a la clase y, de hecho, su URL cumple con 1808.

En realidad, las cadenas de consulta no tienen inherentemente ningún formato definido por RFC; perfectamente puede poner cualquier cadena en ellos y recuperarlos intactos en el lado del servidor. Sin embargo, el estándar HTML describe una forma de crear cadenas de consulta a partir de los contenidos del formulario, y este formato application/x-www-form-urlencoded es utilizado por la mayoría de los scripts del lado del servidor.

De acuerdo con la sección 17.13.4.1 HTML 4, es & los navegadores parámetro de separación del mosto usar para crear cadenas de consulta de múltiples parámetros, de modo que sí, que debe ser compatible con el símbolo de unión como un separador de parámetros. HTML4 recomienda que las secuencias de comandos del lado del servidor acepten el punto y coma como un separador alternativo al signo en cadenas de consulta, ya que eso evita más escapes. Pero no lo requiere, y de hecho (desafortunadamente) muchos entornos de servidor/lectura de formularios no aceptan el punto y coma para este propósito.