PHP: Hochkomma für MySQL/MariaDB maskieren?

[Yadgar]

Hi(gh)!

PHP (Version 7.4.5) schmeißt mir beim Versuch, eine Abfrage abzuschicken, die den String "Gene Roddenberry's Andromeda" enthält, eine Fehlermeldung:

"Die Abfrage kann nicht ausgeführt werden. Fehler: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 's Andromeda'' at line 1"

Ich vermute, dass es an dem Hochkomma liegt... leider ändert sich auch bei Verwendung von mysqli_real_escape_string() nichts! Was mache ich falsch?

Bis bald im Khyberspace!

Yadgar

[Der Martin]

Hallo,

PHP (Version 7.4.5) schmeißt mir beim Versuch, eine Abfrage abzuschicken, die den String "Gene Roddenberry's Andromeda" enthält, eine Fehlermeldung:

"Die Abfrage kann nicht ausgeführt werden.
Fehler: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 's Andromeda'' at line 1"

Ich vermute, dass es an dem Hochkomma liegt... leider ändert sich auch bei Verwendung von mysqli_real_escape_string() nichts! Was mache ich falsch?

du lässt uns nicht wissen, wie dein SQL-Query genau aussieht, und wo oder wie du mysqli_real_escape_string() anwendest. So kann man nur im Nebel stochen. Und ich sehe ganz diffus im Nebel, dass du mysqli_real_escape_string() auf den gesamten Query-String anwendest, anstatt nur auf die darin enthaltenen Daten-Strings.

Das ist aber wirklich nur eine diffuse Vermutung, denn bei richtiger Verwendung von mysqli_real_escape_string() sollte gerade so etwas, was du beschreibst, nicht passieren.

Live long and pros healthy,
 Martin

[Yadgar]

Hallo,

du lässt uns nicht wissen, wie dein SQL-Query genau aussieht, und wo oder wie du mysqli_real_escape_string() anwendest. So kann man nur im Nebel stochen. Und ich sehe ganz diffus im Nebel, dass du mysqli_real_escape_string() auf den gesamten Query-String anwendest, anstatt nur auf die darin enthaltenen Daten-Strings.

Das ist aber wirklich nur eine diffuse Vermutung, denn bei richtiger Verwendung von mysqli_real_escape_string() sollte gerade so etwas, was du beschreibst, nicht passieren.

Der Code:

  $stichwort = $_POST["stichwort"];
  $stichwort = mysqli_real_escape_string($db, $stichwort);
  $kategorie = $_POST["kategorie"];
  $kategorie = mysqli_real_escape_string($db, $kategorie);
  
  $sql1 = "SELECT nr, stichwort FROM STICHWOERTER WHERE stichwort = '".$_POST['stichwort']."'";

Mir wurde dabei natürlich klar, dass mysqli_real_escape_string() nur funktionieren kann, wenn ich statt $_POST['stichwort'] $stichwort verwende... und damit handelte ich mir gleich den nächsten Error ein:

Fehler: Incorrect integer value: '' for column tagebuch_stichwoerter.STICHWORT_KATEGORIE.stichwoerter_nr at row 1

Ich glaube, ab einem bestimmten Alter sollte man das Programmieren bleiben lassen...

Bis bald,

Yadgar

[Auge]

Hallo

Der Code:

  $stichwort = $_POST["stichwort"];
  $stichwort = mysqli_real_escape_string($db, $stichwort);
  $kategorie = $_POST["kategorie"];
  $kategorie = mysqli_real_escape_string($db, $kategorie);
  
  $sql1 = "SELECT nr, stichwort FROM STICHWOERTER WHERE stichwort = '".$_POST['stichwort']."'";

Mir wurde dabei natürlich klar, dass mysqli_real_escape_string() nur funktionieren kann, wenn ich statt $_POST['stichwort'] $stichwort verwende...

Dass du den unbehandelten POST-Wert statt des behandelten Werts in $stichwort benutzt hast, ist dir ja nun klar geworden. Mit …

