&region ® & und = codieren? +PHP

[Tim]

Hi,

mir ist gerade ein Problem aufgefallen von ich gar nicht wusste so eines zu haben. Bei der Ursachenforschung fand ich hier einen Thread mit der gleichen Problematik:

http://forum.de.selfhtml.org/archiv/2000/7/t17178/

Zunächst mal grundsätzlich zu Sonderzeichen, bisher dachte ich die Form wäre  "&irgendwas;". Den Gedanken muss ich wohl abhaken, denn sowohl IE als auch FF benötigen nicht zwingend das Semikolon am Schluss, was mich erstmal zur Frage bringt, warum nicht?

Ok, da ich nun darauf vorbereitet bin, muss ich wohl davon ausgehen, jeder Browser versucht ein Sonderzeichen zu finden wenn auf ein "&" direkt etwas folgt. Das kann aber auch zu weit gehen, wenn wie im Link der IE aus "&region=" => "®ion=" macht.

Nun habe ich den Forumsbeitrag natürlich gelesen und nicht ganz verstanden,
weil Calocybe schreibt:

Du musst korrekterweise schreiben: href="file.php3?land=xyz&region=abc"

Nur, so hatte der OP das doch  sowieso gemacht, oder nicht?

Was ich sonst aus der Aussage von Calocybe interpretiere ist, dass man wohl auch "&" und "=" in solchen Parameterstrings codieren soll?

Wenn dem so ist frage ich mich natürlich warum zb. Google das nicht macht, denn bsp. http://www.google.de/search?hl=de&q=pfalz&start=50&sa=N

Jetzt kommt natürlich bei den Googleparametern kein "region" vor, somit war wohl noch nie dort ein Problem vorhanden, denn seltsamerweise dachte ich wenn der IE das bei "&region" macht, müsste er das ja auch bei "&tradeion" machen also das Trademarkzeichen, tut er aber nicht.

Fragen:

1. "&" und "=" codieren?

• Falls ja, in "%26" und "%3D"?
• • Falls ja, ist denn darauf Verlass, dass ein Script solch ankommenden Strings sauber wieder erkennt? Denn hier kann es durchaus sein, dass einzelne Parameter gewollt codiert sind und es auch bleiben sollen.

2. Macht Google es falsch?

Zu PHP (Musste mich leider für einen Themenbereich entscheiden, obwohl es beide betrifft, Mehrfachauswahl wäre manchmal wünschenswert)

Normalerweise erzeuge ich solche Strings so:
*nur vom Prinzip her, in echtem Code natürlich anders!

url?a=rawurlencode('wert1')&b=rawurlencode('wert2').....

Beim Empfang nehme ich dann die Paare und verarbeite sie wie gewünscht weiter, also entweder raw oder decodiert. Wenn ich aber nun gezwungen wäre die Trenner & und = auch zu codieren, was dann?

Oder mache ich schon mal grundsätzlich etwas falsch?

Tim

[Joachim]

Hi,

href="file.php3?land=xyz&region=abc"

href="file.php3?land=xyz&region=abc" ist die korrekte Schreibweise.

php3? ist das Dein Ernst?

Gruesse, Joachim

[Vinzenz Mai]

Hallo Joachim,

href="file.php3?land=xyz&region=abc"
href="file.php3?land=xyz&region=abc" ist die korrekte Schreibweise.

php3? ist das Dein Ernst?

der von Tim verlinkte Archivthread ist aus dem Jahr 2000:
http://forum.de.selfhtml.org/archiv/2000/7/t17178/

Damals war die Lage noch so ernst :-)

Freundliche Grüße

Vinzenz

[Joachim]

Hi,

der von Tim verlinkte Archivthread ist aus dem Jahr 2000:

ups.

;-)

Gruesse, Joachim

[Vinzenz Mai]

Hallo,

mir ist gerade ein Problem aufgefallen von ich gar nicht wusste so eines zu haben. Bei der Ursachenforschung fand ich hier einen Thread mit der gleichen Problematik:

http://forum.de.selfhtml.org/archiv/2000/7/t17178/

1. "&" und "=" codieren?

Nein, als Sonderzeichen schreiben :-)

• Falls ja, in "%26" und "%3D"?

