Post reply

Reply to the message by Auge

Name:

E-mail: (optional, won't be displayed directly)

Leave this field empty:

Homepage: (optional)

Leave this field empty:

Location: (optional)

Remember me (cookie)

Category:

Subject:

Formatting help

skip to input

format text bold: [b]bold text[/b]
format text italic: [i]italic text[/i]
insert hyperlink: [link=http://example.com/]link text[/link] / [link]http://example.com/[/link]
set text color: [color=#rgb]colored text[/color]
font size: [size=small]small text[/size]; [size=large]large text[/size]
insert list: [list][*]list item[/list]
insert image: [img]http://example.com/image.jpg[/img]; left: [img=left]http://example.com/image.jpg[/img]; right: [img=right]http://example.com/image.jpg[/img]; thumbnail: [img=thumbnail]http://example.com/image.jpg[/img]; thumbnail left: [img=thumbnail-left]http://example.com/image.jpg[/img]; thumbnail right: [img=thumbnail-right]http://example.com/image.jpg[/img]
upload image: upload image ...
insert TeX code: [tex]TeX code[/tex]
insert code: [inlinecode]code[/inlinecode]; [code]code[/code]; [code=css]code[/code]; [code=html]code[/code]; [code=javascript]code[/code]; [code=perl]code[/code]; [code=php]code[/code]; [code=sql]code[/code]; [code=xml]code[/code]

:-)
;-)
:-P
:-D
:-|
:-(
:yes:
:no:
:ok:
:lol:
:lol2:
:lol3:
:cool:
:surprised:
:angry:
:crying:
:waving:
:confused:
:lookaround:
:clap:
:love:
:tick:

Message:

> 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 "[link=https://d-mueller.de/blog/htmlspecialchars-richtig-nutzen-fallstricke/]htmlspecialchars richtig nutzen – Fallstricke[/link]" (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 [link=https://github.com/auge8472/My-Little-Forum-1/blob/v1.7.7.1/functions.php#L418]Gestern ich[/link] eingebaut. Und, um das klarzustellen, statt [inlinecode]ENT_COMPAT[/inlinecode] das weitergehende [inlinecode]ENT_QUOTES[/inlinecode] zu verwenden, ist nicht falsch. Falsch ist das dort vorgestellte Szenario, mit [inlinecode]htmlspecialchars[/inlinecode] inklusive [inlinecode]ENT_QUOTES[/inlinecode] 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 [inlinecode]mysql_real_escape_string[/inlinecode] 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 [i]für die Übergabe an die Datenbank[/i] im Query mit einem Backslash maskiert ([inlinecode]\'[/inlinecode]). Ein Backslash selbst wird wiederum selbst mit einem Backslash maskiert. Andere relevante Zeichen werden ebenfalls so behandelt. Das macht die Funktion [inlinecode]mysql_real_escape_string[/inlinecode]. Die zusätzliche unnötige Doppelung, die besonders bei Zitaten auftritt, stammt aus der fehlerhaften Behandlung der Eingaben beim erstellen von Postings.
> 
> Das alles [i]hat aber [b]nichts[/b] mit unserem Problem zu tun[/i].
> 
> Die Funktion [inlinecode]htmlspecialchars[/inlinecode] ist für die Maskierung von für HTML relevanten Zeichen in einer HTML-[i]Ausgabe[/i] zuständig. Sie maskiert, wie ich schon einmal auflistete, die Zeichen [inlinecode]<[/inlinecode] (wird zu [inlinecode]&lt;[/inlinecode]), [inlinecode]>[/inlinecode] (wird zu [inlinecode]&gt;[/inlinecode]), [inlinecode]&[/inlinecode] (wird zu [inlinecode]&amp;[/inlinecode]), [inlinecode]"[/inlinecode] (wird zu [inlinecode]&quot;[/inlinecode]) und, wenn es aktiviert ist, das einfache Anführungszeichen/Hochkomma [inlinecode]'[/inlinecode] (wird in HTML 4 und XHTML 1 zu [inlinecode]&#039;[/inlinecode] und in HTML5 zu [inlinecode]&apos;[/inlinecode]). 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: [inlinecode]htmlspecialchars($string, ENT_QUOTES | ENT_XHTML, 'ISO-8859-1');[/inlinecode]. Statt 'ISO-8859-1' kann man auch, wie ich es gemacht habe, [inlinecode]$lang['charset'][/inlinecode] einsetzen, nachdem man [inlinecode]global $lang;[/inlinecode] 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 [b]dahinter[/b] 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

E-mail notification on reply of this posting