Im Parameter GET zulässige Zeichen


71

Welche Zeichen sind in GET-Parametern zulässig, ohne sie zu codieren oder zu maskieren? Ich meine so etwas:

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

Was können Sie dort anstelle von XYZ haben? Ich denke nur die folgenden Zeichen:

  • az (AZ)
  • 0-9
  • - -
  • _

Ist dies die vollständige Liste oder sind zusätzliche Zeichen zulässig?

Ich hoffe ihr könnt mir helfen. Danke im Voraus!



2
@ j0k: Kein wirklicher Betrug, wie in der anderen Frage, ist ein Entkommen erforderlich, im Gegensatz zu hier, wo es vermieden werden soll.
Marcel

Antworten:


102

Es gibt reservierte Zeichen , die eine reservierte Bedeutung haben, das sind Begrenzer - :/?#[]@- und Unterbegrenzer -!$&'()*+,;=

Es gibt auch eine Reihe von Zeichen, die als nicht reservierte Zeichen bezeichnet werden - alphanumerische Zeichen und -._~-, die nicht codiert werden sollen.

Das bedeutet, dass allesGET , was nicht zum nicht reservierten Zeichensatz gehört,% -codiert sein soll, wenn sie keine besondere Bedeutung haben (z. B. wenn sie als Teil eines Parameters übergeben werden) .

Siehe auch RFC3986: URI (Uniform Resource Identifier): Generische Syntax


2
Vielen Dank! Also muss ich hinzufügen. und ~ zu meiner Liste? Kann ich index.php schreiben? Page = start_en-new ~. ohne ihm zu entkommen?
Caw

3
Es wäre eine etwas zu kühne Aussage zu sagen, dass Sie nicht können, aber Sie sollten nicht. Wenn Sie URI zu normalisieren wären , würden Sie haben nicht reservierte Zeichen (und nur nicht reserviert) zu entkommen, aber es ist sehr wahrscheinlich , dass es tatsächlich wird funktionieren unescaped.
Michael Krelin - Hacker

Im Allgemeinen haben Sie die Escape-Funktion, die alles maskiert, was maskiert werden muss. Normalerweise verwenden Sie diese Funktion, um alle übergebenen Parameter zu umgehen.
Michael Krelin - Hacker

2
OMG, ich habe mir Ihr Beispiel nicht genau angesehen. Ich dachte, das wäre nur eine Reihe von Sonderzeichen ;-) Nein, diesen muss man natürlich nicht entkommen, da sie nicht reserviert sind. Entschuldigen Sie das Durcheinander. Was urlencode()ich habe keine Ahnung , ob es korrekt funktioniert - es ist nicht immer der Fall mit PHP - Funktionen - aber wenn es dann ja den Fall ist, kann man damit testen ;-) Wie ich schon sagte - Flucht alles , aber nicht reserviert.
Michael Krelin - Hacker

1
Der RFC sagt, dass es tatsächlich erlaubt ist, den Zeichen /und nicht zu entkommen ?. Ich habe das nachgeschlagen, weil Swift diesen in ihrer stringByAddingPercentEncodingForURLQueryParameterMethode nicht entgeht ! (Richtig, anscheinend)
StijnSpijker

15

In der Frage wird gefragt, welche Zeichen in GET-Parametern zulässig sind, ohne sie zu codieren oder zu maskieren .

Gemäß RFC3986 (allgemeine URL-Syntax) und RFC7230, Abschnitt 2.7.1 (HTTP / S-URL-Syntax) müssen Sie nur Zeichen außerhalb des Abfragesatzes prozentual codieren (siehe Definition unten).

Es gibt jedoch zusätzliche Spezifikationen wie HTML5, Webformulare und die veraltete W3C-Empfehlung für die indizierte Suche . Diese Dokumente verleihen einigen Zeichen eine besondere Bedeutung, insbesondere Symbolen wie = & +; .

Andere Antworten hier legen nahe, dass die meisten reservierten Zeichen codiert werden sollten, einschließlich "/" "?". Das stimmt nicht Tatsächlich rät RFC3986, Abschnitt 3.4 von einer prozentualen Codierung "/" "?" Zeichen.

Für die Benutzerfreundlichkeit ist es manchmal besser, eine prozentuale Codierung dieser Zeichen zu vermeiden.

RFC3986 definiert die Abfragekomponente als:

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

Ein Prozentcodierungsmechanismus wird verwendet, um ein Datenoktett in einer Komponente darzustellen, wenn das entsprechende Zeichen dieses Oktetts außerhalb des zulässigen Satzes liegt oder als Begrenzer oder innerhalb der Komponente verwendet wird.

Die Schlussfolgerung ist, dass der XYZ-Teil Folgendes codieren sollte:

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

