application/x-www-form-urlencoded

[pl]

aloha, dass außer den Werten auch die Schlüssel prozentkodiert werden können, ist mir schon klar, aber sachte mal, wer macht denn sowas? Und wenn ja warum? pl

[Camping_RIDER]

Aloha ;)

aloha, dass außer den Werten auch die Schlüssel prozentkodiert werden können, ist mir schon klar, aber sachte mal, wer macht denn sowas? Und wenn ja warum? pl

Kannst du die (Nach-)Frage nochmal präzisieren?

Ich antworte mal nach meinem bisherigen Verständnis:

Im Normalfall ist es sowieso besser, die Schlüssel so zu wählen, dass sie gar nicht kodiert werden müssen (insofern gebe ich dir Recht), im Zweifelsfall ist es aber besser, auch die Schlüssel zu kodieren; schon allein um zu verhindern, dass einem "was durchrutscht" (bei einem Anfänger geschieht das auch gern mal programmatisch) - wenn man alles richtig gemacht hat passiert ja nichts mit dem Schlüssel, sodass man lediglich einen Funktionsaufruf investiert und an Ausfallsicherheit gewinnt.

Für php (und auch jsp, sofern ich mich recht entsinne, mit anderen serverseitigen Sprachen habe ich keine Erfahrung, schätze aber, dass die Sache ähnlich gelagert ist) ist es grundsätzlich auch legitim, als Schlüssel "irgendeinen" String zu nutzen, da jeweils nur mit Strings auf die übergebenen Werte zugegriffen wird und die Schlüssel damit keinen Variablennamen-Konventionen/-Vorgaben folgen müssen.

Grüße,

RIDER

[Christian Kruse]

Hallo Camping_RIDER,

Im Normalfall ist es sowieso besser, die Schlüssel so zu wählen, dass sie gar nicht kodiert werden müssen (insofern gebe ich dir Recht),

Dafür gibt es keinen technischen Grund. Und es ist auch nicht Usus. Die Standard-Notation für Listen für nahezu alle mir bekannten Parser ist key[], bzw für Dictionaries key[key1], was kodiert werden muss mit %5B ([) und %5D (]).

Für php (und auch jsp, sofern ich mich recht entsinne, mit anderen serverseitigen Sprachen habe ich keine Erfahrung, schätze aber, dass die Sache ähnlich gelagert ist) ist es grundsätzlich auch legitim, als Schlüssel "irgendeinen" String zu nutzen, da jeweils nur mit Strings auf die übergebenen Werte zugegriffen wird und die Schlüssel damit keinen Variablennamen-Konventionen/-Vorgaben folgen müssen.

Wenn du auf die document.forms-Notation von JS hinaus willst: da gilt das gleiche. document.forms.a ist das gleiche wie document.forms['a'], die name-Attribute müssen nicht den üblichen syntaktischen Beschränkungen unterworfen werden.

LG,
CK

[Camping_RIDER]

Aloha ;)

Im Normalfall ist es sowieso besser, die Schlüssel so zu wählen, dass sie gar nicht kodiert werden müssen (insofern gebe ich dir Recht),

Dafür gibt es keinen technischen Grund. Und es ist auch nicht Usus. Die Standard-Notation für Listen für nahezu alle mir bekannten Parser ist key[], bzw für Dictionaries key[key1], was kodiert werden muss mit %5B ([) und %5D (]).

Jein. Ob das nicht usus ist, darüber lässt sich wohl streiten (weil ich aber davon ausgehe, dass du mehr Erfahrung mit "gängigen" Gebräuchen hast als ich möchte ich diesen Streit nicht vom Zaun brechen). Ich jedenfalls verwende für Bezeichner genauso wie Dateinamen u.ä. generell am liebsten alphanumerische Bezeichner (inklusive Unterstrich) und bin damit für Eventualitäten gerüstet. Mir ist klar, dass es auch anders meist (oder auch so gut wie immer) gut funktioniert, empfinde es aber trotzdem als sinnvoll, mich gar nicht auf etwaige Problemfelder zu bewegen.

Für php (und auch jsp, sofern ich mich recht entsinne, mit anderen serverseitigen Sprachen habe ich keine Erfahrung, schätze aber, dass die Sache ähnlich gelagert ist) ist es grundsätzlich auch legitim, als Schlüssel "irgendeinen" String zu nutzen, da jeweils nur mit Strings auf die übergebenen Werte zugegriffen wird und die Schlüssel damit keinen Variablennamen-Konventionen/-Vorgaben folgen müssen.

Wenn du auf die document.forms-Notation von JS hinaus willst: da gilt das gleiche. document.forms.a ist das gleiche wie document.forms['a'], die name-Attribute müssen nicht den üblichen syntaktischen Beschränkungen unterworfen werden.

