Caractères autorisés dans les paramètre GET

Quels sont les caractères autorisés dans les paramètres GET sans codage ou d'y échapper? Je veux dire quelque chose comme ceci:

http://www.example.org/page.php?name=XYZ

Que pouvez-vous avoir là, au lieu de XYZ? Je pense que seuls les caractères suivants:

  • a-z A-Z)
  • 0-9
  • -
  • _

Est-ce la liste complète ou y at-il des caractères supplémentaires autorisées?

J'espère que vous pourrez m'aider. Merci à l'avance!

InformationsquelleAutor caw | 2009-09-21
  1. 80

    Il y a les caractères réservés, qui ont réservé un sens, ce sont des délimiteurs — :/?#[]@ — et subdelimiters — !$&'()*+,;=

    Il y a aussi un ensemble de caractères appelée sans réserve caractères — caractères alphanumériques et -._~ — qui ne sont pas encodés.

    Cela signifie, que quelque chose qui ne lui appartient pas sans réserve à l'ensemble de caractères est censé être codé -%, quand ils n'ont pas de signification particulière (par exemple, lorsqu'il est passé comme une partie de GET paramètre).

    Voir aussi RFC3986: Identificateur de Ressource Uniforme (URI): Syntaxe Générique

    • Merci beaucoup! Donc, je dois ajouter . et ~ à ma liste? Puis-je écrire index.le php?page=start_en-nouvelle~. sans lui échapper?
    • Il serait un peu trop audacieuse, une déclaration pour dire que vous ne pouvez pas, mais vous ne devriez pas. Si vous étiez à normaliser URI vous feriez pour pour quitter sans réserve des personnages (et seulement entière), mais il est très probable qu'il sera en fait travail sans échappement.
    • Généralement, vous avez la fonction d'échappement, qui échappe à tout ce qui doit l'être échappé. Et normalement, vous utilisez cette fonction pour échapper à la tous paramètres que vous passez.
    • Donc, je ne devrais pas utiliser ~ et . sans échappement, soit? Donc alphanumériques uniquement? Est la fonction urlencode() en PHP la fonction que vous voulez dire? J'ai pu passer tous les caractères de la fonction urlencode() et voir ce qui va sans échappement!?
    • OMG, je n'ai pas regardé attentivement votre exemple. Je pensais que c'était juste un générique tas de caractères spéciaux 😉 Non, vous n'avez pas à échapper à ceux, bien sûr, comme ils sont sans réserve. Désolé pour la confusion. Comme pour urlencode() je n'ai aucune idée si cela fonctionne correctement, il n'est pas toujours le cas avec les fonctions PHP - mais si c'est le cas alors oui, vous pouvez tester avec ça 😉 Comme je l'ai dit - échapper à tout, mais sans réserve.
    • 🙂 Merci. J'ai donc créer une page avec le nom "~my_start-page.fr" et de transmettre le nom de via GET sans aucun problème, correct? page.le php?nom=~my_start-page.fr
    • Oui, cela devrait suffire. Ces caractères sont en sécurité tant que les paramètres de la requête avec pas de s'échapper, donc si vous avez des problèmes de traitement de ce nom plus tard, je ne sais pas, mais vous pouvez passer sans problèmes 😉
    • Vous avez raison, ~ et . semblent bien fonctionner. Mais quid des autres réponses ici? Ils mentionnent d'autres personnages qui peuvent être utilisés clair ainsi. Pourquoi n'avez-vous pas de les mentionner? Sont les autres réponses de mal?
    • Je ne mentionnez RFC sur la syntaxe d'URI, n'ai-je pas? Et le plus récent de tous les Rfc mentionné aussi! 😉 En fait, comme je l'ai dit, quelques autres approches pour échapper peuvent rester impunis, mais toujours hors norme-conforme. Aussi longtemps que les Uri sont normalisées et comparé pour l'égalité dans la forme normalisée de la peine de sanction du crime 😉
    • Ainsi, le Rfc mentionné dans les autres questions sont environ 8 ans de plus et contenant des caractères spéciaux qui ne sont pas autorisés non encodée plus?
    • Je n'ai pas vraiment lire ces Rfc donc je ne sais pas ce qu'ils traitent. Mais ce que ceux qui les référencent dire, c'est qu'il traite avec caractères autorisés dans l'URL. Évidemment, & est également autorisé, mais il a une signification spéciale, alors je soupçonne ils ont répondu à une autre question.
    • Le RFC dit qu'en fait, il est autorisé à ne pas échapper les caractères /et ?. Je cherchais ce parce que Swift n'échappe pas à ces dans leur stringByAddingPercentEncodingForURLQueryParameter méthode! (Correctement, apparemment)

    InformationsquelleAutor Michael Krelin - hacker
  2. 8

    La question demande quels sont les caractères autorisés dans les paramètres GET sans codage ou d'échapper.

    Selon RFC3986 (générale de la syntaxe d'URL) et RFC7230, la section 2.7.1 (HTTP/S, la syntaxe de l'URL) les seuls personnages dont vous avez besoin pour cent-encoder sont ceux à l'extérieur de l'extérieur de la requête ensemble, voir la définition ci-dessous.

    Cependant, il existe d'autres caractéristiques, comme le HTML5, Des formulaires Web, et le obsolètes Indexé de recherche, recommandation du W3C. Ces documents ajouter une signification particulière pour certains caractères, notamment, à des symboles comme = & + ;.

    D'autres réponses ici suggèrent que la plupart des caractères réservés doivent être codées, y compris les "/" "?". Ce n'est pas correct. En fait, RFC3986 la section 3.4 de l' déconseille pour cent de codage "/" "?" caractères.

    c'est parfois mieux pour la convivialité à éviter pour cent-
    l'encodage de ces personnages.

    RFC3986 définit composant de requête comme:

    query       = *( pchar /"/" /"?" )
pchar       = unreserved /pct-encoded /sub-delims /":" /"@"
pct-encoded = "%" HEXDIG HEXDIG
sub-delims  = "!" /"$" /"&" /"'" /"(" /")" /"*" /"+" /"," /";" /"="
unreserved  = ALPHA /DIGIT /"-" /"." /"_" /"~"

    Un pour cent-le mécanisme de codage utilisé pour représenter un octet de données dans un
    composant lorsque que l'octet du caractère correspondant est à l'extérieur de la
    jeu autorisé, ou est utilisé comme un délimiteur de, ou dans, la
    composante.

    La conclusion est que XYZ partie doit encoder:

    special: # % = & ;
Space
out of query set: [ ]
non ASCII encodable characters

    À moins que des symboles spéciaux = & ; sont clé=valeur séparateurs.

    Encodage des autres personnages est autorisée, mais pas nécessaire.

    • Ce doit être la accepté de répondre - merci pour la clarification
    InformationsquelleAutor dmitri
  3. 4

    De RFC 1738 sur laquelle les caractères sont autorisés dans les Url:

    Uniquement des caractères alphanumériques, les caractères spéciaux "$-_.+!*'(),", et
    les caractères réservés utilisé pour l'usage prévu peut être utilisé
    non codée dans une URL.

    Les caractères réservés sont ";", "/", "?", ":", "@", "=" et "&", ce qui signifie que vous auriez besoin de les encoder, si vous souhaitez les utiliser.

    • Merci! Êtes-vous sûr que je peux utiliser $+!'()" sans y échapper?
    InformationsquelleAutor ctford
  4. 4

    Caractères alphanumériques et tous

    ~ - _ . ! * ' ( ) ,

    sont valables dans une URL.

    Tous les autres caractères doivent être encodés.

    • Merci, vous avez tout compris correctement. Je veux savoir quels sont les personnages que je peux utiliser sans de les encoder. Êtes-vous sûr que le !*'(), sont de tels personnages?
    • par ctford de répondre, en se référant à la RFC 1738, le signe dollar est aussi un personnage qui n'a pas besoin de codage.
    InformationsquelleAutor womp
  5. 4

    J'ai fait un test à l'aide de la barre d'adresse de Chrome et un $QUERY_STRING en bash, et observé ce qui suit:

    ~!@$%^&*()-_=+[{]}\|;:',./? et grave (backtick) sont transmises en clair.

    , ", < et > sont convertis à %20, %22, %3C et %3E respectivement.

    # est ignoré, car il est utilisé par ye olde ancre.

    Personnellement, je dirais mordre la balle et de l'encoder en base64 🙂

    • Ces caractères que vous mentionnez sont probablement celles qui vont être échappé dans le code HTML, pas de la chaîne de requête. Je ne crois pas =, ? et & peut être transmis en texte clair.
    InformationsquelleAutor jimmetry
  6. 2

    Toutes les règles concernant l'encodage des URIs (qui contient des Urnes et des Url) sont précisées dans la RFC1738 et la RFC3986, voici un TL;DR de ces documents longs et ennuyeux:

    Pour cent de codage, aussi connu comme l'encodage de l'URL, est un mécanisme de codage de l'information dans un URI dans certaines circonstances. Le nombre de caractères autorisés dans un URI sont réservés ou sans réserve. Les caractères réservés sont ces personnages qui ont parfois une signification particulière, mais ils ne sont pas les seuls caractères qui a besoin de codage.

    Il y a 66 sans réserve des caractères qui n'a pas besoin de n'importe quel encodage:
    abcdefghiklmopqrstuvwABCDEFGHIKLMOPQRSTUVWXYZ0123456789-_.~

    Il y a 18 caractères réservés qui doit être codée: !*'();:@&=+$,/?#[], et tous les autres caractères doivent être encodés.

    Pour cent de l'encodage d'un caractère, il suffit de concaténer "%" et sa valeur ASCII en
    hexadécimal. Les fonctions php "urlencode" et "rawurlencode" faire ce travail pour vous.

    InformationsquelleAutor Nino Filiu
  7. 0

    "." | "!" | "~" | "*" | "'" | "(" | ")" sont également acceptables [RFC2396]. Vraiment, n'importe quoi peut être un paramètre GET, si elle est correctement codé.

    • mais ceux-ci ont une signification spéciale, donc si tu veux envoyer % ou + vous ont pour les encoder.
    • ouais je ne sais pas pourquoi j'ai écrit %
    • Merci!!!! Je veux seulement savoir les caractères qui peuvent être utilisés SANS codage ou d'y échapper. Je devrais avoir souligné ce mieux. Donc, je peux vraiment utiliser *!'()| sans codage eux?
    InformationsquelleAutor geowa4