Nein, sondern - wie hier im Archiv massenhaft nachlesbar - mit &
Das heißt, statt

href="file.php?land=xyz&region=abc"

href="file.php?land=xyz&region=abc"

Der Browser zeigt Dir das übrigens als:

file.php?land=xyz&region=abc

an :-) Nutze einen Validator!

Freundliche Grüße

Vinzenz

[Tim]

Hi,

1. "&" und "=" codieren?

Nein, als Sonderzeichen schreiben :-)

also dann wohl htmlspecialchars().

Bedeutet das dann zwangsläufig ich lag bisher falsch und, selbst im Zeitalter von UTF-8, ich muss einen komplexen Querystring sowohl mit (raw)urlencode bearbeiten und mit htmlspecialchars?

Und bedeutet das auch zwangsläufig Google macht es verkehrt?

Danke
Tim

[Vinzenz Mai]

Hallo,

Hi,

1. "&" und "=" codieren?

Nein, als Sonderzeichen schreiben :-)

Ach so: = muss nicht maskiert werden.

also dann wohl htmlspecialchars().

wieso?

Und bedeutet das auch zwangsläufig Google macht es verkehrt?

Nein, woraus schließt Du das? Du solltest Dir mal den HTML-Quelltext von Google ansehen. Bei den Suchergebnissen, die ich gerade ermittelte, steht da überall ein &

Freundliche Grüße

Vinzenz

[Tim]

Hi,

also dann wohl htmlspecialchars().
wieso?

Weil ich das natürlich nicht manuell machen will und auch nicht weiss bei welchen zeichen ich noch mit sowas konfrontiert werde.

Und bedeutet das auch zwangsläufig Google macht es verkehrt?

Nein, woraus schließt Du das? Du solltest Dir mal den HTML-Quelltext von Google ansehen. Bei den Suchergebnissen, die ich gerade ermittelte, steht da überall ein &

Autsch, stimmt, hatte im Quelltext die Verweise angeschaut und zwar das & gesehen aber nicht das daran folgende amp;-)

Danke
Tim

[Vinzenz Mai]

Hallo,

Weil ich das natürlich nicht manuell machen will und auch nicht weiss bei welchen zeichen ich noch mit sowas konfrontiert werde.

und wann musst Du htmlspecialchars() verwenden?
Genau dann, wenn Du etwas in einen HTML-Kontext bringst (und es dort nicht als HTML interpretiert werden darf).

Freundliche Grüße

Vinzenz

[Tim]

Hi,

Weil ich das natürlich nicht manuell machen will und auch nicht weiss bei welchen zeichen ich noch mit sowas konfrontiert werde.

und wann musst Du htmlspecialchars() verwenden?
Genau dann, wenn Du etwas in einen HTML-Kontext bringst (und es dort nicht als HTML interpretiert werden darf).

Das wäre jetzt mal eine gute Frage, die ich mal eben teste.

Test beendet. Irgendwie scheine ich heute Halluzinationen zu haben, ich hatte mir eingebildet auch im Quelltext würde das ® im String auftauchen.

Klar im Quelltext kann normalerweise nur drin sehen was man reinschreibt, aber hier wird er automatisch generiert und mehrfach übergeben, also war ich voll überzeugt bei dieser Prozedur hat sich das durch den Browser dargestellte ® bei einer Übergabe reinproduziert, daher überhaupt meine frage hier. Aber da ich das nicht reproduzieren kann, bleibt wohl nur eine Halluzination. (Sollte mir mal hin und wieder Pausen gönnen;-)

