nicht angemeldet
echo $begrüßung;
Nicht die URI, nicht die Parameternamen, nein, nur deren Werte werden mit urlencode behandelt.
Die Parameternamen bedürfen in dem Beispiel keiner Behandlung, weil sie keine kritischen Zeichen enthalten. Täten sie das (beispielsweise ein #), müssten sie ebenfalls URL-gerecht behandelt werden (%23, sonst zählt es ja als Anker-Anfang). PHP verhält sich hier gemäß der urlencode()-Arbeitsweise, denn es behandelt + und %20 gleich (wandelt es zu einem Unterstrich, weil ein Leerzeichen nicht in einem Variablennamen vorkommen kann, und damit register_globals nicht mehr funktionieren tät).
Das Beispiel zeigt auch gleich noch (wo wir grade dabei waren), dass htmlentities nicht einfach der "unnötig aufgeblasene große Bruder" von htmlspecialchars ist[1], sondern da, wo _jedes_ Sonderzeichen maskiert werden muss, seinen Einsatz findet.
Und auch da (wie an einigen anderen Handbuchstellen) ist es sinnlos eingesetzt, htmlspecialchars() völlig ausreichend. Ja, es bleibt nach Anwendung von urlencode() noch nicht mal Arbeit für htmlentities() übrig, die nicht von htmlspecialchars() erledigt werden kann. Es geht dann ja nur noch um das &, denn alles andere ist bereits URL-kodiert. Und selbst das & kann man sich unter PHP sparen und gegen ein keine Maskierung benötigendes ; als Parametertrenner austauschen, und damit einer Empfehlung des W3C folgen: Ampersands in URI attribute values. Voraussetzung ist, dass man PHP _vor_ dem Scriptstart konfigurieren kann (ini_set() ist zu spät). Das geht in einer eingenen php.ini bei CGI oder bei erlaubtem php_value in den üblichen Apache-Konfigurationsdateien bei Verwendung von mod_php. Stellt man arg_separator.input auf ";&", so kann man selbst das ; verwenden (url?foo=bar;qux=baz), und der Browser sein & beim Formularversand. Beide zeichen werden dann gleichberechtigt als Trenner anerkannt.
echo "$verabschiedung $name";
Auge