nicht angemeldet
Hi!
also, so wies aussieht, hab ich überall utf-8. ich glaube mittlerweile, es hat garnichts mit der db zu tun, sondern damit, wie die php-datei meine daten weitergibt. ein beispiel:
hiergibt es ein testformular, das den eintrag weitergibt, und
diese datei wertet das ganze aus. alles auf utf-8 eingestellt, und wenn du mal einen umlaut eingibst, hast du bei der auswertung schon den salat;-)
Nö, hab ich nicht. Aber der Reihenfolge nach:
Ich sehe, dass die Seite test1.php keine charset-Angabe im HTTP-Header Content-Type mitsendet, aber es gibt als Ersatz ein Meta-Element dafür. Ich tippe ein:
<"ä
und bekomme angezeigt
Vorname: <\"ä
und der Firefox 3.0 zeigt als URL
.../weiterleitung.php?vorname=<"ä
Dabei sehe ich kein Problem, was das UTF-8 anbelangt, dafür aber vier andere.
Der Livehttpheaders-Mitschnitt zeigt als POST-Daten
vorname=%3C%22%C3%A4&submit=Versenden
Mein Browser nimmt für das ä die zwei UTF-8-Byte und zusammen mit den anderen Zeichen URL-kodiert er die Eingabe. Als Antwort erhalte ich (gekürzt)
HTTP/1.x 302 OK
Content-Type: text/html
Location: weiterleitung.php?vorname=<"ä
X-Powered-By: PHP/4.4.4, ASP.NET
Es gibt also einen Redirect (Status 302), die PHP-Version ist uralt und der Content-Type enthält keine charset-Angabe. Mein Browser darf in dem Fall raten und er rät richtig. (Zum \ vor dem " sag ich später noch was.)
Mein Browser fragt also nach
GET /VCP2.0/weiterleitung.php?vorname=%3C%22%C3%A4 HTTP/1.1
und bekommt die oben erwähnte Ausgabe.
Für die Weiterleitung ist diese Zeile zuständig:
header("Location: weiterleitung.php?vorname=".$_POST['vorname']."");}
Das Anfügen eines Leerstrings an einen String ist eine sinnlose Handlung. Es ändert an dem String nichts und hat auch keine Nebenwirkungen (à la Integer verknüpft mit Leerstring ergibt einen Typecast des Integers nach String), die man vielleicht ausnutzen könnte.
Nicht beachtet hast du, dass ein Location-Header gemäß Vorschrift eine vollständige URL benötigt. In den meisten Fällen machen die Browser trotzdem das von dir Vorgesehene. Wichtiger ist, dass du da einen URL-Kontext hast, und die Daten URL-kodiert einfügen musst. Ansonsten kann man dir beliebig den Querystring manipulieren.
Obendrein fummelt das PHP-Feature Magic Quotes in den Daten rum, ohne dass das da sinnvoll wäre. Zu den Magic Quotes kannst du den Abschnitt PHP-Besonderheit Magic Quotes lesen. Auch der Rest (der Vorabversion) des Artikels Kontextwechsel erkennen und behandeln wird einge Sachen enthalten, die du vielleicht bisher noch nicht berücksichtigst. Die Magic Quotes jedenfalls sorgen bei der ersten Runde dafür, dass aus dem " ein " wird. Beim Redirect wird aus dem \ ein \ und das " wiederum zum ", zusammen ergibt das: \"
Magic Quotes solltest du deaktiveren und die Kontextwechsel zur Datenbank hin und in alle anderen Richtungen selbst und passend behandeln.
Wenn ich mir den Quelltext ansehe, sehe ich
<p>Vorname: <\"ä</p>
Wenn ein < kein Tag-Öffner ist, wie muss das dann in HTML notiert werden? Du hast da den nächsten nicht beachteten Kontextwechsel. In dem zitierten Code von test1.php sind weitere Stellen:
<form method="POST" action="<?php echo $_SERVER['PHP_SELF']?>" name="kontakt">
Das unbehandelte Einfügen von $_SERVER['PHP_SELF'] eignet sich zum Manipulieren des form-Elements. Da muss mindestens ein htmlspecialchars() drumrum.
Das gleiche Problem befindet sich hier (gekürzt):
<input name="vorname" type="text" value="<?php echo $_POST['vorname'];?>"></p>
Zum Umlautproblem: PHP reicht die Daten nur durch, ohne daran was zu ändern. Die einzige Stelle, die da was ändert, muss dein Browser sein, der anders rät als meiner. Ob du ihm das Raten mit einem selbst gesetzten Content-Type-Header inklusive charset-Angabe abgewöhnen kannst, vermag ich nicht mit Bestimmtheit zu sagen. Jedoch empfehle ich dir, zunächst den Ablauf selbst einmal nachzuvollziehen, so wie ich das gemacht habe. Nimm dir dazu die Livehttpheaders-Extension und den FF oder ein ähnlich arbeitendes Tool für deinen Browser. Kontrollausgaben können ebenfalls hilfreich sein. Wenn du das nachvollzogen hast, und eventuell Unterschiede zu dem von mir beobachteten Verhalten sieht, füg die Headerzeile ein und schau erneut, sowohl die Auswirkungen als auch die interne Arbeitsweise. Wenn du das Problem nicht lösen kannst, so solltest du nun ein paar neue Beobachtungen gemacht haben, aus denen man vielleicht weitere Schlüsse ziehen kann.
Zum Abschluss noch:
ich muß den php-block aber da [vor dem <!DOCTYPE usw.] stehen haben, sonst bekomme ich einen "headers already sent"-error...
Beschäftige dich mal mit dem Thema EVA-Prinzip und der Aufteilung des Codes in Dateneingabe, -verarbeitung und -ausgabe. Dann sollte es dich auch nicht mehr wundern, wenn PHP-Blöcke vor dem HTML rumstehen.
Lo!