Was ist gültig und was ist nicht in einer URI-Abfrage?

Hintergrund (Frage weiter unten)

Ich habe schon Googeln dieses hin und her-das Lesen von RFCs und SO Fragen versuchen zu knacken, aber ich glaube trotzdem nicht, bekam jack.

Also ich denke, dass wir nur Stimmen für die "beste" Antwort, und das ist es, oder?

Im Grunde läuft es auf dies.

3.4. Query-Komponente

Die query-Komponente ist eine Reihe von Informationen interpretiert werden, die von der Ressource.

query = *uric

Innerhalb einer query-Komponente, die Zeichen ";", "/", "?", ":", "@", "&", "=", "+", ",", und "$" sind vorbehalten.

Das erste, was, das verwirrt mich ist, dass *die Harnsäure ist wie folgt definiert

uric = reserved | unreserved | escaped

reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","

Dies ist jedoch etwas geklärt durch Absätze wie

"Reservierten" syntax-Klasse oben bezieht sich auf die zulässigen Zeichen innerhalb einer URI, die aber möglicherweise nicht erlaubt, innerhalb einer bestimmten Komponente der generischen URI-syntax; Sie werden verwendet als Trennzeichen der Komponenten, beschrieben in Abschnitt 3.

Zeichen in der "reserviert" eingestellt werden, sind nicht reserviert, die in allen Kontexten. Der Satz von Zeichen, die eigentlich reserviert sind, innerhalb einer gegebenen URI-Komponente definiert ist, die von dieser Komponente. Im Allgemeinen wird ein Charakter ist reserviert, wenn die Semantik der URI ändert, wenn die Zeichen ersetzt mit seiner Escape-US-ASCII-Codierung.

Dieser Letzte Auszug fühlt sich etwas nach hinten, aber es eindeutig, dass die reservierten Zeichen gesetzt, abhängig vom Kontext. Noch 3.4 besagt, dass alle reservierten Zeichen sind reserviert innerhalb einer query-Komponente, aber die einzigen Dinge, die zu einer Veränderung der Semantik hier ist Flucht das Fragezeichen (?) als URIs definieren Sie nicht das Konzept der query-string.

In diesem Punkt habe ich aufgegeben auf die RFCs ganz aber gefunden RFC 1738 besonders interessant.

Einen HTTP-URL hat die form:

http://<host>:<port>/<path>?<searchpart>

Innerhalb der <Pfad> und <searchpart> Komponenten, "/", ";", "?" reserviert sind. Die " /" - Zeichen kann verwendet werden innerhalb von HTTP zu benennen, die eine hierarchische Struktur.

Interpretiere ich dies zumindest für HTTP-URLs, RFC 1738 ersetzt RFC 2396. Da die URI-query hat keine Vorstellung von einem query-string auch die interpretation der gebuchten, nicht wirklich lassen Sie mir erlauben, zu definieren, Abfrage-strings, als ich gewohnt bin zu tun.

Frage

Dieser alle Schritte, wenn ich es wollte zu übergeben eine Liste von zahlen zusammen mit der Anfrage einer anderen Ressource. Ich habe nicht viel von ihm denken, und nur an ihn als ein Komma getrennte Werte. Zu meiner überraschung obwohl das Komma entgangen war. Die Abfrage page.html?q=1,2,3 - codiert-stellte sich in page.html?q=1%2C2%2C3 es funktioniert, aber es ist hässlich und nicht erwarten, dass es. Das ist, wenn ich ging durch RFCs.

Meine erste Frage ist einfach, ist die Codierung Komma wirklich notwendig?

Meine Antwort, nach RFC 2396: ja, gemäß RFC 1738: keine

Später fand ich ähnliche Beiträge in Bezug auf die Weitergabe von Listen zwischen den Anforderungen. Wo die csv-Ansatz wurde balanciert, als schlecht. Dies zeigte sich stattdessen (noch nicht gesehen vorher).

page.html?q=1;q=2;q=3

Meine zweite Frage, ist dies ein Gültiger URL?

Meine Antwort, nach RFC 2396: keine, gemäß RFC 1738: keine (; ist reserviert)

Ich habe keine Probleme mit übergabe von csv-solange es zahlen, aber ja, Sie tun, laufen Sie in die Gefahr, dass das Kodieren und Dekodieren von Werten hin und her, wenn das Komma plötzlich ist erforderlich für etwas anderes. Trotzdem habe ich versucht, das semi-colon-query-string-Ding mit ASP.NET und das Ergebnis war nicht das, was ich erwartet hatte.

Default.aspx?a=1;a=2&b=1&a=3

Request.QueryString["a"] = "1;a=2,3"
Request.QueryString["b"] = "1"