Gut das heisst, selbst wenn ich nicht & nutze(was ich natürlich jetzt machen werde, könnte mir das bei den Strings nie gefährlich werden, richtig?

Tim

[Gunnar Bittersmann]

@@Tim:

Bedeutet das dann zwangsläufig ich lag bisher falsch und, selbst im Zeitalter von UTF-8, ich muss einen komplexen Querystring sowohl mit (raw)urlencode bearbeiten und mit htmlspecialchars?

Selbst im Zeitalter von UTF-8 musst Zeichen immer kontextspezifisch codieren. Das bedeutet auch, Zeichen, die in diesem Kontext eine Sonderbedeutung haben, zu escapen.

'&' hat in HTML (SGML, XML) die Sonderbedeutung, eine Zeichenreferenz einzuleiten. Deshalb muss das Zeichen "&" (wenn es als solches gemeint ist und nicht als Einleitung einer Zeichenreferenz) escapet werden: kontextspezifisch als '&' oder '&' (oder '&#38', aber das ist unsinnig).

'&' hat in einem Query (der Teil nach '?' (bis '#') in einem URI) die Sonderbedeutung, Parameter voneinander zu trennen. Deshalb muss das Zeichen "&" (wenn es als solches gemeint ist und nicht als Trennzeichen) escapet werden: kontextspezifisch als '%26'.

So sieht ein URI mit dem Parametern company=Gump&Bubba und product=shrimps so aus:
http://example.com/?company=Gump&26Bubba&product=shrimps
                     Zeichen "&"▲▲▲     ▲Trennzeichen

Kommt dieser in den HTML-Kontest, dann:
<a href="http://example.com/?company=Gump&26Bubba&amp;product=shrimps">
                                                 ▲▲▲▲▲Zeichen-Entity-Referenz

Live long and prosper,
Gunnar

[Gunnar Bittersmann]

@@Gunnar Bittersmann:

http://example.com/?company=Gump%26Bubba&product=shrimps
                     Zeichen "&"▲▲▲     ▲Trennzeichen

<a href="http://example.com/?company=Gump%26Bubba&amp;product=shrimps">
                                                 ▲▲▲▲▲Zeichen-Entity-Referenz

„So eine Schande, wo ist die Editierfunktion?“ [Orlando]

Live long and prosper,
Gunnar

[Vinzenz Mai]

Hallo Gunnar,

„So eine Schande, wo ist die Editierfunktion?“

wäre eine Editierfunktion nicht das Ende der Gunnar™-Beiträge?
Willst Du das wirklich?

Freundliche Grüße

Vinzenz

[dedlfix]

echo $begrüßung;

Der Browser zeigt Dir das übrigens als:
    file.php?land=xyz&region=abc
an :-)

Ja, aber an der Stelle ist es kein HTML, weswegen deine Auszeichnung mit [code lang=html] nicht richtig ist.

echo "$verabschiedung $name";

[Cheatah]

Hi,

1. "&" und "=" codieren?

• Falls ja, in "%26" und "%3D"?

Grundprinzip der elektronischen Datenverarbeitung: Wenn Du einen Wert in einen Kontext bringst, musst Du ihn kontextspezifisch maskieren. Dieses Prinzip gilt immer und überall, in jedem Kontext, in- und außerhalb des Webs, bei jeder Sprache oder Technik, bei jedem System. Ausnahmen sind diejenigen Dinge, die man genau deswegen meiden sollte, weil sie Ausnahmen sind: Sie sind dadurch unverlässlich.

Wenn Du "&" und "=" in einen URL-Kontext bringst, etwa als Namen oder Wert eines Parameters, so musst Du sie wie von Dir genannt kodieren. Bringst Du sie in einen anderen Kontext, etwa HTML, so musst Du sie HTML-kodieren. Das wäre z.B. "&" für das "&" bzw. "=" für das "=".[1] Nutzt Du jedoch das "=" als Trennzeichen zwischen Parameternamen und -wert, so _bildet_ dieses Zeichen den Kontext - es ist ein Sonderzeichen, Du meinst es in seiner Sonderbedeutung. Eine Kodierung in dem Kontext, des es bildet, ist falsch.

• • Falls ja, ist denn darauf Verlass, dass ein Script solch ankommenden Strings sauber wieder erkennt?

