Hallo

Nur, um das klarzustellen. Das in dem Blogbeitrag skizzierte Fehlerszenario ist Bullshit!

da dachte ich nun (für mich): Ein blindes Huhn findet auch mal ein Korn ; -)

Wenn du nicht selbst programmierst, musst du dich natürlich auf Aussagen anderer verlassen. Dir bleibt ja nichts anderes übrig. Von daher ist es kein Problem, dass du diese Quelle nanntest.

Die Lösung aus dem Blogbeitrag entschärft zwar das einfache Anführungszeichen/Hochkomma, andere für MySQL relevante Zeichen aber nicht.

Hm, ich hatte mich in dem kritisierten Blogbeitrag "htmlspecialchars richtig nutzen – Fallstricke" (bei meiner ersten Linkangabe war leider das Komma mit reingerutscht) auf den hinteren Abschnitt "Encoding" gestürzt, der ja der vermeintlichen oder tatsächlichen Reparatur "unseres Problems" durch Sebastian & Co. am nahesten kam.

Die Wrapper-Funktion an sich passt schon. Die hat Sebastian so ähnlich wie du und auch Gestern ich eingebaut. Und, um das klarzustellen, statt ENT_COMPAT das weitergehende ENT_QUOTES zu verwenden, ist nicht falsch. Falsch ist das dort vorgestellte Szenario, mit htmlspecialchars inklusive ENT_QUOTES MySQL-Eingaben mit Anführungszeichen jeglicher Couleur maskieren zu wollen.

Verwirrend ist das der Aussage des Rests des Blogbeitrags widersprechende Ende. Dort wird nämlich korrekterweise doch auf mysql_real_escape_string und seine Geschwister verwiesen.

Ich muß noch einmal darauf zurück kommen. Unter "Encoding" (wie allerdings auch im davorliegenden Abschnitt "Das verflixte Hochkomma") wird die Verwendung von ENT_QUOTES statt ENT_COMPAT empfohlen. Das habe ich ja auch so umgesetzt - in der Annahme, die (vielleicht nur wenig) bessere Variante zu benutzen.

Falsch ist das, wie gesagt, nicht.

Rein äußerlich scheint auch alles ok. Wenn ich allerdings phpMyAdmin benutze oder in den SQLDump gucke, sieht die Sache schon sehr verschieden aus.

Ja, das ist ein generelles Leiden von MLF1 bis inklusive 1.7.7.

Ich vergleiche mal den Inhalt bei Einträgen _vor_ und _nach_ meinem Reparaturversuch.

Du vermischst hier mehrere Baustellen. Dein "Reparaturversuch" setzt richtigerweise bei der Generierung der HTML-Ausgabe an. Zu diesem Zeitpunkt hat das Skript die Daten bereits aus der Datenbank abgefragt. Alles, was mit SQL zu tun hat, ist schon geschehen und vorbei.

Textbeispiel: 'Hochkomma' "Anführung"

- phpMyAdmin
vorher: \'Hochkomma\' \"Anführung\"
nachher: 'Hochkomma' "Anführung"

Korrekt. Wobei das Leiden von MLF1 dafür sorgt, dass die Daten tatsächlich mit den Backslashes in der Datenbank liegen. Davon siehst du in phpMyAdmin nur nichts.

- SQLDump
vorher: \\\'Hochkomma\\\' \\\"Anführung\\\"
nachher: \'Hochkomma\' \"Anführung\"

Da werden wohl ggf. die Backslashes mitcodiert.

Ja. Ein Anführungszeichen – nehmen wir mal das einfache – wird für die Übergabe an die Datenbank im Query mit einem Backslash maskiert (\'). Ein Backslash selbst wird wiederum selbst mit einem Backslash maskiert. Andere relevante Zeichen werden ebenfalls so behandelt. Das macht die Funktion mysql_real_escape_string. Die zusätzliche unnötige Doppelung, die besonders bei Zitaten auftritt, stammt aus der fehlerhaften Behandlung der Eingaben beim erstellen von Postings.

Das alles hat aber nichts mit unserem Problem zu tun.

Die Funktion htmlspecialchars ist für die Maskierung von für HTML relevanten Zeichen in einer HTML-Ausgabe zuständig. Sie maskiert, wie ich schon einmal auflistete, die Zeichen < (wird zu <), > (wird zu >), & (wird zu &), " (wird zu ") und, wenn es aktiviert ist, das einfache Anführungszeichen/Hochkomma ' (wird in HTML 4 und XHTML 1 zu ' und in HTML5 zu '). Für den letzten Fall muss natürlich auch die HTML-Version angegeben werden. Wir nutzen in MLF1 noch XHTML1. Der Funktionsaufruf muss also vollständig so lauten: htmlspecialchars($string, ENT_QUOTES | ENT_XHTML, 'ISO-8859-1');. Statt 'ISO-8859-1' kann man auch, wie ich es gemacht habe, $lang['charset'] einsetzen, nachdem man global $lang; in der ersten Zeile der Funktion notiert hat.

Welche Variante ist/wäre denn nun "richtig"? Doch ENT_COMPAT?

Behalte dein ENT_QUOTES. Das hat, wie ich hoffentlich verständlich ausführte, mit deiner Beobachtung nichts zu tun. Das dahinter liegende Problem muss gesondert gelöst werden. Dafür bräuchte ich deine und, falls er noch da ist, auch Sebastians Hilfe bei Tests.

Tschö, Auge