Ich nicht, um zu sehen, wie diese stark unterscheidet sich von einer csv-Ansatz, wie wenn ich Frage "a" bekomme ich einen string mit Kommas. ASP.NET sicherlich keine Referenz-Implementierung, aber es hat mich nicht enttäuscht noch.

Aber am wichtigsten ist-meine Dritte Frage -- wo ist die Spezifikation für diese? und was würden Sie tun oder auch nicht tun?

InformationsquelleAutor der Frage John Leidegren | 2010-03-02

  1. 57

    Dass ein Charakter reserviert ist, innerhalb einer generischen URL-Komponente bedeutet nicht, dass es geschützt werden müssen, wenn es erscheint, innerhalb der Komponente oder innerhalb von Daten in der Komponente. Der Charakter muss auch definiert werden als ein Trennzeichen innerhalb der generischen oder Schema-spezifischen syntax und das Aussehen der Charakter muss sich innerhalb der Daten.

    Den aktuellen standard für generische URIs ist RFC 3986was hat dies zu sagen:

    2.2. Reservierte Zeichen

    URIs gehören Komponenten und Unterkomponenten, die durch Trennzeichen in der "reserviert" gesetzt. Diese Zeichen werden als "reserviert" werden, weil Sie vielleicht (oder auch nicht) werden definiert als Trennzeichen, die durch die generische syntax, die von jedem Schema-spezifischen syntax, oder der Umsetzung-konkrete syntax einer URI ist die Dereferenzierung-Algorithmus. Wenn Daten für eine URI-Komponente würde Konflikt mit einem reservierten Zeichen den Zweck als Trennzeichen [Hervorhebung Hinzugefügt], und dann die widersprüchlichen Daten muss sein Prozent-verschlüsselt, bevor Sie den URI gebildet wird.

     reserved = gen-delims /sub-delims 

gen-delims = ":" /"/" /"?" /"#" /"[" /"]" /"@" 

sub-delims = "!" /"$" /"&" /"'" /"(" /")" 
/"*" /"+" /"," /";" /"="

    3.3. Pfad-Komponente

    [...] 

    pchar = vorbehaltlosen /pct-encoded /sub-delims /":" /"@"

    [...]

    3.4 Query-Komponente

    [...] 

     query = *( pchar /"/" /"?" )

    Damit Kommas sind ausdrücklich erlaubt in query-strings und müssen nur entkommen werden, in Daten, wenn spezifische Regelungen definieren es als Trennzeichen. Das HTTP-Schema verwenden nicht das Komma oder Semikolon als Trennzeichen in query-strings, so dass Sie nicht brauchen, um zu entkommen. Ob Browser, Folgen Sie dieser Norm, ist eine andere Sache.

    Mithilfe von CSV-sollte gut funktionieren, für string-Daten, Sie müssen nur Folgen Sie den standard-CSV-Konventionen und entweder zitieren von Daten oder die Flucht der Kommas mit backslashes.

    Als für RFC-2396, es ermöglicht auch ohne Umschreibung Kommas in HTTP-query-strings:

    2.2. Reservierte Zeichen

    Viele URI-Komponenten enthalten, die aus oder getrennte, die durch bestimmte
    Besondere Zeichen. Diese Zeichen werden als "reserviert", da
    Ihre Nutzung im Rahmen der URI-Komponente ist beschränkt auf Ihren vorbehalten
    Zweck. Wenn die Daten für eine URI-Komponente in Konflikt mit der
    reserviert Zweck, dann die widersprüchlichen Daten die geschützt werden müssen, vor
    Bildung der URI.

    Da Kommas nicht über einen reservierten Zweck unter dem HTTP-Schema, Sie müssen nicht escaped werden in Daten. Der Hinweis von § 2.3 über reservierte Zeichen davon, dass der Wandel der Semantik bei der Prozent-kodiert gilt nur im Allgemeinen; Zeichen Prozent-codiert ohne änderung der Semantik für bestimmte Systeme und noch vorbehalten.

    InformationsquelleAutor der Antwort outis

  2. 13

    Zu beantworten, was gültig ist in einem query-string habe ich überprüft, die Sonderzeichen ersetzt, die von chrome, wenn Sie eine Anfrage:

    Space -> %20
! -> !
" -> %22
# -> removed, marks the end of the query string
% -> %
& -> &
' -> %27
( -> (
) -> )
* -> *
+ -> + (this usually means blank when received at the server, so encode if necessary)
-> ,
- -> -
. -> .
/-> /
: -> :
; -> ;
< -> %3C
= -> =
> -> %3E
? -> ?
@ -> @
[ -> [
\ -> \
] -> ]
^ -> ^
_ -> _
` -> `
{ -> {
| -> |
} -> }
~ -> ~