Es sei denn, spezielle Symbole = &; sind Schlüssel = Werttrennzeichen.

Das Codieren anderer Zeichen ist zulässig, aber nicht erforderlich.


Bedeutet das Vorhandensein in der Menge "Sub-Delims" nicht, dass "!" / "$" / "&" ..."als Trennzeichen oder innerhalb der Komponente verwendet werden". und dafür sollte prozentual codiert werden?
lmsurprenant

7

Ich habe einen Test mit der Chrome-Adressleiste und einem $QUERY_STRINGIn-Bash durchgeführt und Folgendes festgestellt:

~!@$%^&*()-_=+[{]}\|;:',./?und grave (backtick)werden als Klartext durchgereicht.

, ", <Und >umgewandelt werden %20, %22, %3Cund %3Esind.

#wird ignoriert, da es vom alten Anker benutzt wird .

Persönlich würde ich sagen, beißen Sie die Kugel und codieren Sie mit base64 :)


Diese Zeichen, die Sie erwähnen, sind wahrscheinlich diejenigen, die in HTML maskiert werden, nicht die Abfragezeichenfolge. Ich glaube nicht = ,? und & können im Klartext übergeben werden.
Luc Bloom

Schätzen Sie Ihre Bemühungen, aber es bedeutet uns nicht viel, da ein reservierter Charakter heute von Chrome akzeptiert werden könnte, aber nicht morgen, oder andere Kunden ihn ablehnen könnten - viel sicherer mit der offiziellen Definition:ALPHA / DIGIT / “-” / “.” / “_” / “~”
Muleskinner

5

Ab RFC 1738, welche Zeichen in URLs zulässig sind:

Nur alphanumerische Zeichen, die Sonderzeichen "$ -_. +! * '()" Und reservierte Zeichen, die für ihre reservierten Zwecke verwendet werden, dürfen innerhalb einer URL nicht codiert verwendet werden.

Die reservierten Zeichen sind ";", "/", "?", ":", "@", "=" Und "&". Dies bedeutet, dass Sie sie per URL codieren müssen, wenn Sie sie verwenden möchten.


Vielen Dank! Sind Sie sicher, dass ich $ +! '() "Verwenden kann, ohne ihnen zu entkommen?
caw

RFC 1738 ist veraltet, siehe rfc-editor.org/info/rfc1738
David Balažic

4

Alphanumerische Zeichen und alle

~ - _ . ! * ' ( ) ,

sind innerhalb einer URL gültig.

Alle anderen Zeichen müssen codiert sein.


Danke, du hast alles richtig verstanden. Ich möchte wissen, welche Zeichen ich verwenden kann, ohne sie zu codieren. Bist du sicher, dass! * '() Solche Zeichen sind?
Caw

Nach der Antwort von ctford, die sich auf den RFC-1738 bezieht, ist das Dollarzeichen auch ein Sonderzeichen, das keine Codierung benötigt.
рüффп

3

Alle Regeln für die Codierung von URIs (die URNs und URLs enthalten) sind im RFC1738 und im RFC3986 angegeben. Hier ist eine TL; DR dieser langen und langweiligen Dokumente:

Die Prozentcodierung, auch als URL-Codierung bezeichnet, ist unter bestimmten Umständen ein Mechanismus zum Codieren von Informationen in einem URI. Die in einer URI zulässigen Zeichen sind entweder reserviert oder nicht reserviert. Reservierte Zeichen sind Zeichen, die manchmal eine besondere Bedeutung haben, aber nicht die einzigen Zeichen, die codiert werden müssen.

Es gibt 66 nicht reservierte Zeichen, die keine Codierung benötigen: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_.~

Es gibt 18 reservierte Zeichen, die codiert werden müssen: !*'();:@&=+$,/?#[]und alle anderen Zeichen müssen codiert werden.

Um ein Zeichen in Prozent zu codieren, verketten Sie einfach "%" und seinen ASCII-Wert hexadezimal. Die PHP-Funktionen "Urlencode" und "Rawurlencode" erledigen diesen Job für Sie.


0

"." | "!" | "~" | "*" | "'" | "(" | ")"sind auch akzeptabel [RFC2396] . In einem GET-Parameter kann sich wirklich alles befinden, wenn er richtig codiert ist.


Diese haben jedoch eine besondere Bedeutung. Wenn Sie also % oder + senden möchten, müssen Sie sie codieren.
Esteban Küber

Ja, ich weiß nicht, warum ich% geschrieben habe
geowa4

Vielen Dank! Ich möchte nur wissen, welche Zeichen verwendet werden können, ohne sie zu codieren oder zu maskieren. Ich hätte besser darauf hinweisen sollen. Kann ich also wirklich *! '() | Verwenden? ohne sie zu kodieren?
Caw
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.