Das o.g. Grundprinzip hat notwendigerweise einen Umkehrschluss: Wenn Du einen Wert aus einem Kontext herausnimmst, musst Du ihn kontextspezifisch dekodieren. Die meisten Systeme machen dies automatisch, so dass der Punkt scheinbar entfällt. Ein DOM-Parser wird Dir die Inhalte eines Dokuments dekodiert zur Verfügung stellen, in PHP findest Du in $_GET['name'] den dekodierten Wert, SQL-Schnittstellen liefern Dir die Datenbankinhalte in dekodierter Form. Ebenso funktioniert es, wenn Du entsprechende Schnittstellen nutzt, um Werte irgendwo abzuliefern: _sie_ bringen ihn in den Kontext, sind also für die kontextspezifische Kodierung zuständig. Befüllst Du per JavaScript den nodeValue einer Text-Node mit '&', ist im Browser '&' zu sehen. Befragst Du eine Datenbank mit Bind-Variablen, anstatt das SQL-Statement als String selbst zusammenzubauen, übergibst Du die Abfragewerte in originaler Form. Hast Du eine setParam()-Methode, um eine URL zu erzeugen, so wird jedes '%xy' in einem '%25xy' resultieren.

Denn hier kann es durchaus sein, dass einzelne Parameter gewollt codiert sind und es auch bleiben sollen.

Wenn am Ende ein kodierter Wert herauskommen soll, so musst Du diesen als Original betrachten - und ihn kontextspezifisch kodieren.

2. Macht Google es falsch?

Ja. Google spart fast zwanghaft Bytes und riskiert Fehler, von denen sie durch Erfahrung und Tests wissen, dass sie - zumindest im Moment - zu keinen Problemen führen bzw. nur zu solchen, die Google in Kauf zu nehmen bereit ist. Um es deutlich zu sagen: Google macht (bewusst) *viel* falsch.

url?a=rawurlencode('wert1')&b=rawurlencode('wert2').....
Beim Empfang nehme ich dann die Paare und verarbeite sie wie gewünscht weiter, also entweder raw oder decodiert. Wenn ich aber nun gezwungen wäre die Trenner & und = auch zu codieren, was dann?

Dann kodierst Du sie halt auch. Sie verlieren dadurch - im aktuellen Kontext - ihre Sonderbedeutung.

Cheatah

[1] In den meisten Fällen ist es möglich, Kodierungen auch für Zeichen zu forcieren, deren Standard-Kodierung sie selbst ergibt. Nötig ist es selten.

[Beat]

Ja. Google spart fast zwanghaft Bytes und riskiert Fehler, von denen sie durch Erfahrung und Tests wissen, dass sie - zumindest im Moment - zu keinen Problemen führen bzw. nur zu solchen, die Google in Kauf zu nehmen bereit ist. Um es deutlich zu sagen: Google macht (bewusst) *viel* falsch.

Inkonsequentes Argument: ";" statt "&" als Parameter Trenner in Querystrings in Urls wäre korrekt bei gleicher Kürze.

mfg Beat

[Cheatah]

Hi,

Ja. Google spart fast zwanghaft Bytes und riskiert Fehler, von denen sie durch Erfahrung und Tests wissen, dass sie - zumindest im Moment - zu keinen Problemen führen bzw. nur zu solchen, die Google in Kauf zu nehmen bereit ist. Um es deutlich zu sagen: Google macht (bewusst) *viel* falsch.
Inkonsequentes Argument: ";" statt "&" als Parameter Trenner in Querystrings in Urls wäre korrekt bei gleicher Kürze.

das war kein Argument, sondern eine Erklärung :-) Welche Gründe Google dafür hat, keinen anderen Trenner zu verwenden, kann ich höchstens mutmaßen.

Cheatah

[dedlfix]

echo $begrüßung;

SQL-Schnittstellen liefern Dir die Datenbankinhalte in dekodierter Form.

Einspruch Euer Ehren. Falscher Kontext. SQL ist eine Abfragesprache. Das Ergebnis einer Query hat mit SQL nichts weiter zu tun. Deswegen kann man auch nicht von "dekodierter Form" sprechen. Das Dekodieren von Werten in SQL-Statements passiert bereits beim Parsen. Der Rest ist Blackbox bis zu dem Moment, wenn die Daten zum Client zurückkommen. Ob das DBMS intern was zu kodieren und dekodieren hat ist unerheblich. Es interessiert nur, dass die Daten von der DBMS-API in Rohform geliefert werden.

Ebenso funktioniert es, wenn Du entsprechende Schnittstellen nutzt, um Werte irgendwo abzuliefern: _sie_ bringen ihn in den Kontext, sind also für die kontextspezifische Kodierung zuständig.