Extended ASCII (like °) -> Every character from this set is encoded

    Hinweis: Das wahrscheinlich bedeutet nicht, sollten Sie nicht die escape-Zeichen nicht ersetzt, die beim generieren von URIs für die links. Zum Beispiel ist es oft empfohlen, nicht zu verwenden ~ in URIs wegen der Kompatibilität Fragen, aber es ist immer noch ein gültiges Zeichen.

    Ein weiteres Beispiel wäre das plus-Zeichen, das gilt aber in der Regel so behandelt, als codierte leere, wenn ein server empfängt Sie als Teil der Anfrage. Damit sollte es codiert werden, auch wenn dann gültig, wenn Sie den Zweck darstellen, ein plus und nicht ein Raum.

    So zu beantworten, was soll codiert werden: Ungültige Zeichen und Zeichen, die Sie behandeln wollen buchstäblich, sondern haben eine Besondere Bedeutung oder kann die Ursache für Probleme am server-Ende.

    InformationsquelleAutor der Antwort user764754

  3. 9

    Verwenden Sie einfach ?q=1+2+3

    Beantworte ich hier eine vierte Frage 🙂 , habe nicht gefragt, aber alles begann mit: wie gebe ich die Liste der zahlen a-la-Komma-getrennte Werte? Scheint mir der beste Ansatz ist einfach, Sie zu übergeben, durch Leerzeichen getrennte, wo Räume bekommen wird, die url-form-codiert +. Funktioniert Super, solange Sie wissen, die Werte in der Liste keine Leerzeichen enthalten (etwas, das die zahlen eher nicht).

    InformationsquelleAutor der Antwort Nas Banov

  4. 4

    Seite.html?q=1;q=2;q=3

    ist dies ein Gültiger URL?

    Ja. Die ; ist zurückhaltend, aber nicht von einem RFC. Der Kontext, der definiert, diese Komponente ist die definition der application/x-www-form-urlencoded Medien geben, die Teil der HTML-standard (Abschnitt 17.13.4.1). Insbesondere der hinterhältige Hinweis versteckt, die in Abschnitt B. 2.2:

    Empfehlen wir, dass die HTTP-server implementors, und insbesondere CGI-implementors unterstützen die Verwendung von ";" statt "&", um zu speichern Autoren die Mühe entkommen "&" - Zeichen auf diese Weise.

    Leider viele populäre server-side-scripting-frameworks einschließlich ASP.NET nicht unterstützen diese Nutzung ein.

    InformationsquelleAutor der Antwort bobince

  5. 1

    Ich möchte zu beachten, dass page.html?q=1&q=2&q=3 ist eine gültige url. Dies ist ein völlig legitimer Weg, um ein array in einem query-string. Ihre server-Technologie bestimmen, wie genau, die präsentiert wird.

    In der Klassischen ASP-überprüfen Sie Response.QueryString("q").Count und verwenden Sie dann Response.QueryString("q")(0) (und (1) und (2)).

    Beachten Sie, dass Sie sah, das in Ihrem ASP.NET (ich glaube, es war nicht beabsichtigt, aber sehen):

    Default.aspx?a=1;a=2&b=1&a=3

Request.QueryString["a"] = "1;a=2,3"
Request.QueryString["b"] = "1"

    Beachten Sie, dass das Semikolon wird ignoriert, so haben Sie a definiert, zweimal, und Sie hat seinen Wert zweimal, getrennt durch ein Komma. Mit allen kaufmännisches Default.aspx?a=1&a=2&b=1&a=3 Ausbeute a wie "1,2,3". Aber ich bin sicher, es gibt eine Methode, um jedes einzelne element, im Fall der Elemente selbst Kommas enthalten. Es ist einfach die default-Eigenschaft der nicht-indizierten QueryString, wird der sub-gemeinsam Werte mit Komma-Trennzeichen.

    InformationsquelleAutor der Antwort ErikE

  6. 1

    Ich hatte das gleiche Problem. Die URL, die verlinkt wurde, war eine Dritte Partei, die URL und erwartet eine Liste von Parametern, die im format page.html?q=1,2,3 NUR und die URL page.html?q=1%2C2%2C3 hat nicht funktioniert. Ich war in der Lage, um es arbeiten mit javascript. Möglicherweise nicht der beste Ansatz sein, aber check-out die Lösung hier wenn es hilft jemand.

    InformationsquelleAutor der Antwort slash

  7. -3

    Wenn Sie das senden der CODIERTEN Zeichen zu FLASH/SWF - - Datei, dann sollten Sie CODIEREN die Zeichen zweimal!! (weil der Flash-parser)

    InformationsquelleAutor der Antwort T.Todua

Schreibe einen Kommentar