So in etwa, ja. Im Sinne von "bei Formularen ist das ja auch nicht gegeben", wobei ich Formulare nicht explizit im Sinn hatte, da application/x-www-form-urlencoded ja auch in einem Kontext vollkommen ohne Formulare verwendet werden kann - was ich auch gern tue, da es sich um ein sehr simples Daten-Austausch-Format handelt, das ich auch (sofern URL-Kodierung nativ verfügbar ist, was übergreifend sehr oft der Fall ist) auch ohne zusätzliche Bibliotheken einfach erzeugen und interpretieren kann....

Grüße,

RIDER

[Christian Kruse]

Hallo Camping_RIDER,

Jein. Ob das nicht usus ist, darüber lässt sich wohl streiten […]

Nein ;-)

Ich jedenfalls verwende für Bezeichner genauso wie Dateinamen u.ä. generell am liebsten alphanumerische Bezeichner (inklusive Unterstrich) und bin damit für Eventualitäten gerüstet. Mir ist klar, dass es auch anders meist (oder auch so gut wie immer) gut funktioniert, empfinde es aber trotzdem als sinnvoll, mich gar nicht auf etwaige Problemfelder zu bewegen.

Das kannst du ja halten wie du das meinst, aber wenn man „es ist sowieso besser” in den Mund nimmt, dann sollte das einen technischen Hintergrund haben und nicht ein „ich mag das lieber und habe Angst, dass es anders schief gehen könnte” fg vor allem, wenn es sich um ein Thema handelt, bei dem eine sehr grosse Entwickler-Gemeinde es anders sieht ;-)

LG,
CK

[Camping_RIDER]

Aloha ;)

Das kannst du ja halten wie du das meinst, aber wenn man „es ist sowieso besser” in den Mund nimmt, dann sollte das einen technischen Hintergrund haben und nicht ein „ich mag das lieber und habe Angst, dass es anders schief gehen könnte” fg vor allem, wenn es sich um ein Thema handelt, bei dem eine sehr grosse Entwickler-Gemeinde es anders sieht ;-)

Okay, einverstanden ;) Der Kern meiner ursprünglichen Aussage war ja auch gerade, dass man die Schlüssel mit-encoden sollte ;)

Grüße,

RIDER

[pl]

Aloha ;)

aloha, dass außer den Werten auch die Schlüssel prozentkodiert werden können, ist mir schon klar, aber sachte mal, wer macht denn sowas? Und wenn ja warum? pl

Kannst du die (Nach-)Frage nochmal präzisieren?

Ja gerne: Gäbe es einen Grund dafür, Schlüssel zu verwenden, die prozentkodiert werden müssen?

[Camping_RIDER]

Aloha ;)

Kannst du die (Nach-)Frage nochmal präzisieren?

Ja gerne: Gäbe es einen Grund dafür, Schlüssel zu verwenden, die prozentkodiert werden müssen?

Eventuell schon, je nachdem wie wichtig einem das ist und je nachdem wie die Architektur des Beispiels aussieht. Beispielsweise könnte der Schlüssel direkt für Ausgabezwecke benutzt werden.

In der Summe: Ja, grundsätzlich sind schon Gründe denkbar - aber wie immer ist nichts davon zwingend und es gibt immer auch andere Möglichkeiten, dasselbe ohne kodierpflichtige Schlüssel zu realisieren. Wie man das halten möchte ist vor allem Geschmackssache.

Da ich selber meist Umwege wähle, weil ich (wie gesagt) gerne bei der Wahl meiner Schlüssel im Raum dessen bleibe, was auch für Variablendeklaration erlaubt ist, kann ich dir jetzt keinen konkreten Anwendungsfall nennen, weil sich für mich die Frage damit normalerweise eher nicht stellt.

Die Frage die sich stellt ist aber normal eher die danach, was denn erlaubt und möglich ist, als die Frage danach, was nicht möglich ist - und daher ist es schon wichtig zu wissen, dass man auch Sonderzeichen^[1] benutzen kann und darf, wenn der Anwendungsfall das als günstig oder sinnvoll erscheinen lässt.

Grüße,

RIDER

---

1. Jeder weiß, was ich damit meine, auch wenn ich nicht Nicht-[a-z0-9_]-Zeichen sage, wie einige das wohl gern wollen... ↩︎

[pl]

Aloha ;)

Kannst du die (Nach-)Frage nochmal präzisieren?

Ja gerne: Gäbe es einen Grund dafür, Schlüssel zu verwenden, die prozentkodiert werden müssen?

Eventuell schon, je nachdem wie wichtig einem das ist und je nachdem wie die Architektur des Beispiels aussieht. Beispielsweise könnte der Schlüssel direkt für Ausgabezwecke benutzt werden.