Das interessiert den Anwender nicht. Es ist ja noch nicht mal gesagt, ob intern überhaupt ein Kontextwechsel stattfindet. Wichtig ist, was die Schnittstelle verlangt. Wenn das Rohform ist, dann ist das eben Rohform. Interne Kontextwechsel können unbetrachtet bleiben.

echo "$verabschiedung $name";

[Cheatah]

Hi,

SQL-Schnittstellen liefern Dir die Datenbankinhalte in dekodierter Form.
Einspruch Euer Ehren. Falscher Kontext. SQL ist eine Abfragesprache. Das Ergebnis einer Query hat mit SQL nichts weiter zu tun. Deswegen kann man auch nicht von "dekodierter Form" sprechen. Das Dekodieren von Werten in SQL-Statements passiert bereits beim Parsen. Der Rest ist Blackbox bis zu dem Moment, wenn die Daten zum Client zurückkommen. Ob das DBMS intern was zu kodieren und dekodieren hat ist unerheblich. Es interessiert nur, dass die Daten von der DBMS-API in Rohform geliefert werden.

und das widerspricht dem Umstand, dass SQL-Schnittstellen dekodierte Inhalte liefern, an welcher Stelle? Kodiert sind sie jedenfalls bei keiner Schnittstelle, die ich jemals benutzt hätte.

Ebenso funktioniert es, wenn Du entsprechende Schnittstellen nutzt, um Werte irgendwo abzuliefern: _sie_ bringen ihn in den Kontext, sind also für die kontextspezifische Kodierung zuständig.
Das interessiert den Anwender nicht.

Nein, aber denjenigen, der sich mit der Thematik beschäftigt.

Es ist ja noch nicht mal gesagt, ob intern überhaupt ein Kontextwechsel stattfindet.

Doch, das ist durch Verwendung des Wortes "entsprechend" und den Zusammenhang, also das Thema dieses Threads, gesagt.

Cheatah

[dedlfix]

echo $begrüßung;

und das widerspricht dem Umstand, dass SQL-Schnittstellen dekodierte Inhalte liefern, an welcher Stelle? Kodiert sind sie jedenfalls bei keiner Schnittstelle, die ich jemals benutzt hätte.

SQL ist keine Schnittstelle sondern eine Sprache. Die Schnittstelle zum DBMS ist beispielsweise die Client-API. SQL liefert nicht, man kann damit lediglich Abfragen formulieren.

Das interessiert den Anwender nicht.
Nein, aber denjenigen, der sich mit der Thematik beschäftigt.

Das sei ihm gegönnt, der heißt dann aber nicht mehr Anwender.

echo "$verabschiedung $name";

[Gunnar Bittersmann]

@@Tim:

Zunächst mal grundsätzlich zu Sonderzeichen, bisher dachte ich die Form wäre  "&irgendwas;". Den Gedanken muss ich wohl abhaken, denn sowohl IE als auch FF benötigen nicht zwingend das Semikolon am Schluss, was mich erstmal zur Frage bringt, warum nicht?

Fehlertoleranz. Du solltest dich nicht darauf verlassen und jede Zeichen-Entity-Referenz mit ';' abschließen.

Ok, da ich nun darauf vorbereitet bin, muss ich wohl davon ausgehen, jeder Browser versucht ein Sonderzeichen zu finden wenn auf ein "&" direkt etwas folgt.

Nein, bei fehlerhaftem Quelltext ist nicht davon auszugehen, dass jeder Browser dieselbe Fehlertoleranz zeigt und dasselbe Ergebnis liefert.

Das kann aber auch zu weit gehen, wenn wie im Link der IE aus "&region=" => "®ion=" macht.

Weil 'reg' eine benannte Entity für das Zeichen '®' ist.

Live long and prosper,
Gunnar

[Tim]

Hi,

Das kann aber auch zu weit gehen, wenn wie im Link der IE aus "&region=" => "®ion=" macht.

Weil 'reg' eine benannte Entity für das Zeichen '®' ist.

Genau, aber aus &tradeion= macht er nicht ™ion=

Seltsam inkonsequent der IE, selbst bei seinen eigenen internen Besonderheiten.

Gruss
Tim