$sql1 = "SELECT
 nr,
 stichwort
FROM STICHWOERTER
WHERE stichwort = '". mysqli_real_escape_string($db, $_POST['stichwort']) ."'";

… wäre das nicht passiert. Das ist natürlich nur dann sinnvoll, wenn du mit $stichwort nicht noch andere Dinge tust, die du hier nicht zeigst.

und damit handelte ich mir gleich den nächsten Error ein:

Fehler: Incorrect integer value: '' for column tagebuch_stichwoerter.STICHWORT_KATEGORIE.stichwoerter_nr at row 1

Das ist aber eine gänzlich andere Abfrage, oder? Und ja, ein Leerstring ist keine gültige Integer-Zahl.

Tschö, Auge

[Felix Riesterer]

Lieber Yadgar,

  $stichwort = $_POST["stichwort"];
  $stichwort = mysqli_real_escape_string($db, $stichwort);
  $kategorie = $_POST["kategorie"];
  $kategorie = mysqli_real_escape_string($db, $kategorie);

das sind Beispiele aus der Hölle. Das willst Du später so nicht mehr haben. Die Variable $stichwort ist ein String, dem man nicht ansieht, woher sein Wert kommt und wie er für welche Zwecke behandelt worden ist. Besser so:

$sql = 'SELECT * FROM ...';
$params = [
  'search' => mysqli_escape_string($_POST['stichwort'])
];

$db->get($sql, $params);

So sieht man, dass da ein POST-Wert konkret für DB-Anfragen vorbehandelt wird. Der Inhalt in $_POST ist prinzipiell nicht vertrauenswürdig, das sieht man dem Variablennamen schon an. Das sieht man einer Variable $stichwort nicht an. Man sieht ihr auch nicht an, dass da (vielleicht oder auch nicht) mysqli_escape_string() drübergefahren ist.

Ich glaube, ab einem bestimmten Alter sollte man das Programmieren bleiben lassen...

Man darf auch im hohen Alter noch dazu lernen. Und Dein Alter sollte so hoch nun doch noch nicht sein. ;-)

Liebe Grüße

Felix Riesterer

[Rolf B]

Hallo Felix,

ich habe den Finger zweimal auf dem + gehabt, und zweimal auf dem -, am Ende also Neutral.

Plus: Eine saubere Trennung von Parametrierung und DB-Zugriff ist prima.

Plus: Du forderst Yadgar auf, sich mit Neuem zu befassen

Minus: Du gehst nicht auf die Umsetzung ein. Dein SQL Statement macht an der entscheidenden Stelle ein ... - wie wird params["search"] ins SQL eingebaut?

Minus: Du schlägst eine get-Methode vor, die es weder in MYSQLi noch in PDO gibt. Oder sie in in php.net nicht dokumentiert.

Dein Einwand, dass $stichwort eine mehrdeutige Semantik hat, ist je nach Kontext richtig oder falsch. In einer Riesenfunktion, die alles mögliche tut, hast Du recht. In einer Funktion, die genau diese Abfrage durchführt und weiter nichts, kann man das machen.

---

mysqli hat eine query-Methode, um SQL direkt auszuführen. Dann muss man aber die variablen Teile direkt ins SQL einsetzen und natürlich auch von Hand maskieren. Gleiches gilt für die query-Methode in PDO.

Eine eigengeschriebene get-Methode auf einem Objekt, dass mysqli kapselt oder davon abgeleitet ist, ist machbar. Sie müsste dann die benannten Parameter ins SQL Statement einsetzen. Das SQL muss dafür benannte Parametermarker enthalten.

Dann sollte man das aber nicht so machen, dass der Aufrufer die Maskierung durchführt. Statt dessen sollte die $param-Struktur den unmaskierten Wert und einen Wertetyp enthalten, und die get-Methode kümmert sich um Maskierung und das Einsetzen der Werte.

