Türkisch in DB speichern

[dedlfix]

Tach!

Davon ganz unabhängig solltest du Texte meiner Meinung nach besser erst dann mit htmlspecialchars() sichern, wenn es wirklich nötig ist - nämlich direkt bei der Ausgabe. Der Datenbank tut HTML nicht weh
Oh doch.
Nein. Dass MySQL wegen HTML in irgendeinem Feld sich verselbständigt hätte oder gar explodiert wäre, ist mir jedenfalls noch nicht untergekommen.

Explodieren wird es nicht, aber es kann wie gesagt zu Datenverlust und anderen "seltsamen" Folgefehlern kommen.

Zum anderen lässt sich mit einer Ersatzschreibweise keine gescheite Stringverarbeitung (inklusive Sortierung) mehr betreiben. Hühner werden beispielsweise vor Hasen einsortiert, weil &...; kleiner als a ist.
Da hast du zwar eine richtige Schlussfolgerung gezogen, aber als Antwort auf meine lang und breit ausgeführte Empfehlung ist sie völlig belanglos.
Wenn er die Texte erst, siehe Zitat oben, "bei der Ausgabe" durch htmlspecialchars() jagt, nicht schon nach der Eingabe, kommt logischerweise auch kein Hühnchen in die Datenbank.

Du gehst davon aus, dass die verwendete Funktion der Übeltäter wäre und deine Empfehlung das Problem löst. Das ist aber nach meinem Dafürhalten nicht der Fall. Die Empfehlung löst nur ein nebensächliches Problem, aber nicht das eigentliche des OP. Da das nebensächliche Problem durch die fehlerhafte Anwendung von htmlspecialchars() ebenfalls negativen Einfluss auf die Datenhaltung hat, was du jedoch verneintest, habe ich hier zum Widerspruch angesetzt.

Zum einen verbrauchen die NCRs (oder andere Ersatzschreibweisen üblicherweise) mehr Zeichen als das originale korrekt kodierte.
Dabei kann beim Speichern in Feldern mit begrenzter Zeichenanzahl ein Verlust auftreten.
Das erscheint mir nun, mit Verlaub, etwas albern. Wer wegen der Kodierung einiger Zeichen Datenverlust erleidet, der hat ein ganz anderes Problem als die Kodierung: Die zu knapp bemessenen Felder.

Nö. Wenn vorgesehen ist, dass ein bestimmter Wert maximal x Zeichen hat, muss ich das Feld nicht auf n*x Zeichen dimensionieren, nur damit alle fehlerhaft verwendeten Ersatzschreibweisen Platz darin haben. Ich fände es albern, das Feld nur wegen nicht erkannter Programmierfehler aufzubohren.

Aber, ich schreib's zum dritten Male, wenn's nach mir geht, sollen die Texte ja gar nicht HTML-kodiert in der Datenbank landen.

Richtig, das ist auch mein Anliegen. Das Weglassen von htmlspecialchars() trägt jedoch nur einen kleinen Beitrag bei (der in der Beschreibung des OP aber gar nicht relevant geworden ist - was aber mit anderen Daten noch werden kann).

dedlfix.