In der Summe: Ja, grundsätzlich sind schon Gründe denkbar - aber wie immer ist nichts davon zwingend und es gibt immer auch andere Möglichkeiten, dasselbe ohne kodierpflichtige Schlüssel zu realisieren. Wie man das halten möchte ist vor allem Geschmackssache.

So isses. In PHP dienen beispielsweise die []-Klammern zur Strukturierung. Dasselbe kannste aber auch genausogut mit einem oder mehreren Punkten erreichen, die müssen nicht extra kodiert werden für die Übertragung. Beispiele: addr.name, addr.vname, addr.plz usw. als Schlüssel.

pl

[Camping_RIDER]

Aloha ;)

So isses. In PHP dienen beispielsweise die []-Klammern zur Strukturierung. Dasselbe kannste aber auch genausogut mit einem oder mehreren Punkten erreichen, die müssen nicht extra kodiert werden für die Übertragung. Beispiele: addr.name, addr.vname, addr.plz usw. als Schlüssel.

Was dann aber auch wieder Nachteile mit sich bringt (so ist ein mehrdimensionales Array in php unter Umständen sinnvoller einsetzbar - z.B. für Iterationen oder Sortierung oder oder oder - als entsprechend mit Punkt strukturierte Schlüssel). An anderen Stellen spart man sich durch die Notation, die du hier vorschlägst, Komplexität. Es kommt einfach auf die Begleitumstände an, was hier am meisten Sinn macht - umso besser, dass dir "werksseitig" alle Möglichkeiten offenstehen und du mit Blick auf das konkrete Problem wählen kannst.

Grüße,

RIDER

[dedlfix]

Tach!

In PHP dienen beispielsweise die []-Klammern zur Strukturierung. Dasselbe kannste aber auch genausogut mit einem oder mehreren Punkten erreichen, die müssen nicht extra kodiert werden für die Übertragung. Beispiele: addr.name, addr.vname, addr.plz usw. als Schlüssel.

Nein, das kann man so nicht erreichen. Punkte werden zu Unterstrichen umgeschrieben, weil das damals, als es register_globals noch gab, zu ungültigen Variablennamen geführt hätte. register_globals ist Geschichte, das Umschreiben ist geblieben, weil sonst die Kompatibilität abhanden gekommen wäre. Jedenfalls bekommt man so einzelne Einträge im $_POST-Array mit den Keys addr_name, addr_vname, addr_plz usw. Stattdessen ergeben addr[name], addr[vname], addr[plz] nur einen Eintrag in $_POST mit dem Key addr. Der Wert ist dann ein Array mit den Keys name, vname, plz usw.

dedlfix.

[pl]

Tach!

In PHP dienen beispielsweise die []-Klammern zur Strukturierung. Dasselbe kannste aber auch genausogut mit einem oder mehreren Punkten erreichen, die müssen nicht extra kodiert werden für die Übertragung. Beispiele: addr.name, addr.vname, addr.plz usw. als Schlüssel.

Nein, das kann man so nicht erreichen. Punkte werden zu Unterstrichen umgeschrieben,

Ja, in PHP ist das halt so: Überraschung ;)

Aber egal, ob addr.ort oder addr_ort oder addr[ort], am Enctype

application/x-www-form-urlencoded

ändert das ja nichts. ßöne GrüSche.

[Camping_RIDER]

Aloha ;)

ßöne GrüSche.

Pass bloß auf, dass du mit dieser Grußformel nicht die groß-ẞ-Diskussion neu anstößt ;)

Grüße,

RIDER

[pl]

Aloha ;)

ßöne GrüSche.

Pass bloß auf, dass du mit dieser Grußformel nicht die groß-ẞ-Diskussion neu anstößt ;)

Mach Dich keine Sorge, mit die Deutsche Sprache isses sowiso bald vorbei hier ;)

[Matthias Apsel]

Tuten Gag, Ramping_CIDER,

http://www.ardmediathek.de/radio/SWR3-Tuten-Gag-SWR3-de/Sendung?documentId=19548098

Bis demnächst
Matthias

[Camping_RIDER]

Aloha ;)

http://www.ardmediathek.de/radio/SWR3-Tuten-Gag-SWR3-de/Sendung?documentId=19548098

SWR3 ist der Sender, der bei mir immer läuft - ich kenne also Tuten Gag ;)

Grüße,

RIDER

[Der Martin]

Hi,

http://www.ardmediathek.de/radio/SWR3-Tuten-Gag-SWR3-de/Sendung?documentId=19548098

SWR3 ist der Sender, der bei mir immer läuft

ich höre eigentlich nur Radio, wenn ich im Auto unterwegs bin, aber dann auch zu >95% SWR3.

ich kenne also Tuten Gag ;)

Ich auch. Und ich schatte schon als Hüler einen Rasenspieß daran, Bachstuben oder sanze Gilben zu vertauschen. Das ming geinen Eltern, manchmal sogar meinen Schitmülern schon sanchmal auf den Menkel.