Es ist aber wenig sinnvoll, sowas selbst zu bauen. Dafür gibt's PDO, da ist das alles schon fertig vorhanden, wenn man prepared statements nutzt (die natürlich den Nachteil eines doppelten DB-Roundtrip haben). Allerdings wird auch da zwischen prepare und execute getrennt. Benannte Parameter in einem Rutsch in benannte SQL Platzhalter einzusetzen geht auch da nicht.

Rolf

[Raketenwilli]

Ich glaube, ab einem bestimmten Alter sollte man das Programmieren bleiben lassen...

Oder man sollte es öfters tun. Als Workout für die eigenen Logikbausteine. Denn Haupttodesursache für graue Zellen sind Alkohol und Langeweile. (Manche behaupten auch: „Verbeamtung“. Ich halte das aber nicht für zwingend.)

[Raketenbeispielgeber]

Das ist aber wirklich nur eine diffuse Vermutung, denn bei richtiger Verwendung von mysqli_real_escape_string() sollte gerade so etwas, was du beschreibst, nicht passieren.

Ein Beispiel sagt mehr als tausend Worte: (Ich hoffe, ich hab nichts falsch gemacht...)

Man hat:

$_GET['search'] = "Gene Roddenberry's Andromeda";
$mysqli = mysqli_connect( ... );

Man will:

SELECT
   title, isbn, author, price
FROM books
WHERE title SOUNDS LIKE 'Gene Roddenberry\'s Andromeda'

Man nehme also:

$sql = sprintf(
    "SELECT 
        `title`,
        `isbn`,
        `author`,
        `price`
     FROM `books`
     WHERE `title` SOUNDS LIKE '%s'",
     $mysqli->real_escape_string( $_GET['search' )
);
$result = $mysqli->query( $sql );

$tdata = '';
while ( $row = $result->fetch_assoc() ) {
    $tdata .= sprintf (
       "\t<tr><td>%s</td><td>%s</td><td>%s<td></td>€ %01.2f<td></tr>\n",
       htmlspecialchars( $row['title'] ),
       htmlspecialchars( $row['isbn'] ),
       htmlspecialchars( $row['author'] ),
       100 * $row['price'];
    );    
}

Oder:

$stmt = $mysqli->prepare(
    "SELECT
        `title` 
        `isbn`,
        `author`,
        `price`
     FROM `books`
     WHERE `title` SOUNDS LIKE ?"
);
$stmt->bind_param( "s", $_GET['search'] );
$stmt->execute();
$stmt->bind_result( $title, $isbn, $author, $price );

$tdata = '';
while ( $stmt->fetch() ) {
    $tdata .= sprintf (
       "\t<tr><td>%s</td><td>%s</td><td>%s<td></td>€ %01.2f<td></tr>\n",
       htmlspecialchars( $title ),
       htmlspecialchars( $isbn ),
       htmlspecialchars( $author ),
       100 * $price;
    );
}

Edit Rolf B: htmlspecialchars, nicht htmlspezialchars

[Yadgar]

Das ist aber wirklich nur eine diffuse Vermutung, denn bei richtiger Verwendung von mysqli_real_escape_string() sollte gerade so etwas, was du beschreibst, nicht passieren.

Ein Beispiel sagt mehr als tausend Worte: (Ich hoffe, ich hab nichts falsch gemacht...)

Man hat:

$_GET['search'] = "Gene Roddenberry's Andromeda";
$mysqli = mysqli_connect( ... );

Man will:

SELECT
   title, isbn, author, price
FROM books
WHERE title SOUNDS LIKE 'Gene Roddenberry\'s Andromeda'

Man nehme also:

$sql = sprintf(
    "SELECT 
        `title`,
        `isbn`,
        `author`,
        `price`
     FROM `books`
     WHERE `title` SOUNDS LIKE '%s'",
     $mysqli->real_escape_string( $_GET['search' )
);
$result = $mysqli->query( $sql );

$tdata = '';
while ( $row = $result->fetch_assoc() ) {
    $tdata .= sprintf (
       "\t<tr><td>%s</td><td>%s</td><td>%s<td></td>€ %01.2f<td></tr>\n",
       htmlspecialchars( $row['title'] ),
       htmlspecialchars( $row['isbn'] ),
       htmlspecialchars( $row['author'] ),
       100 * $row['price'];
    );    
}

Oder:

$stmt = $mysqli->prepare(
    "SELECT
        `title` 
        `isbn`,
        `author`,
        `price`
     FROM `books`
     WHERE `title` SOUNDS LIKE ?"
);
$stmt->bind_param( "s", $_GET['search'] );
$stmt->execute();
$stmt->bind_result( $title, $isbn, $author, $price );

$tdata = '';
while ( $stmt->fetch() ) {
    $tdata .= sprintf (
       "\t<tr><td>%s</td><td>%s</td><td>%s<td></td>€ %01.2f<td></tr>\n",
       htmlspecialchars( $title ),
       htmlspecialchars( $isbn ),
       htmlspecialchars( $author ),
       100 * $price;
    );
}

Verstehe ich nicht, bin ich zu dumm für!

Edit Rolf B: Zitierten Tippfehler korrigiert

[Raketenwilli]

Verstehe ich nicht, bin ich zu dumm für!

Und welche Ausrede hast Du dafür, das nicht als Humor zu „taggen“?

[Yadgar]

Hi(gh)!

Verstehe ich nicht, bin ich zu dumm für!

Und welche Ausrede hast Du dafür, das nicht als Humor zu „taggen“?

Ich habe halt wirklich kaum Ahnung vom Programmieren, weil ich es viel zu selten tue und einfach nicht dran bleibe... der größte Teil meiner Zeit geht für Schlafen, Essen, Kacken, Zocken (Satisfactory, Valheim) und konfus im Netz rumsurfen drauf, ich schaffe es ja nicht einmal, mein Zimmer (für eine richtige Wohnung hat es auch nie gereicht) in Ordnung zu halten...

Aber es muss auch Loser geben, da sich andernfalls die Winner nicht allzuviel auf ihr Supererfolgsleben einbilden könnten...

Und auf den ganzen Programmier-Trip bin ich ja nur gekommen, weil ich EIGENTLICH gar kein Computerfreak werden, sondern als langhaariger bärtiger Aussteiger mit dem Fahrrad nach Afghanistan fahren wollte (und dann weiter nach Indien, mit allem, was zu so einem Hippie-Ausflipp dazugehört)... Afghanistan ist aber leider seit über 40 Jahren unbereisbar und wird auch unbereisbar bleiben, also muss ich mir mein eigenes Afghanistan hier in meinem Wohnklo schaffen - das geht nur mittels Computer, was wiederum Programmieren erfordert.

Zu langen Haaren und Bart hat es gereicht, ansonsten habe ich allerdings seit meinem Abitur (1989) nichts mehr auf die Reihe bekommen...

Bis bald im Khyberspace!

Yadgar

[Raketenwilli]

Verstehe ich nicht, bin ich zu dumm für!

Und welche Ausrede hast Du dafür, das nicht als Humor zu „taggen“?

Zu langen Haaren und Bart hat es gereicht, ansonsten habe ich allerdings seit meinem Abitur (1989) nichts mehr auf die Reihe bekommen...

Ersetze einfach das „ich zu dumm für“ durch „muss mich halt mehr anstrengen als die Überflieger“.

Ich habe mein Abitur 1985 gemacht - mit 3 Jahren Verspätung weil die „Kommunisten“ meinten, dass ich dazu erst mal der Arbeiterklasse(*) angehören muss. Also bist Du deutlich jünger als ich: Dann mach's wie ich: Streng Dich mal brav an.

*) dazu gehörte man z.B. mit einem Facharbeiterbrief und einjähriger Tätigkeit als „Maschinen- und Anlagenmonteur“ oder mit den richtigen Vorfahren als Mitglied der Nomenklatur.

[Raketendanksager]

Edit Rolf B: htmlspecialchars, nicht htmlspezialchars

THX!

[Gunnar Bittersmann]

@@Yadgar

Ich vermute, dass es an dem Hochkomma liegt... leider ändert sich auch bei Verwendung von mysqli_real_escape_string() nichts! Was mache ich falsch?

Du verwendest ' U+0027 anstelle eines Apostrophs ’ U+2019.

Bei richtiger Zeichensetzung („Gene Roddenberry’s Andromeda“) können solche Probleme gar nicht auftreten.

Wenn Inhalte nicht nur von dir kommen, sondern auch von anderen (die sowas wie ' oder " verwenden), müssen die Zeichen natürlich dem Kontext entsprechend behandelt werden.

😷 LLAP

[An die Zukunft denken ...]

Wenn Inhalte nicht nur von dir kommen, sondern auch von anderen (die sowas wie ' oder " verwenden), müssen die Zeichen natürlich dem Kontext entsprechend behandelt werden.

Wenn man nicht vollständig ausschließen kann, dass der geschriebene Code in irgendeiner fernen Zukunft mit Strings gefüttert wird, die nicht vom Programmierer selbst stammen und wenn man nicht vollständig ausschließen kann, dass man selbst an einer Stelle "1000 Zeilen über der Abfrage" oder gar in einer anderen Datei dann Strings notiert, die plötzlich einer Behandlung bedürfen, sollte stets man alle Variablen in SQL-Statements „behandeln“.

Also fast immer.

[Gunnar Bittersmann]

@@An die Zukunft denken ...

Also fast immer.

Nicht fast, sondern immer. 😉

Der Kontextwechsel ist immer zu beachten. Zeichen, die in einem bestimmten Kontext eine Sonderfunktion haben, sind immer diesem Kontext entsprechend zu behandeln.

Meine Formulierung war da nicht korrekt.

Dass im Text weder ' noch " vorkommen sollte, hat natürlich nicht den Grund, sich die kontextgerechte Behandlung dieser Zeichen zu sparen.

😷 LLAP

[Yadgar]

Hi(gh)!

Ich habe es jetzt mit htmlspecialchars() probiert... aber htmlspecialchars("Gene Roddenberry's Andromeda") ergibt nach wie vor "Gene Roddenberry's Andromeda" (und damit weiterhin den MySQL-Error) und nicht etwa "Gene Roddenberry's Andromeda", wie es laut https://www.php.net/manual/de/function.htmlspecialchars.php sein müsste (und wie auch in phpmymyadmin der entsprechende Eintrag in der Tabelle STICHWOERTER angezeigt wird)!

Warum bekomme ich das nicht hin? Ist eventuell die Maskierung von HTML Special Characters auf meinem lokalen Server nicht aktiviert? Wo in phpinfo() kann ich das nachsehen?

Bis bald im Khyberspace!

Yadgar

[MudGuard]

Hi,

Ich habe es jetzt mit htmlspecialchars() probiert...

htmlspecialchars gehört da nicht hin, Du erzeugst ja grade nicht eine HTML-Ausgabe, sondern eine Datenbank-Query.

aber htmlspecialchars("Gene Roddenberry's Andromeda") ergibt nach wie vor "Gene Roddenberry's Andromeda" (und damit weiterhin den MySQL-Error)

Klar, ' ist kein Html-Special-Char.

und nicht etwa "Gene Roddenberry's Andromeda", wie es laut https://www.php.net/manual/de/function.htmlspecialchars.php sein müsste

aber nur wenn ENT_QUOTES gesetzt ist

Nachzulesen unter Deinem Link.

(und wie auch in phpmymyadmin der entsprechende Eintrag in der Tabelle STICHWOERTER angezeigt wird)!

Oh, dann ist schon beim Import der Daten in die Datenbank was schiefgelaufen - was soll eine HTML-Maskierung in der Datenbank?

cu,
Andreas a/k/a MudGuard

[Yadgar]

Hi(gh)!

htmlspecialchars gehört da nicht hin, Du erzeugst ja grade nicht eine HTML-Ausgabe, sondern eine Datenbank-Query.

Wenn in der Datenbank selbst der Eintrag auch schon entsprechend maskiert wurde, gehört es da schon hin!

aber nur wenn ENT_QUOTES gesetzt ist

Nachzulesen unter Deinem Link.

Habe ich gemacht, jetzt funktioniert es... danke für den Hinweis!

Oh, dann ist schon beim Import der Daten in die Datenbank was schiefgelaufen - was soll eine HTML-Maskierung in der Datenbank?

Die Daten wurden nicht importiert, sondern von Hand eingegeben (und zwar nicht via phpmyadmin, sondern mittels eines ebenfalls selbst programmierten PHP-Skripts!)…

Bis bald im Khyberspace!

Yadgar

[Auge]

Hallo

Hi(gh)!

htmlspecialchars gehört da nicht hin, Du erzeugst ja grade nicht eine HTML-Ausgabe, sondern eine Datenbank-Query.

Wenn in der Datenbank selbst der Eintrag auch schon entsprechend maskiert wurde, gehört es da schon hin!

Es gehört dort definitiv nicht hin. Eine Maskierung für den HTML-Kontext gehört in den HTML-Kontext und nicht in die Datenbank. Was ist, wenn du mit den Inhalten aus der Datenbank einstmals ein PDF erzeugen willst? Prökelst du dir dann die Maskierungen wieder heraus?

Oh, dann ist schon beim Import der Daten in die Datenbank was schiefgelaufen - was soll eine HTML-Maskierung in der Datenbank?

Die Daten wurden nicht importiert, sondern von Hand eingegeben (und zwar nicht via phpmyadmin, sondern mittels eines ebenfalls selbst programmierten PHP-Skripts!)…

… und genau dabei es ist doch schiefgelaufen.

Tschö, Auge

[Raketenzustimmungsbeauftragter]

Es gehört dort definitiv nicht hin. Eine Maskierung für den HTML-Kontext gehört in den HTML-Kontext und nicht in die Datenbank.

Jepp! In die Datenbank gehören Rohdaten. Daran Herumfummeln kann man bei Abfragen oder - nur wenn nötig - mit zusätzlichen, speziell erzeugten und indizierten Suchspalten.

[Raketenbeispielgeber]

wenn, dann wohl etwas wie:

$string = htmlspecialchars( 
    'Gene Roddenberry\'s Andromeda',
    ENT_QUOTES | ENT_HTML5,
    'UTF-8'
);
echo $string . PHP_EOL;

Gene Roddenberry's Andromeda

Aber das löst Dein Problem nicht; Du willst das der Datenbank übergeben und nicht im HTML-Kontext ausgeben.

[Raketenbeispielgeber]

Ach so. In der Datenbank steht schon "Mist".

$string = htmlspecialchars( 
    'Gene Roddenberry\'s Andromeda',
    ENT_QUOTES | ENT_HTML401,
    'UTF-8'
);
echo $string . PHP_EOL;

Gene Roddenberry's Andromeda

[Rolf B]

Hallo Yadgar, hallo Raketen.*,

bis PHP 8.0 ist der Defaultwert für den flags-Parameter von htmlspecialchars ENT_COMPAT, d.h. einfache Anführungszeichen werden nicht umgesetzt. Das ändert sich mit PHP 8.1, da wechselt der Default auf ENT_QUOTES|ENT_SUBSTITUTE, ein breaking change, der meines Erachtens etliche Webseiten abschießen könnte. Immerhin ist es hier aufgeschrieben.

Deswegen sollte man die Funktion definitiv nicht ohne Flags aufrufen, sondern

htmlspecialchars($data, ENT_QUOTES | ENT_HTML5)

verwenden. Dann entsteht aus dem Hochkomma ' und nicht das nichtssagende '. Man könnte auch noch das in PHP 8.1 hinzu kommende ENT_SUBSTITUTE hinzufügen.

Für Yadgar ist aber auch wichtig, dass die htmlspecialchars-Maskierung nicht vor dem Schreiben in die DB erfolgen darf. In die Datenbank gehört das ' (besser natürlich das typographisch richtige Zeichen ’, das aber nur ausgewählte Benutzer überhaupt eingeben können) und keine HTML-Codierung dieses Zeichens. Die HTML Codierung gehört ausschließlich vor die HTML Ausgabe und nirgendwo anders hin.

Und um Probleme mit der Schreibweise auszuschließen, muss man dafür sorgen, dass Interpunktion möglichst von Suchvorgängen ausgenommen wird. Ob der SOUNDS LIKE Operator dafür genügt, weiß ich nicht.

Rolf

[Raktentestpilot]

Eigentlich war das nur ein Syntaxbeispiel… Aber wenn wir schon dabei sind.

MariaDB [(none)]> select if (
    -> 'Gene Roddenberry\'s Andromeda'
    -> sounds like
    -> 'Gene Roddenberrys Andromeda',
    -> 'Ja',
    -> 'Nein'
    -> ) as Antwort;
+---------+
| Antwort |
+---------+
| Ja      |
+---------+
1 row in set (0.000 sec)

• Dito mit ''s' statt '''.
• Nein mit ''' statt '''.
• „visa versa“ mit jeweilig gleichem Ergebnis.

[Gunnar Bittersmann]

@@Rolf B

(besser natürlich das typographisch richtige Zeichen ’, das aber nur ausgewählte Benutzer überhaupt eingeben können)

Bei „smarten“ Systemen sind alle Nutzer auserwählt: ' wird automatisch in ’ (bzw. ‚ (kein Komma!) oder ‘) umgewandelt; " in „/“/”.^[1]

Die HTML Codierung gehört ausschließlich vor die HTML Ausgabe und nirgendwo anders hin.

Gehört sie? " und ' müssen in HTML als Elementinhalt nicht escapet werden, sondern nur in Attributwerten, wo das jeweilige Zeichen als Begrenzungszeichen verwendet wird.

korrekt: <p>Deppenapostroph's</p>

korrekt: <img src="…" alt="Deppenapostroph's"/>

hier muss escapet werden: <img src="…" alt='Deppenapostroph&apos;s'/>

hier auch: <img src="…" alt=Deppenapostroph&apos;s/>

😷 LLAP

---

1. Die Automatik ist nicht immer smart. Besonders nicht, wenn sie smarter als der Nutzer sein will. Slack macht mir aus eingebenen „x“ „x” und lässt mich so aussehen als könnte ich nicht richtig schreiben. (Im Polnischen und Niederländischen wäre ” als schließendes Anführungszeichen richtig; im Deutschen aber nicht.) ↩︎

[Rolf B]

Hallo Gunnar,

" und ' müssen in HTML als Elementinhalt nicht escapet werden, sondern nur in Attributwerten

Ja gut, kontextgerechte Behandlung bedeutet auch, den jeweiligen Kontext korrekt zu identifizieren und die entsprechende Maskierung durchzuführen

$snip = "<img src='$imgsrc' alt='A foo's folly'>";

da merkt man schon beim Schreiben, dass da was falsch ist und würde von Hand ein ' einsetzen müssen (und $imgsrc wurde hoffentlich anderweit vorbehandelt). Bei

$snip = "<img src='$img->url' alt='$img->altText'>";

fällt das nicht auf, aber da muss man dann eben drauf achten, korrekt zu maskieren:

$snip = sprintf("<img src='%s' alt='%s'>", 
                htmlspecialchars($img->url, ENT_QUOTES | ENT_HTML5),
                htmlspecialchars($img->altText, ENT_QUOTES | ENT_HTML5));

ist dann angesagt.

Das ist der Vorteil von UI Frameworks wie ASP.NET, die kümmern sich da automagisch drum. Dafür haben sie genügend anderen Unfug im Kopf.

Rolf