2010-01-22 16 views
6

Je voudrais utiliser -[NSURL parameterString] pour analyser les paramètres d'une URL que j'ai été passé. Il dit que l'URL doit être conforme à RFC 1808 mais maintenant se demandant si le nôtre fait?!? Nous utilisons quelque chose comme:Paramètre de la chaîne NSURL Confusion avec l'utilisation de ';' vs '&'

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

mais RFC 1808 ne mentionne jamais l'esperluette (&) comme séparateur de paramètre valide (au moins la façon dont je l'ai lu). Il suggère le point-virgule (;). Peut-être parce qu'il a été rédigé en 1995? A le & remplacé le ;? Si oui, quelqu'un vérifie-t-il si parameterString de NSURL va aussi analyser avec & comme délimiteur?

Quelle est la «bonne» façon de creuser un grand trou? RFC1808 ne définit pas le format interne de la chaîne de requête.

Répondre

8

Selon RFC 1808 (. 2.1 URL Syntactic composants) syntaxe correcte est la suivante:

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

Il dit des informations de requête est formaté conformément à la section 3.3 de la RFC 1738 qui nous dit:

" Dans les composants path et searchpart, "/", ";", "?" Sont réservés. "

Pour moi, le dit plus haut que dans votre URL le chemin (à votre CGI) est:

http://server/path/query 

et la requête est:

property1=value1&property2=value2 

qui ne contient pas de caractères réservés. Donc vous allez bien.En fait, l'utilisation du « & » comme séparateur dans la chaîne de requête provient ici de la CGI specification et non l'URL RFC:

« Les données du formulaire est un flux de paires nom = valeur séparées par le caractère &. »

+0

très utile ... merci! difficile de ** rechercher ** pour ce genre de choses sur le Web parce que chaque URL friggin "hits" d'une manière ou d'une autre. – Meltemi

2

Je crois que le point-virgule 1808 parle d'informations supplémentaires d'un type différent (sur les chemins), qui en pratique ne sont jamais utilisées. Pour autant que je puisse le voir, l'interface NSURL n'inclut aucune méthode traitant de l'analyse/découpage du contenu de la chaîne de requête elle-même, donc cela ne présente aucun intérêt pour la classe, et votre URL est conforme à 1808.

En fait, les chaînes de requête n'ont pas de format défini par RFC; vous pouvez parfaitement y mettre n'importe quelle chaîne et les récupérer intactes côté serveur. Cependant, la norme HTML décrit un moyen de créer des chaînes de requête à partir du contenu du formulaire, et ce format application/x-www-form-urlencoded est utilisé par la plupart des scripts côté serveur.

Selon l'article HTML4 17.13.4.1, & est les navigateurs de séparation des paramètres must utiliser pour créer des chaînes de requête à partir de plusieurs paramètres, donc oui, vous devez prendre en charge l'esperluette comme séparateur de paramètres. HTML4 recommande que les scripts côté serveur acceptent le point-virgule comme un séparateur alternatif à l'esperluette dans les chaînes de requête, car cela évite plus d'échappement. Mais il ne l'exige pas, et en effet (malheureusement) de nombreux serveurs/environnements de lecture de formulaires n'acceptent pas le point-virgule à cette fin.