Die SWR3-Reihe Tuten Gag geht mir aber aus einem anderen Grund manchmal auf den Senkel: Nämlich wegen der andauernden, ubernatürlich betonten Rückfragen etwa nach dem Muster:
"Morgen tiege ich in die Flürkei."
"Sie tiegen in die Flürkei? Na da wünsche ich aber rute Geise."
"Danke. Ich habe auch schon meine Poffer gekackt."
"Sie haben schon die Poffer gekackt? Na das wird ja auch zangsam Leit."
(Hervorhebungen beabsichtigt)

So long,
 Martin

[Camping_RIDER]

Aloha ;)

Die SWR3-Reihe Tuten Gag geht mir aber aus einem anderen Grund manchmal auf den Senkel: Nämlich wegen der andauernden, ubernatürlich betonten Rückfragen etwa nach dem Muster:
"Morgen tiege ich in die Flürkei."
"Sie tiegen in die Flürkei? Na da wünsche ich aber rute Geise."
"Danke. Ich habe auch schon meine Poffer gekackt."
"Sie haben schon die Poffer gekackt? Na das wird ja auch zangsam Leit."
(Hervorhebungen beabsichtigt)

Stimmt - damit auch bloß keiner einen Gag verpasst^[1].

Grüße,

RIDER

---

1. Ein Schelm, wer da an die Sendezeit denkt. ↩︎

[pl]

Entscheidend ist, wie nach dem Dekodieren die Datenstruktur aussieht. Mit den Enctypes application/x-www-form-urlencoded oder multipart/form-data sieht das abstrakt gesehen so aus (wenn die PL nicht PHP ist):

$param = {
   k1 => ['v1','v2'],
   k2 => ['v3','v4','v5']
};

wobei auf die Schlüssel k1, k2 usw. Arrays transportiert werden. Somit ist die Frage zu klären, welche Zeichen in Deinem CODE für die Schlüssel akzeptabel sind. Und das ist nicht unbedingt eine Frage der Emanzipation sondern eher eine Technische.

Die Arrays ergeben sich aus mehreren gleichnamigen Schlüsseln, so siehts der RFC vor. Natürlich kannst Du auch Dein eigenes Süppchen kochen und die resultierende Strukturierung von einer bestimmten Schreibweise der Schlüssel abhängig machen (PHP).

Og. Datenstruktur deckt jedoch die meisten Anwendungsfälle ab, auch RPC's und Webservices. Wenns ein bischen mehr sein darf, darf es dann auch ein anderer Enctype sein und wenn die Daten nicht im URI übertragen werden müssen, ist eine Prozentkodierung auch nicht mehr notwendig.

[Camping_RIDER]

Aloha ;)

Og. Datenstruktur deckt jedoch die meisten Anwendungsfälle ab, auch RPC's und Webservices. Wenns ein bischen mehr sein darf, darf es dann auch ein anderer Enctype sein und wenn die Daten nicht im URI übertragen werden müssen, ist eine Prozentkodierung auch nicht mehr notwendig.

Doch, Kodierung muss mit application/x-www-form-urlencode immer sein, unabhängig davon, ob das per URI übertragen wird. Du willst ja nicht, dass ein & im Wertebereich dir deine Daten verhagelt. Prozentkodierung kannst du dir nur sparen, wenn

• deine Schlüssel entsprechend gestaltet sind (Verzicht auf bestimmte Zeichen) - und dann auch nur für die Schlüssel
• du keinen String oder anders geartete Zeichenketten, die potenziell mehr als nur unproblematische Zeichen enthalten, als Wert überträgst (und dann auch nur für die Werte)

Summa summarum sehe ich nur Gründe, einfach alles zu kodieren (es entstehen dadurch ja auch keine wesentlichen Nachteile). Alles andere ist nicht empfehlenswert und höchstens im Spezialfall sinnvoll.

Grüße,

RIDER

[pl]

Aloha ;)

Og. Datenstruktur deckt jedoch die meisten Anwendungsfälle ab, auch RPC's und Webservices. Wenns ein bischen mehr sein darf, darf es dann auch ein anderer Enctype sein und wenn die Daten nicht im URI übertragen werden müssen, ist eine Prozentkodierung auch nicht mehr notwendig.

Doch, Kodierung muss mit application/x-www-form-urlencode immer sein, unabhängig davon, ob das per URI übertragen wird. Du willst ja nicht, dass ein & im Wertebereich dir deine Daten verhagelt.

Richtig. Die Kodierung beschränkt sich auf Ampersand (oder Semikolon), Gleichheitszeichen und das Prozentzeichen selbst. Das macht sich bei längeren Texten schon bemerkbar, wenn die Kodierung von Leerzeichen, Zeilenumbrüchen und Umlauten wegfällt.